徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第3弾。
テストに共通するガイドライン（原則）
原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない
品質保証（QA）は品質が合格レベルでに達していることを示す作業ではあるけれども、完全に欠陥がないとは保証できない。
原則2：全数テストは不可能
ソフトウェアは、条件分岐で通るロジックが変わる。システムによっては条件分岐は山のようにあるため、全ての組み合わせをテストしようとすると、分岐数のべき乗となり膨大な数になる。分岐ごとに関連ありそうなものは組み合わせでテストするが、それ以外は分岐単独でテストするのに止めることになる。
境界値分析
例えば、商品の合計が500円以上か未満かで分岐するとした場合、500円になる値と499円になる値だけを試すテスト技法のこと。
全数テスト
入力値と条件の全てを組み合わせるテストのこと。
入力値と条件分岐の組み合わせまで考えると天文学的な数字になる。そのため、これは非現実的なものだとして割り切る必要がある。
その代わりに、リスク分析・テスト技法・テストの優先度などをもとにして、テストにかける労力を削減するべし。
原則3：早期テストで時間とコストを節約
早期テストとは、ソフトウェア開発ライフサイクルのなるべく早い時間（上流）にテストすることを意味する。シフトレフトともいう。早い段階でテストすればするほど、まだ欠陥の数が少ないため、1つの欠陥が多くのコンポーネントに入り込むのを未然に防ぐに防ぐ事ができ、コスト削減につながる。
原則4：欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定のモジュールに集中する。モジュールの数や人のスキルに依存する場合もある。
欠陥の偏在の傾向を見つけると、効率良くテストすることができる。 そのため、テストや運用における欠陥の発生状況をもとにリスク分析し、どこを集中的にテストすればいいかを予測する。
原則5：殺虫剤のパラドックスにご用心
同じ殺虫剤を使い続けると、虫に耐性ができて効きにくくなるということ。
テストで言えば、「同じテストを何度も繰り返すと、最終的にはそのテストで欠陥を見つけられなくなる」ことだ。例えば、境界値分析は条件分岐の毛感を見つけやすいため、これを徹底的に行なって欠陥を修正すれば、条件分岐の欠陥は見つからなくなる。しかし、入力値に値が入っていない（NULLの状態）場合、や意図しない文字種などを入力してみないと、NULLや文字種のバリデーション（妥当性）に関する欠陥は残ったままになる。
欠陥には様々な種類があるため、色々なテストパターンやテストデータを試す必要がある。
原則6：テストは状況次第
状況が異なれば、テストの方法。
システムの適用分野
例えば、安全性が重要産業用制御ソフトウェアでは、フェールセーフ（以上が発生した場合に安全側に動作する）が機能するかを重点的にテストする。また、利用者の数が一定でないeコマースシステムでは、キャンペーンなどでアクセスが急増した際の負荷テストを重点的に行う。
システムの用途によってテストで重視するポイントが異なる。
システムの開発手法
アジャイル開発とウォーターフォール開発では、テストの実行方法が異なる。
アジャイル開発では、イテレーション（開発サイクルのこと）ごとにテストを行なってリリースする。ウォーターフォール開発では、開発フェーズが終了した後にまとめてテストを行う。
このように、開発手法によってテストをするタイミングが異なる。
原則7：「バグゼロ」の落とし穴
よくある思い違い（落とし穴）には以下がある。
- テスト担当者は、可能なテストを全てを実行できる
- テスト担当者は、全ての欠陥が検出できる
- 大量の欠陥を検出して修正すれば、システムを正しく構築できる。
この3つは、１+２=３という関係になります。
つまり、徹底的にテストして（1）、可能な限りの欠陥を全て検出し（2）、それらの欠陥を全て修正すれば、ただしシステムとなる（3）という考え方である。
しかし、これらは全て思い違いだ。
次回