超(個人)訳JSTQB Foundation Level シラバス Part4

はじめに

前回はテストの目的とテストとデバッグの違いについて説明したが、今回は1.3 テストの原則の部分についてシラバス解釈を進めていく。

引用元について

テーマにある通り、ISTQBが提供するFoundation Levelシラバスを引用させて頂く。

1.3 テストの原則

これまで長い間にわたり、さまざまなテストの原則が提唱され、あらゆるテストで適用できる一般的なガイドラインとなってきた。本シラバスでは、そのような 7 つの原則を示す

このシラバスにはテストについての細かな知識は数多くあるが、原則と言われることもあり、これを覚えておくことで、テストを行うに当たっての状況判断や考え方で役に立ってくる。
また、開発やテストに関するドキュメントを読む時や、実際にテストを行う時にこの原則が頭に入っていることで、ソフトウェアテストに対する向き合い方が変わってくるかもしれない。

1.テストは欠陥があることは示せるが、欠陥がないことは示せない テストにより、テスト対象に欠陥があることは示せるが、欠陥がないことは証明できない（Buxton 1970）。テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できな
い。

テストで欠陥を見つけ、それらを全て修正したからといってソフトウェア内に欠陥がないとは言い切れない。もしかしたら、重箱の隅をつつくテストを行うことで微細な欠陥が見つかるかもしれない。
テストはあくまでソフトウェアの品質を評価する1つの方法であり、テストの完了がソフトウェアに潜む欠陥を全て見つけたことまでは担保できず、テストによって「欠陥がない状態」を示すことはできない。

では、どこまでテストを行えばいいのかという疑問が自然と出てくるはず。
そこはステークホルダーと協議の上、テスト計画の時点で目標とする品質に達成しているかを計測し、予算やスケジュールを鑑みてどの程度の欠陥は許容するかを決めておくのが理想である。
テストでは全ての欠陥が見つけきれないと知った上で、世に出てはいけない不具合をテストの段階でどうやって出すかを常に考えて業務に取り組む必要がある。

2.全数テストは不可能 すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である（Manna 1978）。全数テストの代わりに、テスト技法（第 4 章参照）、テストケースの優先順位付け（5.1.5 項参照）、リスクベースドテスト（5.2 節参照）を用いて、テストにかける労力を集中すべきである。

すべての条件を網羅するテストは実質不可能である。
実質と言い表したのも、1ケタの四則演算だけ行える電卓ソフトのような単純なソフトウェアであれば実現可能かもしれない。しかし、現在のソフトウェアは複雑化と大規模化が進んでおり、全数テストを行うためにテストの全ての条件を見積もるだけでも膨大な数となり、ほぼ不可能と考えても差し支えがない。
予算もスケジュールも限られた中で、全数テストを行うのがいかに非現実的で非効率かを把握してもらった上で、効率よく欠陥を検出するためにテストタイプやテスト技法を駆使し、欠陥を見つけるのがテスト実行者の役割である。

3.早期テストで時間とコストを節約 プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。SDLC の後半に発生する故障が少なくなるため、品質コストは削減される（Boehm 1981）。早い段階で欠陥を見つけるために、静的テスト（第3 章参照）と動的テスト（第 4 章参照）の両方をなるべく早い時期に開始すべきである。

早い段階でテストを行うことで、開発後期に欠陥が見つかることによるリスクを軽減される。
開発後期に出てくる欠陥は開発初期に出てくる欠陥と異なり、実装当時の記憶が飛んでいるケースもあり、欠陥の事象が深刻な場合、大幅な手戻りやリリース可否への悪影響が生じる。
開発仕様書等の作業成果物であれば、レビュー等の静的テストを早期に着手し、早い段階で欠陥を検出することで、開発後半に見つかる欠陥をきっかけとした大幅なやり直しを防ぐメリットがある。

4.欠陥の偏在 通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する（Enders 1975）。この現象は、パレートの法則を示している。予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる（5.2節参照）。

欠陥はあちこちに散らばっていると言うより、特定の場所や領域に集中しやすい。
何か欠陥を見つけた際は、見つけた欠陥をヒントに条件を少し変えてみたり、再現した手順に一手間加えてみることで、芋づる式に欠陥が発見されることがある。

5.テストの弱化 同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる（Beizer1990）。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテストを繰り返すことが有益な結果を示すことができる場合がある（2.2.3 項参照）。

同じテストをずっと使い続けることで、テスト実行による欠陥検出の見込みが段々と薄れてくる。
機能の追加・変更をきっかけに、テストもブラッシュアップすることで、これまでのテストでは出てこなかった欠陥が見つかるかもしれない。
余談だが、この原則名について前のシラバスでは「殺虫剤のパラドックスにご用心」という原則名だったが、現シラバスでは名称が変わってしまった。前の原則名の方が覚えやすかったなと。。

6.テストはコンテキスト次第 テストに唯一普遍的に適用できるアプローチは存在しない。テストは、コンテキストによって異なる方法で行われる（Kaner 2011）。

あらゆるテストで使うことができるアプローチは存在しない。
コンテキストは直訳すると「文脈」や「前後関係」という意味が出てくるはずだが、ソフトウェアテストにフォーカスすると、テスト対象のソフトウェアによって、状況に適したソフトウェアテストを行いましょうと自分は解釈をしている。
この記事を書いている時点で、自分もこの原則だけ何となくでしか分かっておりませんでした。
なので、そういう時は先人たちの解説を参考にしましょう。
秋山浩一氏の記事がとても分かりやすいため、是非ご一読を薦めたい。

7.「欠陥ゼロ」の落とし穴 ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである（Boehm 1981）。

欠陥を全て修正した状態がユーザーが望むソフトウェアとイコールになるとは限らない。
「要件が全て実現されていること」というのはあくまでソフトウェアを作る側の視点であり、この視点だけだと、ユーザーが望むものが何であるかという視点が欠けており、出来上がったものを提供しても、ユーザーから必要とされないと見なされてしまうことがある。
こうした事態を避けるため、テストにおいては要件が全て実現していることの検証に加え、「ユーザーが期待していることは何か？」という妥当性確認も並行して行っていく必要がある。

おわりに

次回はテスト活動を中心に取り上げていく。
現状は週1ペースを目標に投稿していきます。