レビューでのチェックリストの使用

テストアナリストとレビュー活動

テストアナリストは、システムの動作だけでなく「システムの仕様」がテスト可能かどうかを検証するため、開発の初期段階からレビュー（静的テスト）に積極的に参加します。これにより、欠陥を早期に発見・修正し、後工程での手戻りコストを大幅に削減（シフトレフト）することができます。

レビューを効果的に行うために、テストアナリストはチェックリストを使用します。

要件レビュー

要件仕様書などのドキュメントをレビューする際、テストアナリストは主に「テスト担当者の視点」から以下のポイントをチェックします。

• テスト可能性 (Testability): その要件が満たされているか、客観的に検証（テスト）できるか。
• 明確さ: 曖昧な表現がなく、誰が読んでも一意に解釈できるか。
• 一貫性: 他の要件と矛盾していないか。
• 完全性: 必要な情報（正常系だけでなく異常系や制約事項など）が欠落していないか。

ユーザーストーリーレビュー

アジャイル開発において、テストアナリストはユーザーストーリー（およびエピック）のレビューに大きく貢献します。ここでは「INVEST」などの基準に基づいたチェックリストがよく使われます。

• 受け入れ基準の確認: ストーリーが「完成（Done）」したと判断するための条件（受け入れ基準）が明確かつテスト可能に定義されているかをチェックします。
• エッジケースの指摘: プロダクトオーナーや開発者が見落としがちな、例外処理や境界値のシナリオをレビュー段階で提示します。

チェックリストの調整（テーラリング）

チェックリストは「一度作ったら終わり」ではなく、プロジェクトの状況や組織の成熟度に合わせて**継続的に調整（テーラリング）**する必要があります。

• プロジェクトに合わせる: 開発モデル、ドメイン（金融、医療など）、対象となるドキュメントの種類に応じて、チェックリストの項目を追加・削除します。
• 過去の欠陥データを活用する: 後のテストフェーズや本番環境で頻発した欠陥を分析し、「なぜレビューで防げなかったのか」を考えてチェックリストに新しい項目を追加します。
• 項目の陳腐化を防ぐ: 開発チームのスキルが上がり、もう発生しなくなった初歩的なミスに関するチェック項目は削除し、チェックリストが肥大化・形骸化するのを防ぎます。