テスト技法の目的は、テスト条件、テストケース、テストデー タを決定することである。
| テスト技法は、テスト分析（何をテストするか）とテスト設計（どのようにテストするか）におて、 テスト担当者をサポートする。
| 【変更点】
2018年版では、テスト技法を選択する際に考慮すべき多岐にわたる要因を詳しく述べています（例：複雑さ、規制や標準、リスクレベル、ドキュメントの可用性、テスト担当者のスキルなど）。一方、2023年版では、具体的な要因の言及はなく、参考となるISO標準や文献を提供しています。
また2018年版では、適用範囲、目的、カバレッジの計測方法など、各技法の具体的で詳細な解説がありましたが、2023年版では2018年版ほどの詳細な説明は提供していません。
4.2 ブラックボックステスト技法
2023年版では、同値分割法 、 境界値分析 、 デシジョンテーブルテスト 、 状態遷移テストの4つを扱っているのに対し、2018年版では、これらにユースケーステストを加えた5つの技法を解説しています。
4.2.1 同値分割法（2018年版・2023年版共通）
【共通点】
両シラバスで、同値分割法がデータを同等に処理されると想定されるグループ（同値パーティション）に分割する技法であることが説明されています。有効な値と無効な値の概念について言及しており、それぞれが異なるパーティションに分類されることが共通しています。
また両者とも、同値分割法がテスト対象に関連するあらゆるデータ要素に適用可能であることを強調しています。さらに、同値パーティションから少なくとも1つの値を選択してテストケースを作成することで、カバレッジを達成する方法について言及しています。
【変更点】
2018年版では、同値分割法の詳細な実施方法、特に無効な値を含むパーティションのテスト時の注意点について詳細に説明しています。また、100%カバレッジを達成するための方法として、識別された有効なパーティションと無効なパーティションそれぞれから少なくとも1つの値をカバーする必要があると具体的に述べています。
2023年版では、同値分割法の理論的背景と基本原理により重点を置き、異なるパーティションからの値のテストがなぜ重要であるかの説明が含まれています。また、カバレッジの計測方法として、識別されたすべてのパーティションを少なくとも一度はカバーすることが述べられていますが、特に、テストケースが各パーティションセットから各パーティションを少なくとも 1 回は通すことを要件とする「イーチチョイスカバレッジ」という概念に触れている点が異なります。
2018年版では、パーティションをさらに細かく分割する可能性について言及していますが、2023年版ではパーティションが重複しないこと、空でない集合でなければならないことについて強調しています。
4.2.2 境界値分析（2018年版・2023年版共通）
【共通点】
両シラバスで、境界値分析（BVA）が同値分割法の拡張であること、そして数値または順序付け可能な値を持つパーティションに対してのみ適用可能であることが説明されています。パーティションの最小値と最大値（または最初と最後の値）が境界値であるという点が強調されています。
また両方の説明で、境界値分析は開発者がエラーを犯しやすい境界値に着目する技法であることが指摘されています。
【変更点】
2018年版では、境界値分析の具体的な例（1桁の整数値が入力できる場合の例）を通じて、技法の概念を詳しく説明しています。また、境界値分析の結果を用いたテストがソフトウェアの境界値が属するパーティションとは別のパーティションの振る舞いを示すような欠陥を見つけ出すことができると述べています。
2023年版では、2値BVAと3値BVAという2つのバージョンのBVAについて説明し、これらの間で境界ごとのカバレッジアイテムの違いを強調しています。また、3値BVAが2値BVAよりも厳密であり、2値BVAでは見落とされた欠陥を検出する可能性があることを指摘しています。また2023年版では、2値BVAと3値BVAの具体的なカバレッジアイテムの違いと、それらがどのように100%カバレッジを達成するのに役立つかについて具体的に説明しており、特定の欠陥検出例に言及しています（例：if(x≦10)を誤ってif(x=10)として実装した場合の説明）。
4.2.3 デシジョンテーブルテスト（2018年版・2023年版共通）
【共通点】
両シラバスで、デシジョンテーブルが条件とアクションの組み合わせを体系的に表現し、テストするための効果的なツールであることを強調しています。
条件（入力）とアクション（出力）の関係を明確にするための表記法について言及しています。また、デシジョンテーブルの最適化、つまり必要のない列の削除や組み合わせの簡略化の方法に触れています。
【変更点】
2018年版では、デシジョンテーブルの作成プロセスと、条件のブール値または離散値に基づく表現の詳細に焦点を当てています。また、標準的なカバレッジの最小単位に関する説明が含まれています。
2023年版では、デシジョンテーブルを用いたテストの目的と、より広い範囲の条件やアクションの値を取り扱う拡張指定デシジョンテーブルについても言及しています。さらに、実行不可能な条件の組み合わせを含む列の削除や表の最小化についても触れており、リスクベースドアプローチの使用についての言及があります。
これらの違いは、2018年版がデシジョンテーブルテストの基本概念と標準的なアプローチに焦点を当てているのに対し、2023年版ではデシジョンテーブルテストの応用範囲を広げ、より複雑なシナリオや最小化アプローチを含めたテスト戦略に言及している点にあると言えます。
※2018年版ではこれらに加えてユースケーステストの解説をしていますが、内容は省略いたします。
4.2.4 状態遷移テスト（2018年版・2023年版共通）
【共通点】
両シラバスにて、状態遷移テストがシステムやコンポーネントの異なる状態とその遷移をどのように扱うかについて説明しています。
状態遷移図と表の使用を説明し、システムの振る舞いをモデル化する方法について触れています。
テストケース設計の考え方について言及し、有効な遷移だけでなく無効な遷移も考慮に入れるべきであることを述べています。
【変更点】
2018年版では、状態遷移テストの概念を広範囲にわたって紹介し、テストの目的やアプローチ、ソフトウェアの異なる状態の振る舞いに焦点を当てています。より理論的な説明と多様なテストケースの設計について触れています。さらに、メニューベースのアプリケーションや組込みソフトウェアなど、特定の領域での利用についても言及しています。
2023年版では、遷移がどのように発生し、ガード条件やアクションと組み合わされるかにより具体的に焦点を当て、遷移をモデル化する具体的な方法（例: イベント［ガード条件］／アクションの構文）について解説しています。また、カバレッジ基準については、全状態カバレッジ、有効遷移カバレッジ、全遷移カバレッジの3つを例に挙げ、より詳細に解説しています。
4.3ホワイトボックステスト技法（2018年版・2023年版共通）
2018年版ではステートメントテストとデシジョンテストを扱っていましたが、2023年版ではステートメントテストとブランチテストに焦点を当てています。また、2018年版のセクション4.3.3では「ステートメントテストとデシジョンテストの価値」について述べていたのに対し、2023年版では「ホワイトボックステストの価値」を広く解説しており、ホワイトボックステスト全体の重要性について語っています。
4.3.1ステートメントテストとステートメントカバレッジ（2018年版：ステートメントテストとカバレッジ）
ステートメントテストに関する説明は、基本的な概念と目的において両シラバスで共通していますが、2023年版ではステートメントカバレッジが100%に達した場合の意味と、それが必ずしも全ての欠陥を検出するわけではない点についてより詳細な説明が加えられています。2018年版ではステートメントテストの基本的な定義とカバレッジの計算方法に焦点を当てているのに対し、2023年版ではステートメントカバレッジの完全性とその限界についても触れている点が主な違いです。
4.3.2 ブランチテストとブランチカバレッジ（2023年版のみ）
要約は以下の通りです。
ブランチとは、プログラムの制御フロー内で2つのノード間の遷移を意味し、無条件または条件付きの遷移が可能。ブランチテストは、プログラム内の各ブランチをテストケースで通過させ、特定のカバレッジレベルを達成することを目的としている。ブランチカバレッジは、テストされたブランチの割合で測定され、100%に達するとプログラム内の全ブランチがテストされたことになるが、全ての欠陥が検出されるわけではない。ブランチカバレッジはステートメントカバレッジを含むため、100%のブランチカバレッジは同じく100%のステートメントカバレッジを意味するが、その逆は必ずしも成立しない。
なお2018年版では、「デシジョンテストとカバレッジ」として、ブランチテストではなくデシジョンテストについて解説しています。デシジョンテストは、プログラムの判定ポイント（例えば、if文）でのすべての可能な結果をテストします。一方、ブランチテストは、コードのすべての可能なパスを通ることに焦点を置き、特に条件分岐を評価します。ブランチテストはデシジョンテストよりも広範囲にわたり、デシジョンテストに含まれる概念を拡張したものと見なすことができますが、基本的にはコードの異なるパスを確実にカバーすることを目指します。
4.3 経験ベースのテスト技法（2018年版・2023年版共通）
両シラバスとも、ここではエラー推測、探索テスト、チェックリストベースドテスト3つの技法を扱っています。
4.4.1 エラー推測（2018年版・2023年版共通）
両シラバスとも、エラー推測が担当者の経験や過去のデータに基づく非系統的な技法であることに言及している点が共通しています。2023年版ではエラー、欠陥、故障の発生予測について、より詳細に説明しています。具体的には、開発者の一般的なエラーや類似アプリケーションでの故障例を含む、エラー推測のための情報源を挙げています。また、エラー推測の具体的なアプローチとしてフォールト攻撃を紹介し、参考文献も提示しています。
一方、2018年版はエラー推測の基本的な説明に留まり、テストケース設計の過程を簡潔に述べており、2018年版に比べて情報の詳細度が低いです。
4.4.2. 探索的テスト（2018年版・2023年版共通）
両シラバスとも、探索的テストはテストを動的にデザイン、実行し、評価する非形式的なアプローチであると説明しています。探索的テストが特に有効なのは、仕様が限定的または不十分な場合や、テストスケジュールの制約がある場合です。これらはセッションベースのテストを利用して体系化され、テストチャーターに従ったテスト実行や、発見事項の文書化が行われるとしている点も共通しています。また両者とも、探索的テストは他のテスト技法と併用できることに言及しています。
2023年版では、セッションベースドテストにおいて、テスト結果に関するステークホルダーとのデブリーフィングや、カバレッジアイテムはテストセッション中に識別して確認することについても触れています。さらに、テスターの経験とスキルが探索的テストの効果を高めると述べ、探索的テストに関する追加の参考文献も紹介しています。
4.4.3. チェックリストベースドテスト（2018年版・2023年版共通）
両シラバスとも、「チェックリストベースドテストでは、チェックリストのテスト条件をカバーするように、テストケース を設計、実装、および実行する。」と述べています。
両者とも、チェックリスト作成にはテスターの経験やユーザーの重要視する点、ソフトウェアの失敗原因に対する理解が必要であるとしています。またどちらも、機能テストや非機能テストを含むさまざまなテストタイプのために作成できることにも触れています。さらに、チェックリストは概要を示す¬ため、テストを実施する際には人によって異なる解釈が生じることがあり、これにより多くの範囲をカバーできるものの、同じテストを完全に再現するのが難しくなることがあるという点も共通して言及しています。
2023年版ではチェックリストの項目が質問形式であるべきであり、自動チェックに不向きな項目や一般的すぎる項目を避けるべきと具体的に述べ、チェックリストの定期的な更新の重要性や長くなりすぎる問題にも言及しています。
4.5 コラボレーションベースのテストアプローチ（2023年版のみ）
2023年版で新たに追加された内容です。
「4.5.1 ユーザーストーリーの共同執筆」「4.5.2 受け入れ基準」「4.5.3 受け入れテスト駆動開発（ATDD）」の3つで構成されています。
それぞれの要約は以下の通りです。
4.5.1. ユーザーストーリーの共同執筆
ユーザーストーリー共同執筆の過程は、システムもしくはソフトウェア使用者及び購買者に価値ある機能を明確に示すものである。これには三つの重要な側面、「3つのC」が含まれる：
・カード（Card）-ユーザーストーリーを記述する媒体（例：インデックスカード、電子なボード 上のエントリー）
・ 会話（Conversation）-ソフトウェアがどのように使用されるかを説明する（文書化または口 頭）
・ 確認（Confirmation）-受け入れ基準
共同執筆はブレーンストーミングやマインドマップなどの技法を用い、ビジネス、開発、テストの各視点を融合させ、チームに共通のビジョンを与える。優れたユーザーストーリーは独立性、交渉可能性、価値、見積もり可能性、小ささ、テスト可能性を備えるべきである。
4.5.2. 受け入れ基準
ユーザーストーリーの受け入れ基準は、ステークホルダーがユーザーストーリーの実装を受け入れるために必要な条件を定義する。これはテストケースを通じて検証されるテスト条件として機能し、ユーザーストーリーのスコープを明確にし、ステークホルダー間の合意を促し、受け入れテストの基礎を築く。受け入れ基準の文書化にはシナリオ指向やルール指向の方法があり、明確で曖昧さのない条件を設定することが重要である。
4.5.3. 受け入れテスト駆動開発（ATDD）
受け入れテスト駆動開発（ATDD）はテストファーストのアプローチで、ユーザーストーリー実装前にテストケースを作成する。これには顧客、開発者、テスト担当者が協力し、仕様化ワークショップでユーザーストーリーとその受け入れ基準を分析・議論する。テストケースは受け入れ基準に基づいており、ソフトウェアの動作例として機能する。テスト設計にはさまざまなテスト技法が適用可能で、自動化のサポートも考慮される。ATDDは、正確な計画と見積りに貢献し、ユーザーストーリーの全特性をカバーするテストケースを目指す。
2023年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf
2018年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
AIQVE ONE株式会社 人材開発セクション
2008年新卒でベリサーブに入社。テスト一筋15年。入社以来社内の研究活動を実施。ブルーレイプレイヤ、カーナビ、カラオケ機器などの組込みのテストで経験を積み、自動車の車載ECUのシステムテストや、航空機の安全評価など経て、直近は社内でMBT及びアジャイルにおけるテストプラクティスの研究を行っている。自社プロダクト開発のプロダクトオーナーも経験。2023年5月よりAIQVE ONEにも所属し、教育も行う。幅広い分野のテストのプロフェッショナル。
資格取得はISTQB-AL-TM/IVEC-Lv4/基本情報技術者
