test plan tutorial guide write software test plan document from scratch
ソフトウェアテスト計画ドキュメントの究極のガイド:
このチュートリアルでは、ソフトウェアテスト計画ドキュメントについてすべて説明し、詳細なソフトウェアテスト計画を最初から作成/作成する方法と一緒にガイドします。 テスト計画とテスト実行の違い。
ライブプロジェクトQAトレーニング3日目 –読者に私たちのライブアプリケーションを紹介した後 無料のオンラインソフトウェアテストトレーニング 、私たちは知るようになりました SRSを確認してテストシナリオを作成する方法 。そして今こそ、ソフトウェアテストのライフサイクルの最も重要な部分を深く掘り下げる適切な時期です。 テスト計画 。
このシリーズのすべてのチュートリアルのリスト:
テスト計画文書:
チュートリアル#1: テスト計画文書の書き方 (このチュートリアル)
チュートリアル#2: 簡単なテスト計画テンプレートの内容
チュートリアル#3: ソフトウェアテスト計画の例
チュートリアル#4: テスト計画とテスト戦略の違い
チュートリアル#5: テスト戦略ドキュメントの書き方
テスト計画のヒント:
チュートリアル#6: テスト計画中のリスク管理
チュートリアル#7: テストする時間が十分にない場合の対処方法
チュートリアル#8: テストプロジェクトを効果的に計画および管理する方法
STLCのさまざまな段階でのテスト計画:
チュートリアル#9: 回帰テストの計画
チュートリアル#10: UATテスト計画
チュートリアル#11: 検収試験計画
テスト自動化計画:
チュートリアル#12: 自動化テスト計画
チュートリアル#13: ERPアプリケーションテスト計画
チュートリアル#14: HPALMテスト計画
チュートリアル#15: マインドマップテスト計画
チュートリアル#16: JMeterテスト計画とWorkBench
学習内容:
テスト計画の作成–テストの最も重要なフェーズ
この有益なチュートリアルでは、テスト計画ドキュメントの作成に関連する方法と手順について説明します。
このチュートリアルの最後に、 19ページの包括的なテスト計画文書 これはライブプロジェクトOrangeHRMのために特別に作成されたもので、この無料で使用しています QAトレーニングシリーズ
テスト計画とは何ですか?
テスト計画は動的なドキュメントです 。テストプロジェクトの成功は、常に最新の適切に作成されたテスト計画ドキュメントに依存します。テスト計画は多かれ少なかれ似ています テスト活動がどのように進んでいるかの青写真 プロジェクトで行われます。
以下に、テスト計画に関するいくつかの指針を示します。
#1) テスト計画は、参照ポイントとして機能するドキュメントであり、そのテストのみに基づいてQAチーム内で実行されます。
#二) また、ビジネスアナリスト、プロジェクトマネージャー、開発チーム、その他のチームと共有するドキュメントでもあります。これは、外部チームに対するQAチームの作業の透明性のレベルを高めるのに役立ちます。
#3) これは、QAチームメンバーからの入力に基づいて、QAマネージャー/ QAリードによって文書化されます。
#4) テスト計画は通常、1/3で割り当てられますrdQAエンゲージメント全体にかかる時間の他の1/3rdはテスト設計用で、残りはテスト実行用です。
#5) このプランは静的ではなく、オンデマンドで更新されます。
#6) 計画がより詳細で包括的であるほど、テスト活動はより成功します。
C ++用のEclipseの設定
STLCプロセス
現在、ライブプロジェクトシリーズの途中です。したがって、アプリケーションから一歩後退して、ソフトウェアテストライフサイクル(STLC)プロセスを見てみましょう。
STLCは、大きく3つの部分に分けることができます。
- テスト計画
- テスト設計
- テストの実行
以前のチュートリアルで、実際のQAプロジェクトでは、SRSレビューとテストシナリオの作成から始めたことがわかりました。これは、実際にはSTLCプロセスの2番目のステップです。テスト設計には、何をテストするか、どのようにテストするかに関する詳細が含まれます。
なぜテスト計画を始めなかったのですか?
計画は確かに、あらゆるテストプロジェクトで発生する最初のそして最も重要な活動です。
SDLCフェーズでのテスト計画
SDLCフェーズ | テスト計画活動 |
---|---|
スケジュール=> | テストシナリオの準備 |
開始する | 理想的には、プロジェクトの範囲がビジネス要件の形で顧客/クライアントから収集されている間、QAチームが関与する必要があります。しかし、現実の世界ではそうではありません。実用的な観点から、QAチームの関与はNILです。このフェーズの終わりに、BRDが完成し、基本的なプロジェクト計画が作成されます。 |
定義する | SRSはBRDから作成されます。テスト計画の最初のドラフトが作成されます。この時点では、QAチームはSRSレビューを完了していないため、テストの範囲は明確ではありません。したがって、このフェーズのTPには、テストがいつ行われるかに関する情報、プロジェクト情報、およびチーム情報(ある場合)のみが含まれます。 |
設計 | SRSレビューが実行され、テストの範囲が特定されます。何をテストするか、および取得する可能性のあるテストケースの数などについて、さらに多くの情報があります。これらすべての情報を組み込んだテスト計画の2番目のバージョンが作成されます。 |
上記の表から、テスト計画は、一度に作成してそれ以降使用できる単なるドキュメントではないことが非常に明確です。
計画文書のコンポーネント
テスト計画テンプレートの項目 | それらには何が含まれていますか? |
---|---|
スコープ=> | 検証されるテストシナリオ/テスト目標。 |
スコープ外=> | カバーしない内容の明確性の向上 |
仮定=> | 私たちが成功するために当てはまる必要があるすべての条件 |
テストドキュメント-テストケース/テストデータ/セットアップ環境 | |
テストの実行 | |
テストサイクル-何サイクル | |
サイクルの開始日と終了日 | |
役割と責任=> | チームメンバーがリストされています |
誰が何をするのか | |
モジュールの所有者とその連絡先情報が一覧表示されます | |
成果物=> | どのドキュメント(テスト成果物)がどの時間枠で作成されますか? |
各ドキュメントから何が期待できますか? | |
環境=> | どのような環境要件がありますか? |
誰が担当しますか? | |
問題が発生した場合はどうすればよいですか? | |
ツール=> | たとえば、バグ追跡用のJIRA |
ログイン | |
JIRAの使い方は? | |
欠陥管理=> | 誰に欠陥を報告しますか? |
どのように報告しますか? | |
何が期待されますか-スクリーンショットを提供しますか? | |
リスクとリスク管理=> | リスクが記載されています |
リスクが分析され、可能性と影響が文書化されます | |
リスク軽減計画が作成されます | |
終了基準=> | いつテストを停止しますか? |
上記のすべての情報が最も重要な情報であるため、 QAプロジェクトの日常業務 、計画書を時々更新しておくことが重要です。
ライブプロジェクトのサンプルテスト計画ドキュメント
サンプルのテスト計画テンプレートドキュメントは、「 ORANGEHRMバージョン3.0–私の情報モジュール」 プロジェクトと以下に添付。ご覧ください。セクションを説明するために、赤のドキュメントにコメントが追加されました。
このテスト計画は、機能フェーズとUATフェーズの両方を対象としています。また、HPALMツールを使用したテスト管理プロセスについても説明します。
テスト計画サンプルのダウンロード:
ドキュメント形式 => テスト計画をドキュメント形式でダウンロードするには、ここをクリックしてください これは、OragngeHRMライブプロジェクト用に作成したものであり、ソフトウェアテストのクラッシュコースにも使用しています。
PDF形式 => テスト計画をPDFファイル形式でダウンロードするには、ここをクリックしてください 。
上記のdoc / pdfバージョンで参照されているワークシート(.xls)ファイル => ダウンロード 参照されるXLSファイル 上記のテスト計画で
上記のテンプレートは非常に包括的で詳細なものです。したがって、最良の結果を得るには、よく読んでください。
計画も作成され、十分に説明されているので、SDLCとSTLCの両方で次のフェーズに進みましょう。
SDLCのコード:
プロジェクトの残りの部分がTDDの作成に時間を費やしている間に、QAはテスト範囲(テストシナリオ)を特定し、最初の信頼できるテスト計画ドラフトを作成しました。 SDLCの次のフェーズは、コーディングがいつ行われるかを確認することです。
このフェーズでは、開発者がチーム全体の主な焦点となります。 QAチームはまた、これまでで最も重要なタスクにふけるだけです。 「テストケースの作成」 。
テストシナリオが「何をテストするか」である場合、テストケースは「テスト方法」を扱います。テストケースの作成は、STLCのテスト設計フェーズの主要な部分です。テストケース作成アクティビティの入力は、テストシナリオとSRSドキュメントです。
私たちのようなテスターにとって、 テストケース 本物です –それは私たちがほとんどの時間を費やしているものです。私たちはそれらを作成し、レビューし、実行し、維持し、自動化します-そして、あなたは全体像をつかむことができます。私たちがどれほど経験を積んでいて、プロジェクトでどのような役割を果たしていても、テストケースを使用します。
テスト計画とテスト実行
ソフトウェアテスト計画は、比較的優れた範囲を確保します。 STLCフェーズ 。高品質のソフトウェアの提供は、テストチームによって保証されています。そして、テストで何をしなければならないかは、実際にはテスト計画段階で決定されます。
このセクションでは、完全な概要を提供し、テスト計画の重要性と 実行フェーズ 。これを読んだ後、実行フェーズと比較した場合の計画フェーズの重要性を理解できます。 イラストの実例とケーススタディ 。
テスト計画
以下に示すのは、計画中に注意すべき特定の重要事項です。
テストの計画は、テストサイクルの中心的な重要なセクションです。テストフェーズの結果は、テストのために行われた計画の品質と範囲によって決定されます。
テストの計画は通常、関係するすべての関係者の相互合意に基づいてテスト実行のリードタイムを節約するために、開発フェーズで行われます。
注意すべきいくつかの重要な事実は次のとおりです。
- 要件が凍結されている場合は、開発と並行して計画を開始する必要があります。
- 設計者、開発者、クライアント、テスターなどのすべての利害関係者は、計画を完成させる際に関与する必要があります。
- 未確認または未承認のビジネスニーズに対して計画を立てることはできません。
- 同様のテスト計画が、ビジネスが必要とする新しい要件に適用されます。
例1
開発チームは、クライアントからいくつかの要件を取得した後、ソフトウェアXYZに取り組んでいます。テストチームは、テストの定義または計画フェーズの準備をほぼ開始しました。テスト計画は、クライアントが見積もった初期要件に対応するように設計する必要があります。これはテストチームによって行われました。
このフェーズでは、他の利害関係者のいずれも関与せず、計画は凍結されました。
開発チームは、クライアントの承認を得て作業のいくつかの問題に対処するために、ビジネスフローにいくつかの変更を加えました。これで、ソフトウェアはテストのためにテストチームに渡されました。古いビジネスフローに従ったテスト計画で、テストチームはテストのラウンドを開始しました。これは、変更されたビジネスフローがテストチームと共有されなかったため、多くの遅延を伴ってテスト成果物に影響を与えました。
例1からの観察:
上記の例からいくつかの観察があります。
彼らです:
- 新しいビジネスフローを理解するには、多くの時間がかかりました。
- プロジェクトの成果物の遅延。
- フェーズの計画およびその他のタスクのやり直し。
これらの観察結果はすべて、効果的なテスト成果物の本質的なニーズに変換する必要があります。
計画段階の主要コンポーネント
以下に、計画フェーズに関係する主要なコンポーネントを示します。
- テスト戦略: これは、テスト中に使用される戦略を説明できる最も重要なセクションの1つです。
- テストカバレッジ: これは基本的に必須であり、ソフトウェア全体がテストされているかどうかを確認できるように、ビジネスニーズとテストケースの適合性マッピングを実行します。
- テストサイクルと期間: これは、開発のラウンドと各ラウンドを完了するための時間によっては非常に重要になる可能性があります。
- 合格/不合格の基準: 合格基準と不合格基準が定義されているものが非常に必要です。数回、これもクライアントによって定義されます。
- ビジネスおよび技術要件: ソフトウェアが必要であり、それらが提供する目的は、低レベルの説明とともに明確に定義されます。
制限事項
ソフトウェアのテスト段階、特に計画段階を実際に制御できるものはほとんどありません。
以下はそのようないくつかの分野です:
- テストする機能とテストしない機能: これにより、何をテストする必要があり、何をテストしてはならないかが明確に示されます。
- 一時停止の基準と再開の要件: これは、テストを一時停止または再開するために開発されたソフトウェアと定義された基準に関する意思決定者です。
- 責任: テスターは、テスト対象のソフトウェアの問題、バグ、および欠陥を確認する上で複数の責任を負います。さらに、バグを修正するには、開発者がバグを検証する必要があります。
- リスクと不測の事態: テスト中に関連するリスクを明確に言及し、その期間中の適切な不測の事態を非常に明確に定義する必要があります。
ケーススタディ#1
からの開発チーム 例1 ソフトウェアXYZを2段階でリリースすることを計画しています。フェーズ1には、テストする必要のある機能が多数あり、テストしない機能はほとんどありません。この場合も、ソフトウェアは、まだ開発されていない機能についてテストチームに通知することなく、テスト用にリリースされています。
これで、テストチームは、すでに作成したテスト計画に基づいて実行を開始します。彼らはたくさんのバグを思いつきます。そして、開発チームからの検証後、それらのほとんどは無効になります。
上記のケーススタディからの観察:
- 開発チームは、リリースノートと要件カバレッジノート(リリースノート)とともにソフトウェアをテストチームにリリースします。
- テストする機能とテストしない機能は、テストする前に、リリースされたソフトウェアに基づいて考慮に入れる必要があります。
- テストの一時停止と再開の基準を適切に定義する必要があります。
- ソフトウェアが利用できない場合のリスクと緊急時対応計画を完全に描写する必要があります。
また読む=> テスト計画フェーズでリスクを管理する方法
テスト実行計画
テストケースの実行は、STLCフェーズのステップの1つです。これは、以前に作成された計画に従って実行する必要があります。したがって、計画は常にテストフェーズ全体を支配し続けます。以下は、テスト計画の変更によってテストチームが影響を受ける例です。
例2
ソフトウェアAのテストは、チームが作成した計画1に基づいて開始されました。その後、ビジネスニーズと変更により、テスト計画にいくつかの変更を加える必要がありました。これにより、テストケースまたは実行の変更が強制されました。
観察:
- テスト計画は、テストケースの実行を決定します。
- 実行部分は計画により異なります。
- 計画と要件が有効である限り、テストケースも有効です。
実行中に問題を克服する方法
テスターは、テストの実行中にさまざまなシナリオに遭遇することがよくあります。これは、テスターが問題を解決する方法を理解して知る必要がある場合、または少なくとも問題の回避策を見つける必要がある場合です。
例3
ソフトウェアBのテストケースの実行中に、テストチームは複数の問題に遭遇します。それらのいくつかはショーストッパーです。彼らは問題を克服するのを助けるために開発者を必要とします。これは数回発生しており、その結果、成果物のテストが遅れています。
観察:
- 環境問題や問題を克服するための依存関係があります。
- テスターには、環境を正しく理解する必要があります。
- 頻繁に発生する既知の問題は、将来それらを克服するために文書化する必要があります。
バージョン管理と管理
バージョン管理 タイムリーな成果物を紹介するためには、テスト計画とテストケースの管理が非常に重要です。これはより重要であり、多くの場合、バージョン管理ツールの助けを借りて行われます。
バージョン管理ツールは、テスト計画の管理を支援するだけでなく、欠陥管理も支援します。複数のサイクルとリリースを持つテストプロジェクトがある場合、これらのツールは、テストの成果物をサポートするためのメトリックを下げるのに非常に役立ちます。
また、読んでください=> テスト実行フェーズでのリスク管理
テスト計画とテスト実行の違い
以下は、計画がテスト実行フェーズとどのように異なるかを指摘するいくつかの重要な領域です。
比較エリア | テスト計画 | テストの実行 |
---|---|---|
成果物のポジショニング | テスト計画は、テスト活動の主要な成果物と見なされます。これは、テストプロセスの最初のステップとして実行されます。 | これは、テストフェーズの最後のベンチメンバーとして登場します。実行後の欠陥/バグステータスは、テストケースの実行ステータスとともに、テスト成果物の1つとして共有されます。 |
責任者 | テストマネージャーはテスト計画を準備し、レビューのためにすべての利害関係者に共有します。 | これは通常、準備されたテストケースが承認され、承認されていることを念頭に置いて、テスターによって行われます。 |
主な焦点 | テスト計画の重点分野は、テストの実行方法、考慮すべきことと考慮すべきでないこと、使用できる環境、テストスケジュールなどです。 | テストの実行は、主にソフトウェアでテストするために提供されたテストケースの実行に焦点を合わせています。 |
繰り返しモードまたは反復モード | これは1回限りのアクティビティです。ソフトウェアの将来のリリースのために変更が必要な場合と必要でない場合があると言っています。 | 反復について話すとき、この領域には3つの部分があります。 1.機能テスト。 2.回帰テスト。 3.再テスト。 |
入力 | テスト計画を作成するための入力は本当に必要であり、ビジネスアナリスト、アーキテクト、クライアントなどによって提供されます。 | テストケースドキュメントが主要な入力です。 |
開始できる期間 | 効果的な結果を得て時間を節約するために、開発サイクルとともに開始する必要があります。ただし、ウォーターフォールモデルのように、開発フェーズが完了した後にのみテストフェーズが開始されるモデルはほとんどありません。 | ソフトウェアの開発が完了した後、厳密に実行を開始する必要があります。 |
閉鎖期間 | テスト計画には、そのような閉鎖期間はありません。通常、ソフトウェアのすべての関係者からの承認が提供されます。 | 特定のリリースまたはサイクルの実行は、すべてのテストケースがソフトウェアに対して実行されたときに終了したと見なされます。 |
ツールの使用法 | 計画活動はより多くの議論と文書化になるため、使用されるツールは多くありません。計画への変更を追跡するために、テストマネージャーは通常、VSSなどのバージョン管理ツールを使用します。 | 実行モードによって異なります。手動の場合、実行にツールは使用されません。ただし、欠陥をログに記録して管理するために、いくつかのツールが使用されます。 自動化テストの場合、実行はQTP、SELENIUMなどのツールを使用して行われます。 |
成果物への影響 | これは、すべてのテストフェーズに大きな影響を与えます | これは、テストする後続のサイクルまたはリリースに影響を与えます。 |
上記の図は、テストの実行よりもテストの計画活動の重要性をよりよく説明している可能性があります。ある意味では、実行フェーズはテスト計画のサブセットの一種です。
テスト戦略、アプローチ、およびその他の事項に基づいて、テスト計画は変更の余地を与えるために変更される可能性が高くなります。テストの実行がテストケースに依存することは確かです。テストケースは計画に基づいています。したがって、計画を変更すると、テストケースも確実に変更されます。
しかし逆に、テストケースの変更は強制的に変更を探す必要はありません。これは、テスト実行フェーズと比較して計画が維持される主な理由の1つです。
今後のチュートリアルでは、テストケースの作成方法について詳しく説明しますか?彼らは何ですか?そして、テストケースに関連する他のさまざまな側面とともに、それらをどのように機能させることができるか。
次のチュートリアル=> QAトレーニング日-4: SRSドキュメントからのテストケースの作成
あなたはテスト計画文書を書くことの専門家ですか?次に、これは、今後のテスターのための改善のための貴重なヒントを共有するための適切な場所です。下記のコメント欄にご意見をお聞かせください!!