テストの課題

　社内監査コンプライアンスグループは、テスト担当部門が対処しなければならない2つの緊急課題を特定した。

1. 製品のテストおよび実装は、隔離・制御された環境の中で、権限を持ったスタッフによって一貫した方法行われなければならない。
2. 実装要求にはテストの証拠――テスト内容の要約（テストの詳細、テスト基準／要件、期待される結果、実際の結果、テストの結論／リポート出力）と経営者、IT部門、社内監査担当者によるテスト結果の承認――を添付しなければならない。

テストの成果物（テストのコンプライアンス）

　テスト担当部門は、新しい社内監査要件に対応するためには以下のようなテストの成果物を規定する必要があると判断した。

1. テストプランニング――詳細なテスト計画
2. テスト要件――実装される製品の詳細な説明
3. テストケース／スクリプト――要件を検証するための将来なテストケース／スクリプト
4. テストケースのデザイン――期待される結果
5. テストの結果――実際のテスト結果を把握する
6. テストの欠陥――テスト中に見つかった問題とその解決策を把握する
7. テストの結論――（現時点までの）テスト結果に基づく製品の状態

1. テストプランニング（テストの詳細）

　テストプランニングでは、何をテストするのか、なぜテストするのかを明確にしなければならない。また、何をテストしないのか、そしてなぜテストしないのかも明確にする必要がある。何をテストしないかを理解することは、何をテストするかを理解するのに劣らず重要な場合もある。

2. テスト要件（テスト基準）

　システムの詳細を把握するための最も効率的な方法は、それらを要件として把握することである。これらの要件は、具体的な実装要求に対してビジネス部門とIT部門が承認できるよう十分に具体的な内容であること。これらの要件は将来的に、IT部門とビジネス部門にシステムの全体像を提供するものでなくてはならない。

　この要件リストには、システムの変更／改良および新たな実装によって影響を受けるシステムの各側面を含める必要もある。コンプライアンス基準は、ビジネスリスクを軽減するために一般に対処すべき事柄だけでなく、テスト範囲やテスト要件も拡大する場合が多い。

3. テストケース／スクリプト（テストの詳細）

　テストの定義・設計・保守を行う上で最も効率的な方法は、こういった詳細をテストケースとして把握することである。テストケースはその後、テストに関連した要件を検証する際に適用可能なテストのリポジトリあるいはカタログとして利用することができる。

　テストは、ビジネス部門とIT部門が特定の機能に照らし合わせて承認できるよう十分に具体的な内容でなければならない。これらのテストは将来的に、IT部門とビジネス部門にシステムの全体像を提供するものであるべきだ。テストのリストは、適切な要件と関連付けなければならない。テストケース／スクリプトは、1つ以上の要件をカバー（テスト）する必要がある。

4. テストケースのデザイン（期待される結果）

　テストデザイン環境あるいはテストデザインテンプレートは、あらゆるテストデザインタスクに対して「ワンストップショッピング」を提供しなければならない。コンプライアンスに対応するためには、手順の説明、インプットおよび期待されるアウトプットがテストケース／スクリプトに必要とされる。効果的なデザインテンプレートあるいはテストデザイン環境では、将来のテストケース／スクリプトデザインのために再利用可能なテンプレート（内容的な要件に関して）を提供することが可能だ。テストケースデザインは、監査可能な合否基準が含まれる明確なテストケースを社内／社外監査人に提供するものでなくてはならない。

5. テストの実施（実際の結果）

　実施の結果は、適切なレベルのセキュリティとデータの整合性が維持されたテストの実行時に取得しなければならない。取得する結果には、単なる合否判定だけでなく、合格あるいは不合格の証拠が含まれていなければならない。これは通常、テストの実行時に記録したスクリーンショットやデータダンプによって提供され、検証手順と関連付けることができる。適切なテストデザイン（上記項目4参照）と実行結果があれば、ほとんどのコンプライアンス課題に対応することができる。テスト実行時に遭遇した欠陥は、捕捉・追跡する必要がある。

6. テストの欠陥（実際の結果）

　新しいコンプライアンス基準に対応するには、監査可能な欠陥管理システムによってサポートされる欠陥管理プロセスが必要となる。このツールは、結果の取得・対処・伝達のための主要なメカニズムとして利用しなければならない。欠陥に関する標準的な記述は、欠陥の説明、欠陥の深刻度や状態、解決策などが含まれる明確な監査証跡を提供するものでなくてはならない。できれば欠陥の解決策の明確な記述に加えて、「修正前」と「修正後」のテスト結果のスクリーンショットを欠陥リポートに含めることが望ましい。

7. テストの結論（テストリポート）

　テストの結論／最終テストリポートには、欠陥リポートと欠陥サマリーリポート、実施リポートと実施サマリーリポート、カバレッジリポートとカバレッジサマリーリポート（要件範囲）、そして最初のテスト計画の範囲内／範囲外の推定に対応したリポートの結論を含めなければならない。

まとめ

　コンプライアンス要件を理解し、それを厳格に定義・管理されたテストプロセスに適用することは、テストによってコンプライアンスの課題に対処する上で重要なポイントである。

　コンプライアンス基準に準拠するための構造は、監査可能な結果とテスト記録の整合性を重視した優れたテスト手法の実現につながる。特定のコンプライアンス基準に従うことが求められる業界で働くテスターおよび特にテスト管理者にとっては、自身の法的・倫理的責任を理解することが重要である。コンプライアンス基準およびその基準に対する自社の解釈を熟知し、その基準の下での自身の法的責任を理解しなければならない。

本稿筆者のデビッド・W・ジョンソン氏は、さまざまな業界で20年以上にわたってIT業務に携わった経験を持つシニアコンピュータシステムアナリストである。ビジネスニーズ分析、ソフトウェア設計、ソフトウェア開発、テスト、トレーニング、実装、組織評価、ビジネスソリューションのサポートなどの分野で重要な役割を果たしてきた。同氏はこの12年間、テストの戦略、プランニング、自動化、管理ソリューションなどの「テストウェア」の導入に関するノウハウを蓄積してきた。