テスト設計コンテスト ’24

テスト設計
チュートリアルテスコン編
2024. 6. 26
NPO法人 ソフトウェアテスト技術振興協会（ASTER）

講師自己紹介
近美 克行（テスト設計コンテスト実行委員会/OPENクラス審査委員）

•
•
•
•
•

普段の業務では、所属会社（いわゆるSIer）でソフトウェア品質向上のための各種活動に従事。プロダクト品質の方法論だけでなく、プロ
セス品質の方法論も大好物。
好きなテスト技法は同値クラス分割（基本は大事）。
過去にはテスト設計コンテストに「TFC KA・RI・YA」で参戦。
テスト設計コンテスト実行委員（2023年～）
今回のテストベースとなるだんだん動物園システムの設計を担当（開発会社のプロマネ役のてい）
テスト設計コンテストOPENクラス審査委員（2023年～）

2本日お伝えしたいこと• コツ：２つの質問「それはなぜ？」＆「で、どうなるの？」• 知識を学習する＝情報を体系（システム）として頭の中に構築する活動• 体系（システム）＝要素＆要素間の関係の２つの特性で目的を達成するもの→知識システム＝情報どうしをつなげて運用して、あたしい知見を生み出す• 情報どうしをつなげるために、 「それはなぜ？」＆「で、どうなるの？」を問いながら、情報の位置づけと関連性を理解するとよい• 本日のテーマ：テスト開発プロセスの話をする• テスト開発プロセスとは、ある目的（検証目標の達成）のために、テストベー
スをINPUTとして、テストケースをOUTPUTする、“システム“としてとらえることができる。
• テスト設計を含むテスト活動プロセスの理解とは、この“システム”を理解するということに他ならない。
• 情報のどうしの“つながり”を、 「それはなぜ？」＆「で、どうなるの？」を問いながら、追いかけてみてください。

3

想定している聴講者とおことわり• 想定している聴講者• OPENクラスに参加を予定している、または参加を検討している方• 業務としてテスト設計を担当しているが、より納得感を得たい、理解を深めたいと思っている方• テスト設計を説明する必要があり、概念体系を言語化、再整理したい方• おことわり• 本講演は、上記のようなある程度の知識と経験のある方を想定しています。
• なので、用語の説明、個別のテスト技法の説明や事例の提示や解説は詳細にはできません。
（時間制約もあるので…）• 用語・概念の説明や、事例解説については、テスト設計コンテスト実行委員会で、YouTube動画を 公開しているので、次ページの動画もご興味と必要にあわせて、ご参照ください。
• 学習のための３つの情報要素（PRE：Point/Reason/Example）のExampleはぜひ、動画を見て獲得してください。
• 動画は分かりやすいです。本日の講師が自分の解説が必要ないのでは？と落ち込むぐらいすばらしいです。
• なので、今回は、メタな情報を含め、テスト設計の理解を進めるのための概念共有を優先します。

4

テスコン実行委員で公開している動画のご紹介• チャンネル：テスト設計コンテストチャンネル
https://www.youtube.com/@user-uz8mw1ux4p

5

チュートリアルの流れ【前提知識のおさらい】
A) テスト活動の抱える問題
B) 問題解決のために必要となる知識と考え方
C) ここまでのまとめ【テスト設計チュートリアル本編】
1. テスト開発プロセス
2. TRA（テスト要求分析）
3. TAD（テストアーキテクチャ設計）
4. TDD・TI（テスト詳細設計、テスト実装）
5. テスト開発のTIPS
6. 過去の応募作のポイント
テスト開発プロセスについてはVSTePを基に解説します©NISHI, Yasuharu
6A）テスト活動の抱える問題

7

求められるテスト開発
ソフトウェア→

ソフトウェア開発

大規模化・複雑化している→

高品質・短納期を求められる顧客の要求・要件に合致すること【社会的な急務】

柔軟で高速かつ精度の高いソフトウェアテストを開発すること10万件を超える様々な観点による質の高いテストケースをいかに体系的にスピーディに開発するか、が課題である。

8

テスト計画とテスト戦略
テスト計画やテスト戦略の立案という工程は未成熟である。
テストケースという成果物の開発とテストのマネジメントが混同されている。
テスト計画書にテストケースもスケジュールも人員アサインも全て記載されている。
さらに・・・
テスト（ケース）開発という用語はほとんど使われない。
テスト計画、テスト仕様書作成、テスト実施準備という用語は使われている。
テスト戦略という用語もイマイチよく分からない。
テストケースの開発という工程が見えにくくなっており、そこで必要となる様々な工程が混ざり、一体的に扱われている。

9

テスト開発プロセス
テストケースを開発成果物と捉え、開発のプロセスを整備する必要がある。
大規模化・複雑化・高品質・短納期に対応するテストケースを開発する
ために、必要な作業を明らかにする。

→ 「テスト開発プロセス」という概念が必要となる。

10

問題を一言で言うと…
ソフトウェアのテスト

・でかい
・複雑
・めんどくさい・1人で手に負えないので複数人でチームを組んで取り組む→コミュニケーションのめんどくささがさらにトッピングされる

11

対策

でかい＆複雑＆めんどくさい+複数人でわらわらやる
工学の伝統的アプローチ

・段階的詳細化、段階的統合＆評価
端的に言えば、テスト開発にもV字適用による分割統治
加えて：
複数人でのコミュニケーション対応のために、システム思考によるモデリングを活用
12B）問題解決のために必要となる知識と考え方

13

本日お伝えしたいこと（再掲）• コツ：２つの質問「それはなぜ？」＆「で、どうなるの？」• 知識を学習する＝情報を体系（システム）として頭の中に構築する活動• 体系（システム）＝要素＆要素間の関係の２つの特性で目的を達成するもの→知識システム＝情報どうしをつなげて運用して、あたしい知見を生み出す• 情報どうしをつなげるために、 「それはなぜ？」＆「で、どうなるの？」を問いながら、情報の位置づけと関連性を理解するとよい• 本日のテーマ：テスト開発プロセスの話をする• テスト開発プロセスとは、ある目的（検証目標の達成）のために、テストベー
スをINPUTとして、テストケースをOUTPUTする、“システム“としてとらえることができる。
• テスト設計を含むテスト活動プロセスの理解とは、この“システム”を理解するということに他ならない。
• 情報のどうしの“つながり”を、 「それはなぜ？」＆「で、どうなるの？」を問いながら、追いかけてみてください。

14

システムとは？
• システム（特に工学の文脈におけるシステム）とは・・・• ある目的のために、外界と相互作用（INPUTして、なにかして、OUTPUTする）するもの• システムは構成要素をもつ。構成要素の特性と構成要素間の相互作用により、目的を達成する• システムを理解するためには、目的、構成要素（とその特性）、構成要素間の相互作用を理解する• テストの文脈でとらえると…
• テスト開発プロセスとは、ある目的（検証目標の達成）のために、テストベー
スをINPUTとして、テストケースをOUTPUTする、“システム“としてとらえることができる。
• テストの目的ってなに？テストの構成要素（テストを構成する情報要素）ってなに？その相互作用ってなに？を把握できれば、理解できそう。
システムやシステム開発の知見を活かす、というのが基本アイディア
15

システムとしてのテスト開発プロセス
テスト開発プロセスにおける、• テストの目的は？・・・〇〇〇• テストのINPITは？・・・テストベース• テストのOUTPUTは？・・・テストケース• テストの構成要素（情報要素）は？ ・・・〇〇〇• 構成要素間の相互作用は？ ・・・〇〇〇

以上を理解したい。

16

システムとしてのテスト開発プロセス
テスト開発プロセスにおける、
まずここを説明します。

• テストの目的は？・・・〇〇〇• テストのINPITは？・・・テストベース• テストのOUTPUTは？・・・テストケース• テストの構成要素（情報要素）は？ ・・・〇〇〇• 構成要素間の相互作用は？ ・・・〇〇〇

以上を理解したい。

17

テストの目的• テストの目的を、テスト結果の利用、貢献の観点で理解する。
引用：テスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J01
1.2.2 テストと品質保証（QA）「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと品質保証は同じではない。テストは品質コントロール（QC）の形式の1つである。
QCは、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチである。テストは品質コントロールの主要な形式であり、その他に形式的手法（モデル検査や定理証明）、シミュ
レーション、プロトタイピングなどがある。
QAは、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチである。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。QAは、開発プロセスとテストプロセスの両方に適用し、プロジェクトに参加するすべての人が責任を持つ。
テスト結果は、QAとQCで使用する。QCでは欠陥の修正に使い、QAでは開発とテストプロセスがどの程度うまくいっているかについてのフィードバックに使う。

→欠陥の修正（QC）とテスト対象の品質保証（QA）に貢献できなければ、100万件のテストケースもその結果も意味がない。
18

欠陥の修正（QC）への貢献• 欠陥の修正（QC）へのテストの貢献→テストNG（期待結果からの逸脱）という結果をつかって、
テスト対象プロダクトの逸脱の是正を駆動する。
• テスト開発における関心事• いかに少ないコスト（人的リソース、時間、スキルニーズ、精神力など）で、是正につながる欠陥を発見できるか？
• NGが発生する条件を絞り込めるような十分な情報提供ができるか？
• 欠陥であることが正しく判断しやすいか？（偽陰性/擬陽性＝嘘OK、嘘NGがでにくいか？）悪い例）いい感じに動作すること？
（「いい感じ」に異論がでないように基準を明確化したい→1秒以内に応答する事）

19

品質保証（QA）への貢献（1/3）• 品質保証（QA）へのテストの貢献→開発とテストプロセスがどの程度うまくいっているか？
についてのフィードバックに使う。
• JSTQBではプロセス品質を意図しているが…
• 品質特性モデル（ISO/IEC25010：JISX25010）では、プロセス品質→プロダクト品質→利用時品質の依存関係で、品質保証を（より広く）とらえている
利用状況により多重化

プロセス

品質

製品
品質

利用時
品質
JSIX25010 図C.2を参考に作成
20

品質保証（QA）への貢献（2/3）• 品質保証で本当に保証したいのは、利用時品質→すべての利用者の、すべての利用状況の、すべてのユースケースを、すべて組み合わ
せでテストし保証するのは現実的ではない。

→利用時品質を推定するために、妥当な推定ロジック（論証）を構築している（このあたり、ISO9001、QMSの歴史をしらべると面白い）

利用時
品質

測定
測定
測定
…

利用状況により
多重化

品質

製品
品質

測定

測定

プロセス

利用時
品質

測定＋推定

推定ロジック(論証）
膨大な実証実験の代わりに、推定ロジック（論証）を挟むことで、現実的な数の製品テスト＋プロセス準拠の証拠で、品質保証を可能にしている
21

品質保証（QA）への貢献（3/3）

利用状況
A
利用状況
利用状況
B
典型的な
E
製品
利用状況
利用状況 品質
利用状況

D

プロセス

品質

C

製品
品質

「ソフトウェアは腐らない（経年劣化しない）」という前提で
テスト結果の同一視を上手くつかっている

品質論証について（1/4）
やりたい事＝「製品は品質問題がないである」という証明
証明とは・・・論理と証拠をもとに、主張（主張したい内容）の妥当性（正しさ）を相手に受け入れてもらう
主張「製品は品質問題がない」ことを、相手（社会）に受け入れてもらうためには・「テストで品質が確認されていない（品質が不明）」では、困る（受け入れ難い）・「テストした時はOK」でも、「相手が利用した時はOKではない（orOKか不明）」では、困る（受け入れ難い）・「あなたはOKであると判断した」でも「別の人が判断したらOKではない（orOKか不明） 」では、困る（受け入れ難い）

上記から、
・【実証性】OKであることの実証結果（テスト等実物・現物による実証・検証結果）がある
・【再現性・結果の予測可能性】実証結果の保証範囲と、実際の利用状況が、品質OKの観点（判断基準）で同一とみなせる
・【客観性・論証の再現性】証拠を出発点に論理をなぞると別な人でも同じ結論（同じ主張）にたどり着けるが必要

別な人がやっても同じ結論になる事（客観性）が重要、これにより納得感・社会受容性が得られる・そのために、証拠＆前提が共有される（議論の出発点を一致させられる）必要がある
・また、論証・説明論理が共有される（議論の道筋が一致させられる）必要がある
・さらに論証・説明論理が妥当である（筋道に論理矛盾がない）必要がある※矛盾する論理からはどんな形式上の結論もだせちゃう23

品質論証について（2/4）
【実証性】テストOKであることの実証結果（テスト等実物による実証・検証結果）がある
テストでOKが確認されたなのでユーザーの利用でもOKである
なぜなら、
ユーザーの利用状況とテスト条件は同一なので、機能実行結果も同一とみなせるから。

証拠：
テストを実施した結果「製品はOKである」ことが確認された【実証性】証拠（観測事実）がある

主張：
ユーザーが利用した場合でも「製品はOKである」と言える

理由（論証）：【再現性】
テスト条件が明確

ユーザーの利用状況とテスト条件が同一なので、結果も同一と予測できる【客観性】論理をなぞれば同じ主張に辿りつける
24

品質論証について（3/4）
品質論論証の展開例（多段展開の例）・・・テストレベルとテスト対象でスライス

主張：
製品は仕様を満足する
理由（前提）：
製品仕様は、コンポーネン
トの入出と相互作用で決定
される

サブ主張：
コンポーネントAは設計仕様を満足する
証拠：
コンポーネントAの単体テスト結果

論証戦略
構成要素と相互作用
に分解

サブ主張：
コンポーネントBは設計仕様を満足する

サブ主張：
コンポーネントAB間の相互作用は仕様を満足する

証拠：
証拠：
コンポーネントB
コンポーネントABの統合テスト結果の単体テスト結果
参考：モデル化の方法としては、D-Case等が参考になる

25

品質論証について（4/4）
品質論論証の展開例（多段展開の例）・・・内部状態を通じた、２つの入出力仕様の依存関係
理由（前提）：
コンポーネントは状態Bである

主張：コンポーネントのI/F（C）の操作によりコンポー
ネントは状態Bに遷移する

証拠：
I/F（B)の操作記録

主張：コンポーネントにおいてI/F（A）は状態Bのとき入出力仕様を満足する証拠：
I/F（A)の入出力
テスト結果

参考：モデル化の方法としては、D-Case等が参考になる
26

品質論証について（品質保証における論証）
論証＝反論の余地をつぶす
反論の余地＝「可能性（ゆらぎ・あいまいさ） 」→成果物を観察し、（A）製品振る舞いの可能性、（B）ミスの可能性＆解釈の可能性から、「ゆらぎ・あいまいさ」を制限していく。
（A)製品振る舞いの可能性：製品の実際の利用には不確実性がある。
・製品の使われる環境や、使われ方は、多様性がある→想定外の使われ方をした場合に、何が起こる？
・外部システムとの相互作用は、SW開発チームが制御しきれない→想定外の入力（内容・タイミング）があった場合に、何が起こる？
・ハードウェア故障（経年劣化）は、 SW開発チームが制御しきれない→ハードウェア故障でSWが想定外の振る舞いをした場合に、何が起こる？
「何が起こる？」を分析（かもしれない分析を実施）し、可能性のある振る舞いにより品質目標が侵害しない様に、方策を追加する。
例）エラーハンドリングの追加、安全機能の追加、セキュリティ機構の追加、運用対応を含む外部方策の追加（B）ミスの可能性＆解釈の可能性：人間はミスをし、成果物内容には解釈の不確実性がある。
・要求や設計書が不完全だったり、解釈にミスがあると、意図通りに実装されない
・検証の仕様化があいまいだったり、解釈にミスがあると、十分に検証エビデンスが確保されない・計画があいまいだったり、資源確保が十分でないと、目的達成に必要な活動が十分実施されない
上記は、SW開発チームで可能な限り制御する。そのために、活動計画・活動実施・活動成果の検証の実績を観測し制御する
例）プロセス定義監査、計画監査、進捗管理、検証（レビュー・テスト）活動、問題管理、成果物管理（構成管理）、
成果物監査、プロセス実施実績監査の実施
27

論証の話で、脱線しましたが、戻ります・・・

28

品質保証（QA）への貢献（まとめ）• 品質保証（QA）へのテストの貢献→開発とテストプロセスがどの程度うまくいっているか？
についてのフィードバックに使う。（JSTQBの記載）• 加えて、品質保証目的・目標によりテストのモチベーション（テスト結果を証拠として、検証したい内容）を定義する• テスト開発における関心事

単純なツリーやリスト構造にならない場合があることが悩ましい・・・• 例えば、I/Fの振る舞いが製品の「機能仕様を満たす」という検証したい内容があったら、それを論証のテクニックで、個々のテストケースまで展開する（個々のテストケースに、展開した論証のサブゴールを割り当てる）• テストケースに割り当てられた論証のサブゴールどうしは、システムの内部構造を通じて依存する場合がある→テストケースどうしの依存関係を設計する必要がある
29

システムとしてのテスト開発プロセス
テスト開発プロセスにおける、• テストの目的は？・・・
QCへの貢献（バグだし）＋論証モデルを通じた品質保証への貢献（QA）• テストのINPITは？・・・テストベース• テストのOUTPUTは？・・・テストケース• テストの構成要素（情報要素）は？ ・・・〇〇〇• 構成要素間の相互作用は？ ・・・〇〇〇

以上を理解したい。
30

システムとしてのテスト開発プロセス
テスト開発プロセスにおける、• テストの目的は？・・・
QCへの貢献（バグだし）＋論証モデルを通じた品質保証への貢献（QA）• テストのINPITは？・・・テストベース• テストのOUTPUTは？・・・テストケース• テストの構成要素（情報要素）は？ ・・・〇〇〇
次にここを説明します。
• 構成要素間の相互作用は？ ・・・〇〇〇

以上を理解したい。
31

テストの構成要素（情報要素）
結論は以下
・テスト目的に関する情報要素：テスト要求（品質論証の論証ゴールと論証の有効範囲を表現したもの）→テストの目的のパートで解説したもの
・テストケース実装に関る情報要素：
テスト対象とテスト対象の持つI/Fに関連する情報※テストはテスト対象のもつI/Fを通じてしかできないという制約がある

→次ページ

32

テストケース実装に関する情報要素• テストは、論証を支えるエビデンス（＝テスト結果）を提供する• エビデンス（＝テスト結果）は、再現性が確実に保証できる有効範囲（スコープ/条件）を持つ• この条件をテスト条件（Test Conditionまたはテストパラメータ）と呼ぶ• テストケースに結びつくテスト条件の情報構造（テストフレーム）は以下の通り

33

テストケース実装に関する情報要素• 後述する、テスト要求分析では、テストの論証ゴールを導出するとともに、
テストケース構築に関わるテスト条件を構成する、イベント、データ、状態、機能実行基盤・環境、テス
トで使えるI/F、I/Fを関連するアクター・外部システム、アクタの利用状況と利用の動機、となる情報をテストベースから収集し、整理する。
• テストの論証ゴールもテスト条件も「テスト観点」と呼ばれることがあるので、「観点」の使用は注意が必要

テストベース34

テストケース実装に関する情報要素の相互作用①• 情報要素の相互作用は情報要素どうしの関係性、テストケースにおける情報要素の役割• 同じ「データ」でもある機能にとっては、出力データ、別な機能にとっては入力データや内部データになることもある。→データやトリガーイベントを経由して、機能どうしは依存関係をもつ

35

テストフレーム•

テストケースに結びつくテスト条件の情報構造を後述のVSTePでは「テストフレーム」と呼んでいる•

テストケースをテストフレームなどのスケルトンを基に系統的に生成することで、ミスを発見しやすくミスを是正
しやすくなる。
（どんなエキスパートでも、人間はミスをする。作業量が多くなるときはなおさら。なので、ミスを発見しやすく、是正しやすい方法論は品質保証のためにも重要…品質保証のためのテストの品質が低いとイヤ）•

テスト設計では、テストフレーム等、テスト条件の関連性・依存関係を定義することも重要な活動となる。

テストフレームの定義例（ちびこん編のチュートリアル’24資料より）

テストフレームのメタモデル

36

テストケース実装に関する情報要素の相互作用②• 先に述べたとおり、テストケースどうしが依存関係をもつ場合はある。
• その場合は、複数のテストケースをまとめて、管理したり、実行したりしたくなる。
• そのテストケースを束ねたものをVSTePでは（テスト）コンテナと呼ぶ。
• どのようなご利益をねらって、テストコンテナとしてまとめるのかを決定することもテスト設計の重要な活動となる。
負荷テスト

テスト目的でまとめた例
テスト条件のうち「機能実行基盤・環境」のバリエーション展開をするテストケース
をまとめた

ボリュー
ム

高頻度

ストレー
ジ

ロングラ
ン

コンテナをさらにまとめた例
情報の階層化は認知負荷をさげて伝わりやすくする有力な方法
37テストアーキテクチャのコンテナモデル•

テストコンテナどうしもテストケースやテスト手順を共有する、あるテストケースを実行するために前提となるテストケー
スがOKとならなければならないなど、依存関係をもつ。

•

テスト設計（特にテストアーキテクチャ設計）では、テストコンテナレベルでの関連性・依存関係を定義することも重要な活動となる。
→テストの実行可否判断、実行順番の計画立案、テストケースの保守用姿勢確保などに役立つ•

テストコンテナのモデルで表すと全体像を把握しやすくなる。

•

先に設計／実施しておくべきコンテナを後に回してしまう、といったトラブルが防げる•

順序依存性以外の依存関係も把握すると、保守性やテスト環境設計などの役に立つ38

システムとしてのテスト開発プロセス
テスト開発プロセスにおける、• テストの目的は？・・・
QCへの貢献（バグだし）＋論証モデルを通じた品質保証への貢献（QA）• テストのINPITは？・・・テストベース• テストのOUTPUTは？・・・テストケース• テストの構成要素（情報要素）は？ ・・・テスト要求とテスト条件の集合• 構成要素間の相互作用は？ ・・・
テストフレームやテストコンテナで表現されるテストケースやテスト条件の依存関係
以上を理解した！
39C）ここまでのまとめ

40ここまでのまとめ
以下の概念を紹介した。
• テストケース生成システムとしての「テスト開発プロセス」というアイ
ディア• システム＝目的+構成要素＋目的達成のための要素間の相互作用※ITシステムやソフトウェアシステムに限らず要素間の相互作用で目的達成するもの• テストの2つの目的（QC貢献とQA貢献）• テストの目的・論証ゴール• 論証ゴール・論証・証拠（ロジック、論理の流れ）• テストフレーム• テストコンテナ• コンテナモデル（テストアーキテクチャの表現形式）
41ここまでのまとめ
ここまで概念把握の準備ができれば、VSTePの理解は捗るはず。

ただし、（テストケース生成システムとしての）テスト開発プロセスの構成方法は、
VSTePに限るわけではない。
他にも可能性な構成方法はある。

・マトリクス・階層構造付リスト
・マインドマップ、などなど

また、目的にあせて、表現方法は変えても良い。変えるべき。
方法論はあくまで道具なので、目的にあった道具を適切につかうことが儒十重要

42

注意点
前年のテスト設計コンテストでは以下のようなコメントがあった。
• 誰に伝えたいのか？
• ドキュメントの作りはじめからプレゼンテーション資料作成までターゲットを意識しましょう→誰に何を使えたいのか？ドキュメントの目的にあった形式を意図をもって選択すると、より目的を達成しやすくなる。
• 根拠をちゃんとつなげよう• 活動の出発点となるテスト要求（テストの論証ゴール）を妥当性のあるものしよう。
これが崩れると、どんなに矛盾のないロジックを組んでも、あとが全部説得力のないものになる。
• 工程一貫性が重要、論理飛躍や矛盾のある品質論証だと、説得力がなくなる• 前提や根拠の妥当性は意識しましょう、これも説得力がなくなる→テストのQA貢献を達成して、製品を受けいれてもらうためには、ほしいのは説得力。
そのために、論証ゴール、論証ロジック、証拠を適切にそろえると納得感は増す。
• テストする順番以外のアーキテクチャを考えよう• 俯瞰と関連がとても大事• アーキテクチャの図が一つである必要ない。無理に情報を詰め込むより分けたほうが参照者の認知負荷が下がり伝わりやすい→欠陥の修正（QC）とテスト対象の品質保証（QA）に貢献できなければ、100万件のテストケースもその結果も意味がない。やった事の報告ではなく、納得させてほしい。
43

後半戦

44

チュートリアルの流れ【前提知識のおさらい】
A) テスト活動の抱える問題（で、なぜテストを設計するのか？）B) 問題解決のために必要となる知識と考え方
C) ここまでのまとめ【テスト設計チュートリアル本編】
1. テスト開発プロセス
2. TRA（テスト要求分析）
3. TAD（テストアーキテクチャ設計）
4. TDD・TI（テスト詳細設計、テスト実装）
5. テスト開発のTIPS
6. 過去の応募作のポイント
テスト開発プロセスについてはVSTePを基に解説します©NISHI, Yasuharu45おことわりその２

ここからVSTePを例に、テスト開発プロセスを流れにそって説明します。
しかし、時間制約があり、ポイント解説のとどめる予定です。
以下に、すばらしい解説動画あるので、ぜひご参照ください。

テスト設計チュートリアル テスコン編 ’23
https://www.youtube.com/watch?v=NUYMYLaghy0

テスト設計チュートリアル ちびこん編 ’24
https://www.youtube.com/watch?v=CJ-QP8XdvXc

46

１．テスト開発プロセス47

テスト開発プロセス
テストケースを開発成果物と捉え、開発のプロセスを整備する必要がある。
大規模化・複雑化・高品質・短納期に対応するテストケースを開発する
ために、必要な作業を明らかにする。

→ 「テスト開発プロセス」という概念が必要となる。

48

テスト設計とテスト開発の違い
いきなりコーディングをすることと、ソフトウェア開発とは、違うよね。

テストも同じいきなりテスト vs テスト開発とはレベル感の異なる活動

テストケース作成
テスト（詳細）設計技法と文書フォーマットが分かっていればできる。

コーディングもアルゴリズムとプログラミング言語を分かっていればできる。
テスト開発

テスト要求を把握して、テスト設計の原則を理解・適用して、ソフトウェア開発
も同じ

段階的に詳細化しながら順序立てて進めていく必要がある。
→

様々なソフトウェア工学上の概念や技術、方法論、モデリングスキル

抽象化／パターン化能力なども必要となる。
テスト開発がきちんとできるようになると、自動化やAIを用いることもできるようになる。
49

つまりは・・・？

テストのことだけではなくソフトウェア開発に必要となる思考力やモデリング力を身につけようシステム開発における設計力（思考力やモデリング力）と類似の能力
大変そうだけど、参考になる知見は、システム開発にもたくさんある。
そして、なによりシステム思考やモデリングは楽しい。
50

テスト開発プロセスの基本的考え方
テストケースを開発成果物と捉え、ソフトウェア開発プロセスとテスト開発プロセスを対応させよう。
ソフト要求分析＝

テスト要求分析

ソフトアーキテクチャ設計＝

テストアーキテクチャ設計

ソフト詳細設計＝

テスト詳細設計

ソフト実装 ＝ テスト実装

テストケースがどの工程の成果物かを考えるために、各プロセスの成果物を対応させよう。
ソフト要求仕様（要求モデル）＝

テスト要求仕様（要求モデル）

ソフトアーキテクチャモデル＝

テストアーキテクチャモデル

ソフトモジュール設計＝

テストケース

プログラム

＝

テスト手順

．

（手動／自動化テストスクリプト）51

旧来のテストプロセスでは粗すぎる
旧来
テスト設計（or テスト計画 or テスト実施準備）

テスト実施

テスト項目の抽出

理想
テスト
要求分析

テスト
アーキテクチャ設計

テスト要求の獲得と整理・
テスト要求モデリング

テストアーキテクチャ
モデリング

本資料はこの

テスト
詳細設計

テスト実装

テスト実施

テスト詳細設計
手動／自動化モデリングとテストスクリプト
テスト技法の適用による （テスト手順）の記述
テストケースの列挙

VSTeP

を基に作成している。

©NISHI, Yasuharu

52テスト観点とテストケースとテスト手順
テスト観点とテストケースとテスト手順をきちんと区別する。
「Myersの三角形」を例にすると

テスト観点
何をテストするのかのみ端的に記述したもの

正三角形

テストケース
そのテスト観点でテストするのに必要な値のみを特定したもの
通常は、網羅基準に沿って特定される値のみから構成される。
テストケースは基本的にシンプルになる。

（1, 1, 1）（2, 2, 2）（3, 3, 3）…

1．PCを起動する

2．C:¥sample¥Myers.exe
テスト手順（テストスクリプト）
を起動する
そのテストケースを実行するために必要な全てが書かれたもの
手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある。
複数のテストケースを集約して１つのテスト手順にすることもある。

これらを区別し、異なる文書に記述し、異なる開発工程に割り当てることで、テスト観点のみをじっくり検討することができる。

53

上流工程でのモデリング
上流工程でテスト観点のモデリングを行って、テストを開発すべきである。
• モデリングを行うと、テストで考慮すべき観点を一覧でき、俯瞰的かつビジュアルに整理できる• テスト要求分析では、テスト要求モデルを作成する• テストアーキテクチャ設計では、テスト詳細設計・実装・実行しやすいように
テスト観点をグルーピングする（各項目の詳細は次ページ以降）
54

上流工程でのモデリング（モデリングの重要性）
モデリングを行うと、テストで考慮すべき観点を一覧でき、俯瞰的かつビジュアルに整理できる• 10万件を超えるテストケースなど、テスト観点のモデル無しには理解できない• モデルとして図示することで、大きな抜けや偏ったバランスに気づきやすくなる• 複数のテストエンジニアでレビューしたり、意志を共有しやすくなる

55

上流工程でのモデリング（テスト要求モデル）
テスト要求分析では、テスト要求モデルを作成する• テスト対象、ユーザの求める品質、使われる世界などをモデリングする• 具体的なテスト条件が特定できるまで丁寧に段階的に詳細化する• 仕様書や設計書を書き写すのではなく、モデリングし直す覚悟で行う※現実の現場でもモデリングを開発者任せにしても、物事は進まないことが多い→

最終的に「テスト観点を示す」ことにつながる。
※テスト観点=テストの目的、テスト結果を証拠として論証すべきゴール＆論証条件・論証範囲を定義するテストパラメータ56

上流工程でのモデリング（テスト観点のグルーピング）
テストアーキテクチャ設計では、テスト詳細設計・実装・実行しやすいように
テスト観点をグルーピングする• テスト観点をグルーピングして、テストタイプやテストレベル、テストサイクルを設計する• テスト観点をグルーピングして、テストケースの構造（スケルトン）を設計する• 体系的で、見通しのよいテストアーキテクチャを構築する
体系的で見通しの良いテストアーキテクチャは理解容易性や保守性の向上に貢献する• テストスイートの品質特性を考慮して適切なテストアーキテクチャを設計する• よいテスト設計のためのテストデザインパターンを蓄積し活用する
57

テスト観点の例：組込みの場合（１）
機能：テスト項目のトリガ• ソフトとしての機能> 音楽を再生する• 製品全体としての機能
> 走る

パラメータ
• 明示的パラメータ> 入力された緯度と経度• 暗黙的パラメータ> ヘッドの位置• メタパラメータ> ファイルの大きさ• ファイルの内容> ファイルの構成、内容• 信号の電気的振舞い> チャタリング、なまり

プラットフォーム・構成
チップの種類、ファミリ
メモリやFSの種類、速度、信頼性
OSやミドルウェア
メディア> HDDかDVDか• ネットワークと状態> 種類> 何といくつつながっているか• 周辺機器とその状態
•
•
•
•

外部環境
• 比較的変化しない環境> 場所、コースの素材• 比較的変化しやすい環境> 温度、湿度、光量、電源
58

テスト観点の例：組込みの場合（２）状態• ソフトウェアの内部状態> 初期化処理中か安定動作中か• ハードウェアの状態> ヘッドの位置、省電力モード

GUI・操作性••••

操作パス、ショートカット
操作が禁止される状況は何か
ユーザシナリオ、10モード
操作ミス、初心者操作、子供

タイミング• 機能同士のタイミング• 機能とハードウェアのタイミング

性能

出荷先• 電源、電圧、気温、ユーザの使い方• 言語、規格、法規• 最も遅そうな条件は何か

障害対応性

信頼性
• 要求連続稼働時間• 対応すべき障害の種類> 水没• 対応動作の種類

セキュリティ

テスト観点はテストケースの「意図」を表している

59

Test Request Analysis

２．TRA（テスト要求分析）60

テスト要求分析（TRA）
顧客やステークホルダーから「何に対して、どのようなテストを行うように求められているか」を得るため、主に以下の項目を確認しなければならない。
• テストの目的、動機。何をテストするのか？（何をテストしてほしいのか？）• テストの範囲はどこからどこまでか？（他システムまで及ぶのか？）• テストの規模はどれくらいか？（機能数や画面数など）• テストレベルは何か？（コンポーネントテスト？統合テスト？システムテスト？）• テストタイプやテスト観点は何か？
• 顧客やステークホルダが特に重視しているもの（優先度）は何か？
• テストの期間やコストはどれくらいか？

61

テスト要求の源泉
もし入手できるのなら、テスト要求の源泉を準備する。
テスト要求の源泉＝

テスト要求分析に活かせる情報のこと• 動いているテスト対象や動作の結果・状況• 要求系文書、開発系文書、ユーザ系文書、マネジメント系文書など各種文書• テストに関して従うべき社内・社外の標準や規格• ヒアリングできるステークホルダーなど
１つでも入手できないなら、自分たちでステークホルダーになりきってブレーンストーミングや仮想ヒアリングなどを行う。

テスト要求の源泉からテスト要求を獲得する

62

テスト要求の分割
テスト要求を、テストケースを導くエンジニアリング的テスト要求と、テストケースを導かないマネジメント的テスト要求に分ける
エンジニアリング的テスト要求
システムの完成像とテスト対象の途中経過に関わる。

技術的
要求

利害関係者
要求

管理的
要求

• システムの完成像への要求例> システム要求、ソフトウェア要求、機能要求、非機能要求、理想的な使い方、差別化要因、目的機能• テスト対象の途中経過に関する情報例> 良さに関する知識：テスト対象のアーキテクチャや詳細設計、実装、自信があるところ> 悪さに関する知識：バグが多そうなところ

次ページで詳しく説明
マネジメント的テスト要求
品質リスクやテストアーキテクチャ設計などに反映させる。

•
•
•
•

工数、人数、スキル分布、作業場所、オフショアか否か、契約形態など機材利用可否（シミュレータや試作機）、ツール利用可否（ツールの種類、ライセンス、保有スキル）など
目標残存バグ数、信頼度成長曲線など
テストスイートの派生可能性や保守性など

63前ページの「バグが多そうなところ」について
人的要因が主だが、以下のようなところに注意を向ける。

• ユーザがミスしそうなところ• 構造上問題が起きそうなところ• 前工程までの検証作業（レビューやテスト）が足りなかったり滞ったりしたところ• 類似製品や母体系製品の過去バグ、顧客クレームから分析した知識• スキルの足りないエンジニアが担当したところ• 設計中に不安が感じられたところ• 進捗が滞ったり、エンジニアが大きく入れ替わったりしたところ

64

テスト要求モデルの構築と納得
テスト要求モデルを構築し、自分たちとステークホルダーが納得するまでモデルを洗練する。
テスト要求モデルの構築
1. エンジニアリング的テスト要求を基に、テスト観点を列挙する
2. 階層構造やマトリクス、一覧表などでテスト要求モデルを記述する
3. テスト観点を詳細化したり、関連を追加したりする
4. モデルを洗練する→ 最終的に「テスト観点図」や「テスト観点表」になる。
自分たちが「十分に充実した」と実感できたら、そのモデルを囲んで、
ステークホルダーが納得するまで一緒に洗練し続ける。
→ ステークホルダーに不十分・不完全・不正確な把握が無いようにする。
→ ステークホルダーに「本当はこれだけテストしなければならない」という実感を持ってもらうことが重要である。
65

テスト観点を挙げるときの注意点（１）• 仕様書に書いてある仕様や文、単語を書き写してもテスト観点は網羅できない• 仕様書は通常不完全である（もしくは、テスト観点を挙げる時点で存在していない）• (特に致命的な）バグは仕様書に書かれていないテスト観点でしか見つけられないことがある
ここまで例に挙げたテスト観点は、皆さんの組織の仕様書に全て書いてありましたか？

• テスト観点は多面的に挙げる
入力に関するテスト観点だけ挙げたり、機体結果やその観測に関するテスト観点だけ挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する。
「観点」だから機体結果やチェックポイントだけを挙げるのはテスト観点を理解していない証左である。

66

テスト観点を挙げるときの注意点（２）• テスト観点を挙げただけでバグが見つかることがある• 開発者が考慮していなかったテスト観点はバグの温床であり、テストしなくてもバグだと分かることも多々ある• 期待結果に関するテスト観点を挙げたり詳細化したりすると、仕様の抜けが分かることがある
テストケースにも期待結果を必ず書くのを忘れないこと。
「正しく動作すること」は期待結果ではない！

• 「網羅した」風のテスト観点の文書や納品物を作ろうとせず、網羅しようと多面的に様々なことを考え尽くそう• 「あーでもない、こーでもない」とワイワイ議論したアイデアのリポジトリがテスト観点図（テスト観点表）である
見逃したバグを見つけ得るテスト観点を気軽に追加して整理することも大事である。
• 最初から網羅しようと気張ると大事なテスト観点を見逃す
そもそも網羅することが必要なのか？
67

モデリングの２つのアプローチ
トップダウン型

おもむろにテスト観点を挙げ、詳細化していく
ボトムアップ型

思いつくところから具体的なテストケースを書き、いくつか集まったところで抽象化し、テスト観点を導き出していく。

68

モデリングの２つのアプローチ
トップダウン型

おもむろにテスト観点を挙げ、詳細化していく

三角形

三角形

成立

直線

三角形

不成立

成立

二等辺
三角形

ボトムアップ型

直線

正三角形

思いつくところから具体的なテストケースを書き、いくつか集まったところで抽象化し、テスト観点を導き出していく。
正三角形(1, 1, 1)(1, 1, 1)(2, 2, 2)(3, 3, 3)

不成立

不等辺
三角形

三角形の種類
二等辺
三角形

正
三角形

不等辺
三角形

(1, 1, 1)(2, 2, 2)(3, 3, 3)

トップダウンとボトムアップを循環させながらモデリングしていく。

69

テスト要求モデルの全体像の種類「テスト要求モデルの全体像をどう整理すればよいか」に唯一絶対の解はない。
注意 • 一面的な全体像のモデルは考慮が足りないことが多い••••仕様ベースモデル
機能ベースモデル
画面ベースモデル
正常系異常系モデル• 多面的な方が考慮されている可能性が高いが、注意 お仕着せのものを流用したものは考慮が足りないことが多い••••

CIBFWモデル

品質特性モデル
一般テストタイプモデル
CIBFW（Condition／Item／Behavior／Fault／World）モデル
三銃士モデル
世界観／コンテキスト／実装 + ユーザ感情• システム構成モデル
そのシステム構想がそのまま全体像になる（ラルフチャートなど）
三銃士モデル

全体像の構造によってモデリングの質がかなり左右される。
大事なのはどれを採用したかではなく、考慮が十分かどうかである。

70

テスト要求モデルの洗練
質の高いモデルにするために様々な洗練を行う。
• 網羅化：MECE分析（漏れやダブりがないか）• 子観点がMECEに列挙されているかどうかをレビューし、不足している子観点を追加する• MECEにできない場合、必要に応じて「その他」の子観点を追加し、非MECEを明示する• 子観点をMECEにできるよう、適切な抽象度のテスト観点を親観点と子観点の間に追加する• 網羅化：親子関係分析
MECE性を高めるために、テスト観点の親子関係を明示し、子観点を分類する。

• 整理• 読む人によって意味の異なるテスト観点を特定し、名前を変更する• テスト観点や関連の移動、分割、統合、パターンの適用、テスト観点と関連・網羅基準との変換などを行う。
• 本当にその関連が必要なのかどうかの精査を行う必要もある• 剪定
ズームイン・アウト、テスト観点や関連の見直し、網羅基準や組み合わせ基準の緩和によってテスト項目数とリスクとのトレードオフを大まかに行う。

• 確定
子観点および関連が全て網羅的に列挙されているかどうかをレビューすることで、テスト要求モデル全体の網羅性を明示し、見逃しリスクを最小化する。
71Test Architecture Design

３．TAD（テストアーキテクチャ設計）

72

テストアーキテクチャ設計（TAD）
テストアーキテクチャ設計とは、テストスイートの全体像を把握しやすくしつつ後工程や派生製品、後継プロジェクトが作業しやすくなるように、テスト観点をグルーピングしてテスト要求モデルを整理する工程である。

VSTePでは、テスト観点のグルーピングについて、
以下の２つのモデリングを推奨している。
• テストコンテナモデリング• テストフレームモデリング
互いのモデリングを反復的に進めていくことを想定しており、どちらから始めても構わない。

73テストコンテナモデリング
テスト要求モデルを分割し、同じまとまりとしてテストすべきテスト観点を同じグループにまとめることで整理する。
複数のテスト観点をグルーピングしたものを「テストコンテナ」と呼ぶ。

テストコンテナモデリングのねらい• グルーピングすることで粒度が粗くなり、テストスイートの全体像の把握や全体に関わる設計がしやすくなる• 自社で定められているテストレベルやテストタイプの趣旨を理解し、全体像を設計できるようになる。
テストにも保守性など特有の「テストスイートの品質特性」や「テストコンテナの責務」があるが、どのような品質特性や責務を重視するかによって異なるテストアーキテクチャとなる。

74

テストコンテナ
テストコンテナを使って、テストタイプやテストレベル、テストサイクルなどを表現する。
それぞれの区別に時間を取られないで済む

テストコンテナは包含関係を持つことができる。

テストコンテナに含まれるテスト観点を比べると、テストコンテナ間の役割分担を明確に把握できる。
構成テスト

違いがよく分からないものも区別できる

負荷テスト
動作環境

プラットフォーム

OS

ボリューム

高頻度

ストレージ

ロングラン

ネットワークハードウェア75

テストコンテナモデル
テストコンテナのモデルで表すと全体像を把握しやすくなる。
先に設計／実施しておくべきコンテナを後に回してしまう、といったトラブルが防げる
単体テスト

単体テスト

構造テスト

呼び出し
テスト

例外ハンド
リングテスト

割込みハンドリングテスト

システムテスト

機能テスト

機能テスト

負荷テスト

負荷テスト

動作環境テスト
マルチバイト
テスト

共有メモリ
テスト

配列境界
テスト

デバイス制御テスト

セキュリティ
テスト76

テストコンテナモデリングのメリット• テスト観点よりも粒度の粗いテストコンテナを用いるので、俯瞰して把握しやすい• テストコンテナ間に含まれるテスト観点を比べると、役割分担を明確に把握できる現場で経験的に用いているテストコンテナの妥当性を評価したり改善できるようになる。
負荷テストと性能テストなど、違いがよく分からないテストタイプを区別できる。
単体テストと結合テストなど、役割分担がよく分からないテストレベルを区別できる。

• 複数のテストタイプからなるテストレベル、サブレベルを持つテストレベルなどのように、他のテストコンテナを包含しながらまとめることもできる• テストコンテナの順序や依存関係、設計時期（や実施時期）を適切に考慮することができる
CIなどツールチェーンを構築したり、フロントローディングしたり、シフトライトをする際には必須となる。

• テストスイートの品質特性（保守性や自動化容易性など）やテストコンテナの責務を意識してテスト設計に反映できるので、納得しやすいテストアーキテクチャになる77テストコンテナモデリングのポイント• テストが小規模で単純な場合、テスト要求モデルの大まかな分類をそのままテストコンテナにしてしまってよい場合もある• テスト要求モデルでは単一だったテスト観点を分割したり統合したりすることにより、意味の違いに気付いて名前を変えたりテスト観点を追加したりすることもある
現実的には、テストコンテナモデリングとテスト観点モデリングは反復的に行うことになるだろう。

• マネジメント的要求からテストスイートの品質特性やテストコンテナの責務を抽出し、それらを達成できるようにモデリングする
例）保守性を高めたいというマネジメント的要求がある場合、変更要求があまり入らないテストコンテナと変更要求が頻繁に入るテストコンテナに分割する• テスト（スイート）のアーキテクチャ、システム・サービス・製品・ソフトウェアのアーキテクチャ、開発環境やテスト実行環境（テストシステム）のアーキテクチャ、
開発プロセスは相互に影響する78テストコンテナへのまとめかたの基本• 同じ時期にテストすべきテスト観点をテストレベルとしてまとめる
テスト観点には、テスト観点同士、または欠陥特定の絞り込みのための順序依存関係や、プロジェクト制約としての時期依存関係がある。

• 同じ趣旨を持っているテスト観点をテストタイプとしてまとめる
例えば、負荷テストタイプは複数のテスト観点から成るが、「負荷をかける」という同じ趣旨を持つ。

• 繰り返しのテストや回帰テストが必要なテスト観点、スプリントやイテレーション
ごとのテストをテストサイクルとしてまとめる
同じテスト観点を繰り返しているようでいて、実は意味が異なっていることがあるので注意する。

• テストコンテナ間の関係がなるべく少なくなる（疎になる）ようにまとめる
結合度を低く、凝集度を高く（同じテスト設計意図のテスト観点はまとめるように）設計する。

79

自分なりのテストコンテナを考えてよい
Automated testing for Gacha (gamble) probability

Exhaustive automated testing for payment for various items
Complicatedpayment flow
verification
Mainstream
devicesverification

Basic
networkverification

Model of World
suitability validation
Background Story suitability
Validation

Equipment and items
suitability Validation

Complianceverification

Businessmodel
suitability
Validation

Load testingfor payment

Minor
devicesverification

Various
networkverification

Movement
sync.
verification

Movement
realityvalidation

Automated testing
for wall penetration

Various
payment
verification

Delightful
payment
validation

Payment
security
verification

Multi server
handoff
verification

Load testingfor play

SUT
updatetesting

Interruptionof other apps
testing

Balancebreaker
exploratory
testingBuzz-ability
validation

Difficulty validation
by expert
Difficulty validation
by beginner

Shot&deadtimingvalidation

User
thrill & relax
validation

Catharsis
validation

Addiction
validation

Distraction
validation

Resumption
validation

Competitor
comparison
verification

Businessmodel
suitability
Validation

Platform
certification
testing

Businessmodel
suitability
Validation

Marketingmaterials
suitability
verification

Businessmodel
suitability
Validation
80異なるテストコンテナが混在することもある
Automated testing for Gacha (gamble) probability

Exhaustive automated testing for payment for various items
Complicatedpayment flow
verification
Mainstream
devicesverification

Basic
networkverification

Model of World
suitability validation
Background Story suitability
Validation

Equipment and items
suitability Validation

Complianceverification

Businessmodel
suitability
Validation

Load testingfor payment

Minor
devicesverification

Various
networkverification

Movement
sync.
verification

Movement
realityvalidation

Automated testing
for wall penetration

Orange ... SoR
Blue …
SoE

Various
payment
verification

Delightful
payment
validation

Payment
security
verification

Multi server
handoff
verification

Load testingfor play

SUT
updatetesting

Interruptionof other apps
testing

Balancebreaker
exploratory
testingBuzz-ability
validation

Difficulty validation
by expert
Difficulty validation
by beginner

Shot&deadtimingvalidation

User
thrill & relax
validation

Catharsis
validation

Addiction
validation

Distraction
validation

Resumption
validation

Competitor
comparison
verification

Businessmodel
suitability
Validation

Platform
certification
testing

Businessmodel
suitability
Validation

Marketingmaterials
suitability
verification

Businessmodel
suitability
Validation81

テストコンテナの粒度も自分なりでよい
Automated testing for Gacha (gamble) probability

Exhaustive automated testing for payment for various items

Complicatedpayment flow
verification
Mainstream
devicesverification

Basic
networkverification

Basic env.
test level
Model of World
suitability validation

Monetization test type
Load testingfor payment

Minor
devicesverification

Various
networkverification

Movement
sync.
verification

Movement
realityvalidation

Various env.
test level

Particularemotional impression
test level

Background Story suitability
Validation

Equipment and items
suitability Validation

Complianceverification

Businessmodel
suitability
Validation

Automated testing
for wall penetration

Various
payment
verification

Delightful
payment
validation

Payment
security
verification

Multi server
handoff
verification

Load testingfor play

SUT
updatetesting

Interruptionof other apps
testing

Balancebreaker
exploratory
testingBuzz-ability
validation

Actual env.
test level
Difficulty validation
by expert

Real usage
test level

Holistic
emotional impression
test level

Difficulty validation
by beginner

Shot&deadtimingvalidation

User
thrill & relax
validation

Catharsis
validation

Addiction
validation

Distraction
validation

Resumption
validation

Competitor
comparison
verification

Businessmodel
suitability
Validation

Platform
certification
testing

Businessmodel
suitability
Validation

Marketingmaterials
suitability
verification

Businessmodel
suitability
Validation

Business test type82

テストアーキテクチャ設計における責務の分担
テストスイートの品質特性が満たされテストコンテナの責務が適切に分担されるようにテストアーキテクチャを設計する必要がある。
• アーキテクチャを検討するほど大規模で複雑なテストスイートでは、
スイート自身の品質特性やコンテナの責務を考慮しなければならない• テストコンテナには責務を表す名前を適切につける必要がある

テストスイートの品質特性やテストコンテナの責務には色々ある。
•
•
•
•
•
•
•
•
•
•
•

Coupling（結合度）
Cohesion（凝集度）
Test design intention（テスト設計意図）
Maintainability（保守性・派生容易性）
Automatability（自動化容易性）
Circumstance consistency（環境類似性）
Development consistency（開発工程類似性）
Describability（記述容易性）
Execute velocity consistency（実行速度類似性）
Stability / Change frequency（安定性／変更頻度類似性）
Design type（設計種別類似性）

性能テスト

性能測定

大規模負荷
テスト

負荷分散機能確認テスト

適切にDoSアタック「責務の分担」
テストがなされ、適切な名前が付いているだろうか？
83テストコンテナの責務
テスト設計意図• テストには様々な設計意図があり、しばしば混在するため、（サブ）コンテナとして同じ設計意図に揃えた方がよい
テスト設計意図は、そのテスト（コンテナ）の実行結果をどのように役立てたいか、である。

• テストコンテナの設計意図とテストケースの意図は連動すべきである
テストケースの意図は、そのテストコンテナの設計意図を満たすように詳細化され、何らかのテスト観点に表現されるはずである。

設計種別類似性• 設計種別類似性は、設計者の頭の使い方の類似性である• 設計時の頭の使い方が異なる設計は混ぜない方がよい
例：
テスト条件→引き起こされる期待結果を考えるテスト設計
vs
期待結果→引き起こすテスト条件を考えるテスト設計

動くことを証明したいテスト設計（肯定的テスト設計）vs
動かないことを証明したいテスト設計（否定的テスト設計）
84

テストフレームモデリング
複数のテスト観点を同じグループにまとめて、テストケースの構造（スケルトン）を定義し、テスト詳細設計をしやすくする。
実際のテスト設計では、複数のテスト観点をまとめてテストケースを設計したい場合がある。

テストケースの構造をテスト観点の組み合わせで示すことで、複数のテスト観点によるテスト
ケースを設計する。
「テストフレーム」と呼ぶ<<frame>>というステレオタイプの関連を用いる

データ量<<frame>>

残メモリ量<<frame>>

性能

テスト条件＋テスト対象＋振る舞いをテストフレームとしている。
組み合わせテストを設計しようとしているわけではない点に注意する。
85テストケースの構造の明示「テストケースの構造」には単純なものから複雑なものまで色々あり得る。

複雑なテストケースがバグを見つけやすいわけでもないことに注意する。
どのくらい複雑なテストフレームを組むかによって、テスト設計の良し悪しが変わる。
どういうトレードオフをどう考え、どういう意図でこの複雑さのテストフレームにしたのか、をきちんと説明できないといけない。
〇〇テスト
〇〇〇

期待結果

単純なテストフレーム例
連続稼働期間

△△△

□□□

３辺の長さ

三角形種別
判定機能
ユーザ種別

▲▲▲

三角形種別
判定機能

３辺の長さ

期待結果

視認性

狙っているバグ

入力頻度■■■

ハードウェアOS

ブラウザ

複雑なテストフレーム例

86

テストフレームはテストケースのスケルトン
テストフレームの要素を見出しとして表を作ると、テストケースになる。
• テストフレームをきちんと考えないと、「大項目―中項目―小項目」という見出しで整理した気になっていても、全く整理されていない、網羅しにくいテストケース表が出来上がる• マインドマップやUMLツールなどを併用すると描きやすいが、全部一覧表やマトリクスでも構わない
テストケース表の例

３辺の長さ

三角形種別
判定機能

ブラウザ

テストフレーム例

期待結果

ID

3辺の長さ

ブラウザ

期待結果

1

(3, 4, 5)

Safari

不等辺三角形

2(3, 3, 4)

Safari二等辺三角形

3(3, 3, 3)

Safari

正三角形

4(3, 3, 6)

Safari

潰れて三角形にならない
87

組み合わせテストでもテストフレームに示そう組み合わせてテストすべきテスト観点があったら、テストフレームに明記する。
• 明記しないと、組み合わせずに代表値や境界値だけのテストケースを作ってしまいがち• 組み合わせが多い方が良いわけでもバグを見つけやすいわけでもないことに注意する
どのくらい複雑な組み合わせのテストを設計するかによって、テスト設計の良し悪しが変わる。どういうトレードオフをどう考え、どういう意図でこの複雑さの組み合わせにしたのか、をきちんと説明できないといけない。
組み合わせのテストケース表の例

ブラウザ<<combination>>OS

組み合わせのテストフレーム例

ID

ブラウザ

OS

1

Safari

iOS 9.3.2

2

Safari

iOS 8.4.1

3

ChromeiOS 9.3.2

4

ChromeiOS 8.4.1
88

探索的テスト• エキスパートによる非記述的なテストを探索的テストと呼ぶ• テストエンジニアが五感と経験（によって得られたパターン）と感受性を駆使することでバグを出すことに集中しながら学習し、探索することで創造性を発揮するテストの方法である• 「ただ触るだけ」のモンキーテストやアドホックテストではない• チャーターとセッションでマネジメントを行う• 大まかにどの辺をテストするか、どんなことをテストするか、を伝える「チャーター」を用いてマネジメントを行う• テストエンジニアが集中力を高めておける時間を１つの「セッション」という単位で捉え、マネジメントを行う• テストアーキテクチャ設計時に考慮しておく必要がある• チャータ―をテスト観点として扱い、いくつかのテストコンテナとしてまとめ、記述的テストと区別してテストアーキテクチャを設計するとよい• 記述的テストとの棲み分けをきちんと考慮しておかないと、「その他のテスト」コンテナに成り下がる

89

探索的テストのポイント• 探索的テストで何に着目するかはエキスパートに依存する
•
•
•
•
•
•

バグの出そうな仕様やつくりに着目する（人がいる）
プロジェクトの状況やエンジニアの納得度に着目する（人がいる）
バグの出方に着目する（人がいる）
ユーザの使い方や、そう使うとは想像しない使い方に着目する（人がいる）
出てほしくないバグや起こってほしくないハザード・アクシデントに着目する（人がいる）
ふるまいの一瞬の揺れなど怪しい動作に着目する（人がいる）• 探索的テストは万能ではない• 探索的テストと記述的テストは補完させるべきである
探索的テストだけでテストアーキテクチャを構成するのは極めて危険である。
記述的テストを受注する第3者テスト会社でも50%近くを探索的テストで行う場合もある• 探索的テスト中にテストエンジニアがテスト対象について学習し、野生に還ったかどうか（感受性を鋭敏にしたかどうか）をマネジメントするとよい•

網羅性や一貫性などを求めない方がよい• 探索的テスト後にテストエンジニアが仲間とそのセッションについておしゃべりするとよい••

学習した結果や気付いた怪しい動作、言語化しにくい経験ベースのパターンを言語化するチャンス
高い感受性で開発者と対話ができるように心理的安全を確保しておく必要がある
90

アジャイル開発におけるテストアーキテクチャ(1)アジャイル開発でもTDLC（テスト開発ライフサイクル）やテストアーキテクチャに関する技術が必要になる。
• ユーザの価値にフォーカスする• ユーザの価値や、ストーリー、フィーチャーといったテストベースに関する非言語的理解が多いため、テスト要求分析を深く行わないとテスト設計に漏れが発生しやすくなる• 変化・成長しやすいダイナミックなテストであることをキープする
計画やプロダクトの変化・成長にテストの変化・成長が追いつかねばならないため、テスト観点やテストコンテナのように高い抽象度で可視化して分析・設計を行い、保守性・派生容易性や自動化容易性を高めてテストのダイナミックさを実現し続けることがキーになる• 顧客との対話によってフィーチャーやユーザストーリーに留まらず、プロダクトの方向性や価値すらも変わっていく
ため、抽象度の高い（モデルで可視化された）検討や意志決定がテスト（QA）エンジニアにも必要になる• よいテストアーキテクチャがないと、フィーチャが高速かつ創発的に追加されていくのに釣られてテストが乱雑になっていき、開発の速度を落としてしまったりテストが追いつけなくなってしまう• よいテストアーキテクチャがないと、自動化できるテストと手動でしかできないテストを区別しにくくなるため、手動テスト率が増えてしまい、速度が落ちたり、開発に変化・成長したくない圧力をかけてしまうアジャイル開発におけるテストアーキテクチャ(2)アジャイル開発でもTDLC（テスト開発ライフサイクル）やテストアーキテクチャに関する技術が必要になる。

• チーム全員でテスト（QA）を行う• テストコンテナやテスト観点を可視化し整理し議論し納得感を共感することで、開発エンジニアが行うテストとテスト（QA）エンジニアが行うテストとの役割分担やその必要性・重要性を両者が理解・把握しきちんとダイナミックかつ有機的に連携できる• テスト（QA）エンジニアが最初から参画しレビューなども行うのであれば、テストアーキテクチャにはレビューなども含まれた「QAアーキテクチャ」になるべきである• チーム全員で考えてチーム全員で賢くなっていく
テスト観点やテストコンテナのように（複雑すぎない）モデルで可視化することで、テスト（QA）エンジニアが気にすべきことや（開発エンジニアが気付かず）テスト（QA）エンジニアが気付いたことを、プロダクトオーナーや開発エンジニアとの間で最初から双方向で共有しやすくできる。

イテレーション型テストアーキテクチャの設計(1)イテレーションコンテナと非イテレーションコンテナの識別• イテレーションごとに分割統治できる独立フィーチャーと一部依存関係を持つ依存フィーチャー、基盤となるプラットフォーム、システム全体のテストに関するコンテナなどを識別する
通常はアーキテクトやPO、チームがQAが理解し設計しているはずなので、皆で対話しながら、テスト（QA）として品質を積み上げていけるかどうかをイメージしフィードバックする。

• フィーチャーをまたいでテストしなくてはならないテスト観点を識別する•••

UXなどふるまい的なテスト観点については、イテレーション間の一貫性などだけでなく、
イテレーションが進むとどう変化するのかなどについても検討する
いくつか/全体のフィーチャーが揃わないとできないテスト観点については、
フィーチャーごとのテストによって揃う前から品質を積み上げていけるように検討する
ソフトウェア設計上の依存関係については、アーキテクトや開発エンジニアと対話したり、過去のバージョンやそれまでのイテレーションのバグの出方、同種の製品で発生したバグの原因から推測する• 運用中テストやシフトライトテストが必要かどうかを検討する•••

運用中に追加・変更されるフィーチャーやテスト観点の独立性を検討する
ある時点のデプロイより前に絶対にやらなくてはならないテスト観点、後に回せるテスト観点、運用中にテストすべきテスト観点などを識別する
運用中テストやシフトライトテストで測定すべき項目を検討するイテレーション型テストアーキテクチャの設計(2)イテレーションコンテナの設計• 各イテレーションのフィーチャーごとに必要なテスト観点やテストサブコンテナを設計する
どのフィーチャーを開発するかはイテレーションごとにダイナミックに決まることが多いので、イテレーションコンテナに含まれるだろうフィーチャー群（フィーチャープール）としてグルーピングしておくと、テストアーキテクチャ設計がしやすくなる。

• イテレーションスリップやイテレーションフォークをどう扱うかについて検討しておく• イテレーションが進んで回帰テスト量が増えるなど
手動テスト工数やテスト自動化工数が増えてしまった際にどうするか、に正解はない• 最初から意図的にイテレーションスリップやイテレーションフォークを発生させる場合もある• なし崩し的に発生したイテレーションスリップやイテレーションフォークを回収するのは容易ではない• イテレーションプールごとに扱いが異なる場合もある• イテレーションスリップやイテレーションフォークが発生しないようテスト自動化のためのテストコンテナをわざわざ設計する場合もあるイテレーション型テストアーキテクチャの設計(3)非イテレーション/準イテレーションコンテナの設計
プラットフォームやシステム全体に関するテストコンテナ、依存フィーチャーに関するテストコンテナ、
フィーチャーまたぎのテストコンテナなどに含まれるサブテストコンテナ・テスト観点や、そのテスト
コンテナに関するテスト設計やテスト実行の頻度を設計する。
QAチームが別にテストしたり、そのために新たなイテレーションを始めることもあれば、バラしてイテレーションに組み込むこともあるので、チーム外QAやPO、SMなどと対話しながら検討する。

テストコンテナ間の設計• イテレーションコンテナ内のテスト（サブ）コンテナ間の依存関係を識別し、組み合わせや順序関係を設計する• バグの出方などからイテレーションコンテナ間に「依存関係がある」と感じられた場合は、すぐにアーキテクトや開発エンジニアと対話して一緒に取り扱いを検討するフルスタックQAエンジニアを目指そう
これからは（特にアジャイル開発の場合）
テスト（QA）エンジニアであっても、開発の知識がフルスタックで必要になる• イテレーション• フィーチャーやユーザーストーリーなど• リファタクタリング• マイクロサービスアーキテクチャ（MSA）や疎結合、古くはカプセル化や結合度・凝集度• 各種プラットフォームやアーキテクチャ• クラウド・エッジ/サーバ・フロントエンドのバランス• devOps / シフトライト（カオスエンジニアリング）• CI/CDやテスト自動化の技術・プラットフォーム• TDD（テスト駆動開発）を何らかの品質を「保証」するためのテストとみなすのか否か
など

もちろん、
テストの技術もTDLC（テスト開発ライフサイクル）の技術もQAの技術もドメインの知識も必要になってくるTest Detail Design

Test Implementation

4．TDD・TI（テスト詳細設計、テスト実装）97

テスト観点からテスト値を網羅する• テスト値の網羅は以下の手順で行う。
1. テスト観点がどのタイプの「テストモデル」なのかを見極める
2. 網羅基準（カバレッジ基準）を定める
3. 定めた網羅基準でテストパラメータを網羅するようにテスト値を設計する• テスト詳細設計は機械的に行っていくのが基本である。
• 可能な限り自動化すると、Excelを埋める単純作業を撲滅できる• 機械的にできないところは、網羅基準が曖昧だったり、テスト観点が隠れていたりする

98

テスト詳細設計モデル
テスト詳細設計モデルのタイプには４つのタイプがある。
• 範囲タイプ• 一覧表タイプ• マトリクスタイプ• グラフタイプ

テスト値には２種類あるので注意する必要がある• 直接テスト値：テスト値が直接テスト手順の一部（テストデータ）として実施できるもの
例）３辺の長さ（3, 3, 3）• 関節テスト値：テスト値からさらにテストデータを導く必要があるもの例）制御パス

制御パスを網羅して、そのあとにそれぞれの制御パスを通す
テストデータを作成する。

テストパラメータやテスト詳細設計モデルを特定せずに闇雲にテストケースを挙げるのは、質の高いテストとはいえない。
99

範囲タイプのテストモデルの網羅範囲タイプのテスト詳細設計モデルは、
ある連続した範囲を意味するテスト観点を網羅するときに用いる。
例）
辺の長さ（0以上65535以下の整数値）
範囲のことを「同値クラス」と呼び、同値クラスを導出する技法を同値分割と呼ぶ。

範囲タイプのテスト詳細設計モデルの網羅基準は以下のとおりである。
• 全網羅例）0, 1, 2, 3, 4, 5, 6, … 100, … 10000, … 65534, 65535
漏れはないが、テスト値が膨大になるため現実的ではない。

• 境界値網羅例）0, 65535, -1, 65536➢ 境界値分析や境界値テスト、ドメインテストなど独立した技法として説明されることが多い➢ 有効境界値だけでなく無効境界値も忘れないこと➢ 範囲が開いている（上限や下限が定まっていない）時は自分で定める必要があるが、よく検討しないと漏れが発生しやすくなる• 代表値網羅例）3
テスト値は少くなく収まるが、漏れが発生する。
100

一覧表タイプのテストモデルの網羅
一覧表タイプのテスト詳細設計モデルは、複数の要素からなる集合を意味するテスト観点を網羅するときに用いる。
例）
ブラウザ

一覧表タイプのテスト詳細設計モデルの網羅基準は以下のとおりである。
• 全網羅例）Chrome, Firefox, Safari, Internet Explorer, Edge
漏れはなく、通常はテスト値もそれほど膨大にならないが、組み合わせになったら無視できな
い程にテスト値が多くなってしまう。

• 境界値網羅例）一番昔にリリースされたブラウザと一番最近にリリースされたブラウザ
よく検討しないと漏れが発生しやすくなる• 代表値網羅例）Chrome
テスト値は少くなく収まるが、漏れが発生する。
101

マトリクスのテストモデルの網羅マトリクスタイプのテスト詳細設計モデルは、２つ（以上）のテスト観点の組み合わせを網羅するときに用いる。
例）
OSとブラウザの組み合わせ
組み合わせたいテスト観点の数をここでは段数と呼ぶ。

一覧表タイプのテスト詳細設計モデルの網羅基準は以下のとおりである。
• 全網羅例）Chrome, Firefox, Safari, Internet Explorer, Edge
漏れはないが、掛け算によりテスト値が膨大になるため現実的ではない。
禁則（無効な組み合わせ）に注意する。

• N-wise網羅
N+1以上の段数の組み合わせの網羅を意図的に無視することによって、現実的な数でNまでの組み合わせを全網羅する方法である。N＝２のときをPairwiseと呼ぶ。
Nまでの組み合わせの網羅で十分かどうか検討しないと漏れが発生する。

• 代表値網羅テスト値は少くなく収まるが、漏れが発生する。
102

グラフタイプのテストモデルの網羅グラフタイプのテスト詳細設計モデルは、丸と線で図が描けるようなテスト観点を網羅するときに用いる。
例）
プログラムのロジック、状態遷移図、シーケンス図、ユーザシナリオ、地下鉄の路線図
折れ線グラフや棒グラフのグラフではない。
丸と線で描ける図を（フロー）グラフ、丸をノード、線をリンク、丸と線による経路をパスと呼ぶ。
制御フローパステストの場合は、if文の複合判定条件の真理値表の網羅と組み合わせることがある。（C2網羅）

グラフタイプのテスト詳細設計モデルの網羅基準は以下のとおりである。
• 全パス網羅

漏れはないが、テスト値が膨大になるため現実的ではない。

• MC/DC（Modified Condition / Decision Coverage）• Nスイッチ網羅• リンク網羅（0スイッチ網羅，C1網羅）
テスト漏れが発生する。
• ノード網羅（C0網羅）• 代表パス網羅
テスト値は少くなく収まるが、漏れが発生する。

103

テスト実装（TI）
テストケースが生成できたら、テスト実装を行う。
• テスト対象のシステムやソフトウェアの仕様、テストツールなどに合わせてテストケースをテストスクリプトに具体化していく• テスト実装は、テスト対象のUI系の仕様や実行環境、ユーザのふるまいに関するノウハウが必要である

集約• テスト実施を効率的に行うため、複数のテストケースを１つのテストスクリプトにまとめる作業を「集約」と呼ぶ• 同じ事前条件や同じテスト条件、同じテストトリガのテストケース、あるテストケースの実行結果が他のテストケースの事前条件やテスト条件になっている場合は集約しやすい

キーワード駆動テスト• “クリック”といった自然言語の「キーワード」で自動化テストスクリプトを記述することにより、保守性を高めたり自動生成をしやすくしたりする技術である• テスト観点とキーワードを対応させると、キーワード駆動テストを実現しやすくなる
1045．テスト開発のTIPS

105

テスト開発プロセスを現場に適用する際のポイント(1)• テストエンジニアのマインドを、「表を埋める単純作業」からクリエイティブなモデリングに変えていく• 単純作業だと思ってしまっている限り、モチベーションもスキルも向上しない• 単純作業の部分は自動化するように技術を高めていく• できるところから小さく始めて小さく回し、効果を実感しながら進めることが重要••••

まずは腕の良いエンジニアに、テストスイートのごく一部から適用してもらうとよい
初めはあまり網羅性を意識せず、テスト要求モデルをつくり、自分たちのテストの良さ悪さを実感してみる
常にテスト開発プロセスの良さをエンジニアが実感しながら進めるようにする
自分たちに必要だができていないことを明らかにして、さらなる導入を進める• モデルをコミュニケーションの道具として使う• 同じプロジェクトの異なるテストエンジニア同士で、役割の違うエンジニアと、そして顧客とのコミュニケーションの道具としてテスト観点を用いるとよい• 網羅しているかどうか、質の高いモデルかどうかなどを皆で「納得」することがとても重要である
106

テスト開発プロセスを現場に適用する際のポイント(2)• テスト要求分析・テストアーキテクチャ設計でのモデリングスキルを高める
•
•
•
•
•
•
•

観点の意味をブレないようにする
詳細化の種類を明示し整理する
テスト観点の抽象度をきちんと意識し、詳細度が丁寧に落とし込まれるようにする
単に適当に組み合わせるのではなく、関連が発生する要因を推測する
テストのデザインパターンを抽出し蓄積する
テストアーキテクチャスタイルを蓄積する
自分たちが気にしている・気にすべきテスト品質特性を明らかにする• テスト開発プロセスの導入と合わせてリバースエンジニアリングで現状のテストを改善できるとよい• テストプロセスそのものの改善や、テストをきっかけとした開発プロセスの改善の道具としてテスト開発プロセスを活用できるとよい

107

6．過去の応募作のポイント

108応募作のテストアーキテクチャ(1)
過去の応募作を分析すると、テストアーキテクチャの構成要素は様々だった。
• 多くのチームが以下のようなテスト観点を抽出していた• テスト条件、ふるまい（期待結果）、見つけたいバグ• テスト対象（の要素）、Test item

• 多くのチームが２つの書き方で構造を記述していた• モデルっぽい書き方• 表（マトリクス）っぽい書き方

表（マトリクス）風の記法
テストすべき条件／ふるまい／バグ
テスト対象（の要素）

テストすべきテスト条件／ふるまい／バグ

モデル風の記法

テスト
対象
（の要素）

C1

C2

C3

P1

P1をC1でテスト

P1をC2でテスト

P1をC3でテスト

P2

P2をC1でテスト

P2をC2でテスト

P2をC3でテスト

P3

P3をC1でテスト

P3をC2でテスト

P3をC3でテスト
109

応募作のテストアーキテクチャ(2)
過去の応募作を分析すると、様々なテストアーキテクチャが構築されていた。
• （伝統的）テストタイプ型アーキテクチャ
サービス
レイヤ

• レイヤ型アーキテクチャ• フィルタ型アーキテクチャ

機能
レイヤ• 複合型アーキテクチャ

プラット
フォーム
レイヤ

• アジャイル開発に対応したテストアーキテクチャ？

レイヤ型アーキテクチャ
全体統括レイヤ

単純バグ
検出
フィルタ

論理バグ
検出
フィルタ

負荷バグ
検出
フィルタ

フィルタ型アーキテクチャ

網羅的
テスト
フィルタ

アプリ
レイヤ

アプリ
レイヤ

アプリ
レイヤ

アプリ
レイヤ

アプリ
レイヤ

ドライバ
レイヤ

ドライバ
レイヤ

ドライバ
レイヤ

ドライバ
レイヤ

ドライバ
レイヤ

ドライバ
レイヤ

マスタ
CPU

金銭管理
CPU

缶ラック
管理
CPU

ボタン
管理
CPU

スロット
センサ
CPU

懸賞管理
CPU

複合型アーキテクチャ
110応募作のテストアーキテクチャ(3)一見似たようなレイヤ型アーキテクチャであっても、実は異なっていた。

ビューやレイヤ数も様々だった。
システム
アーキテクチャビュー

ソフトウェアアーキテクチャ
ビュー

サービス
レイヤ

全体管理
レイヤ

機能ビュー
（３階層）

機能ビュー
（４階層）

機能
組み合わせ
レイヤ

機能組み合わせ
レイヤ

機能
レイヤ

アプリ
レイヤ

複数機能
レイヤ

プラットフォーム
レイヤ

ドライバ
レイヤ

単一機能
レイヤ

主機能
レイヤ
サポート機能
レイヤ
基本機能
レイヤ
111

過去の応募作の審査で気になった点(1)• 設計根拠を明示してほしい• 特にテストアーキテクチャ設計の設計根拠を論理的に記述してほしい「なんかよく分からないけどこんな風に配置してみました」は設計したことにならない。
「このような文脈だからこのような品質特性を達成する必要があるので、これこれこうしたコンテナの責務に分割されなくてはならない」、のように書けるとよい。
機能重要度・リスクベースドや実行順序だけを考えたテストアーキテクチャはもう平凡である。
最初に機能で分割することが果たしてよいテストアーキテクチャなのか、を熟考すべき。

• トレードオフの種類と判断根拠や、対案を却下した理由を記述してほしい
多面的な／複数のトレードオフが必要になるはずである。
異なる判断に基づいた複数の設計案が示されていると素晴らしい。

• トレーサビリティやカバレッジは、読めば確保できていることが分かるようにしてほしい• テスト観点を多面的に考慮し、それらの関係と根拠を明示してほしい
テスト対象は一般に、テスト対象ごとに固有なものも含めて多面的なテスト観点が必要になる。
また、テスト対象ごとにテスト観点間の関係も異なる。したがって、多面的にテスト観点を考慮し、それらの関係をきちんとモデリングし、その根拠を明示してほしい。

112

過去の応募作の審査で気になった点(2)• スコープとその根拠を明示してほしい
設計範囲とそのために考慮すべき範囲、考慮する必要がない範囲と設計しない範囲を根拠とともに明示してほしい。仕様書にあるから考慮しました、設計したところがスコープです、ではない・・・• これで本当に俯瞰しやすいのかどうかをきちんと検討してほしい
巨大なマトリクス、ごちゃごちゃした線、責務が重複した箱・・・
だからといって単にシンプルにすればいいわけではない。

• 自分たちのテスト開発プロセスの結合度と凝集度に目を向けてほしい
TRA、TAD、TDD、TIの各フェーズを自分たちなりに定義し直したり、新たに定義したりするのは問題ないが、なぜそのようにフェーズを決めたのかをきちんと説明してほしい。

• 最新のプラクティスを取り入れるのであればきちんと取り入れてほしい
それぞれのプラクティスになるコンセプトや強み、実際に直面する弱みなどをきちんと熟考して、それぞれのプラクティスがテストによってより良くなるように、最新のテスト開発方法論を構築してほしい。
とにかくアジャイルにしてみた、とにかく自動化してみた、とにかく探索的テストやります、ではそれぞれのプラクティスに対応したことにならない。
113考えろ、考えろ、そして考えろ• まずは、一つ一つきちんと、
自分たちが扱っているものや、行っていることの意味を熟考して、それらを言語化して論理的に順序立てて説明してほしい
文章だけでなく図やモデルを使っても構わない。
他の文章や規格から引用する際は、それらの意味や妥当性、引用してよい理由をきちんと熟考して説明する。

• そして、常に全体像を俯瞰して捉えてほしい
全体像が分からないと、そこかしこで思い込みや矛盾、部分最適が発生する。
全体像から、詳細なテストケースやテスト手順までを段階的に詳細化する必要• ただし、言語化や論理を重視するあまり、直感を捨ててはならない
直感も大事な技術力である。

直観で判断などを行ったところは、「ここは直感で〇〇した」と書いておけばよい。
後でリスクヘッジをしたり、振り返りや改善をしたり、流用したときに説明可能になることを期待する。
114

テストはエンジニアリングである
テスト設計コンテストは、業務での「熟考度」や「俯瞰度」を反映している。
• 言語化して論理的に説明できなかったり、俯瞰できないテスト設計はレビュー不能であるし、そもそもテスト設計できていない見込みが高いし、何より自分たちが納得してテストを勧められていないはずである• テスト設計コンテストOpenクラスは、自社の最先端の技術開発のオープンイノベーションの場である• テストはソフトウェア開発の（重要な）一部であり、テストはエンジニアリングである

テストのことだけではなく、ソフトウェア開発に必要となる思考力やモデリング力を身につけよう115

ご清聴ありがとうございました

116