テスト文書とは、テストプロセス、基準、オブジェクト、シナリオを記述した文書の集合です。これは、ソフトウェア品質管理の構造化アプローチの進展と共に登場し、チーム内の透明性、再現性、ナレッジの伝達を確保するために必要です。
問題の歴史:
ITの初期段階では、テストは無秩序でほとんど口頭で行われていましたが、これによりバグを見逃したり、知識が失われたりしました。チーム開発の普及とプロセスの標準化の必要性から、テストを文書化する必要が生まれました。
問題:
文書がないため、バグの再現が困難で、テストによるカバレッジの評価が難しく、変更時のリグレッションリスクが高まります。テスターの作業に透明性がなく、新しい専門家はテストのロジックを再度理解しなければなりません。同じバグを探すためのリソースの重複が発生する可能性があります。
解決策:
標準化されたテンプレート（チェックリスト、テストケース、バグレポート）を導入することで、受け入れ基準を記録し、要件を詳細化し、タスクを委任し、カバレッジを追跡し、新入社員のために知識を保存できます。
主な特徴：
テストケースとチェックリストの違いは？
チェックリストは、確認すべき項目の簡単なリストです。テストケースは、手順、期待される結果、入力データを含む1つのテストの詳細な説明です。
テスト文書なしで完全にやり過ごせますか？
いいえ、「アジャイル」や「カンバン」のアプローチでも、基本的なアーティファクトは必要です—少なくとも簡潔なチェックリストや回帰テストシナリオは必要です。
要件が変更された場合、テスト文書は更新するべきですか？
はい、古い文書は非現実的なテストや重要なバグの見逃しにつながるからです。
チームではテスターが口頭でのみ議論し、テスト結果をノートに記録していました。回帰エラーが発生した際、バグを引き起こしたアクションの順序を再現できませんでした。
利点:
欠点:
テスターはテストケースのテンプレートを導入し、要件の変更に応じて定期的に更新しました。エラーが発生した際、再現と修正に必要な条件を迅速に見つけることができました。
利点:
欠点: