品質保証業務（その２：テストとは）

テストとは

システムに要求されていることが、正しく組み込まれていることを確認するための行為である。

新規／エンハンス／保守と言った何れの開発であろうと、開発作業の動機は「要求」である。

その要求を、どのように実現しているか、そこにテストの真価が問われる。
従って、「テストはエラーを見付ける」ことにその意義がある。
しかしながら現実には、そこまでテストされないことが多く、その理由は、テストの目的を勘違いしているからである。

「正しく動くことを確認する」という姿勢からは、効果的なテストケースが想定されない。
その結果、表面的な機能テストでは「ＯＫ」となるかも知れないが、限界・境界値や発生しうる特異データを試した途端に、実現の不十分さが露呈することになる。

そこで、事前にチェックリスト（PCL：Program Check List）を作成し、愚直に実施することが重要となる。

【テストと品質】
「テストで品質の向上を図る」という考え方の人がいるが、テストは、
プログラムが要求仕様を実現しているかどうかを確認する行為に過ぎない。
したがって、テストは仕様の確認行為であって、ここには品質を作り込む機会はない。

品質は、あくまでも仕様策定や、その仕様を実現すべく適切なデータ構造などの設計や、実装の作業の中で「作り込まれる」ものである。

実際に、データ構造の選択を間違えると品質を満たさない事が起きる。

その状態を発見することがテストであって、その時点では、品質は既に作り込まれている。

【テストの作業分析】
テストは、現実問題として省くことは出来ない。
設計の問題を含めて、テストのあり方を考えるのに、テストのどの作業に時間がかかっているか測ってみる。

現実のテスト作業を調べて、作業を定義すれば、時間などを記入するシートが作れる。

テストそのものに時間がかかっているとすれば、
・ それはテストの量が多いからか
・ 個々のテストに時間がかかっているからか。あるいは
・ エラーの修正作業に時間がかかっているのか

原因が、テスト仕様そのものが用意されていないことにあるとすれば、全く論外である。

【テスト者の心理】
設計者がそのテストを“簡単で、容易で、また自明”だと考えた瞬間から、
警戒心が薄れ、品質意識が軽視され、そして、多くのケースでテストが誤って行なわれるようになる。

これは、誤ったテストという形か、または考えもしなかった副作用という形で、結果が現れる。

特に厳しい状況では、“簡単だと思いたい”心理に陥り、厄介な問題なのである。