はじめに

ソフトウェアテストというと、後工程で作ったものを動作させる認識が多い。
もちろん、出来上がったものを動作させるテストも重要である。

ただ、それだけで終わるのであれば、製造（コーディング）している人がテストしているのと大して変わらない。
そうなると残念なテストだと思う。

それぞれシラバスや本には書かれている通りではあるが「テスト」と「チェック」の作業（アクティビティ）とは違うということを念頭に、テストの目的を自分なりに考えて整理をしてみた。

テストの目的

JSTQBのシラバス（JSTQBの本）には以下のように書かれている。

テストはモノだけをターゲットに実施する作業（アクティビティ）ではなく、要件、仕様（開発設計、テスト設計）、開発物全てに対して評価をすることが大切。

局所的にモノだけをみていると、そもそも要件と合わないという事態が発生する。
そうなると、時間をかけて実装した機能やモジュールなどは役に立たないものとなる。これではだれも幸せになれない。

こういうことを防ぐためにも、全ての成果物を評価する必要がある。

要件を満たしていることも大切。
盲目的に成果物のみを評価することにもつながるが、局所的にテストしていたら要件を満たしているか見えなくなる。

要件を満たしているかどうかだけの場合、本当に必要だった機能かを判断することが難しい。
よくある風刺画にあるが、そもそも期待していたものか判断しなければならない。

修正に伴って怖いのはデグレ。元の機能の動作が変わったり、動作しなくなったり。
これが発生すると、もぐらたたきの状態になり、あっち直したらこっちがおかしくなるなど手に負えなくなる。
これを防ぐためにどこに波及するかを考えてテストしなければならない。

また、「欠陥」とは「コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備」とある。
「欠陥」は「エラー」により発生するものであり、「エラー」とは、「間違った結果を生み出す人間の行為」である。

つまり、要件定義、仕様、製造（プログラム）において全てのエラーを防止することが大切でテストのアクティビティである。

テストのメインのアクティビティではあるが、故障や欠陥が「0」はないはずである。（テストの7原則の1つ）
故障や欠陥はあることを示してリスクを示すものとしなければならない。

欠陥はプログラムだけではなく、仕様などのドキュメントにも含まれている可能性はある。

リリース判定というと厳粛な感じがするが、リスクを示してステークホルダーの意思決定を促したり助けたりすることが大事である。
何もなし（テストしましたー、終わりましたー）では、どのような品質が保てているのか、リリースしてもいいのか、使っても大丈夫なのか判断ができない。

「故障や欠陥を発見」にもあるが、リスクを示せないテスト（というアクティビティ）は、単なる確認作業である。

リスクを低減するだけはなく、リスクのあり方を考えてステークホルダーのリスクに対する以下の意思決定に役立つ情報を収集する必要がある

製品によって安全性などの基準があったり、ライセンスなどの契約なども確認して、その基準に満たしているかを確認する必要がある。

便利だからといって利用していた環境やライブラリなどが商用では有償だったなどのライセンス違反をしていたなど、故意ではなかったとはいえ会社、組織などの信用は著しく低下する。（それぐらいの意識でしかないのかっと思われる）
このようなことが発生を防ぐこともテストの重要な役割である。

局所的にバグを修正したことだけ、その機能やモジュールの近しい周りを見ただけのテストで終わるのは、テスト（というアクティビティ）とは言えないということで、以下のようなことを考えないとテストとは言えないんじゃないかと考えた