ソフトウェア開発において、テストは欠かせないプロセスです。効率的かつ効果的なテストを実施するためには、基本的な原則を理解することが重要です。この記事では、ソフトウェアテストの7原則を紹介し、これらがなぜ重要であり、どのように活用できるのかを解説します。テストの質を向上させ、開発プロセス全体を強化するためのヒントを提供します。
ソフトウェアテストの7原則
ソフトウェアテストを行う上で理解しておくべき考え方をまとめたのが 『ソフトウェアテストの7原則』です。
ISTQBテスト技術者資格制度 Foundation Level シラバスに記載されており、ソフトウェアテストを行う上で理解しておく必要のある、世界共通のガイドラインです。
※要約(黄枠内)はISTQB(日本版：JSTQB) Foundation Level シラバスより引用
File1 テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。
テストを実施することで 「バグや欠陥」 を見つけることは出来ますが、どれだけテストを行っても、そのソフトウェアに 「バグや欠陥」 が無いと証明することはできません。言い換えれば、世の中にある全てのソフトウェアには 「バグや欠陥」が存在している可能性があるということです。『バグゼロのソフトウェアを開発した！』と豪語する開発者がいたり、『バグのないソフトウエアを作りたい』というお客様がいらっしゃったりしますが、それはほぼ不可能なことです。テストによって「バグや欠陥」が見つからない状態であっても、それをもって『一切の欠陥がない』とは言えないということです。
この後説明する原則に基づき、テストの目的を明確にし、その目的に沿ったテスト計画・設計・実行・分析を行うことで、テストの精度やテスト効率を上げていく活動は、とても大切なことです。
また、何をテストしたのか記録を残すことで「バグや欠陥」が見つからなかったところを明確に示すこともできます。
テストをして「バグや欠陥」が出てこなくなっても、行ったテストの記録を確認・分析し、その内容が適切だったか？テスト項目は十分だったか検討することも重要です。ウォーターフォール開発に適した開発プロジェクトは、要件が明確で変更の少ないものや、各工程が順番に進むことが求められるケースが多いです。以下のような特徴を持つプロジェクトに適しています。
File2 全数テストは不可能
すべてをテストすること(入力と事前条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。
よほど単純なソフトでないかぎり、全ての入力、状態、および環境の組み合わせをテストすることは不可能です。さまざまなシステムや機能と連動している場合には、その条件の組み合わせや遷移パターンなどを想定した場合、テスト項目は天文学的な数字となり実行するには、膨大な人員・期間・予算が必要になります。
テストを実施する際には、リソースや制約を考慮し、リスクに基づいて最適なテスト計画をたてる必要があります。例えば、モバイルアプリの場合、全てのデバイスやOSの組み合わせをテストすることは現実的ではないため、人気機種やシェアの高いOS・ブラウザなどに焦点を当てることが一般的です。
File3 早期テストで時間とコストを節約
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。
テスト活動は開発プロセスの早い段階から始めることが重要です。早期のテストにより、バグの早期発見や修正コストの削減が可能となります。例えば、アジャイル開発プロセスでは、要件定義の段階からテストを開始し、開発サイクル全体でテスト観点による取り組みをすることが一般的です。最近では、ウォーターフォール型の開発プロセスにおいても、アジャイル開発の観点を取り入れたテスト計画を適用するプロジェクトが増えています。
File4 欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。
テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則2で触れたことと同様）。
欠陥はソフトウェア全体に均等に散らばっているわけではなく、特定のモジュールに集中する傾向があります。
・ 特に複雑な構造の機能や難易度の高い処理
・ 過去に開発経験がない機能や、経験の浅いエンジニアにより設計・実装された箇所
・ 十分なレビューが行われていない機能
などが、欠陥が偏在する代表的な要因です。
テスト工程での不具合分析により、特定のモジュールに欠陥が集中していることが判明することもあります。また、以前のバージョンで欠陥が検出されたモジュールでは、他の箇所と比較して欠陥が検出される可能性が高いということも分かっています。
それらのデータに基づき、テスト計画をすすめることが重要です。
File5 殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。
ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
File6 テストは状況次第
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。
ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
ソフトウェアの性質や、開発スタイル（アジャイル型、ウォーターフォール型）により、テストの実施内容やテスト手法、スケジュールは大きく変わります。このテストのセットを行えば、完璧であるという万能なものはありません。
それぞれの開発環境や、テスト対象のソフトウェア、顧客の要望に合わせた柔軟で適切なテスト計画が必要です。
File7 「バグゼロ」の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
既出の原則１、2により、「バグゼロ」のソフトウェアは不可能ではありますが、たとえ機能的な欠陥を無くしたとしても、それだけで良い製品になるとは限りません。ユーザーのニーズや期待を満たしておらず使いにくかったり、性能面で他の競合システムより劣っていたり、セキュリティ対策が不十分であったりなど、品質向上の観点からすると「バグゼロ」＝高品質というわけではないのです。
まとめ
完璧で非の打ちどころのないソフトウェアが存在しないのと同じで、どんな開発環境でも対応可能な、完璧なソフトウェアテストは存在しません。
しかし、過去のテストエンジニアのノウハウがつまった「ソフトウェアテストの7原則」を深く理解し活用することで、より少ないコスト（時間）で、より品質の高いソフトウェアを作るためのテスト計画を提案することが可能です。
この原則に基づき、開発の各フェーズにおいて適切な品質検証対策（テスト計画）を行うことで、テストだけでなく開発における全ての工程での効率化や、ソフトウェアの品質向上が図れます。
