はじめに

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

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

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

テストの目的

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

• 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価
• 明確にしたすべての要件を満たしていること
• ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認
• 品質に対する信頼を積み重ねて、所定のレベルにあることを確証
• 欠陥の作りこみ防止
• 故障や欠陥を発見
• 品質レベルについての十分な情報を提供しステークホルダーの意思決定を助ける
• ソフトウェア品質のリスクレベルを低減
• 契約上、法律上、または規制上の要件や標準を遵守

要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価

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

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

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

明確にしたすべての要件を満たしていること

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

ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認

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

欠陥の作りこみ防止

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

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

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

故障や欠陥を発見

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

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

品質レベルについての十分な情報を提供しステークホルダーの意思決定を促す

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

ソフトウェア品質のリスクレベルを低減

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

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

• 回避
• 低減
• 受容
• 転嫁

契約上、法律上、または規制上の要件や標準を遵守

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

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

まとめ

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

• テストは単純作業（言われたことをやる）ではないこと
• テストはどうして、そのテストで問題ないか（どうしてそのテストをしようと思ったのか）を説明する重要なアクティビティであること
• バグがでたときは（なぜ挙げきれなかったのか）、どこでどうして漏れたのかフィードバックをして品質をよくするアクティビティ（の1つ）であること
• ステークホルダーの意思決定の情報を提供

参考

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Ver%20sion2018.J01.pdf
http://testerchan.hatenadiary.com/entry/2020/06/29/080000