テスト設計の本質を改めて考えてみる～生成AIを活用する時代だからこそ、作ったテストの説明性を高めよう～

JaSST'26 Kansai テーマセッション S2-A）

テスト設計を学ぶ際、多くの場合はテスト技法から入りがちです。しかし、技法を個別に学んだとしても、実務で適切に使いこなせないという課題は少なくありません。

本セッションでは、特定の技法の解説には踏み込まず、「テスト設計とは本質的に何をしているのか」という観点から、テストベースを起点にテストケースを導出する思考プロセスを整理します。そのうえで、技法がどのような役割を持ち、どのように選択・適用されるべきかを考えます。

本質的な理解に立ち返ることで、個々の技法に振り回されず、説明性の高いテスト設計へとつなげるための示唆を提供します。

Transcript

1. テスト設計の本質を改めて考えてみる ～生成AIを活用する時代だからこそ、作ったテストの説明性を高めよう～ 2026年7月3日(金) 於 JaSST’26 Kansai
2. 山﨑 崇 2001年からセキュリティ対策ベンダーにおいて、さまざまなプロジェクトのソフトウェア テスト活動にQAエンジニアとして従事。その傍ら、さまざまなテストコミュニティに参画し、 活動の場を広げる。2015年にベリサーブに入社。現場への技術支援、教育、 コンサルテーションなどを担い、少しでも現場が幸せになるように日々奮闘中。 主な活動 • SQuBOKガイドV4 策定部会（’25～） • 日科技連ODC分析研究会 運営委員（’24～） • JaSST東京実行委員会 （’11～23） • テスト設計コンテストU-30審査委員 （’16～） • ASTER テストプロセス改善研究会 （’16～） • JSTQB Foundation Level 認定講師 （’12～）など 主な著書・訳書 • 実践ソフトウェアエンジニアリング 第9版 （共訳） • 開発現場で役立つテスト「超」実践講座 第9回 （著） • テスト技術者資格制度Foundation Level Extension シラバス アジャイルテスト担当者 （共訳） • システム開発ジャーナル Vol. 10 （共著） • ソフトウェア・テストPRESS Vol. 8（共著）など 主な講演 • SQiPシンポジウム2024併設チュートリアル「テスト戦略」 • JaSST’22四国 「テストを学び成長する 2022年度版」 • JaSST’21北陸 基調講演「テストを学び成長する」 • JaSST’17東北 基調講演「テストの極みを目指して」 • JaSST’15東京 チュートリアル「初心者からの脱出」 • テスト設計コンテストチュートリアル U-30クラス（’17～’19）ちびこん編（’21 ） • SQiP研究会 品質保証の基礎コース 第7回 「ソフトウェアテストの概観を識る」（’17, ’20～） • 第14回SPIトワイライトフォーラム 「テストプロセス改善モデルの最新動向」 など 株式会社ベリサーブ 品質保証部プロジェクト推進課 課長 兼 ソフトウェア品質コンサルティング部 シニアコンサルタント その他 https://www.linkedin.com/in/yamasaki696/ を参照
3. 特技ソフトウェアテスト 趣味ソフトウェアテスト Yes, I'm loving Software Testing! @yamasaki696
4. テ ス ト 設 計 に つ い て 改 め て 考 え て み て 、 テストベースから説明可能なテストケースを 導く考え方の足掛かりを得る この講演のゴール
5. テスト技法を勉強して演習ではうまく 使えたのに実務ではどうやって技法を 適用すれば良いのか分からずうまく 使えていません… 良く聴くお悩み
6. テ ス ト ベ ー ス を 生 成 AI に 与 え て テ ス ト ケ ー ス を 作 っ て も ら っ た ら それっぽいテストケースができたけど、 それで大丈夫なのか心配です… 良く聴くお悩み
7. テストベースから直接テストを作ろうとしている？ 仕様書など テスト 納得感の高いテストを作るには、いきなり個別のテストケースを作っても駄目 テストを段階的に詳細化して、説明性の高いテストを作り、合意形成する必要がある
8. テスト設計 ※またはテスト計画、テスト準備など表現は様々 テスト 実行 テスト 要求分析 テスト ｱｰｷﾃｸﾁｬ 設計 テスト 詳細設計 テスト 実装 テスト 実行 テスト分析 テスト設計 テスト実装 テスト 実行 昔のプロセス JSTQBの テスト開発 プロセス テスコンの テスト開発 プロセス テストを実行する前の段階をより 詳細化してイメージできるようになろう
9. テストのライフサイクルにおける「テスト開発プロセス」の範囲 テスト開発 ＝ テスト分析 ＋ テスト設計 ＋ テスト実装 テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 計画に基づいてテストを実行可能にするため、テストを開発する一連の活動を範囲としている。ただし、 現在のJSTQB FLシラバスでは「テスト開発」や「テスト開発プロセス」という用語は使われなくなっている点に留意。
10. テ ス ト 実 行 テストのモニタリングとコントロール テ ス ト 計 画 テ ス ト 完 了 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 主にここ！ テスト技法を使うのは主にテスト設計の段階であり、その前の テスト分析が重要で、これを経ることでどの技法を使うか整理できる
11. テスト開発プロセスを一番俯瞰したPFD テストを開発する テスト ベース テスト
12. おおざっぱなPFD（Process Flow Diagram）の説明 出典: https://affordd.jp/koha_hp/process/PFDform3.pdf P.16 要素 形状 説明 形状の別表現 プ ロ セ ス “作業を表します。 階層を持つ場合には線を太くしたり二重にす ると良いでしょう 成 果 物 “プロセスに出入りする成果物を表します。 ソースファイルや分冊の様子や、形になってい ない「ノウハウ」など、適当な記号を使います。 フ ロ ー “成果物とプロセスを繋ぐ線。両側に矢印を付 けて更新の意図をあわらしたり、線上に成果物 を構成する要素を書くこともできます。 要素
13. テスト開発プロセスを深掘りしたPFD テスト分析 テスト ベース テスト 条件 テストケース 仕様書 テスト 手順 テスト設計 テスト実装 テスト ケース
14. テスト 分析 テスト 設計 テスト 実装 テスト ベース テスト 条件 テスト 手順 テスト ケース 気づき 気づき 概念的にはテストプロセスとしての順序性があり、図にするとシーケンシャルに進めるように見 えるが、実際には、分析→設計→実装をいったりきたりすることも多い 注 意
15. テスト開発プロセスをさらに深掘りしたPFD テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット ※分かりやすくするためにテスト開発プロセスのすべてを表していない点にご留意ください テストセットを 実行可能にする テスト手順を 作る テスト手順
16. 見え方は異なるが、ISO/IEC/IEEE 29119-2:2013のテスト設計と実装プロセスと基本的に同じ フィーチャー セットを 識別する (TD1) テスト条件を 得る (TD2) テスト カバレッジ アイテムを 得る(TD3) テスト ケースを 得る (TD4) テスト セットを まとめる (TD5) テスト 手順を 得る (TD6) テスト設計 仕様 テストケース 仕様 テスト手順 仕様 フィーチャー セット テスト条件 テストカバレッジ アイテム テストケース テストセット テスト手順& テストスクリプト ISO/IEC/IEEE 29119-2:2013 test processes, P.30 Figure 10 – Test Design and Implementation Process より。 翻訳は筆者による。
17. テスト分析について、深掘りしてみる テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット テストセットを 実行可能にする テスト手順を 作る テスト手順
18. とどのつまり、 フィーチャーと テスト条件って なんなの？
19. 用語の定義を見ても、よく分からないですよね・・・・（定義も変わったりするし…） JSTQBの用語定義 ISO/IEC/IEEE 29119での定義 フ ィ ー チ ャ ー フィーチャー： 要求仕様ドキュメントで、明示的、暗 示的に規定したコンポーネントやシステムの属性（た とえば、信頼性、使用性、設計上の制約など）。 フィーチャーセット： 後続のテスト設計活動でほか のフィーチャーセットとは独立して扱うことのでき る、論理的なテストアイテムの部分集合。 テ ス ト 条 件 • コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、 機能、トランザクション、フィーチャ、品質特性、構 造要素など（昔の定義） • テストのための根拠となる、コンポーネントやシ ステムのテストが可能な一部分（新しい定義） コンポーネントやシステムにおけるテストの根拠とし て識別された、機能、トランザクション、フィーチャー、 品質特性、構造要素など、テスト可能な側面。 ※最新のISTQBの用語集では、featureの定義がなくなっている 誤解を恐れずに言えば、フィーチャーやテスト条件に関する分かり易い統一的な見解はない
20. 最新のISO/IEC/IEEE 29119-2:2021の「テスト設計と実装プロセス」では テスト条件じゃなくテストモデルに変わっちゃいましたしね… テストモデルの 作成 (TD1) テストカバレッジ アイテムの識別 (TD2) テストケースの 導出 (TD3) テスト手順の 作成 (TD4) テストモデル テスト カバレッジアイテム テストケース テスト手順 ISO/IEC/IEEE 29119-2：2021 P.32 Figure 10 Test design and implementation process より引用。翻訳は筆者による
22. 発想を転換しよう！ JSTQB や ISO/IEC/IEEE 29119 の 定 義 に 沿っているかどうかではなく、フィーチャーに 何を置いて、テスト条件に何を置くと、自分の 考えたテストを説明しやすくなり、利害関係者と 合意形成しやすくなるのかで決めてみよう
23. フィーチャー フィーチャー（feature）と厳密にで対応する日本語はない。 あえて言えば「特徴」や「特性」であり、テスト対象が持つ特徴であ れば、何でもフィーチャーとして捉えることができる
24. フィーチャー 機能 非機能 構造 その他 誤解を恐れずに例を示すと、フィーチャーは機能や非機能や構造 （もちろん、それだけに限らない）であるとしてみる
25. フィーチャー 機能 非機能 構造 その他 システムテストの機能テストでテスト分析するなら、例えばフィーチャーセットは システムが備える機能の一覧であって良い もちろん、テストベースで◦◦機能と記述されるものが、システムテストの機能テ ストにおいて扱う機能の単位になっているかは限らないので、テストの視点から 機能を再整理したほうが良い場合もある
26. フィーチャー 機能 非機能 構造 その他 非機能テストで、テスト技法を使わないわけではもちろんないが、非機能テストで は技法以上に、テストプラクティスが重要になることが多い。 例えば、セキュリティテストであれば、ペネトレーションテストやファズテスト、 性能テストであれば、性能の特性（負荷、ストレス、拡張性、スパイク、耐久など）に 応じた環境とツールの構築など。
27. 出典; JIS X 25010:2025の情報を元に、独自に作図 製品品質 機能適合性 性能効率性 互換性 インタラクション容易性 (対話性) 信頼性 セキュリティ 保守性 柔軟性 安全性 機能完全性 機能正確性 機能適切性 適切度認識性 習得性 運用操作性 ユーザーエラー防止性 ユーザーエンゲージメント (利用者関与性) インクルーシビティ (包摂性) ユーザー支援性 時間効率性 資源効率性 容量満足性 共存性 荘厳妖精 機密性 インテグリティ 否認防止性 責任追跡性 真正性 対攻撃性 運用制約性 リスク識別性 フェールセーフ 危険警告性 統合時安全性 無傷害性 可用性 (アベイラビリティ) 障害許容性 (耐故障性） 回復性 モジュール性 再利用性 解析性 修正性 テスト可能性 (試験性) 適用性 拡張性 インストール性 (設置性) 置換性 自己記述性
28. フィーチャー 機能 非機能 構造 その他 構造などは一番わかりやすく、ソースコードの構造であれば、どのコードカバ レッジの基準を選ぶのか（ステートメント、ブランチ、判定条件、MC/DC、複 合条件など）、決めの問題。
29. ステートメント カバレッジ 100％ ブランチ カバレッジ 100％ 判定条件 カバレッジ 100％ 改良条件判定 カバレッジ 100％ 複合条件 カバレッジ 100％
30. フィーチャー 機能 非機能 構造 その他 必ずしも、機能、非機能、構造に限らなくても良い。 例えば、網羅的な観点以外にも、ピンポイント的なテストも検討することも多 いし、過去のトラブル事例などにもとづき経験ベースのテスト技法を用いたり、 ガイドワードなどを使って起きて欲しくないことなどをあぶり出してもよい。
31. 技法の特徴を抑えておくことで、どう言ったところでどの技法を使うと良いかも把握できる テ ス ト 技 法 ブラックボックステスト技法（仕様ベース） ⚫ 仕様化したモデルを基にしてテストケースを作成する、体系的なテスト技法 ⚫ モデルに対応したテスト設計技法を用いる ホワイトボックステスト技法（構造ベース） ⚫ ソフトウェアやシステムの構造を基にしてテストケースを作成するテスト技法 ⚫ 対象となる構造をどれだけ網羅したかというカバレッジを測って実施する 経験ベースのテスト技法 ⚫ テスト担当者のスキル、知識、経験を基にテストケースを作成する、体系的ではな い（経験に基づいた）テストケース技法 ⚫ ステークスホルダの知識、過去の類似した欠陥なども情報源となる 同値分割法 境界値分析 デシジョンテーブルテスト 状態遷移テスト シナリオテスト ステートメントテスト ブランチテスト(≒デシジョンテスト) その他 その他 探索的テスト チェックリスストベースドテスト エラー推測 テ ス ト 技 法 ブラックボックステスト技法（仕様ベース） ⚫ 仕様化したモデルを基にしてテストケースを作成する、体系的なテスト技法 ⚫ モデルに対応したテスト設計技法を用いる ホワイトボックステスト技法（構造ベース） ⚫ ソフトウェアやシステムの構造を基にしてテストケースを作成するテスト技法 ⚫ 対象となる構造をどれだけ網羅したかというカバレッジを測って実施する 経験ベースのテスト技法 ⚫ テスト担当者のスキル、知識、経験を基にテストケースを作成する、体系的ではな い（経験に基づいた）テストケース技法 ⚫ ステークスホルダの知識、過去の類似した欠陥なども情報源となる 同値分割法 境界値分析 デシジョンテーブルテスト 状態遷移テスト シナリオテスト ステートメントテスト ブランチテスト(≒デシジョンテスト) その他 その他 探索的テスト チェックリスストベースドテスト エラー推測 オールペア法（ペアワイズ） その他
32. テスト対象を理解するためにテストベースに深く深く潜っていく
33. 3色ボールペンでテストベースの情報を分析・補完した例 • パスワードは8文字以上32文字以下の 英数字のみを許容する。 • パスワードを3分以内に連続して4回以上 間違って入力すると、アカウントを5分間 ロックする。 パスワードの文 字列長を判定 パスワードの文 字種を判定 許容しない場合 どうなる？ 要件を満たさない文字入力を はじくのか、エラーとして 処理するのか？ 誤入力回数を管 理している 誤入力期間を管理している ロック状態を保持す る時間を測ってる 時間精度 ミリ秒の精度は手動では 無理。他の方法で担保する 必要がありそう アカウントの 状態を遷移して いる 4回目でロックに なって、ロック中に 再度入力するとど うなるの？ 秒？ミリ？ 全体としてセキュアになって いるかかどうか（非機能） もしブルートフォース攻撃に対してセ キュリティを確保するためであるなら、 セキュリティ要件を満たしていない可 能性はないか？ 回数のクリア タイミング どれだけテストベースを汚せるかがポイントで、不明部分をテストの視点から洗い出す。 この時点で曖昧性や矛盾などを取り除くとともに書かれていないことについても深堀する。
34. 3色ボールペンの使い方の例 正しく色を使い分けることを意識しすぎると、仕様書を汚せなくなるのであくまで色は目安。 色の選択に悩んでしまうくらいであれば、単色でもよいので仕様書を汚すことに注力しよう。 出典: 「ソフトウェア・テストPRESS Vol.2」 三色ボールペンで読む仕様書（鈴木三紀夫氏） 赤 青 緑 • 客観的に見て、最も重要な 箇所 • たとえば、フィーチャーや テスト条件 など • 客観的に見て、まあ重要な 箇所 • たとえば、フィーチャーやテ スト条件を構成する要素 など • 主観的に見て、おかしいと 感じた箇所 • たとえば不明点、疑問点 など
35. なぜ仕様書を汚して、情報を分析するのか？ ⚫ 多くの場合、分析対象のテストベースの仕様書などは十全ではない ⚫ テストに必要なすべての情報が記述されているわけではない ⚫ 抜け漏れや誤りを含んでいることもある ⚫ 多くの場合、分析対象のテストベースはテストのために作られていない ⚫ 仕様書や設計書は第一義に作るのための文書であり、開発とテストでは関心事が異なる ⚫ 開発のために構造化された情報は、テストを考えて実行する上での構造と異なることも多い
36. 3色ボールペンで汚した仕様書を基に再整理した例 パスワード判定 長さ 文字種 セッションの制御 ログイン状態 ロック中 ログイン中 ログアウト中 誤入力回数 誤入力期間 アカウント作成機能 ユーザー名の判定 アカウント フィーチャーとして「アカウント作成機 能」を識別して、アカウント作成時にパス ワードの長さや使用している文字種を 判定しているので、それらが仕様通りに 動作しているかをテスト条件として識別 するとよさそうかな？ テスト対象のシステムはセッションを管理して いるので、「セッションの制御」をフィーチャーと してまずは識別したほうがよいかな？それを構 成している要素を考えると、なにをテスト条件 として定義すると、テスト設計しやすいかな？
37. 3色ボールペンで汚した仕様書を基に構造化した例 パスワード判定 長さ 文字種 セッションの制御 ログイン状態 ロック中 ログイン中 ログアウト中 誤入力回数 誤入力期間 アカウント作成機能 ユーザー名の判定 アカウント フィーチャーとして「アカウント作成機 能」を識別して、アカウント作成時にパス ワードの長さや使用している文字種を 判定しているので、それらが仕様通りに 動作しているかをテスト条件として識別 するとよさそうかな？ テスト対象のシステムはセッションを管理して いるので、「セッションの制御」をフィーチャーと してまずは識別したほうがよいかな？それを構 成している要素を考えると、なにをテスト条件 として定義すると、テスト設計しやすいかな？ 文字種は、文字という要素の集ま りだから、同値分割法を使うとよ いかもしれないな パスワードの長さは、何文字かを チェックしているから、境界値分析 を使うと説明しやすそうだな 全体としては、状態を制御して いるから、状態遷移モデルにす ることで、これらの仕様を扱い やすいかもしれないな
38. 整理していく中で、テスト技法を適用できる箇所が識別できる パスワード判定 長さ 文字種 セッションの制御 ログイン状態 ロック中 ログイン中 ログアウト中 誤入力回数 誤入力期間 アカウント作成機能 ユーザー名の判定 アカウント 同値分割法 境界値分析 同値分割法 状態遷移テスト 同値分割法 境界値分析
39. 機能とその入出力関係を整理した例 前処理: ・ユーザ名の値の確認 ・ユーザ名の重複確認 ・パスワードの値の確認 主処理： ・条件を満たす場合のみ 新規に登録する 後処理： ・登録結果を表示する 登録結果のメッセージ ユーザー名 パスワード 文字種の組み合わせ 文字数 文字種の組み合わせ 文字数 入力 出力 ユーザー データベース アカウントの登録機能 境界値分析 同値分割法 境界値分析 同値分割法 同値分割法 同値分割法 同値分割法
40. なぜ構造化するのか？ 全体を俯瞰しやすい 構造化した結果に基づいて議論しやすい • 大量のテストケースやテスト手順は枝葉であり 全体を俯瞰し難い • 木や森を見るには関心事に応じた抽象度のほ うが分かりやすい • そして、ステークホルダ毎に関心事は異なる • ぱっと見て把握しやすい • 関係性が分かりやすい • MECE（漏れなくダブりなく）であるかを把握 しやすい など
41. HAYST法によるラルフチャート Read Write 内部変数の組合せ（＝State） 信号因子 m{m 1 , m 2 , m 3 , …} Noise/Active Noise 誤差因子 z{z 1 , z 2 , z 3 , …} az{az 1 , az 2 , az 3 , …} Input 信号因子 M{M 1 , M 2 , M 3 , …} Output レスポンス R 対象 R = 𝑓 𝐼𝑛𝑝𝑢𝑡, 𝑆𝑡𝑎𝑡𝑒, 𝑁𝑜𝑖𝑧𝑒, 𝐴𝑐𝑡𝑖𝑣𝑒 𝑁𝑜𝑖𝑧𝑒 出典: 「高信頼化ソフトウェアのための開発手法ハンドブック」 P.204 図3-3 ラルフチャートより。一部変更
42. Tiramisによる基本構造構成要素 誰が 誰に 出力 入力 事前条件 事後条件 環境 蓄積 トリガー 目的 処理 鈴木三紀夫氏のTwitterおよび「高信頼化ソフトウェアのための 開発手法ハンドブック」 P.153 図6-3 「Tiramisで使用してい る基本構造構成要素」をもとに、デザインを変更して掲載
43. ゆもつよメソッドによる論理的機能構造 フィーチャー 外部マネジメント 入力調整 出力調整 変換 サポート（自フィーチャー内部呼び出し） 相互作用（他フィーチャー呼び出し） 貯蔵 テスト実行 入力 出力 外部観察 できる仕様 内部に 関わる仕様 機能組合せ AUT * 外部 フィーチャー フィーチャー *ＡＵＴ: Application Under Test 「(2021年版) ソフトウェアテストの上流設計-4 テスト分析と論理的機能構造」湯本剛氏）の図表をもとに、一部変更
44. VSTePによるテストフレーム ＧＩＨＯＺブログ「VSTeP適用事例のご紹介」より引用
45. なぜ、これらのテンプレート的なモデルを使うと便利なのか？ ⚫ テスト実行する単位に基づいて考えたいので ⚫ 動的テストの基本は、テストの対象に入力を与えて出力を観測することである ⚫ つまり、テストを実行するにあたり、入出力のインターフェースを識別するとよい ⚫ それに影響を及ぼす要素を識別したいので ⚫ テスト対象によっても、どのように要素を構造化すると便利なのかは異なる ⚫ 将来的にはテスト対象の特性に合ったモデルを、自ら作れるようになるとよい
46. テストの導出結果は実施者によって異なります そもそも「全数テストは不可能」であり「テストはコンテキスト次第」 なのでテストが一意的に収束することはなく、絶対的な正しいテストはない
47. どんなテストをするのかを利害関係者と すり合わせて合意を得ることが重要であり、 そのためにはテストを説明できる必要がある
48. テストのスキルだけでは駄目で、バランスが大事！
49. テスト担当者のスキルスペース TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)
50. 深く潜るためにもテスト担当者には テスト以外のスキルや知識も重要です TEST SKILLS DOMAIN KNOWLEDGE SOFT SKILLS IT SKILLS Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)
51. 理想は、要求の段階から 整理されているとよいよね
52. 機能 入力データ 入力イベント 出力データ 出力イベント P.77 「図 5-2 一般的な機能に対するコントロールフロー図 」 in 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019）
53. 機能 入力イベント イベント 出力イベント 非機能要求 入力データ 出力データ データ 対象 入力元対象 出力元対象 機能要求 トリガ関係 フロー関係 実現 入力 入力 出力 出力 出力 トリガ関係 フロー関係 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019） P.78 「図5-3 要求のメタモデル」 より、一部改変
54. 要求仕様 危険運転を警告する 契機 機能 応答 応答対象 センサーログの更新 ①センシングデータに基づき、危 険運転を判別する。 • 速度超過運転 • ふらつき運転 • 急ブレーキ連続運転 ②運転者ならびに周辺者に指定 された警告条件で警告する。 バイブレーション警告 ハンドル 入力対象 入力 音声警告 スピーカー センサーログ 車輪の回転パルス 警告サイン 運転者用ランプ ハンドルの回転角 警告サイン 簡易モニター 車体の傾き 周辺音声警告 周辺者用スピーカー 光量 周辺光警告 周辺者用ランプ 湿度 出力 出力対象 車体振動 危険運転警告記録 警告ログ 前方の物体 危険運転判断情報 管理 自動走行条件 走行環境条件 危険運転警告条件 情報管理 警告条件 -- タイミング -- 間隔 -- 期間 「要求プロセスと技法入門要求開発の基礎知識」山本修一郎著（2019） P.80 「表5-8 要求記述表の例」
55. テスト開発プロセスをもう一段階深掘りしたPFD テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット テストセットを 実行可能にする テスト手順を 作る テスト手順 例:アカウント作成機能 例: パスワードの文字列長判定
56. テスト開発プロセスをもう一段階深掘りしたPFD テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット テストセットを 実行可能にする テスト手順を 作る テスト手順
57. カバレッジアイテム（何を網羅すればテスト条件を確認したと言えるか考える） 1. パスワードの文字数が規定よりも足りない場合の最小値 2. パスワードの文字数が規定よりも足りない場合の最大値 3. パスワードの文字数が規定内の場合の最小値 4. パスワードの文字数が規定内の場合の最大値 5. パスワードの文字数が規定を超える場合の最小値 ０ 8 32 33 7 文 字 数 パスワードの文字数が足りない 無効同値パーティション パスワードの文字数が足りている 有効同値パーティション パスワードの文字数が多すぎ る無効同値パーティション
58. テスト開発プロセスをもう一段階深掘りしたPFD テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット テストセットを 実行可能にする テスト手順を 作る テスト手順
59. テストケース（事前/事後条件・入力・期待結果を特定する） # 境界値分析のカバレッジアイテム 事前条件 入力 事後条件 期待結果 1 パスワードの文字数が足りない場合の最小値 パスワード 設定画面 未登録状態 0文字 パスワード 設定画面 未登録状態 パスワード設定画面の「パスワード」テキストボックスの 直下に、赤文字で「パスワードは8文字以上32文字以 内の長さを指定してください」と表示され、設定完了画 面に遷移しない 2 パスワードの文字数が足りない場合の最大値 7文字 パスワード 設定画面 未登録状態 パスワード設定画面の「パスワード」テキストボックスの 直下に、赤文字で「パスワードは8文字以上32文字以 内の長さを指定してください」と表示され、設定完了画 面に遷移しない 3 パスワードの文字数が足りているの場合の最小値 8文字 設定完了画面 登録済み状態 アカウントが作成され、設定完了画面へ遷移する 4 パスワードの文字数が足りている場合の最大値 32文字 設定完了画面 登録済み状態 アカウントが作成され、設定完了画面へ遷移する 5 パスワードの文字数が多すぎる場合の最小値 33文字 パスワード 設定画面 未登録状態 33 文 字 目 の ユ ー ザ ー の 入 力 が 無 視 さ れ る ※テキストボックスに33文字目を入力できない
60. テストやテストケースという言葉の意味も曖昧な場合がある ここで得られる示唆は、相手の言っていることと自分の言っていることが同じ用語でも 異なる意味を持っている場合があるということ。また、そこで誤解を起こさないためにも 用語の定義というのは地味なようでも非常に重要であるということ <<<<< 広義のテストケース >>>> >>>> 狭義のテストケース <<<< • テスト開発プロセスにおける成果物を丸っと テストケースと呼ぶ場合がある • テスト条件、テストケース、テスト手順な どを明確に区別しないような文脈 • 実施するテスト内容を漠然とテストケースと 呼ぶ場合がある • テスト（test）と同義語くらいの感じで、 特段の意図なくテストケースと呼ぶ • テスト設計のアウトプット（成果物） • テスト条件、テストケース、テスト手順を 明確に区別するような文脈 • 厳密に、事前/事後条件、入力、期待結果と いった情報を含んでいるものを指す
61. テスト開発プロセスをもう一段階深掘りしたPFD テストすべき フィーチャーを 識別する フィーチャー フィーチャーに 対するテスト条件 を決定する テスト条件 テストベース テスト条件を 満たすテスト を考える テスト カバレッジ アイテム 事前/事後条件・ 入力・期待結果など テストケースに 必要な情報を 定義する テストケース テストケースを テスト実行する まとまりに まとめる テストセット テストセットを 実行可能にする テスト手順を 作る テスト手順
62. 1回のテスト実行で、複数のテストケースを確認しうる 前処理: ・ユーザ名の値の確認 ・ユーザ名の重複確認 ・パスワードの値の確認 主処理： ・条件を満たす場合のみ 新規に登録する 後処理： ・登録結果を表示する 登録結果のメッセージ ユーザー名 パスワード 文字種の組み合わせ 文字数 文字種の組み合わせ 文字数 入力 出力 ユーザー データベース アカウントの登録機能 境界値分析 同値分割法 境界値分析 同値分割法 同値分割法 同値分割法 同値分割法
63. 複数のテストケースを組み合わせることのメリットとデメリット メリット 1つのテスト手順を実行するコストが 高い場合、少ない実行回数によって カバレッジできる。 例えば、業務システムにおけるシステ ムテストでは、1つのテスト手順を実 行するために、数時間や数日を必要 とする場合がある。 デメリット 仮にそのテストセットを実行したこと によって故障を識別した場合、問題の 切り分け（どのテストケースが原因で、 テスト手順が失敗したのか）が、難し くなったり手間取ったりする。 そのテストセットがどういった意味の テストであるのか、テストの意味合い がぼやける。
64. テスト モデルを 特定する 4つの テスト モデル モデルに 紐づいた テスト観点 テスト 観点を 詳細化 する 詳細化された テスト観点 (テストパラメータ) 網羅 基準を 設定する 網羅基準 テストケース (テスト値) 基準に 基づいて ケースを 導出する 網羅基準に 紐づいた テスト パラメータ テスト技法 テスト 観点間の 関係性を 見出す テスト フレーム 同じような 意味を持つ テスト観点や テストフレーム をまとめる テスト コンテナ テスト コンテナ間の 関連性を 整理する テスト アーキテクチャ テスト すべきことを 洗い出す テストベース 様々な テスト観点 テスト観点を 構造化する 構造化された テスト観点 (中間状態) ドメイン知識/ ガイドなど リファイン する 最終的に 構造化された テスト観点 どうやれば自分達のコンテキストでうまくテストを作れるか、 テスト開発プロセスを改めて再整理してみましょう
65. 生成AIの性能向上が著しい昨今、作業的なものはどんどん生成AIが担うこ とになります。 その中で人に求められるのは、生成AIへ与える指示と、その結果の妥当性 を判断することです。 また、結果の妥当性を判断するためにも、AIに一足飛びで出力させるので はなく、段階的に中間成果物を出力させ、適宜確認し、修正します。 そして、どのような段階を踏ませてどのような中間成果物をどのように作 らせるかは、人が示す必要があります。 つまり、テスト開発のプロセス設計ができないと、AIの作った成果物につい て妥当かどうかを判断しがたくなります。
66. テ ス ト 設 計 に つ い て 改 め て 考 え て み て 、 テストベースから説明可能なテストケースを 導く考え方の足掛かりを得る この講演のゴール
67. 写真素材 http://images.freeimages.com/static/images/logo.png フ リ ー 写 真 素 材 ぱ く た そ ・ 無 料 ダ ウ ン ロ ー ド ご静聴ありがとうございました！ 本講を切っ掛けに少しでも説明性の高いテストを 作るための第一歩を踏み出してください
68. 主な参考文献一覧 文献 著者 発行年 ISO/IEC/IEEE 29119-2:2013 Software testing Part 2: Test processes ISO/IEC/IEEE 2013 ISO/IEC/IEEE 29119-2:2021 Software testing Part 2: Test processes ISO/IEC/IEEEE 2023 テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02 ISTQB 2024 テスト設計チュートリアル 2021 ちびこん編資料 山﨑崇, 西康晴 2021 WACATE 2023 夏 ー テスト開発について改めて考えてみよう！ ～ テスト分析やテスト設計を業務で上手くできるようになるための四方山話～ 山﨑崇 2023 JaSST’10 東京 テスト初心者セッション～テス活はじめてみよう～ 長谷川聡, 片山徹郎 2010