Microsoft Test Managerアプリケーションのテストに使用します。最初Test Plansに、テストしたいアプリケーションごとに作成しました。したがって、テスト計画は次のような構造になっています。
アプリケーション A
アプリケーション B
アプリケーション C
現在、反復ごとに、テスト用の新しいビルドを取得しています。
では、同じテスト計画を保持し、適切なフィールド (使用中のビルド、イテレーション、構成など) を編集する必要がありますか?それとも、イテレーションごとに新しいものを作成する方がよいでしょうか? このようなもの：
アプリケーション A - 反復 1
アプリケーション A - 反復 2
アプリケーション B - 反復 1
アプリケーション B - 反復 2
アプリケーション C - 反復 1
アプリケーション C - 反復 2
定義とそのテスト計画の小さな回避策を考慮してください。
テスト計画プロセスと計画自体は、プロジェクト チームの他のメンバー、テスター、同僚、マネージャー、およびその他の利害関係者とのコミュニケーションの手段として機能します。このコミュニケーションにより、特に組織全体のテスト ポリシーと動機の領域で、テスト計画がプロジェクト チームに影響を与え、プロジェクト チームがテスト計画に影響を与えることができます。テストの範囲、目的、およびテストする重要な領域。プロジェクトと製品のリスク、リソースに関する考慮事項と制約。そして、テスト中のアイテムのテスト容易性。このコミュニケーションは、1 つまたは 2 つのテスト計画の草案を回覧し、レビュー ミーティングを通じて行うことができます。このようなドラフトには、次のような多くの注意事項が含まれます。
[未定: ジェニファー: システム テストの実行サイクルごとに、テスト アイテムをテスト ラボにリリースする計画を教えてください。]
[デイブ - 以前のインクリメントのリグレッション テストに使用するテスト ツールのバージョンを教えてください。]
この種の質問に対する回答を文書化すると、テスト計画は、テスト担当者とプロジェクト チームの他のメンバーとの間の以前の議論と合意の記録になります。テスト計画は、変更の管理にも役立ちます。プロジェクトの初期段階では、より多くの情報を収集するにつれて、計画を修正します。プロジェクトが進化し、状況が変化するにつれて、私たちは計画を適応させます。書面によるテスト計画は、そのような改訂や変更を測定するためのベースラインを提供します。さらに、主要なマイルストーンで計画を更新することで、テストをプロジェクトのニーズに合わせ続けることができます。テストを実行しながら、結果に基づいて計画の最終調整を行います。一部のプロジェクトは非常に動的である可能性があるため、差異が発生するたびにテスト計画を更新する時間やエネルギーがない場合があります。第 6 章 [Black, 2001] では、データベースまたはスプレッドシートを使用して実装できる、テスト計画からの差異を文書化するための簡単な方法について説明します。これらの変更記録は、テスト ステータス レポートの一部として、またはプロジェクト終了時のテスト サマリーの一部として、定期的なテスト計画の更新に含めることができます (c) ISTQB Foundation book
アプリケーション開発ライフ サイクル全体を通じて行われた修正や修正を確認できるように、既存のテスト計画を更新することをお勧めします。
また、新しいビルドごとに新しいテスト計画を作成することは理にかなっていますか?
通常、テスト計画は機能全般に対して作成されます。また、機能 (機能仕様) が変更されると、それに応じて更新されます。しかし、それは理想的な世界にあります。
このことから、「使用中のビルド、イテレーション、構成など」について、計画ではなくテスト レポートについて話していることがわかります。テスト計画を含むドキュメントを用意してみませんか。そして、
テストに使用される構成、ビルド、環境を更新 (1 行追加) する、このドキュメントの別の例の表はありますか?