how write test strategy document
テスト戦略文書を効率的に書くことを学ぶ
テストアプローチ、達成したいこと、およびそれをどのように達成するかを定義するための戦略計画。
このドキュメントは、テストの目的を達成するための明確なアプローチ計画とともに、すべての不確実性またはあいまいな要件ステートメントを削除します。テスト戦略は、QAチームにとって最も重要なドキュメントの1つです。
=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください
学習内容:
テスト戦略ドキュメントの作成
テスト戦略
テスト戦略を効果的に書くことは、すべてのテスターがキャリアの中で達成すべきスキルです。それはあなたを開始します 思考プロセス これは、多くの不足している要件を発見するのに役立ちます。思考とテスト計画の活動は、チームがテストの範囲とテストの範囲を定義するのに役立ちます。
これは、テストマネージャーがいつでもプロジェクトの明確な状態を取得するのに役立ちます。適切なテスト戦略が実施されている場合、テストアクティビティを見逃す可能性は非常に低くなります。
計画なしでのテスト実行はめったに機能しません。私は戦略文書を書いているチームを知っていますが、テストの実行中にそれを参照することは決してありません。チームがアプローチと責任に一貫性を持たせるために、テスト戦略計画はチーム全体と話し合う必要があります。
締め切りが厳しい場合、時間のプレッシャーのためにテスト活動を放棄することはできません。少なくとも、そうする前に正式なプロセスを経る必要があります。
テスト戦略とは何ですか?
テスト戦略とは、「アプリケーションをどのようにテストするのか」という意味です。テスト用のアプリケーションを入手するときに従う予定の正確なプロセス/戦略について言及する必要があります。
多くの企業がテスト戦略テンプレートに非常に厳密に従っているようです。標準のテンプレートがなくても、このテスト戦略ドキュメントをシンプルに保つことができますが、それでも効果的です。
テスト戦略対。テスト計画
何年にもわたって、これら2つのドキュメントの間に多くの混乱が見られます。それでは、基本的な定義から始めましょう。一般的に、どちらが先かは関係ありません。テスト計画文書は、全体的なプロジェクト計画に組み込まれた戦略の組み合わせです。 IEEEによると 標準 829-2008では、戦略計画はテスト計画のサブアイテムです。
すべての組織には、これらのドキュメントを維持するための独自の標準とプロセスがあります。一部の組織では、テスト計画自体に戦略の詳細が含まれています(ここに 良い例 これの)。一部の組織では、戦略をテスト計画のサブセクションとしてリストしていますが、詳細はさまざまなテスト戦略ドキュメントに分けられています。
プロジェクトの範囲とテストの焦点は、テスト計画で定義されます。基本的に、テストカバレッジ、テストする機能、テストしない機能、見積もり、スケジューリング、およびリソース管理を扱います。
一方、テスト戦略では、テストの目的とテスト計画で定義されたテストタイプの実行を達成するために従うべきテストアプローチのガイドラインが定義されています。テストの目的、アプローチ、テスト環境、自動化戦略とツール、および緊急時対応計画によるリスク分析を扱います。
要約すると、テスト計画は達成したいことのビジョンであり、テスト戦略はこのビジョンを達成するために設計されたアクションプランです。
これですべての疑問が解消されることを願っています。ジェームズ・バッハはこのトピックについてもっと議論しています ここに 。
優れたテスト戦略ドキュメントを作成するプロセス
プロジェクトに最適なものを理解せずに、テンプレートに従うだけではいけません。すべてのクライアントには独自の要件があり、あなたはあなたのために完璧に機能するものに固執する必要があります。組織や標準を盲目的にコピーしないでください。それがあなたとあなたのプロセスに役立っているかどうかを常に確認してください。
以下は、この計画でカバーする必要があるものの概要を示すサンプル戦略テンプレートと、各コンポーネントでカバーする意味があるものを示すいくつかの例です。
STLCのテスト戦略:
ジェンキンスは経験豊富な人のための質問と回答をインタビューします
[画像 ソース ]
テスト戦略ドキュメントの共通セクション
ステップ1:範囲と概要
プロジェクトの概要と、このドキュメントを使用するユーザーに関する情報。また、誰がこのドキュメントをレビューおよび承認するかなどの詳細を含めます。テスト計画で定義されたプロジェクト全体のタイムラインに関して、タイムラインを使用して実行するテストアクティビティとフェーズを定義します。
ステップ2:テストアプローチ
すべてのチームメンバーのテストプロセス、テストのレベル、役割、および責任を定義します。
すべてのための テストタイプ テスト計画で定義( 例えば、 単位 、統合、システム、回帰、 インストール/アンインストール 、ユーザビリティ、負荷、パフォーマンス、およびセキュリティのテスト)は、開始時期、テストの所有者、責任、テストアプローチ、および該当する場合は自動化戦略とツールの詳細などの詳細とともに、実施する必要がある理由を説明します。
テストの実行には、新しい欠陥の追加、欠陥のトリアージ、欠陥の割り当て、再テスト、回帰テスト、最後にテストの承認など、さまざまなアクティビティがあります。各アクティビティで実行する正確な手順を定義する必要があります。以前のテストサイクルで機能したのと同じプロセスに従うことができます。
多数のテスターを含むこれらすべてのアクティビティのVisioプレゼンテーションと、チーム内の役割と責任をすばやく理解するのに非常に役立つアクティビティを担当する人。
例えば、 欠陥管理サイクル–新しい欠陥をログに記録するプロセスについて言及します。ログインする場所、新しい欠陥を記録する方法、欠陥ステータスはどうあるべきか、誰が欠陥トリアージを行うべきか、誰がトリアージ後に欠陥を割り当てるかなど。
また、変更管理プロセスを定義します。これには、変更要求の送信、使用するテンプレート、および要求を処理するプロセスの定義が含まれます。
ステップ3:テスト環境
テスト環境のセットアップでは、いくつかの環境と各環境に必要なセットアップに関する情報の概要を説明する必要があります。 例えば、 機能テストチーム用とUATチーム用の1つのテスト環境。
各環境でサポートされるユーザー数、各ユーザーのアクセスロール、オペレーティングシステム、メモリ、空きディスク容量、システム数などのソフトウェアとハードウェアの要件を定義します。
テストデータの要件を定義することも同様に重要です。方法について明確な指示を提供する テストデータを作成する (データを生成するか、プライバシーのためにフィールドをマスクして本番データを使用します)。
テストデータのバックアップと復元の戦略を定義します。テスト環境データベースは、コード内の未処理の条件が原因で問題が発生する可能性があります。データベースバックアップ戦略が定義されておらず、コードの問題のためにデータ全体が失われたときに、プロジェクトの1つで直面した問題を覚えています。
バックアップと復元のプロセスでは、バックアップを作成するタイミング、データベースを復元するタイミングをバックアップに含めるユーザー、データベースを復元するユーザー、データベースが復元された場合に従うデータマスキング手順を定義する必要があります。
ステップ4:テストツール
テストの実行に必要なテスト管理および自動化ツールを定義します。パフォーマンス、負荷、およびセキュリティのテストでは、テストのアプローチと必要なツールについて説明します。それがオープンソースか商用ツールか、そして何人のユーザーがそれでサポートされているかを述べ、それに応じて計画します。
ステップ5:リリースコントロール
私たちの最後に述べたように UATの記事 、計画外のリリースサイクルにより、テスト環境とUAT環境でソフトウェアバージョンが異なる可能性があります。適切なバージョン履歴を持つリリース管理計画により、そのリリースでのすべての変更のテスト実行が保証されます。
例えば、 答えるビルド管理プロセスを設定します–新しいビルドを利用可能にする場所、デプロイする場所、新しいビルドを取得するタイミング、本番ビルドを取得する場所、本番リリースの合図を出す人、など。
ステップ6:リスク分析
想定するすべてのリスクをリストしてください。これらのリスクを軽減するための明確な計画と、これらのリスクが実際に発生した場合の緊急時対応計画を提供します。
ステップ7:レビューと承認
これらすべてのアクティビティがテスト戦略計画で定義されている場合、プロジェクト管理、ビジネスチーム、開発チーム、およびシステム管理(または環境管理)チームに関与するすべてのエンティティによる承認のためにレビューする必要があります。
レビューの変更の概要は、承認者の名前、日付、コメントとともに、ドキュメントの冒頭で追跡する必要があります。また、これは生きたドキュメントであり、テストプロセスの機能強化により、継続的に確認および更新する必要があります。
テスト戦略ドキュメントを作成するための簡単なヒント
- テスト戦略ドキュメントに製品の背景を含めます。テスト戦略文書の回答の最初の段落で–なぜ利害関係者はこのプロジェクトを開発したいのですか?これは、物事をすばやく理解して優先順位を付けるのに役立ちます。
- テストする重要な機能をすべてリストします。一部の機能がこのリリースに含まれていないと思われる場合は、「テストされない機能」ラベルの下にそれらの機能を記載してください。
- プロジェクトのテストアプローチを書き留めます。明らかに、どのような種類のテストを実施するのかを述べてください。
つまり、機能テスト、UIテスト、統合テスト、負荷/ストレステスト、セキュリティテストなどです。 - 機能テストをどのように実行するかなどの質問に答えますか?手動または自動テスト?テスト管理ツールからすべてのテストケースを実行しますか?
- どのバグ追跡ツールを使用しますか?新しいバグを見つけたときのプロセスはどうなりますか?
- テストの開始と終了の基準は何ですか?
- テストの進捗状況をどのように追跡しますか?テストの完了を追跡するためにどのメトリックを使用しますか?
- タスクの分散–各チームメンバーの役割と責任を定義します。
- テストフェーズ中およびテストフェーズ後にどのようなドキュメントを作成しますか?
- テストの完了にはどのようなリスクがありますか?
結論
テスト戦略は一枚の紙ではありません。これは、ソフトウェアテストのライフサイクルにおけるQAアクティビティ全体の反映です。テスト実行プロセスでこのドキュメントを時々参照し、ソフトウェアリリースまで計画に従ってください。
プロジェクトがリリース日に近づくと、テスト戦略ドキュメントで定義した内容を無視することで、テストアクティビティを簡単に削減できます。ただし、特定のアクティビティを削減することが、リリース後の大きな問題の潜在的なリスクなしにリリースに役立つかどうかについて、チームと話し合うことをお勧めします。
チームはドキュメントではなくテストの実行に重点を置いているため、アジャイルチームのほとんどは戦略ドキュメントの作成を削減しています。ただし、基本的なテスト戦略計画を立てることは、プロジェクトに伴うリスクを明確に計画して軽減するのに常に役立ちます。アジャイルチームは、すべての高レベルのアクティビティをキャプチャして文書化し、問題なく時間どおりにテストの実行を完了することができます。
優れたテスト戦略計画を作成し、それに従うことを約束することで、ソフトウェアのテストプロセスと品質が確実に向上すると確信しています。この記事があなたのプロジェクトのテスト戦略計画を書くようにあなたを刺激するなら、それは私の喜びです!
この投稿が気に入ったら、友達と共有することを検討してください!
=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください
推奨読書
- サンプルテスト計画ドキュメント(各フィールドの詳細を含むテスト計画の例)
- テスト計画チュートリアル:ソフトウェアテスト計画ドキュメントを最初から作成するためのガイド
- テスト計画、テスト戦略、テストケース、テストスクリプト、テストシナリオ、およびテスト条件の違い
- フォーマットと内容のサンプルソフトウェアテスト計画テンプレート
- ERPアプリケーションのテスト計画を作成してテストケースを作成する方法-ERPテストパート2
- 最高のソフトウェアテストツール2021 [QAテスト自動化ツール]
- 例を含む検収試験レポートのサンプルテンプレート
- テストケースの例を含むサンプルテストケーステンプレート[ダウンロード]