品質保証に関する提言（その２：第三者による品質保証体制作り）

ここでいう第三者による品質保証とは、品質保証部門が第三者としての立場で品質保証する体制を作ることである。
最終的には、第三者に品質保証作業を委託することが目標であり、第三者に品質保証をしてもらうことを前提としている。
そのためには、設計作業のテストを委託できるようにしなければならない。
先ず始めに、第三者にテストをしてもらえるようなテスト仕様の作成から始める必要がある。

【テスト仕様のあり方】
要求仕様は「検証可能」でなければならない。
つまり、エラーのケースも含めて、そこに書かれていることが、実際に実現していることを客観的に検証できなければならない。
事前にそのような要求仕様書が作成されていなければ、テスト仕様も作れない、その結果、実際にそれが実現しているのかどうかはテスト者の主観で判断することになる。
したがって、要求仕様書が書き上がったら、テストの責任者は、要求仕様がテスト可能な表現で書かれていること、そこに表現されていることでテストが出来るのかどうかをチェックする必要がある。

テストには、設計者によるテストと評価者（設計テスト責任者であっても良いが品質保証部門の方が望ましい）によるテストがある。
「自分のソフトウェアを自分でテストするな」と言われているが、結合テストに入る前の段階では、設計者によるテストがベターであると言える。
評価者がやることは、以降の結合テストや運用テストに耐えうる状態かどうかの判断と評価である。

テスト計画を作ることは重要な仕事であって、製品の開発と並行して作成すること。
機能仕様書の一部として作成することが望ましい。
別冊で作成してもよいが機能仕様書と同等に完了させること。
テスト計画者（テストの責任者）は、要求仕様書が文書化されたらテスト可能性の観点からレビューすること。
テスト計画の本格的な作成は、要求仕様書がフィックスした後に開始すべきである。

統合テストのテスト項目の本格的な作成は、機能設計書がフィックスした後に開始すべきで、単体テスト項目は、詳細設計が完了した後に開始する。

テストは、今のところ省くことができない。
それは、きちんと仕様を実現しているという保証がないからである。
その確信があるのなら、品質保証の観点からのテストで足りるわけで、その確信がない以上、設計者によるテストはもちろん、仕様に沿って第三者による「評価」をも受けなければならない。

テスト計画を作成するためには、
スケジュールを含めて、プロジェクトの計画が必要である。
その枠の中で、
・テスト方針／テスト戦略、
・ＤＤ／ＭＴ／ＰＴ／ＴＴのフェーズ分け、
・テストの方法やＰＣＬ作成計画と言った作戦、体制は
・テストツール、テストの準備や手順は
・合否の判定は
・結果データの収集は
・バグ報告のルート等は
と言ったことを決めていかなければならない。
特にテストツールは、テスト手法、テスト環境等を記載しノウハウを個人からチーム（my program → our program）のものにする。
さらに、具体的なテストでの確認項目としては、下記のような観点からそれぞれのテストマトリックスを作成すること。
結果は確認項目だけでなく、テスト手段、確認内容が明らかであることと出来ればテスト手段／確認内容はパターンとして別表でまとめておきマトリックスからポイントするのが望ましい。
このためには機能仕様書がしっかりしていないとマトリックスは作成できない。
・整合性(製品間／製品内コンポーネント間)
・排他制御
・障害処理
・正常時／異常時の終了処理
・外部パラメタとその組合せ
・シーケンスとシーケンスの組合せ
・シリアライズとタイミング等

テスト責任者の役割として、
・テスト計画を立案
・要求仕様の検証可能性をチェック
・テストを容易にするための設計方法などのアイデアをフィードバック
・品質保証部署との連携

テスト仕様は、ある機能が正しく実行されることを確認するために、どのようなテストを行うかが記述され、さらにどのような結果であればよいかが記述されていなければならない。
一般的にはチェックリストで記述する。
テスト実施者は、それに沿って作業を進める。

要求仕様は、一般的に電子化されているのでそれに手を加えテスト仕様（簡単なものであればチェックリストでテスト仕様を代用しても良い）を作成すると良い。

チェックリストは、プログラムが仕様どおり正しく動作することを確認するためのテストが、網羅的に実行できることを目的とする。
チェックリストの文書には、期待される結果を記述したものを含めること。
組織としてのテスト計画を作成すること。
そして、品質保証部門は、すべてのテストがテスト計画に従っているかどうかを確認することが重要である。

独立部隊の編成について：大規模システムの場合は必須
合理的テスト計画の立案、冶工具の事前準備、品質、進捗度の客観的把握等を行うためにも独立テスト部隊を設計の中に組織すべきである。
テスト部隊が各パートの未完成時期から全体の組合せテストを始めることにより、全体の整合性の事前確認が客観的に出来るし、遅れている部隊にハッパを掛ける事にも役立つ。
悪い実態にも気づかず、「単体テストは順調に進んでいます」と言うような楽観主義の早期是正にも役立つ。
独立テスト部隊は、テスト方式の設計をキチンとやるべきである。
本来多くのテストをしなければならないのに、限られた期間での選択したテストケースで品質を確保しようと言うことだから、シッカリした方式設計が必要である。
また、単位時間当たりに確認できるテストケースの数を稼がなければならないのだから、テストの実行も結果の確認も極力自動化できるようにしなければならない。
当然のことながら,テストプログラムの設計、テストデータの設計、テスト冶工具の設計も最初にやっておくべきことである。

テスト方式の設計に関しては、契約上の検収条件をキチンと把握し、検収に耐えうることを最低限のテスト条件として設計しなければならない。
検収条件は契約時にキチンと確認されていなければならないが、実際に検収試験を受けようとすると難しい問題が出てくることもありうる。
検収されないかぎり、契約は完了しないのだから、万一、検収に困難をきす事実が判明したら、速やかに関係者で善処策を協議すること。