Vietnamese
Englishテスト活動の成果物
先日の記事で基本的なテストプロセスにおけるテストの活動について紹介いたしました。今回は、それぞれの活動の成果物を一緒に見ていきましょう。
テスト計画の作業成果物
テスト計画は、組織のテストポリシーとテスト戦略に従い、プロジェクトごとに作成されます。プロジェクトの規模や対象、テストアイテムの複雑さに応じて、テストアイテム単位やテストレベル単位で計画が策定されることもあります。また、テストプロセスやテストレベルに関する移行基準（終了基準や完了条件も含む）や、成果物のインプットとアウトプットの関連性を説明するトレーサビリティ情報も、テスト計画における成果物となります。
テストのモニタリングとコントロールの作業成果物
テストの進捗を示すテスト進捗レポートや、各マイルストーンでの成果をまとめたテストサマリーレポートなどが、状況に応じて主要な成果物として作成されます。レポートに含める情報は、プロジェクトやテストレベルによって異なります。
ポイントは、プロジェクトのステークホルダーに対し、必要で的確な情報を含むレポートを適切なタイミングで提供することです。テストプロセスを実施する中で、品質の問題や機能の不十分な実装、リソースの不足といったプロジェクトリスクに関する報告は、迅速な対応が求められます。
テスト分析の作業成果物
テスト分析で得られるテスト条件は、テストベースとのトレーサビリティが確保されていなければ、その条件の過不足を正確に確認することができません。同様に、どのテストアイテムやテストレベルでテスト条件の評価・検証を行うかについても、トレーサビリティが重要です。また、システムや製品にとって優先すべきテスト条件の順位付けに関する情報も、このプロセスにおける成果物の一部です。
さらに、テストベースの分析により発見された欠陥の報告も含まれます。経験ベースのテスト技法を用いる場合、探索的テストでは詳細なテストケースを作成せず、代わりにテストチャーターを作成し、それに基づいてテストの実装・実行を行います。この際、テストチャーターがテストの品質を左右する主要な成果物となります。
テスト設計の作業成果物
テスト設計の成果物には、テスト設計仕様とテストケースが含まれます。テスト設計仕様は、テスト条件を満たすために必要なテストレベルや手法を示し、具体的な入力値や期待値は記載しません。テストケースには、具体的な入力値や期待値、実行順序などを含め、テスト実装が可能となる詳細が記載されます。
実務では、しばしばテスト設計仕様を省略し、テストケースのみで作業成果物とすることがあります。しかし、これではテスト条件の過不足や、変更への対応が難しくなります。高位レベルのテストケースはテスト条件の網羅性を確認でき、仕様の変化にも柔軟に対応できるため、再利用性の高いテスト設計を実現します。
テスト実装の作業成果物
テスト実装の成果物は、テスト実行を可能にするための「テストウェア」を指し、テスト手順とその順序、テストスイート、テスト実行スケジュールが含まれます。その他にも、テストデータやスクリプト、環境設定などが成果物となります。テスト対象や環境に応じて、シミュレーションやモックアップを用いることもあります。
どの状況でも、重要なのは、テスト実行時に計画通りに条件を満たしているか確認できるトレーサビリティを維持することです。そのために、抽象的なテスト条件をより具体的に分解することがあります。また、探索的テストでも、テストチャーターを使い、十分なカバレッジと情報を提供する準備が必要です。
テスト実行の作業成果物
テスト実行の成果物には以下が含まれます。
・テストケースや手順のステータスドキュメント（例：実行可能、合格、不合格、ブロック、スキップなど）
・欠陥レポート
・テストアイテムやテスト対象、テストツール、テストウェアに関するドキュメント
これらの成果物においては、テスト実行の再現性が重要です。特に、故障の報告時には、原因分析と解決のために、故障の再現が必要となります。たとえタイミングの影響で再現が難しい場合でも、解析に十分な情報を提供することが求められます。また、テスト実装段階で設定したテストイベントに対する実行結果や進捗状況といったカバレッジ指標も重要な成果物であり、これらはステークホルダーに提供するテスト進捗レポートとして活用されます。テスト進捗レポートは、テストモニタリングとコントロールの成果物に分類されます。
テスト完了の作業成果物
テスト完了の成果物としては、テストが完了したことをステークホルダーに報告し理解を得るためのテストサマリーレポートが含まれます。テストサマリーレポートは、各マイルストーンごとに作成され、テストモニタリングとコントロールの成果物でもありますが、すべてのテストが終了した後のものはテスト完了の成果物となります。
また、テストレベルの移行やイテレーションの切り替え時には、次のサイクルに引き継ぐ情報として以下の内容が含まれます。
- テストの改善に役立つ情報
- 未実行のテストケースや未報告の欠陥など、次サイクルに持ち越すアイテム
- テストデータや環境、再利用可能なテストウェア
これらのテストサマリーレポートやテストデータ、テスト環境は次のサイクルでも完了成果物として引き継がれます。
これまで、テストの主な活動についての紹介の完了です。では、皆さんは人の心理とテストにどんな関係があるのか考えたことがありますでしょうか。
ソフトウェアの品質向上には「欠陥の指摘」が重要ですが、開発担当者は指摘を批判と捉えやすく、受け入れがたい場合があります。特に、役割分担やコミュニケーションが不十分だと、テスト担当者が外部の存在と感じられ、反発が生じやすくなります。また、開発者は自分のコードが正しいと確信しがちであり、テスト担当者からの指摘を素直に受け入れにくくなる傾向があります。
テスト担当者の指摘は品質向上に貢献しますが、開発者にはコストがかかるため、生産性と結びつかないと感じられることもあります。そのため、テスト活動の重要性を理解してもらうための説明や信頼関係の構築が必要です。欠陥の指摘を「品質向上のための確認」として捉え、改善点を共に説明することで、開発者との良好な関係が築けます。
テスト担当者には、信頼関係を構築するためのコミュニケーション能力が求められます。テストの進捗や欠陥数などを継続的に伝え、テスト活動の目的を共有することで、関係の円滑化が図れます。また、レビューやテストの内容を事前に知らせて合意を得るなど、良好な協力体制が促進されます。
下記がコミュニケーションを適切に行う方法です。
・対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい。
・テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正することで、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
・テスト結果や他の発見事項は、中立な立場で、事実に焦点を当てて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
・他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように協力する。
・自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する。
テスト担当者と開発担当者のマインドセット
開発担当者とテスト担当者は、目的が異なるため活動内容やアプローチも違います。開発担当者は顧客の要求に応えるためにシステムやソフトウェアを設計し、設計書やプログラムなどの成果物を作成します。一方、テスト担当者は品質確認や欠陥検出を目的とし、静的・動的テストや欠陥の報告、品質情報の提供といった作業を行います。お互いのマインドセットは異なりますが、相互に補完し合うことで、より高品質なプロダクトの開発に貢献します。
また、開発モデルによって担当者の役割や視点も変わります。ウォーターフォール型では工程ごとに進め、スパイラルやインクリメンタルのようなモデルでは、より柔軟な対応が求められます。特に大規模なプロジェクトや安全性が求められる分野では、独立したテスト担当者が欠陥を発見しやすく、医療や金融などの専門知識が必要な分野でも、そのスキルが活かされます。
※練習問題をやりましょう！！