ソフトウェアシステムは、日々の生活を構成する要素として必須となっている。ソフトウェアが期待通りに動かなかった経験は誰もが持っている。ソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など、さまざまな問題が発生し、極端な場合は傷害や死亡事故になることもある。ソフトウェアテストは、ソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する手助けとなる。

ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動である。これらアーティファクトは、テストをする際のテスト対象である。テストに関するよくある誤解の 1 つは、テストはテスト実行（すなわち、ソフトウェアを実行しテスト結果を確認する）だけだというものである。しかし、ソフトウェアテストには他の活動も含まれる。そして、ソフトウェア開発ライフサイクルと整合させなければばらない（第 2 章参照）。

テストに関するもう 1 つのよくある誤解は、テストはテスト対象の検証だけに重点を置くというものである。テストでは検証、つまり指定されている要件をシステムが満たすかどうかを確認することに加えて、妥当性確認も行う。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることを確認する。

テストは動的な場合、または静的な場合がある。動的テストはソフトウェアの実行を伴うが、静的テストはソフトウェアの実行を伴わない。静的テストはレビュー（第 3 章参照）と静的解析を含む。動的テストでは、さまざまな種類のテスト技法やテストアプローチを用いてテストケースを導出する（第 4 章参照）。

テストは、技術的な活動だけではない。適切に計画、マネジメント、見積り、モニタリング、コントロールすることもまた必要となる（第 5 章参照）。
テスト担当者はツールを使用するが（第 6 章参照）、テストは大部分が知的活動であり、テスト担当者は専門知識を持ち、分析スキルを使い、批判的思考やシステム思考を適用することが求められることを忘れてはならない（Myers 2011, Roman 2018）。

標準である ISO/IEC/IEEE 29119-1 では、ソフトウェアテストの概念についてさらに詳しい情報を提供している。

1.テスト目的

典型的なテスト目的は以下の通り。

⚫ 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
⚫ 故障を引き起こし、欠陥を発見する。
⚫ 求められるテスト対象のカバレッジを確保する。
⚫ ソフトウェア品質が不十分な場合のリスクレベルを下げる。
⚫ 仕様化した要件が満たされているかどうかを検証する。
⚫ テスト対象が契約、法律、規制の要件に適合していることを検証する。
⚫ ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
⚫ テスト対象の品質に対する信頼を積み上げる。
⚫ テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。

テストの目的は、テスト対象のコンポーネントまたはシステム、テストレベル、リスク、従うソフトウェア開発ライフサイクルモデル（SDLC）、および、例えば企業構造、競争上の考慮事項、市場投入までの時間といったビジネスコンテキストに関わる要因などのコンテキストによって異なることがある。

2.テストとデバッグ

テストとデバッグは別の活動である。テストをすることで、ソフトウェアの欠陥によって引き起こされる故障を発生させたり（動的テスト）、テスト対象の欠陥を直接発見したりすることができる（静的テスト）。
動的テスト（第 4 章参照）が故障を引き起こす一方で、デバッグの関心ごとは、故障の原因（欠陥）を発見し、その原因を解析し、原因を取り除くことにある。典型的なデバッグの流れは以下の通り：

⚫ 故障の再現
⚫ 診断（根本原因を発見すること）
⚫ 原因を修正すること

その後に行う確認テストは、修正によって問題が解決されたかを確認する。確認テストは、最初のテストを行った人と同じ人が行うのがよい。修正によってテスト対象の他の部分に故障が発生していないかを確認するために、続けてリグレッションテストを実施することもできる（確認テストとリグレッションテストの詳細については、2.2.3 項を参照）。
静的テストで欠陥を識別した場合、デバッグすることはその欠陥を取り除くことである。静的テストは欠陥を直接発見するものであり、故障を引

テストをすることは品質コントロールの形式の 1 つであり、設定された範囲、時間、品質、予算の制約の中で、合意されたゴールを達成するために役立つ。成功に向けたテストによる貢献は、テストチームの活動に限定されるべきではない。ステークホルダーであれば、誰でもプロジェクトを成功に近づけるためにテストスキルを活かすことができる。コンポーネント、システム、および関連するドキュメントをテストすることは、ソフトウェアの欠陥を識別するのに役立つ。

1.成功に対するテストの貢献

テストをすることは、欠陥を検出するためのコスト効果のある手段を提供することになる。この欠陥
は、（テスト活動ではないデバッグによって）取り除くことができるため、テストをすることが間接的にテスト対象の品質向上に貢献することになる。

テストをすることは、SDLC のさまざまな段階において、品質を直接評価する手段を提供する。これらの測定結果は、より大きなプロジェクトマネジメント活動の一部として使用し、リリースの判定など、SDLC の次のステージに移行するための判定に貢献する。

テストをすることは、開発プロジェクトにおいて間接的にユーザーが利用した場合の状況を提供することになる。テスト担当者は、開発ライフサイクルを通じて、テスト担当者自身が理解するユーザーのニーズが考慮できていることを確認する。別の方法としては、代表的な複数のユーザーに開発プロジェクトへ関与してもらう方法があるが、コストが高く、適切なユーザーを確保できないため、通常不可能である。

また、テストは、契約上または法律上の要件を満たすため、あるいは規制基準に準拠するために必要となる場合がある。

2.テストと品質保証（QA）

「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと品質保証は同じではない。テストは品質コントロール（QC）の形式の 1 つである。

QC は、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチである。テストは品質コントロールの主要な形式であり、その他に形式的手法（モデル検査や定理証明）、シミュレーション、プロトタイピングなどがある。

QA は、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチである。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。QA は、開発プロセスとテストプロセスの両方に適用し、プロジェクトに参加するすべての人が責任を持つ。

テスト結果は、QA と QC で使用する。QC では欠陥の修正に使い、QA では開発とテストプロセスがどの程度うまくいっているかについてのフィードバックに使う。

3.エラー、欠陥、故障、および根本原因

人間はエラー（誤り）を起こす。そのエラーが、欠陥（フォールト、バグ）を生み出し、その欠陥は、故障につながることもある。人間は、時間的なプレッシャー、作業成果物、プロセス、インフラ、相互作用の複雑度、あるいは単に疲れていたり、十分なトレーニングを受けていなかったりなど、さまざまな理由でエラーを起こす。

欠陥は、要件仕様書やテストスクリプトのようなドキュメント、ソースコード、またはビルドファイルのような補助的なアーティファクトの中から発見できる。SDLC の初期に作成されたアーティファクトの欠陥は、もし検出されなければ、しばしばライフサイクルの後半で欠陥のあるアーティファクトにつながる。コードの欠陥が実行されると、システムがすべきことをしない、またはすべきでないことをしてしまうことがあり、故障の原因となる。欠陥の中には、実行すれば必ず故障になるものもあれば、特定の状況下でしか故障にならないもの、絶対に故障にならないものもある。

故障の原因は、エラーや欠陥だけではない。例えば、放射線や電磁波によってファームウェアに欠陥が生じる場合など、環境条件によっても故障が発生することがある。

根本原因とは、問題（例えば、エラーにつながる状況）が発生する根底の理由のことである。根本原因は、根本原因分析によって特定される。根本原因分析は、故障が発生したときや欠陥が確認されたときに行われるのが一般的である。根本原因を取り除くなどの対処をすることで、さらに同様の故障や欠陥を防止したり、その頻度を減らしたりできると考えられている。

これまで長い間にわたり、さまざまなテストの原則が提唱され、あらゆるテストで適用できる一般的なガイドラインとなってきた。本シラバスでは、そのような 7 つの原則を示す。

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

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

2.全数テストは不可能

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

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

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

4.欠陥の偏在

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

5.テストの弱化

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

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

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

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

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

テストはコンテキスト次第である。しかし、ハイレベルでは、テスト目的を達成する確率を高くする、汎用的なテスト活動のセットというものが複数ある。これらテスト活動のセットがテストプロセスを構成する。テストプロセスは、多くの要因を考慮して特定の状況に対する適切な調整ができる。テストプロセスの中で、どのテスト活動を、どのように、いつ実施するかは、通常、特定の状況に対するテスト計画の一部として決定する（5.1 節参照）。

以降の節では、テストプロセスの一般的な側面を、テスト活動やタスク、コンテキストの影響、テストウェア、テストベースとテストウェア間のトレーサビリティ、テストの役割の観点から説明する。
ISO/IEC/IEEE 29119-2 標準には、テストプロセスのより詳細な情報が記載されている。

1.テスト活動とタスク

テストプロセスは多くの場合、以下に説明する主な活動のグループから構成される。これらの活動の多くは論理的にはシーケンシャルに行われるように見えるが、イテレーティブにまたは並行して実施されることが多い。これらのテスト活動は、通常、システムやプロジェクトに合わせて調整する必要がある。

・テスト計画は、テスト目的を定義することと、その後に全体のコンテキストにより課せられた制約下において目的を最も効果的に達成するアプローチを選択することから構成される。テスト計画については、5.1 節でさらに説明する。

・テストのモニタリングとコントロール。テストモニタリングは、すべてのテスト活動を継続的にチェックし、実際の進捗をテスト計画と比較することを含む。テストコントロールは、テストの目的を達成するために必要な行動をとることを含む。テストのモニタリングとコントロールについては、5.3 節でさらに説明する。

・テスト分析は、テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む（5.2 節を参照）。テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を識別したり、試験性のアセスメントをしたりする。テスト分析では、多くの場合、この活動を支援するためにテスト技法を使用する(第 4 章を参照)。テスト分析では、計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。

・テスト設計は、テスト条件をテストケースやその他のテストウェア（テストチャーターなど）に落とし込む作業を含む。この活動には、多くの場合、テストケースの入力を指定するためのガイドとして機能するカバレッジアイテムの識別が含まれる。テスト設計では、この活動を支援するために、テスト技法（第 4 章を参照）が使用できる。テスト設計には、テストデータ要件の定義、テスト環境の設計、およびその他の必要なインフラストラクチャとツールの識別も含まれる。テスト設計では、「どのようにテストするか?」という問いに答えている。

・テスト実装は、テスト実行に必要なテストウェア（例えば、テストデータ）の作成または取得を含む。テストケースはテストプロシジャーに編成でき、多くの場合、テストスイートにまとめる。手動および自動のテストスクリプトを作成する。テストプロシジャーは、効率的なテスト実行のために、テスト実行スケジュール内で優先順位を付けて配置する（5.1.5 項を参照）。テスト環境を構築し、正しく設定されていることを検証する。

・テスト実行は、テスト実行スケジュールに従ってテストを走らせること（テストラン）を含む。テスト実行は、手動でも自動でもかまわない。テスト実行には、継続的テストやペアテストセッションなど、さまざまな形式がある。実際のテスト結果は、期待結果と比較する。テスト結果を記録する。不正を分析して、考えられる原因を識別する。この分析により、観察された故障に基づいて不正を報告することができる（5.5 節を参照）。

・テスト完了の活動は、通常、プロジェクトのマイルストーン（リリース、イテレーションの終了、テストレベルの完了など）で、未解決の欠陥、変更要求、または作成したプロダクトバックログアイテムに対して行う。将来役立つ可能性のあるテストウェアをすべて識別し、保管するか、適切なチームへ引き渡す。テスト環境は合意した状態でシャットダウンする。将来のイテレーション、リリース、またはプロジェクトに向けて、教訓と改善点を識別するために、テスト活動を分析する（2.1.6 項を参照）。テスト完了レポートを作成して、ステークホルダーへ伝える。

2.コンテキストに応じたテストプロセス

スキルとは、知識、実践、および適性からくる、何かをうまく行う能力のことである。よいテスト担当者は、以下のような自分の仕事をうまくこなすための重要なスキルを持っているべきである。優れたテスト担当者は効果的なチームプレーヤーであるべきであり、異なるテスト独立性のレベルで、テストを実行できるべきである。

1.テストに必要な汎用的スキル

汎用的ではあるが、テスト担当者に特に関連するスキルとして以下のようなものがある：

⚫ テスト知識（テスト技法の活用などによりテストの有効性を高めるため）
⚫ 徹底さ、慎重さ、好奇心、細部へのこだわり、理路整然さ（特に発見しにくい欠陥を識別する
ため）
⚫ 優れたコミュニケーションスキル、積極的な傾聴、チームプレーヤーとなる（すべてのステー
クホルダーと効果的にやりとりするため、他者に情報を伝えるため、理解してもらうため、欠
陥を報告し議論するため）
⚫ 分析的思考、批判的思考、創造性（テストの有効性を高めるため）
⚫ 技術的な知識（適切なテストツールの使用によりテストの効率性を高めるため）
⚫ ドメイン知識（エンドユーザー/ビジネス側代表者を理解し、コミュニケーションできるように
なるため）

テスト担当者は、悪い知らせの運び手となることが多い。悪い知らせの運び手を責めるのは、人間の一般的な特性である。そのため、テスト担当者にとってコミュニケーションスキルは非常に重要となる。

テスト結果を伝えると、プロダクトやその作成者に対する批判と受け取られる可能性がある。確証バイアスは、現在持っている信念と異なる情報を受け入れることを困難にすることがある。テストはプロジェクトの成功やプロダクトの品質に大きく貢献しているにもかかわらず、破壊的な活動であると認識している人もいるかもしれない。このような見方を改善するために、欠陥や故障に関する情報は建設的な方法で伝えるべきである。

2.チーム全体アプローチ

テスト担当者にとって重要なスキルの 1 つは、チームの中で効果的に働き、チームのゴールに積極的に貢献する能力である。エクストリームプログラミング（2.1 節参照）に由来するチーム全体アプローチは、このスキルの上に成り立っている。

チーム全体アプローチでは、必要な知識とスキルを持つチームメンバーであれば、どの仕事を行ってもよく、全員が品質に対して責任を持つ。同じ場所で働くことは情報伝達、および相互作用を活性化するため、チームメンバーは同じワークスペース（物理的または仮想的）を共有する。チーム全体アプローチは、チームダイナミクスを向上させ、チーム内の情報伝達とコラボレーションを強化し、チーム内のさまざまなスキルセットをプロジェクトの利益のために活用できるような相乗効果を生み出す。

テスト担当者は、望ましい品質レベルの達成を確かなものにしていくために他のチームメンバーと緊密に連携する。これには、ビジネス側の代表者と協力して適切な受け入れテストを作成することや、開発者と協働してテスト戦略に合意し、テスト自動化アプローチを決定することを含む。テスト担当者は、こうしてテストに関する知識を他のチームメンバーに広めることができ、プロダクトの開発に影響を与えることができる。

コンテキストによっては、チーム全体アプローチが常に適切とは限らない。例えば、セーフティクリティカルのような状況などでは、高いレベルのテストの独立性が必要な場合がある。

3.テストの独立性

ある程度の独立性があることで、作成者とテスト担当者の認知バイアスの違いにより、テスト担当者がより効果的に欠陥を発見できるようになる（Salman 1995 を参照）。しかし、独立性は、開発者の慣れ親しんだ作業に取って代わるものではない。例えば、開発者は自分のコードにある多くの欠陥を効率的に発見することができる。

作業成果物のテストは、作成者が行う場合（独立性なし）、作成者と同じチームの仲間が行う場合（ある程度の独立性あり）、作成者のチーム外だが組織内のテスト担当者が行う場合（独立性が高い）、組織外のテスト担当者が行う場合（独立性がとても高い）がある。ほとんどのプロジェクトでは、通常、複数の独立性のレベル（例えば、開発者はコンポーネントテストとコンポーネント統合テストを行い、テストチームはシステムテストとシステム統合テストを行い、ビジネス側代表者は受け入れテストを行う）でテストを実施することが最善となる。

テストの独立性の主な利点は、独立したテスト担当者は、経歴、技術的視点、バイ