ソフトウェアテスト実施におけるエビデンス
なぜこの話？
ソフトウェアテストにおいてエビデンス（証拠）を収集することがテスト業務において発生します。これらは決して無駄な作業ではないことと間違った業務実行になってほしくないために目的と良い点、悪い点をまとめようと思います。
エビデンスの目的
目的は多岐にわたりますが、主に以下の点が挙げられます。
- テスト実施したという証明: テストの目的通りに実施されたことを客観的に示すため。これにより、テスト担当者が責任を果たしたことを証明できます。
- 不具合を確認する補助: 発見された不具合がどのような手順、環境、入力値で発生したかを記録することで、開発者が不具合を再現し、修正する手助けとなります。
- 品質の判定のための材料: テスト結果が期待通り（合格）であることを示すことで、ソフトウェアの品質が一定レベルに達していることを保証します。
- デグレの確認: 過去のテスト結果がエビデンスとして残っていれば、後続の変更要求や追加開発時に、以前の機能が正しく動作していたことの根拠となりえます。
- 法的要件や監査対応: 業界によっては、テスト実施の記録が法的要件や監査の対象となる場合があります。エビデンスはこれらの要件を満たすために不可欠になる場合があります。
- 進捗管理と報告材料: テストの進捗状況を正確に把握し、関係者に報告するための基礎データとなります。
- ナレッジ: 将来的なテスト計画や改善のための貴重な情報源となります。
一般的なエビデンスの取得方法
エビデンスの取り方は、テストの目的、対象となるシステム、プロジェクトの規模などによって様々ですが、一般的な方法としては以下のものがあります。
- 共通の種類:
- 合格エビデンス: 期待通りの表示や動作が確認する。
- 不具合エビデンス: 不具合が発生している表示や動作が確認する。
- スクリーンショット:
- 期待通りの表示や動作が確認できた画面のキャプチャ。
- 動画録画:
- 特に複雑な操作手順やアニメーション、インタラクティブなUIのテストにおいて、一連の動作を動画で記録する。
- ログファイル:
- アプリケーションログ、サーバーログ、データベースログなど、システムが出力するログを保存する。
- ファイル出力/レポート出力:
- テスト対象のシステムがファイル出力を行う場合、その出力ファイル自体をエビデンスとして保存します。帳票出力（PDFなど）など。
- その他（第三者検証ではそこまで使わないかも）
- データベースのスナップショット/クエリ結果:
- テスト実行前後のデータベースの状態を記録します。
- 特定のデータが正しく更新されたか、想定外のデータが登録されていないかなどを確認する際に有効です。
- SQLクエリの実行結果をスクリーンショットで残すこともあります。
- テスト実行ツールやフレームワークのレポート:
- 自動テストツール（Selenium, Cypress, Playwrightなど）や単体テストフレームワーク（JUnit, NUnitなど）は、テストの合否や実行時間を自動的に記録し、レポートを生成します。
- これらのレポート自体が強力なエビデンスとなります。
良い話
- 信頼性の向上: エビデンスが豊富であれば、テスト結果の信頼性が高まり、関係者からの信頼を得やすくなります。
- 効率的な不具合修正: 詳細なエビデンスがあれば、開発者は迅速かつ正確に不具合を特定し、修正することができます。これにより、手戻りが減り、開発サイクルが加速します。
- 品質保証の強化: テストが期待通りに実施され、不具合が修正されたことを示すエビデンスは、ソフトウェアの品質が保証されていることの強力な根拠となります。
- リスクヘッジ: 万が一、リリース後に問題が発生した場合でも、テストのエビデンスがあれば、適切なテストが実施されていたことを証明でき、リスクを軽減できます。
- 知識の蓄積: エビデンスは、将来のプロジェクトにおけるテスト計画やリグレッションテストの範囲決定に役立つ貴重な知識となります。
- チーム間のコミュニケーション円滑化: テスト担当者、開発者、プロジェクトマネージャーなど、異なる役割を持つチームメンバー間で、共通の理解を促進し、円滑なコミュニケーションを可能にします。
悪い話
- エビデンス収集の過負荷: エビデンス収集に過剰な時間を費やすと、テスト実施そのものの時間が圧迫され、テストの網羅性が低下する可能性があります。特に手動テストでは顕著に出ます。
- エビデンスの管理コスト: 収集したエビデンスが膨大になると、保管場所の確保、整理、検索、バックアップなどに多大なコストと手間がかかります。
- 形骸化: 目的意識なく「とりあえずエビデンスを取る」という姿勢になると、不要なエビデンスが大量に生成され、誰も活用しないまま埋もれてしまうことがあります。これはリソースの無駄遣いです。
- エビデンスの解釈ミス: スクリーンショットだけでは、その時のシステムの状態や背景情報が不足している場合があり、誤った解釈につながる可能性があります。
- プライバシーやセキュリティの問題: エビデンスに個人情報や機密情報が含まれる場合、適切なマスキングやアクセス制限を行わないと、プライバシー侵害や情報漏洩のリスクが生じます。
- テスト自動化の阻害: 手動でのエビデンス取得に慣れすぎると、自動テスト導入のモチベーションが低下したり、自動テストレポートの活用が進まなかったりする可能性があります。
- エビデンス偽装のリスク: 意図的に偽のエビデンスを作成したり、都合の悪いエビデンスを隠蔽したりする不正行為のリスクもゼロではありません。
まとめ
エビデンスの収集は、その目的を明確にし、効率的かつ効果的な方法を選択することが重要です。闇雲に取るのではなく、「何のために」「どの程度の粒度で」エビデンスが必要かをプロジェクトや状況に応じて見極めることが無駄な作業を減らし効率的な品質保証につながると思います。