はじめに
前回から少し時間が空いてしまいました。
前回の記事ではソフトウェアテスト7原則のうち原則1から原則3まで触れました。
今回は残りの原則4から原則7を見ていきたいと思います。
ソフトウェアテストにおける7原則については、JSTQB-FL1のシラバス2に沿ってご紹介しています。
*引用する内容は日本語版Version 2023V4.0.J01のシラバスを参考にしています。
ソフトウェアテストの7原則
7原則の一覧はこちらです。
（ちなみに、5、6、7についてはシラバス改訂で表現が変わったようなので補足しておきます。今後の追加改訂などで表現が見直されるかもしれません。）
| ＃ | 原則 | 旧シラバスでの表記 |
|---|---|---|
| 1 | テストは欠陥があることは示せるが、欠陥がないことは示せない | - |
| 2 | 全数テストは不可能 | - |
| 3 | 早期テストで時間とコストを節約 | - |
| 4 | 欠陥の偏在 | - |
| 5 | テストの弱化 | 殺虫剤のパラドックスにご用心 |
| 6 | テストはコンテキスト次第 | テストは状況次第 |
| 7 | 「欠陥ゼロ」の落とし穴 | 「バグゼロ」の落とし穴 |
では、原則4からの続きです。
原則4：欠陥の偏在
シラバスに書かれている内容を引用します。
通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する。
この現象は、パレートの法則を示している。
予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、
リスクベースドテストの重要なインプットとなる。
JSTQBでは「欠陥」と「故障」を明確に使い分けています。
人間のエラー（思い込みなど）が欠陥を生み、欠陥によりシステムなどの故障を引き起こすと定義しています。
（詳しくはシラバスの 1.2.3 エラー、欠陥、故障、および根本原因をご覧ください。）
この原則では、故障（いわゆるシステムの不具合）となる欠陥は特定のモジュールに集まっていると謳っています。
パレートの法則（2:8の法則や働きアリの法則とも呼ばれますが）に沿って、欠陥などの情報をきちんと取得してみると、システム全体を見た時の2割の箇所に約8割の欠陥が潜んでいるということです。
状況をよく観察することで、有限な開発リソースをどこに集中すべきかを見極めるのに役立ちますね。
原則5：テストの弱化（殺虫剤のパラドックスにご用心）
シラバスに書かれている内容を引用します。
同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる。
この影響を克服するため、テストとテストデータを変更したり
新規にテストを作成したりすることが必要になる場合がある。
しかし、例えば、自動化されたリグレッションテストのように、
同じテストを繰り返すことが有益な結果を示すことができる場合がある。
例えば新しい機能の追加や既存機能の改修があった場合、前回使用したテスト仕様書、テスト項目、テストデータを再利用するだけでは、新しい不具合を見つけることができません。
追加や改修の内容に応じてきちんとテスト内容を検討しないと、うっかりすり抜けてしまう不具合が発生します。
「しかし」以降については、リグレッションテストつまり機能追加や改修によって副作用（デグレや、思わぬ悪影響）が出ていないかを確認するために、同じテストを繰り返し行うことは有効です。
とはいえ、リグレッションテストは開発が進みシステムが大きくなるにつれ労力もかかるようになります。
人の手で確認ができる範囲を超えてしまいますので、開発当初からテストの自動化を検討すべきです。
原則6：テストはコンテキスト次第（テストは状況次第）
シラバスに書かれている内容を引用します。
テストに唯一普遍的に適用できるアプローチは存在しない。
テストは、コンテキストによって異なる方法で行われる。
つまり・・・
銀の弾丸はない
ということです。
ソフトウェアテストに限らず、つい『万能な方法』を探してしまいますが、我々開発者はコツコツと自らの知識や経験を積み重ね、技術力を高めるほかありません。
原則というのは言われてみれば当然のことで、テストに限らず開発者やそのマネジメントはきちんとシステムに向き合い、「このシステム開発において、またはリリース後、何が起こると困るのか？」や「今回の開発体制では何がどれだけ必要か？」を常に考え、適切な対応をとることが大切です。
テスト活動に関して言えば、『今回の機能は新しくアサインしたメンバーにも開発に携わってもらうので、仕様検討や、設計フェーズから業務知識周りの確認含めて前回よりも厚くしよう』といった判断も必要となります。
原則7：「欠陥ゼロ」の落とし穴（バグゼロの落とし穴）
シラバスに書かれている内容を引用します。
ソフトウェアを検証するだけでシステムを正しく構築できると期待することは
誤り（つまり、思い込み）である。
例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、
ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、
およびその他の競合システムに比べて劣るシステムが構築されることがある。
検証に加えて、妥当性確認も実施すべきである。
システム開発では「機能要件」と「非機能要件」を考える必要があります。
どんなにテストを行い「機能要件」を満たしたとしても「非機能要件」を満たしていなければお客様に満足していただけませんし、言語化されていない要件を見落としている場合もあります。
システム開発では「お客様を満足させるには何が必要か」をいかに見落とさないかが重要となります。
新しくなったシラバスの原則7には書かれていませんが・・・
以前のシラバスまでは、前回の記事に書いた原則1欠陥がないことは示せないと、原則2全数テストは不可能からも『欠陥をゼロにすることはできない』ということが書かれていました。
しかし、新しいシラバスでその記載がないということは、
『システムは顧客のビジネスに貢献することが最も重要な目的である』
ということを特に強調したいのではないかと思います。
おわりに
前回の記事と合わせてソフトウェアテストの7原則をご紹介しました。
皆さんがこの当たり前ともいわれる原則に沿った考え方を意識することで、ソフトウェア品質向上に貢献できればと思います。
『アジャイルソフトウェア開発宣言やその背後にある12の原則』などとの関係性や類似性などに気付かれた方もいらっしゃるかと思いますが、また別の機会にお話ししたいと思います。
所属部署について
ITエンジニアが活躍する地方拠点「長崎 Innovation Lab」
長崎 Innovation Labでは、IT技術を活用して、工場などものづくりの現場で活用できるシステムの開発に取り組んでいます。自由な発想でこれまでにない社会に役立つ製品・サービスを生み出し、長崎から発信していくことを目指しています。
-
日本におけるソフトウェアテスト技術者資格の１つで、FoundationLevel（基礎レベル）のこと。 ↩