自動テストを活かすためのテスト分析・テスト設計の進め方/JaSST25 Shikoku

by Hiroki Iseri

Slide 1

Slide 1 text

自動テストを活かすためのテスト分析・テスト設計の進め方井芹洋輝 2025/11/14 JaSST’25 Shikoku 1

Slide 2

Slide 2 text

自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアとさまざまな立場でさまざまなプロダクトのソフトウェアテスト業務に従事 • テストについて執筆・講演・研究・技術指導多数 • 現在はトヨタ自動車でQA/テストテックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫主な著作 • 「ソフトウェアテスト徹底指南書」「シフトレフトテストを支える現代的なテスト設計」「システムテスト自動化標準ガイド」（共著）など 2

Slide 3

Slide 3 text

この講演について【前半】テスト分析・テスト設計の流れについて解説 • スクラムを対象にステップバイステップで解説 • テーマにフォーカスするため、マネジメント・テスト環境構築は対象外です • 用語はJSTQBに従います【後半】自動テストを対象に、テスト分析・テスト設計の進め方を解説青背景スライド：具体例の解説赤背景スライド：参考解説。講演ではスキップ。必要に応じて後ほど資料を参照ください 3

Slide 4

Slide 4 text

【前半】テスト分析・テスト設計の進め方テスト設計プロセスの要件現代的な開発におけるテスト設計プロセステスト設計プロセス詳細テスト分析テスト設計【補足】テスト実装 4

Slide 5

Slide 5 text

テスト設計プロセスの要件 5

Slide 6

Slide 6 text

テスト設計に求められるもの ⚫潜伏したバグを見逃さないようにする ⚫不確実性のあるプロダクトリスクが一定レベルであることを確認する ⚫様々な品質がリリースできるレベルであることを確認する ⚫複雑で曖昧なテスト対象の仕様や標準との一致性を確認する ⚫個人で対応できない規模・難易度のテスト業務を分担・協力する ⚫バグの予防・早期検出にも貢献する ⚫その他さまざまなテストの目的に対応するテスト設計はあてずっぽうなアプローチでは対応できないアプローチに工夫が必要 6

Slide 7

Slide 7 text

テスト設計に求められる工夫はさまざま ⚫まず何をテストすべきか正しく理解した上でテストを作る • テスト対象をよく分析し適切に理解する • どのようなテストが求められるか分析し具体化する ⚫バグ、プロダクトリスクに早期対策する • テストベースの誤り・矛盾・抜けを見つけ、是正してバグの実装を予防する • 対応すべきプロダクトリスクを調べ、早期コントロールする ⚫対応が必要なプロダクトリスクを深掘りしテストでフォローする • 顕在化が許容されず発生可能性の高いプロダクトリスクを分析しテストを配備する ⚫関心の分離を実施し、テストを構造化する • テストを構造化し、複雑で規模の大きなテストの構成を整理する • テスト活動を関心ごとに分離し、分けて個別に作業を進められるようにする ⚫テストの責務に対し、適切なアプローチを組み立てる • テストの要求に対して適切なテストアプローチ・テスト技法を選択する • 困難なテストの課題に対して戦略・アプローチを工夫する 7

Slide 8

Slide 8 text

工夫をに対応するテスト設計プロセスの基本形 1. テスト分析 • テスト対象を分析し理解する • テストの要求・制約を分析する • テストベースの改善点を分析し、開発側にフィードバックする 2. テスト設計 • どのようにテストするかを技法を活用して設計する 3. テスト実装 • テスト実行に必要な準備を整える 8

Slide 9

Slide 9 text

現代的な開発におけるテスト設計プロセス 9

Slide 10

Slide 10 text

現代的なソフトウェア開発の様相 ⚫プロダクト形態がサービス化・開発ライフサイクルが長大化 • XaaS（SaaS、PaaS）など。パッケージや組込みも継続的な改善・運用で顧客満足を支える ⚫同じ開発チームが継続的にプロダクトを運用・改善 • チームの開発力を鍛えてプロダクトの成功を支える開発チームの総合力を鍛える必要性がますます強まっている 10

Slide 11

Slide 11 text

開発チームに求められる総合力 11 ビジネスパフォーマンスエリート高い中間低い変更リードタイム 1日未満 1日～1週間 1週間～1か月 1か月～デプロイ頻度いつでも（1日複数回） 1日1回～ 1週間に1回 1週間に1回～ 1か月に1回 1か月に1回～変更失敗率 5% 20% 10% 40% 障害復旧時間 1時間未満 1日未満 1日未満 1週間から1か月 DORA Accelerate State of DevOps 2024 現代的なソフトウェア開発の成功のためには、品質実現に加えて、開発のスピード、レジリエンス、開発持続性の総合力強化が必要。テストもそれに貢献しなければならない

Slide 12

Slide 12 text

現代的なソフトウェア開発に対応するためのテスト設計プロセス 1. テスト分析 • テスト対象を分析し理解する • テストの要求・制約を分析する • テストベースの改善点を分析し、開発側にフィードバックする 2. テスト設計 • どのようにテストするかを設計する 3. テスト実装 • テスト実行に必要な準備を整える 12 反復的に小さな粒度でプロセスを回すすばやくスパイラル的にプロダクト価値を高めていくシフトレフトを推進するテスト活動でも、バグやリスクの予防・早期対策に注力するチームの能力を高め・活かしてテストの有効性・効率性を高める

Slide 13

Slide 13 text

テスト設計プロセス詳細 13

Slide 14

Slide 14 text

テスト設計プロセス 1. テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、十分性基準を設定する • テスト条件（JSTQB用語）：テスト可能なテスト対象の要素。機能や品質特性、構造要素など 2. テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース：実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット 3. テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃えるテストケースを実行可能なテスト手順に具体化する 14

Slide 15

Slide 15 text

ユーザーストーリを使ったスクラムにおけるテスト設計プロセス 15 スクラムの活動ユーザーストーリの開発スクラムチーム内のユーザーストーリーテストのテスト設計プロセスバックログリファインメントスプリントプランニングスプリント期間中の開発スプリントレビュープロダクトバックログの作成 POの活動スクラムチームのスプリント活動ユーザーストーリ仕様の作成と洗練ユーザーストーリの具体化・開発とその成果物のテストテスト分析テスト設計テスト実装テスト実行

Slide 16

Slide 16 text

テスト分析 16

Slide 17

Slide 17 text

テスト分析：「何をテストするか」の具体化 ⚫テストベース（テスト設計のインプット）を確保・整理する ⚫テスト対象を理解する ⚫テストの責務を具体化する ⚫プロダクトリスクを分析し対応方針をたてる ⚫テスト条件を分析する ⚫テストタイプを分析する ※活動を通してテストベースの改善点（抜け・誤り・矛盾など）を見つけ、改善を働きかける 17

Slide 18

Slide 18 text

テストベースを確保・整理する ⚫テスト分析・設計・実装に必要なインプットを確保する • テストベース（例：要件定義書、システム仕様書、設計書）を提供するステークホルダを識別し、関係構築する • テストベースを識別し確保する ⚫留意点 • あるべき姿を分析し、その実現を働きかける • あるべきステークホルダ、テストベースを分析し、その確保を働きかける • 受動的な立ち回りはテスト失敗のリスクを高める • 確保の段取りを組む（先行版・暫定版を早期確保、Q&Aで情報補足など） • 通常は計画・プロセス設計段階で実施。計画・プロセスに段取りを組み込む。テスト分析ではそのフォローを行う 18

Slide 19

Slide 19 text

【例】テストベースを確保・整理するテストベース提供者タイミングテスト活動における用途リリース計画 PjM リリース計画時テストのスコープ・目的・十分性基準の検討情報ユーザストーリースクラムチーム PO 初期：PB作成時詳細定義：スプリントプランニング時主なテスト対象の仕様ユーザストーリーマップスクラムチーム PO 初期：リリース計画時詳細定義：PB作成時ユーザーストーリの補完情報。テストの優先付け・網羅基準の検討情報受け入れ基準スクラムチームスプリント中ユーザーストーリーを補完するテストのスコープ、テスト条件、補足仕様 DoD スクラムチームリリース計画時テストの十分性基準の検討情報 UI仕様 UIチームスプリント中に更新詳細な画面設計、意匠、アニメーション仕様アーキテクチャ仕様アーキチームスプリント中に更新詳細なデータ仕様、バッグエンド仕様、UI以外の外部インターフェース定義、横断的な非機能仕様 Q＆Aコメントスクラムチーム PO 逐次テスト担当者からの疑問点・指摘に対する回答・・・ 19

Slide 20

Slide 20 text

テスト対象を理解する ⚫入手したテストベースを理解し、テスト対象を十分に理解する ⚫テストベースの改善点（抜け漏れ、誤り、その他改善点）を見つけ、その是正をテストベース作成者に働きかける ⚫留意点 • テストベース作成時点で実施するのが理想。作成作業やレビューに参加して、問題是正をサポートする 20

Slide 21

Slide 21 text

【例】テスト対象を理解するユーザーストーリ：検索履歴の呼び出し「システム利用者として、過去の検索履歴の一覧を表示し、履歴の検索構文を選択して再実行できる。それにより、以前検索した内容をすばやく実行できるようにする」表示履歴数の最小値・最大値を確認し、本文や受け入れ基準に明記する (1)テストベースの内容をレビュー・理解する (2)問題の検出&改善しながら対象を理解詳細なUI仕様を確保する「検索履歴の削除」「検索履歴のセキュリティ」など、関連するユーザーストーリや仕様の存在を確認する。不足する仕様があればユーザーストーリの発行など改善を促す 21

Slide 22

Slide 22 text

テストの責務を具体化する ⚫何をテストするか全体像を具体化する • テスト対象 • テストのスコープ • テスト分担の境界の明確化。制約やリスク・課題に応じたテストスコープの調整 • 例：自動テストとの分担、外部のサービスやコンポーネント（例：FLOSS）のテスト • テストの目的と十分性基準 • 何のためにどこまでテストすべきかの目安 • 特別に対応すべき重大なリスク・課題 ⚫留意点 • 方針レベルでは計画時に具体化しすり合わせするテスト分析では、目の前のテスト活動にフォーカスを当て、詳細度を高める • 責務が大きすぎる場合は事前に責務分担を工夫する（例：自動テスト充実など） 22

Slide 23

Slide 23 text

【例】テストの責務を具体化する・リリーススプリントはない。スプリントでDoDを満たしたらインクリメントをユーザにリリースする・担当のユーザーストーリーテストがリリース直前のテストであるテストのコンテキスト ●テスト対象とスコープ・依存外部サービス含めた、プロダクトサービス総体を対象にする・スプリント中の変更および変更の影響範囲についてテストする ●テストの目的と十分性基準インクリメントがリリースできる品質であることを確認する。ユーザーストーリが適切に実現されていること、変更のプロダクトリスクがリリースできるレベルであることを確認する分析するテストの責務 23

Slide 24

Slide 24 text

プロダクトリスクを分析し対応方針をたてる ⚫テスト設計対象について、プロダクトリスク（あるいは想定される欠陥）を分析し、必要なテストを検討する • プロダクトリスク：プロダクトの品質に影響をもたらす可能性のある事象や要因。その影響度と発生可能性の組み合わせで程度を示す ⚫重大なリスクや制約・課題があれば、対策としてテストアプローチを策定し運用する 24

Slide 25

Slide 25 text

【補足】プロダクトリスクを分析し対応方針をたてる ⚫プロダクトリスクの分析アプローチ • 要素に分解し、要素ごとにリスク事象を分析する • 代表手法：FMEA • 仕様項目や、テスト対象の構成要素ごとに実施する • 回避したいリスク事象や危害を識別し、その発生要因を分析する • 代表手法：FTA • 蓄積された知識・経験や、その集合知でリスクを分析する • 代表手法：リスクストーミング ⚫テストでのプロダクトリスクへの対応 • プロダクトリスクのリスクレベルが一定以下であることを確認する（発生可能性の確度を高める）。一定以上のリスクレベルであることが判明したら改善フィードバックを提供する 25

Slide 26

Slide 26 text

【例】プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加変更影響マトリクスから、追加に伴う気がかりやリスクを分析するアカウント管理セッション管理 UIフロントエンドユーザ管理バックエンド・・・検索履歴保存・削除の追加保存履歴の外部漏洩未ログイン状態での履歴表示履歴のオーバーフロー重複管理履歴データの移行、バックアップ異常検索履歴の表示・削除・選択UI追加履歴の誤削除ポップアップUIとの競合検索履歴の実行・・・影響を受ける可能性のある構成要素変更・変化点 26

Slide 27

Slide 27 text

【例】プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加要対応リスクに対し、リスクベースドテストとしてテストを用意したり、テストの厚みや網羅基準の調整に用いたりするリスク事象リスクレベルリスクに対するアプローチ検索履歴データがユーザデータ操作と連動して処理されない。例えばユーザのコピーで履歴がコピーされない 5 ユーザデータの追加、移植、コピー、削除時に検索履歴が連動して処理されること受け入れ基準に追記し、ユーザーテストで確認未ログイン状態で特定ユーザの検索履歴が表示される 4 検索履歴に対するセッション管理のセキュリティ監査・セキュリティテストを実施リスクコントロールとしてハイレベルのリスクに対し対策アプローチを策定 27

Slide 28

Slide 28 text

テスト条件を分析する ⚫テスト対象をテスト条件に項目分けし、関心の分離を実施する • テストベースが項目分けされていればそれを流用できる • 例）ユーザーストーリで項目分けできていれば、それをテスト分析で流用するただしテストの目線で項目不足や、仕様レベルの凝集性・結合性の問題があれば改善する • テストベースの項目分けが不適切な場合、まずテストベースの改善を働きかける ⚫テスト条件を優先付けする 28 検索履歴の再実行テスト条件分析検索履歴の保存検索履歴の削除検索履歴表示検索履歴再実行・・・テストすべき項目に分解保存履歴の機密確保履歴表示・実行UIの統一性重複履歴統一化

Slide 29

Slide 29 text

【補足】テスト条件を分析する ⚫テスト設計視座での、仕様としての凝集性の高さと結合性の低さを確保するように、項目分けする • 高い凝集性：意味のある分け方をしている • テスト条件が、密接に関連したテスト要求に集中しているかの程度 • ひとまとまりにテスト設計を進められる。関連性の低いテスト要求が混在していない • 低い結合性：以降のテスト活動を分けて進められる • テスト条件間の依存関係が少ない • テスト条件ごとに分けて別々にテスト設計・テスト実装作業を進められる 29

Slide 30

Slide 30 text

【例】テスト条件を分析するユーザーストーリーリスクマネジメント情報、アーキテクチャ仕様などユーザーストーリー以外のテストベース・項目分けにユーザーストーリー単位をそのまま採用するユーザーストーリー作成から参加し、ユーザーストーリーの高凝集性・低結合性確保を初期から働きかける・項目の漏れが残った場合は、テストタスクとして追加発行するテストベース・各ドキュメントの項目分けに従う項目分けができていないテストベースについては、テスト用に項目一覧を作り、テスト条件とする 30

Slide 31

Slide 31 text

基盤【補足】機能抽象モデルを使ったテスト条件分析入力処理間接入力状態間接出力テスト対象の入力（インプットとアクション）を観点にテスト条件を分析する機能内の静的・動的な状態を観点にテスト条件を分析する全体の管理・調停・横断機能を観点にテスト条件を分析するテスト対象の出力（アウトプットとアクション）を観点にテスト条件を分析する出力入力から出力を得る処理を観点にテスト条件を分析する 31

Slide 32

Slide 32 text

基盤【補足】機能抽象モデルを使ったテスト条件分析 ⚫「検索履歴保存」の機能テストのテスト条件入力処理間接入力状態間接出力出力・検索構文・異常操作（エラー推測）・保存検索履歴（状態遷移）・ログインユーザ（状態遷移）・重複排除処理（エラー推測）・FIFO処理（境界）他でテスト：・検索構文チェック・セッション管理、ログイン管理（状態遷移）・保存検索履歴（境界） 32

Slide 33

Slide 33 text

テストタイプを分析する ⚫採用するテストタイプを分析する • テストタイプ：品質特性など、テストで着目する特性に紐づいたテストの種類セキュリティテスト、ユーザビリティテスト、ストレステストなど • テストタイプも高凝集性・低結合性を確保するように分析する • 高凝集性：特定の特性に特化したテストタイプになっている • 低結合性：テストタイプ間の依存性が少なく、分けてテストの作成・実行を進められる ⚫テスト条件がどのテストタイプに紐づくかを分析する • テスト条件×テストタイプで関心の分離を実施する ⚫留意事項 • テスト計画や全体の基本分析で実施。テスト分析ではそのフォロー行う 33

Slide 34

Slide 34 text

【例】テストタイプを分析する ⚫採用するテストタイプを選択し、各テスト条件をどのテストタイプでテストするか検討・明示化する ⚫テスト条件×テストタイプを単位に、以降の作業を進めるユーザーストーリーテストユーザビリティテストセキュリティテスト・・・検索履歴保存・削除の追加 ● ● 検索履歴の表示・削除・選択 UI追加 ● ● ● 検索履歴の実行 ● 34

Slide 35

Slide 35 text

テスト設計 35

Slide 36

Slide 36 text

テスト設計：「どのようにテストするか」の具体化 ⚫テスト条件を単位に、テストケースを作成する • 探索的テストの場合は、テストチャータを作成する ⚫テストケース • 事前条件、アクション、入力、期待結果、事後条件のセット 36 事前条件入力とアクション期待結果起動画面表示中アカウント登録ボタンを押下登録画面ページに遷移起動画面表示中ヘルプボタンを押下ヘルプページに遷移

Slide 37

Slide 37 text

テストケースの設計 37 テスト条件の識別検索履歴保存ログインユーザ（状態）履歴FIFO処理（境界・状態）文字種チェック（同値パーティション・異常系）・・・本質的なテストモデルの識別テスト設計アプローチとテスト網羅基準の具体化状態遷移テスト境界値分析同値分割・・・エラー推測

Slide 38

Slide 38 text

【例】テストケースの設計：デシジョンテーブル ⚫テスト条件：料金計算機能 ⚫テストモデル：パラメータ組み合わせ・デシジョンテーブル ⚫テストケースの設計アプローチ： • デシジョンテーブルテストを選択。グレーボックスのテストアプローチで簡単化したデシジョンテーブルの各列をテストケース展開 38

Slide 39

Slide 39 text

【例】テストケースの設計：状態遷移 ⚫テスト条件：給湯操作機能 ⚫テストモデル：状態 ⚫テストケースの設計アプローチ：状態遷移テストを選択 • 状態遷移図・状態遷移表を作成 • 全状態網羅、全遷移網羅する実行パスをテストケースに展開 39

Slide 40

Slide 40 text

スクラムでのテスト設計 ⚫ユーザーストーリーテストの設計の場合、ハイレベルテストケースやテストチャータを設計し、受け入れ基準や補足情報での補足や、テスト情報への参照を取る 40

Slide 41

Slide 41 text

【補足】テスト設計の工夫でテストの効率性を高めてチームの総合力に貢献する【根拠なしに技法を使った一律網羅】 ●オールペア法で2ワイズカバレッジ100%網羅 ●状態遷移テストで2スイッチカバレッジ網羅 ●制御フローテストで複合条件カバレッジ網羅【目的やリスクに基づいたピンポイント確認】 ●バグがありそうなところを確認 ●テストの目的にとって重要な箇所を確認 ●探索して怪しいところを深掘り △ ・根拠があっての選択ならば妥当だが、思考停止で選択するのは危険無駄が増えがちで、リソース浪費により、必要なテストの欠落を誘発する場合も・技法は明確な根拠に基づいて選択する〇・ドメイン・プロダクト・品質リスクや不具合への精通が求められる。経験、知識、技術の総合力が求められる・本質的にこちらが重要。実際にプロダクト開発を支えているのもこちら・分析はこのアプローチを支えるために行う 41

Slide 42

Slide 42 text

【補足】テスト実装 42

Slide 43

Slide 43 text

テスト実装：テスト実行の準備 ⚫テスト実行に必要なテストウェアを準備する ⚫テストケースを実行可能なテスト手順に変換する ⚫テスト手順を優先付け・選択する 43 テスト設計結果テスト実装成果物事前条件アクション期待結果料金計算画面を開く 1.年齢に5歳を入力する 2.クーポンなしを選択する 3.料金計算ボタンを押下する料金欄に料金0円が表示される・・・

Slide 44

Slide 44 text

テスト設計プロセス 1. テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、十分性基準を設定する • テスト条件：テスト可能なテスト対象の要素。機能や品質特性、構造要素など 2. テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース：実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット 3. テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃えるテストケースを実行可能なテスト手順に具体化する 44

Slide 45

Slide 45 text

【後半】自動テストを対象とした場合のテスト分析・テスト設計の進め方自動テストでのテスト分析・テスト設計の進め方開発と並走して作成・実行する自動テスト開発から独立して作成・実行する自動テスト【補足】自動テストに合わせたテスト設計・テスト実装 45

Slide 46

Slide 46 text

自動テストでのテスト分析・テスト設計の進め方 46

Slide 47

Slide 47 text

自動テストでのテスト分析・テスト設計 ⚫自動テストでも適切なテスト分析・テスト設計が必要 • テスト自動化は適切なテストケースを自動化してこそ価値がある ⚫アンチパターン：GIGO（Garbage In, Garbage Out） • 元々は情報システムで、ゴミのようなインプットをしたら、ゴミが出力されることを指す • 自動テストでは「ゴミを自動化してもゴミのまま」という格言として知られる ⚫ただし自動テスト特有の事情がある。それに合わせて進める 47

Slide 48

Slide 48 text

開発との併走要求に応じたテスト設計方針：開発との併走程度でアプローチが変わる 48 システムテスト統合テストユニットテスト開発と並走して自動テストを作成・実行開発から独立して自動テストを作成・実行手動テストと同様のテスト設計プロセスをとるテスト設計方針を示し、テスト設計を任せるテストレベルの粒度の細かさ

Slide 49

Slide 49 text

開発と並走して作成・実行する自動テスト 49

Slide 50

Slide 50 text

開発と並走して作成・実行する自動テストの例 ⚫テスト駆動開発 • ２つの活動を短期で繰り返すプログラミング手法 • テストファーストプログラミングまず失敗するテストを書き、プロダクトコードを追加変更して成功に変える • リファクタリング ⚫Cover ＆ Modify（保護して変更する） • 追加変更する際に、十分な自動化されたリグレッションテストで変えたくないふるまいを保護（Cover）し、その成功状態を維持しながらプロダクトコードを追加変更（Modify）するプログラミングプラクティス 50

Slide 51

Slide 51 text

開発と並走して作成・実行する自動テスト ⚫プログラミングと並行してテストを作成する • 作成したテストはCI/CDに組込み、リグレッションテストや、以降の開発サポートの資産として活用する ⚫併走化は自動テストの理想 • 併走化でさまざまなメリットを実現できる。自動テストの費用対効果を確保しやすい • テスト駆動開発として設計・実装を主導 • 無理のないテスト容易性の実現 • 自動テストの品質作りこみ • 高速なフィードバックの実現 • CI/CDのリグレッションテスト強化 51

Slide 52

Slide 52 text

開発と並走して作成・実行する自動テストでのテスト分析・テスト設計 52 テスト分析テスト設計テスト実装 • テストレベルやテストタイプを対象にテストの責務を明確化する • テスト設計方針を立てる • テスト設計方針に基づいて、開発者に任せる。開発と並行しながらテストを設計・実装する • モビング、PRレビューやカバレッジ監視で方針運用をモニタリング・コントロールし、チームを啓蒙する • 詳細なドキュメント化は行わない。テストコード（TaD：Test as Documentation）やHWWWｎの原則で情報を表現する • 詳細なドキュメント化は作成・保守コストが大きく、細かく変更される併走テストには適さない。スピードを損なう

Slide 53

Slide 53 text

開発と並走して作成・実行する自動テストでのテスト設計方針 ⚫テスト設計方針の例：ユニットテスト • ユニットのふるまいやインターフェースの仕様が実現されているか確認する • 例）境界値を網羅する、同値パーティションを網羅する、有則を網羅する・・・ • プログラマが感じるリスク（いわゆる不吉な臭い）が許容できる水準であることを確認する • 法規制など特別なテスト要求があれば対応する • 上記の対応の中で基準のテストカバレッジを満たす • 例）C0/C1カバレッジ80%以上 ⚫著名な原則論や設計パターンがあり活用できる • FIRSTの原則/xUnit Test Patternsの原則/AAAパターン/ 「DRYでなくDAMP」の原則 53

Slide 54

Slide 54 text

テスト駆動開発でのテスト設計プロセスの推進 ⚫全体のテスト分析 • テスト駆動開発の責務（目的、スコープ）、方針（例：ユニットテストは整理してCI/CDに展開）を明確化する • テスト設計方針、テスト駆動開発のノウハウを明文化し展開する ⚫詳細なテスト分析 • テスト条件を識別し、テストリストにまとめる（コード中のコメントやIDE のタスク管理機能を活用） ⚫テスト設計・テスト実装 • テストリストを単位にテストファーストサイクルをまわす • テストコードとして実装する。テスト分析・設計の意図が明確になるように命名や実装、コメントを工夫する • リファクタリングと同じようにテスト設計・テスト実装を改善する 54 事前に実施プログラミングの中で実施

Slide 55

Slide 55 text

開発から独立して作成・実行する自動テスト 55

Slide 56

Slide 56 text

開発から独立して作成・実行する自動テスト ⚫対象 • 開発から独立したテスト（例：WF開発でのシステムテスト）での自動テスト • セキュリティテストでのファジング、ストレステストといった特命的な自動テスト ⚫手動テストと同じテスト設計プロセスをとる ⚫開発から独立して作成・実行する自動テストは、費用対効果の確保に課題が多くテスト分析に工夫が必要 • 自動テストの適切な目的設定 • 自動化環境実現のコストやリスク • テスト容易性・テスト自動化容易性の確保 • 自動テストの投入タイミングの調整 56

Slide 57

Slide 57 text

開発から独立して作成・実行する自動テストでのテスト分析・テスト設計 57 テスト分析テスト設計テスト実装 • 手動テストと同様の分析実施 • 自動テストの適切な責務を具体化し、目的設定する • テスト容易性・テスト自動化容易性の要件を特定し、開発に確保を働きかける • 自動テスト環境要件を分析し、環境確保を手配する • 手動テストと同様のテスト設計実施 • ただし後述する自動テスト特有のテスト設計構造や実装パターンに合わせる • モデル（モデルベーステスト）やテストコード（TaD）でテスト設計・テスト実装の成果物管理を行う

Slide 58

Slide 58 text

自動テストに合わせたテスト設計・テスト実装 58

Slide 59

Slide 59 text

自動テストのテスト設計・テスト実装での工夫点 ⚫自動テストスクリプトが得意な設計構造・実装パターンに合わせて、テストの保守性や効率性を確保する ⚫例）パラメータ化テストの活用「共通の振る舞い＋パラメータのバリエーションのリスト」の形式になるようにテスト設計、テスト実装を推進すると、パラメータ化テストの効果が活かしやすくなる 59

Slide 60

Slide 60 text

まとめ【前半】テスト分析、テスト設計、テスト実装の段取りの重要性を解説し、スクラムでの具体的な流れを解説しました【後半】自動テストでのテスト分析・テスト設計の重要性を解説しました自動テストにおけるテスト分析・テスト設計の進め方を解説しました 60