【初心者向け】ソフトウェア7原則について
テストを実行にあたって覚えておきたい項目にソフトウェアテストの7原則というものがあります。
ソフトウェアテストの7原則とは、『ソフトウェアテストの7原則』とはISTQBテスト技術者資格制度 Foundation Level シラバス(以下シラバスとする)に記載されている、ソフトウェアテストを行う上で共通して理解しておく必要がある一般的なガイドラインです。
テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 (PDF)
シラバスに記載のあるテストの7原則を解説します。
1. 原則１：テストは「欠陥がある」ことしか示せない
「テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。」
テストをおこなうことで、故障が起きれば、そのソフトウェアに欠陥があることは分かります。
また、その原因を究明すれば、欠陥を取り除くことができます。
しかし、そもそもテストをしても故障が起きなかった場合には、どうでしょうか？
もしかしたら、本当にそのソフトウェアには、欠陥がなかったのかもしれません。
しかし、そのテストではたまたま故障が起きなかっただけかもしれません。
その他にも、テストケースに漏れがあって、たまたま故障が起きる値でテストがされなかっただけかもしれません。
このように、テストでは「故障が起きた = 欠陥がある」という証明はできても、「故障が起きない = 欠陥がない」は証明することができないのです。
2. 原則２：全数テストは不可能
「すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。」
全数テストとは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。
しかし、入力条件の全組み合わせをテストするのは、テストケースが膨大になりすぎるため、単純な機能レベルのテスト以外では非現実的です。
そのため、実際のテストでは、ソフトウェアの性質や目的、使われ方、考えられるリスクなどにより、重点的にテストをおこなう場所を絞ったり、優先順位をつけたりしてテストをおこないます。
3. 原則３：早期テストで時間とコストを節約
「早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。（3.1節を参照）。」
ソフトウェアの開発において、欠陥は作りこまないことが理想ですが、人が作っている以上は、完璧なソフトウェアを開発することは不可能です。
もしも欠陥が紛れ込んでしまった場合には、欠陥が作り込まれた時期から欠陥が発見された時期の分だけ、その影響範囲は大きくなってしまいます。
そのため、いかに早く欠陥に気付けるかが重要となってきます。
4. 原則４：欠陥の偏在
「リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則 2 で触れたことと同様）。」
テストは、過去の欠陥分析や、直前のテスト結果などを参考に、欠陥位置を予測してテストの焦点を絞るのが良いとされています。
それは、不具合があった場合に、それがソフトウェア全体に均等に存在することは少なく、むしろ特定のモジュールに集中していることが多いからです。
一説には、ソフトウェアで発見される欠陥の8割は、ソフトウェア全体の２割に集中しているともいわれています。
5. 原則５：殺虫剤のパラドックスにご用心
「同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。」
害虫駆除にずっと同じ殺虫剤を使っていると、そのうち虫が耐性を持ち、殺虫剤がだんだん効かなくなります。
ソフトウェアテストにおいても同様で、同じテストケースを繰り返し行なっても新しい欠陥を摘出できなくなるということです。
対策として、各工程でテスト観点を変えたり、開発者目線だけでなくユーザー目線でテストを設計したりするなど、さまざまな観点でテストを行なう必要があります。
6. 原則６：テストは状況次第
「状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1 節を参照）。」
ソフトウェアの性質によってテストの実施内容や方法は大きく変わります。
自動運転のソフトウェアであれば安全が最優先となるよう十分にテストを行なう必要があります。
一方で社内用の簡単なツールであればテストはある程度行い、ユーザーに提供してからブラッシュアップしていく場合もあります。
これを実施すればどんなソフトウェアも完璧になる、という万能なテストは存在しません。
ソフトウェアそれぞれの特性を考慮してテストを行ないましょう。
7. 原則７：「バグゼロ」の落とし穴
「テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。」
「バグ0＝高品質なシステム」というわけではありません。極端な例ですが「バグ0です、でも画面表示するのに30秒もかかります」といったシステムは高品質とは言えません。
テストの目的は、ソフトウェアに欠陥がないことを証明することではなく、ソフトウェアの品質を評価することです。
テストで欠陥が見つからなくても、それはソフトウェアが完璧であることを意味しないため注意が必要です。
8. まとめ
完ぺきなソフトウェアが存在しえないように、完ぺきなソフトウェアテストもまた存在することが難しいのが現実です。
一方で、ソフトウェア開発の各フェーズにおいて適切な品質保証対策を講じることで、成果物の品質を保ちながらプロジェクトにおける工数や納期を適切にコントロールしやすくなります。