『テストの7原則』と実務上の留意点

『テストの7原則』と実務上の留意点

『テストの 7 原則』とは

『テストの 7 原則』とはISTQBテスト技術者資格制度 Foundation Level シラバス(以下シラバスとする)に記載されている、ソフトウエアテストを行う上で共通して理解しておく必要がある一般的なガイドラインである。

本稿においては、シラバスに記載のあるテストの7原則を引用しながら、実務上生じやすい課題やソフトウエアテスト実施上の留意点などを例示する。

原則1 | テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
必要かつ充分だと考えられるテストケースを消化してもなお、対象範囲に欠陥(バグ)が存在しないことの証明とはなりません。
例えば本番稼働後に想定しえなかった処理や極めて稀な条件や特定の状況下でのみ欠陥が検知される、といったケースが起こりえます。

[ソリューション例]
テスト計画を策定し、テストカバレッジを高める工夫をすると同時に、リリース時および本番稼働後の障害対応について予め計画しておく必要があります。
機能の追加実装時やデバッグ後に該当箇所のテストだけではなく、リグレッションテストを実施するなどの対策を講じることで、欠陥を検出できる可能性を予め高めておくことが重要になります。

原則2 | 全数テストは不可能

すべてをテストすること(入力と事前条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
根拠なく「充分なテストを行った」と判断することや、反対にステークホルダーから「問題がないことを証明する」よう求められる

[ソリューション例]
プロジェクトスケジュールや工数は有限であることから、効果的なテスト計画を策定し実行することが肝要となります。
機能の重要度や、各工程における不具合検知率などからそれぞれのフェーズでどのようなソフトウエアテストを行う必要があるか常に検討・検証し、またプロジェクト関係者内で適切に開示・合意を行うことでステークホルダー間の合意形成や開発フェーズをまたがる手戻りなどを抑止することができます。

原則3 | 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
社外のソフトウエア開発会社に委託をされる際に、一般的には以下のような役割分担になることが多いです。
 ・要件定義と基本設計、および受入テストを自社で行う
 ・詳細設計、開発(コーディング)、単体・結合・システムテストを開発会社に委託
プロジェクトのスケジュールや工数に影響するような課題が、得てして結合テストやシステムテストで顕在化し、受入テスト時にはスコープやスケジュール調整、追加工数のリクエストが必要…となるケースが散見されます。

[ソリューション例]
・インスペクションを実施し、基本設計や詳細設計のフェーズから静的テストを実施することで要件漏れや記載の誤りを低減する

原則4 | 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。(原則 2 で触れたことと同様)。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
エンジニアのスキルが不足していたがレビュー可能なメンバーを配置できなかった、業務要件が複雑である、実装難易度が高い、プロジェクトのリソースなどに起因して充分な開発リソースを手当てできなかった、など様々な要因によって、問題が特定の領域に偏って発生することがあります。

[ソリューション例]
機能の重要度や、各工程における不具合検知率などからそれぞれのフェーズでどのようなソフトウエアテストを行う必要があるか常に検討・検証し、機能ごとにテストの実施内容の濃淡をつけるなど、テストにかかるリソースの最適化を検討する必要があります。

原則5 | 殺虫剤のパラドックスにご用心

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある(殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する)。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
開発した方がテストもあわせて対応される場合、該当の開発者の方の経験に依存してテストの観点やバリエーションなどの不足が生じてしまうことがあります。また、スケジュールなどのプレッシャーや大丈夫だろうといった思い込みなどから確認がおろそかになったりすることも起こりえます。

[ソリューション例]
開発者とQA担当者を分けておく、またはレビュープロセスを定義する、といった方法で、複数人でのレビュー、チェック体制を構築することでリスクを低減することができます。

原則6 | テストは状況次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
開発手法に応じたテスト、とくにアジャイル開発においてどのようにテストするかという点などはイメージがつきにくいこともあるかもしれません。

[ソリューション例]
アジャイル開発において、スプリント期間中にQA要員をチームに投入し、開発と並行してテスト(検証)を行う。

原則7 | 「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

陥りがちなポイントとソリューション例

[陥りがちなポイント]
欠陥を0にすることにこだわりすぎると、要件定義やソリューション選定時に保守的になりがちだったり、リリースまでに過剰なチェックポイントを設けるケースなども起こりえます。また、この原則は逆に「テストをしたから大丈夫」という慢心に陥ることも想定されます。

[ソリューション例]
前者については非常に難しい問題で、かつ大規模プロジェクトほど発生しがちな課題です。各フェーズでいかにビジネスとITがコミュニケーションや合意形成を行うかなど、様々な工夫が必要となります。
また、欠陥は0にならない前提でプロジェクトトランジッションや、本番稼働後の運用プロセスを規定することはとても重要です。リリース判定に紐づくテストについてもCIの観点から制度設計が求められます。

おわりに

完ぺきなソフトウエアが存在しえないように、完ぺきなソフトウエアテストもまた存在することが難しいのが現実です。
一方で、ソフトウエア開発の各フェーズにおいて適切な品質保証対策を講じることで、
成果物の品質を保ちながらプロジェクトにおける工数や納期を適切にコントロールしやすくなります。

そのためにはテスト計画や、それに基づいた各フェーズごとのテスト設計・実行が重要ですが、
それらはすべてこの7つの原則が前提になっていることをまず確認することが肝要です。

記事一覧へ