【JSTQBシラバス解説】新ソフトウェアテストの7原則

ようこそ！テストエンジニア大学へ！

まずは新しくなったソフトウェア7原則をご覧ください。
2018年のシラバスと比べると、タイトル部分が2023年版は解りやすく改良された印象です。
中身はそれほど変更されていません。

Version 2018V3.1.J03(旧)	Version 2023V4.0.J01(新)
1.テストは欠陥があることは示せるが、欠陥がないことは示せない	1.テストは欠陥があることは示せるが、欠陥がないことは示せない
2.全数テストは不可能	2.全数テストは不可能
3.早期テストで時間とコストを節約	3.早期テストで時間とコストを節約
4.欠陥の偏在	4.欠陥の偏在
5.殺虫剤のパラドックスにご用心	5.テストの弱化
6.テストは状況次第	6.テストはコンテキスト次第
7.「バグゼロ」の落とし穴	7.「欠陥ゼロ」の落とし穴

詳しくは以下で1つずつ解説していきますので、見ていきましょう！

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

テストにより、テスト対象に欠陥があることは示せるが、欠陥がないことは証明できない（Buxton 1970）。
テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

テストエンジニアリングの領域では、ある概念が非常に重要です。
それは、テストをしても「完全な正しさ」や「絶対にバグがないこと」を証明することはできない、というものです。

具体的な例を用いてこの考え方を簡単に説明してみましょう。

例：レストランでのオーダー

あなたがレストランでウェイターとして働いているとしましょう。
お客さんから注文を受け、それをキッチンスタッフに正確に伝えるのがあなたの仕事です。
テストの世界で言うなら、あなたが「システム」、お客さんのオーダーが「入力」、そしてキッチンから出てくる料理が「出力」です。

•   シナリオ1： お客さんが「ハンバーガー」を注文しました。あなたはキッチンに「ハンバーガー」を頼み、キッチンは正しい料理を提供します。これは正常なケースで、すべてが順調に行きました。
•   シナリオ2： お客さんが「ベジタブルピザ」を注文しましたが、あなたはキッチンに「ペパロニピザ」を頼んでしまいます。ここにバグが存在しています。

テストエンジニアリングでは、我々はシナリオ2のようなケースを見つけ出そうとします。
ある意味で、お客さんの期待と実際に提供される料理（出力）のズレ、つまり「バグ」を見つける活動がテストです。

でも、考えてみてください。レストランが何千回、何万回とオーダーをこなしても、それが全て正しくいったとしても、次のオーダーでミスがないと断言できますか？答えは「ノー」です。
なぜなら、新しいオーダー（新しいテストケース）が新しい課題（新しいバグ）を引き起こす可能性が常にあるからです。

テストは制約がある

•   テストは時間とリソースが限られています。全てのオーダー（テストケース）を考え、チェックすることは現実的には不可能です。
•   何千回、何万回とテストをしても、次にくるテストケースでバグが発見されない保証はありません。

したがって、テストはシステムに存在するバグを「見つける」活動ですが、システムが100%バグフリーであることを「証明」するものではありません。
私たちはバグが見つからなかったとしても、次のテストで新しいバグが見つかるかもしれないと常に認識しておく必要があります。

私たちテストエンジニアは、このリアリティを理解し、可能な限り多くのバグを見つけ、それを修正して、システムをできるだけ「信頼性の高い」ものにすることを目指します。
私たちの目標は、システムがユーザーにとってできるだけ価値のあるものになるように、リスクを最小限に抑え、品質を高めることです。

2.全数テストは不可能

すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である（Manna 1978）。
全数テストの代わりに、テスト技法（第 4 章参照）、テストケースの優先順位付け（5.1.5 項参照）、リスクベースドテスト（5.2 節参照）を用いて、テストにかける労力を集中すべきである。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

どんなに複雑で難解なソフトウェアであっても、すべてをテストすることは非現実的です。複雑だから全てテストして問題がでないようにするんじゃないの？と考える方も多いと思います。
ですが、システムが大規模かつ複雑になるほど、すべての可能性や状況をテストするのは膨大な時間とリソースが必要になります。
これを具体的な例として説明しますね。

例：アミューズメントパークの運営

あなたがアミューズメントパークのマネージャーだと想像してみてください。
このパークには多くのアトラクションやレストラン、ショップなどがあり、さまざまなシチュエーションでお客様とスタッフがやりとりをします。
ここでシステムの「テスト」を行うとは、一つ一つのアトラクションやショップで起こり得るすべてのシチュエーションをチェックすることとします。

• シナリオ1： アトラクションの乗り物が定員どおりに乗車しているか
• シナリオ2： ショップでの商品の支払いやおつりの処理が正しいか
• シナリオ3： レストランで注文から料理の提供までのフローがスムーズか … などなど

これらのシチュエーションは無数に存在し、すべてを確認するのは現実的でないのが分かりますよね？

このような状況で、私たちが重要だと考えるのは、「効果的なテスト」をどうやって実施するかです。
以下がポイントとなります。

1. テスト技法を適用する：
   テスト技法、つまり「どのようにしてテストを行うか」の方法論を適用します。
   例えば、過去に問題が多かったエリアや、利用者が多いエリアを重点的にテストするなど、経験やデータに基づいて方法を選びます。
2. テストケースの優先順位をつける：
   すべてをテストできないのであれば、何を最初にテストすべきかを決める必要があります。
   もし、ジェットコースターが故障した時の影響が大きいのであれば、これを高優先度でテストします。
3. リスクベースドテストを行う：
   「リスク」をベースにテストを行います。
   もしアトラクションの事故が起きると大きな問題になるため、安全性の確認を最優先にします。
   一方で、ショップでのおつりの間違いは重要ですが、事故ほどのリスクではないため、こちらは少し後回しになるかもしれません。

このようにして、限られたリソース（時間や人員）を最も重要なポイントに集中させ、可能な範囲で最大の効果を得るようなテストを計画・実施します。これが、テストエンジニアリングにおける戦略的なアプローチとなります。

3.早期テストで時間とコストを節約

プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。
SDLC の後半に発生する故障が少なくなるため、品質コストは削減される（Boehm 1981）。
早い段階で欠陥を見つけるために、静的テスト（第3 章参照）と動的テスト（第 4 章参照）の両方をなるべく早い時期に開始すべきである。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

SDLC（Software Development Life Cycle）とは：
ソフトウェア開発ライフサイクルのことで、ソフトウェア開発プロジェクトが、計画からメンテナンスまで、通常進む一連のフェーズを指します。
具体的には、要件定義、設計、実装、テスト、デプロイ、運用、メンテナンスと進んでいきます。

静的テストとは：
コードを実行せずに行うテストで、コードのレビューやウォークスルー（コードを複数人で読み合う活動）、インスペクションなどが含まれます。
例えば、プログラムコードの書き方が正しいか、設計ドキュメントが要件を満たしているかなど、紙の上（あるいは画面上）でチェックを行います。

動的テストとは：
コードを実際に実行して行うテストで、単体テスト、結合テスト、システムテストなどが含まれます。
実際にシステムを動かし、期待した通りの動作をするか、期待した通りの出力が得られるかなどをチェックします。

テストにおいて、プロジェクトの初期段階でバグや問題点を見つけ出し、修正することは大変価値があります。
なぜなら、欠陥が残っている時間が長くなればなるほど、それによって起こされる連鎖的な問題や、修正コストは増大していくからです。

例：家の建築

あなたが家を建てるプロジェクトを進めることになったとしましょう。

• 早い段階の欠陥発見：
  土地を購入し、基礎を作っている段階で、土地が不安定であることが判明したとします。
  ここでこの問題を見つけ、修正することで、後々の家が傾くという大きな問題を防げます。
• 後期の欠陥発見：
  一方で、もし家がほぼ完成した段階で、基礎が不安定であることに気づいたら？
  家全体を安定させるための巨大なコストがかかりますし、修正作業で家の他の部分も影響を受けるかもしれません。

この例からも分かるように、問題（欠陥）を早い段階で解決してしまえば、後の作業でその問題が引き起こす新たな問題を未然に防ぐことができます。

4.欠陥の偏在

通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する（Enders 1975）。
この現象は、パレートの法則を示している。予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる（5.2節参照）。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

偏在（へんざい）とは：
特定の場所や範囲に集中している状態を指します。
ソフトウェアのコンテキストでは、バグや欠陥が特定のコンポーネントや機能に集中している現象を指します。

システムコンポーネントとは：
システムコンポーネントとは、システムを構成する個々の部品や機能のことを指します。
例えば、ウェブアプリケーションの場合、ログイン機能、検索機能、ショッピングカート機能など、それぞれが個別のコンポーネントとなります。

パレートの法則とは：
パレートの法則（または80/20の法則）とは、ある現象や状況において、全体の80%の結果が、全体の20%の要因によって生み出される、とする経済学的な法則です。
ソフトウェアテストにおいても、全体の80%のバグが、コードの20%に存在するという指摘がされることがあります。
リスクベースドテストでは、このパレートの法則を参考に、問題が最も多いと予測される部分を重点的にテストし、バグを早期に検出・修正することで、プロジェクト全体の品質を高めていきます。

経験豊富なテストエンジニアとしてお話しすると、ソフトウェアやシステムにおけるバグや故障は、実はその全体の一部分に集中していることがよくあります。
これを認識し、理解することで、私たちはテストの戦略を効果的に計画することができます。

例：都市の交通課題

例として、大きな都市の交通課題を考えてみましょう。

この都市にはたくさんの交差点がありますが、交通渋滞や事故が起こる場所は特定の交差点やエリアに偏っています。これは、通行量が多い、信号のタイミングが適切でない、道路の構造上の問題など、さまざまな要因によるものです。都市計画者としては、リソース（予算、人員）が限られているため、まずはこれらのトラブルが多いエリアに焦点を絞り、改善策を考えると効果的ですね。

システムテストにおける適用

この原理をソフトウェアテストにも適用できます。
システム内の特定のコンポーネントや機能が、バグを多く生む可能性があり、これを早い段階で特定し、テストの焦点をそこに絞ることで、限られたリソースを最も効果的に使うことができます。
これはリスクベースドテストの核となる考え方であり、最もリスクの高い部分からテストを始めることで、プロジェクト全体の品質を向上させることができます。

5.テストの弱化

同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる（Beizer1990）。
この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテストを繰り返すことが有益な結果を示すことができる場合がある（2.2.3 項参照）。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

リグレッションテストとは：
リグレッションテストとは、ソフトウェアの変更を確認するテスト手法です。ソフトウェアに新しい機能を追加したり、バグを修正したりすると、その変更が他の部分に悪影響を与えていないかを確認するために、過去に実施したテストケースを再実行します。自動化ツールを利用することで、多くのテストケースを効率的に実行でき、変更によって新しくバグが発生していないかをチェックするのに有益です。

同じテストを何度も行うことには一定の意義がありますが、新しいバグを見つける効果は、時間と共に減少していくのが一般的です。
新しいバグを発見する→修正→新しいバグを発見する→修正と初めのうちは明らかなバグを見つけられるかもしれませんが、その後は同じテストを実施しても新しいバグはなかなか発生しない可能性が高いです。
以下に例を書きます。

例：掃除機でのホコリの掃除

例えば、掃除機を使って部屋の掃除をすることを考えましょう。
最初に掃除をすると、床に散らばったホコリやゴミはきれいに吸い取られます。
ですが、同じ場所を何度も何度も掃除しても、最初ほどのホコリやゴミはなく、掃除機が吸い取るものは減っていくはずです。
新しいホコリやゴミを効果的に吸い取るためには、別の場所を掃除するか、別の方法（例えばモップ）を試してみる必要があります。

同様に、テストも最初は多くのバグを見つけるかもしれませんが、同じテストを続けていると新しいバグの発見が難しくなります。
ですから、テストケースを新しく作成したり、既存のテストデータを変更してみたりすることで、新しい視点からシステムをテストすることが大切です。

一方で、システムに変更が加えられたとき、以前のバグが再び現れていないかをチェックするために、同じテストを繰り返すことは非常に価値があります。これが「リグレッションテスト」です。

テストエンジニアとしては、新しいバグを効果的に見つける方法と、既知のバグが再発していないかを確認する方法、両方をバランス良く実施することが、ソフトウェア品質を保つ上で非常に重要です。

「殺虫剤のパラドックスにご用心」
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 Version 2018V3.1.J03
上記の古いバージョンのシラバスではこちらの項目は「殺虫剤のパラドックスにご用心」として説明されていましたが、新バージョンからは「テストの弱化」に変更になりました。
大きく文言が変更されていますが「どう表現するか。」が変更になっただけで中身は同じです。

6.テストはコンテキスト次第

テストに唯一普遍的に適用できるアプローチは存在しない。テストは、コンテキストによって異なる方法で行われる（Kaner 2011）。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

普遍的（universal）とは：
普遍的とは、どのケースにも当てはまる、すべての状況や条件に適用可能なものを意味します。
たとえば、普遍的な真理は、あらゆる状況や文化、時間において真実であるとされるものです。

コンテキスト（context）とは：
コンテキストとは、何かを理解したり評価したりする際の背景や状況のことを指します。
コンテキストは、私たちが物事をどのように捉え、どのようにアクションを起こすかに大きな影響を与えます。
例えば、同じ言葉でも、話す状況（コンテキスト）によって意味が変わることがあります。

テストエンジニアとして私たちが日々行うテストは、プロジェクトや製品、チームや利用されるテクノロジーによって、その方法が大きく変わることがあります。
テストが一つの「正解」や「万能なアプローチ」に囚われることはないのです。これは、テストが行われる各状況（コンテキスト）において、異なる課題やニーズ、制約が存在するためです。

例：料理のテイスティング

考え方を「料理のテイスティング（味見）」のシンプルな例で書いてみます。
ある料理人がスープを作っていて、それが適切な味付けがされているかをチェックするとき、彼/彼女はスープを少し味見しますよね。
では、もし彼/彼女がアイスクリームを作っているとしたら、テイスティングのアプローチは同じでしょうか？
おそらく違います。なぜなら、スープとアイスクリームでは、味のバランスや食感、冷たさなどをチェックするポイントが異なるからです。

同様に、ソフトウェアテストも、テストするアプリケーションの種類や使用技術、開発メンバー、プロジェクトのスケジュールやバジェット、リリースする製品のリスク等々、多くの要因によって最適なアプローチが変わります。
例えば、銀行のシステムテストは、ゲームアプリのテストとは全く異なるアプローチを必要とするでしょう。
銀行システムではセキュリティや正確な計算が非常に重要ですが、ゲームアプリではユーザビリティやグラフィックの質が大きな関心事になるでしょう。

テストエンジニアとしての役割は、コンテキストを理解し、その中で最も適したテストアプローチを見つけ、適用することです。そしてそれは経験と知識、コミュニケーションと理解に支えられています。

7.「欠陥ゼロ」の落とし穴

ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。
例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである（Boehm 1981）。

「Foundation Level シラバス 日本語版 Version 2023V4.0.J01」より

私たちが構築するソフトウェアは、要件を満たし、機能を正確に提供する「ツール」であり、そのツールが実際にユーザーの問題を解決し、ビジネス価値を提供することが本来の目的です。

例：スマートフォンアプリの開発

想像してみてください。ある開発チームが新しいスマートフォンの天気アプリを作っています。
このアプリの要件には、温度表示、湿度表示、および次の3日間の天気予報が含まれています。
チームはこれらの要件を確認（Verification）し、すべての要素が正確に動作することを確認しました。
しかし、リリース後、ユーザーはこのアプリが他の天気アプリに比べて情報が不足していると感じ、使い勝手が悪いと不満を持ちました。
ユーザーは、特定の時間帯の天気や、風速、紫外線指数などの情報も求めていました。
この例では、チームは要件は確認していますが、ユーザーの実際のニーズや期待（Validation）を十分に評価していなかったのです。

検証(Verification) は「製品が計画通りに作られているか」を確認するプロセスであり、一方で妥当性確認(Validation) は「正しい製品を作っているか」を評価するプロセスです。

テストエンジニアとして、私たちはただシステムが正しく動作するか確認するだけでなく、エンドユーザーにとって価値あるものであるか、そしてビジネスの目標を達成しているかを確認する重要な役割も担っています。
それぞれのプロジェクトに対し、検証と妥当性確認のバランスを適切に取りながらテストを計画し実施することで、より高品質でユーザーニーズを満たすソフトウェアをリリースするサポートを行います。

おわりに

「ソフトウェアテストの7原則」を解説してきましたがいかがでしたでしょうか？
この記事が少しでも皆様の勉強やスキルアップに貢献できますと嬉しいです。

最後までご覧頂き、ありがとうございました！