【QA】ソフトウェアの品質を上げたい人が知るべき「テストの7原則」とは
アプリ開発、サービス開発をしていて、次のような悩みを持ったことは有りませんか？
- どのくらいテストしたらいいか分からない
- ちゃんとテストできているのか分からない
- リリース後にバグが多く、ちゃんとテストできているか確認したい
こういった悩みを解決するきっかけになる『テストの7原則』を紹介します。
立場別『テストの7原則』を知るメリット
マネージャー、ディレクター等の全体を見る立場の人の場合
- バグはゼロでなければならないといった極端で実現不可能な考えをしなくて済む
- 商品の品質を上げようとした時にテストエンジニア・QAエンジニアと同じ目線で議論できる
- チーム全体での品質アップに必要な要素を知ることができる
現役のテストエンジニア・QAエンジニアの場合
- 自分の経験を言語化できる
- 言語化により、客観的に分析することで、今後必要なアクションを考えられる
新人テストエンジニア・QAエンジニアの場合
- テストする時の心構え、大前提がわかる
この7原則だけでテストスキルが上がるわけではありませんが、7原則を意識して業務に取り組むだけで成長速度がグンッと上がります！
『テストの7原則』
テストは欠陥があることは示せるが、欠陥がないことは示せない
テストをして分かることは、実施したテストでバグが出たか出なかったかの2つです。
テストケース外の観点や条件でバグが無いことを証明することはできません。
そのため、「これだけの数のテストをしたから大丈夫」ではなく、
「少なくとも、このケースでは問題無かった」と考えましょう。
そして、品質を高めるためには、「何件のテストケースを消化した」よりも、
「どんな内容のテストをしたか」が重要です。
全数テストは不可能
入力パターンと前提条件の組み合わせを全てテストすることは、ごくごく単純なシステム以外では非現実的です。
例えば、
1~5までの数字から2つ選んで足し算するといった単純なシステムなら組み合わせパターンは網羅できます。
５個から2個選ぶ組み合わせは10通り
ですが、これが1~10までの数字になると45通り
1~100だと4950通りです。
数字の選び方が選択ではなく、自分で入力できるようになっているなら、
範囲外の数字が入力された時にエラーとなる事も確認しないといけません。
通常、リリースされる製品はこんな単純なシステムではなく、
複数の条件が影響し合うような複雑なシステムなので、
限られたテスト期間中に組み合わせパターンを網羅することは不可能です。
※ こうした網羅的なテストをしない為に、入力されるデータや影響する状態をセグメント分けしてテスト項目を作成します（同値分析・境界値分析）
早期テストで時間とコストを節約
バグは見つかるフェーズが早ければ早いほど手戻りの工数を小さくすることができます。
（テストフェーズで仕様に関する不備が見つかると仕様決定からやり直し）
効率よく品質を高めるには、開発フローにおける各フェーズでしっかり品質を確保することが重要になってきます。
欠陥の偏在
バグはシステム全体に散らばっているのではなく、特定の機能/モジュールに集中していることが多いです。
そのため、過去の不具合を分析してバグが良く起きる条件を知っておくと、効率よくバグを発見できます。
殺虫剤のパラドックスにご用心
同じ殺虫剤を使い続けていると、いずれ虫の方に耐性ができてしまい、殺虫剤が効かなくなってしまうことから例えられています。
ソフトウェアのテストでも、同じテストばかりしていると、そのテストからは新しいバグは見つからなくなります。
そのため、機能に合わせて新しいテストケース、テストデータでテストを実施する必要があります。
※ リグレッションテストや自動化したテストは既存機能がデグレしていないか確認することが目的となるため、過去と同じテスト内容でも目的を達成できます。
テストは状況次第
テストの内容や実行方法は、開発するシステムの特徴や使用環境、開発手法によって変わります。
安全性が重要視される産業用の制御ソフトと、情報提供を目的としてWebサービスでは重要視するテストの内容は異なります。
また、ウォーターフォール型の開発するのか、アジャイル開発を採用するのかでも、実施タイミングは変わってきます。
「バグゼロ」の落とし穴
システムの発注者やプロジェクトオーナーのような立場の人は、バグをゼロにして欲しいという要求を持っていることが少なくないです。
ですが、100％どこにもバグが無いことを証明することは不可能です。
（原則1：バグが無いことは示せない、原則2：全数テストは不可能より）
また、バグを出さないことにこだわりすぎるあまり、仕様や機能選定が開発者目線のみの観点で選ばれてしまい、ユーザビリティが低いものになってしまう。
といったケースも発生します。
リリース後にバグを出したくないのは皆同じですが、それを証明することも、実際にバグをゼロにすることも不可能だということを認識した上で、運用プロセスを規定することが重要です。
テスターに関して言えば、バグはゼロにできないからといってテストが甘くなってはいけません。
バランスが難しいですが、僕はテスト中はバグゼロを意識してテストをするようにしています。
まとめ
- テストは欠陥があることは示せるが、欠陥がないことは示せない
- 全数テストは不可能
- 早期テストで時間とコストを節約
- 欠陥の偏在
- 殺虫剤のパラドックスにご用心
- テストは状況次第
- 「バグゼロ」の落とし穴
『テストの7原則』は知ってもすぐに効果が出るような特効薬ではありません。
ですが、品質に関わる全ての人に知っておいて欲しい内容です。
『テストの7原則』に沿って、自分のプロジェクトに足らない部分を抽出し、効率よくテストしましょう。
Discussion