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

Transcript

1. 自動テストを活かすための テスト分析・テスト設計の進め方 井芹 洋輝 2025/11/14 JaSST’25 Shikoku 1
2. 自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアとさまざまな立場 でさまざまなプロダクトのソフトウェアテスト業務に従事 • テストについて執筆・講演・研究・技術指導多数 • 現在はトヨタ自動車でQA/テストテックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫主な著作 • 「ソフトウェアテスト徹底指南書」 「シフトレフトテストを支える現代的なテスト設計」 「システムテスト自動化標準ガイド」（共著）など 2
3. この講演について 【前半】テスト分析・テスト設計の流れについて解説 • スクラムを対象にステップバイステップで解説 • テーマにフォーカスするため、マネジメント・テスト環境構築は対象外です • 用語はJSTQBに従います 【後半】自動テストを対象に、テスト分析・テスト設計の進め方を解説 青背景スライド：具体例の解説 赤背景スライド：参考解説。講演ではスキップ。必要に応じて後ほど資 料を参照ください 3
4. 【前半】 テスト分析・テスト設計の進め方 テスト設計プロセスの要件 現代的な開発におけるテスト設計プロセス テスト設計プロセス詳細 テスト分析 テスト設計 【補足】テスト実装 4
5. テスト設計プロセスの要件 5
6. テスト設計に求められるもの ⚫潜伏したバグを見逃さないようにする ⚫不確実性のあるプロダクトリスクが一定レベルであることを確認する ⚫様々な品質がリリースできるレベルであることを確認する ⚫複雑で曖昧なテスト対象の仕様や標準との一致性を確認する ⚫個人で対応できない規模・難易度のテスト業務を分担・協力する ⚫バグの予防・早期検出にも貢献する ⚫その他さまざまなテストの目的に対応する テスト設計はあてずっぽうなアプローチでは対応できない アプローチに工夫が必要 6
7. テスト設計に求められる工夫はさまざま ⚫まず何をテストすべきか正しく理解した上でテストを作る • テスト対象をよく分析し適切に理解する • どのようなテストが求められるか分析し具体化する ⚫バグ、プロダクトリスクに早期対策する • テストベースの誤り・矛盾・抜けを見つけ、是正してバグの実装を予防する • 対応すべきプロダクトリスクを調べ、早期コントロールする ⚫対応が必要なプロダクトリスクを深掘りしテストでフォローする • 顕在化が許容されず発生可能性の高いプロダクトリスクを分析しテストを配備する ⚫関心の分離を実施し、テストを構造化する • テストを構造化し、複雑で規模の大きなテストの構成を整理する • テスト活動を関心ごとに分離し、分けて個別に作業を進められるようにする ⚫テストの責務に対し、適切なアプローチを組み立てる • テストの要求に対して適切なテストアプローチ・テスト技法を選択する • 困難なテストの課題に対して戦略・アプローチを工夫する 7
8. 工夫をに対応するテスト設計プロセスの基本形 1. テスト分析 • テスト対象を分析し理解する • テストの要求・制約を分析する • テストベースの改善点を分析し、開発側にフィードバックする 2. テスト設計 • どのようにテストするかを技法を活用して設計する 3. テスト実装 • テスト実行に必要な準備を整える 8
9. 現代的な開発における テスト設計プロセス 9
10. 現代的なソフトウェア開発の様相 ⚫プロダクト形態がサービス化・開発ライフサイクルが長大化 • XaaS（SaaS、PaaS）など。パッケージや組込みも継続的な改善・運用で顧 客満足を支える ⚫同じ開発チームが継続的にプロダクトを運用・改善 • チームの開発力を鍛えてプロダクトの成功を支える 開発チームの総合力を鍛える必要性がますます強まっている 10
11. 開発チームに求められる総合力 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 現代的なソフトウェア開発の成功のためには、品質実現に加えて、 開発のスピード、レジリエンス、開発持続性の総合力強化が必要。 テストもそれに貢献しなければならない
12. 現代的なソフトウェア開発に対応するための テスト設計プロセス 1. テスト分析 • テスト対象を分析し理解する • テストの要求・制約を分析する • テストベースの改善点を分析し、開発側にフィードバックする 2. テスト設計 • どのようにテストするかを設計する 3. テスト実装 • テスト実行に必要な準備を整える 12 反復的に小さな粒度でプロセスを回す すばやくスパイラル的にプロダクト価値を高めていく シフトレフトを推進する テスト活動でも、バグやリスクの 予防・早期対策に注力する チームの能力を高め・活かして テストの有効性・効率性を高める
13. テスト設計プロセス詳細 13
14. テスト設計プロセス 1. テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、十分性基準を設定する • テスト条件（JSTQB用語）： テスト可能なテスト対象の要素。機能や品質特性、構造要素など 2. テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース： 実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット 3. テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃える テストケースを実行可能なテスト手順に具体化する 14
15. ユーザーストーリを使ったスクラムにおける テスト設計プロセス 15 スクラムの活動 ユーザーストーリの開発 スクラムチーム内の ユーザーストーリーテストの テスト設計プロセス バックログリファインメント スプリントプランニング スプリント期間中の開発 スプリントレビュー プロダクトバックログの 作成 POの活動 スクラムチーム のスプリント活動 ユーザーストーリ仕様の 作成と洗練 ユーザーストーリの 具体化・開発と その成果物のテスト テスト分析 テスト設計 テスト実装 テスト実行
16. テスト分析 16
17. テスト分析：「何をテストするか」の具体化 ⚫テストベース（テスト設計のインプット）を確保・整理する ⚫テスト対象を理解する ⚫テストの責務を具体化する ⚫プロダクトリスクを分析し対応方針をたてる ⚫テスト条件を分析する ⚫テストタイプを分析する ※活動を通してテストベースの改善点（抜け・誤り・矛盾など）を見つけ、 改善を働きかける 17
18. テストベースを確保・整理する ⚫テスト分析・設計・実装に必要なインプットを確保する • テストベース（例：要件定義書、システム仕様書、設計書）を提供するステー クホルダを識別し、関係構築する • テストベースを識別し確保する ⚫留意点 • あるべき姿を分析し、その実現を働きかける • あるべきステークホルダ、テストベースを分析し、その確保を働きかける • 受動的な立ち回りはテスト失敗のリスクを高める • 確保の段取りを組む（先行版・暫定版を早期確保、Q&Aで情報補足など） • 通常は計画・プロセス設計段階で実施。計画・プロセスに段取りを組み込む。 テスト分析ではそのフォローを行う 18
19. 【例】テストベースを確保・整理する テストベース 提供者 タイミング テスト活動における用途 リリース計画 PjM リリース計画時 テストのスコープ・目的・十分性基準の検討情報 ユーザストーリー スクラムチーム PO 初期：PB作成時 詳細定義：スプリントプランニング時 主なテスト対象の仕様 ユーザストーリーマップ スクラムチーム PO 初期：リリース計画時 詳細定義：PB作成時 ユーザーストーリの補完情報。 テストの優先付け・網羅基準の検討情報 受け入れ基準 スクラムチーム スプリント中 ユーザーストーリーを補完するテストのスコープ、テスト条件、 補足仕様 DoD スクラムチーム リリース計画時 テストの十分性基準の検討情報 UI仕様 UIチーム スプリント中に更新 詳細な画面設計、意匠、アニメーション仕様 アーキテクチャ仕様 アーキチーム スプリント中に更新 詳細なデータ仕様、バッグエンド仕様、UI以外の外部イン ターフェース定義、横断的な非機能仕様 Q＆Aコメント スクラムチーム PO 逐次 テスト担当者からの疑問点・指摘に対する回答 ・・・ 19
20. テスト対象を理解する ⚫入手したテストベースを理解し、テスト対象を十分に理解する ⚫テストベースの改善点（抜け漏れ、誤り、その他改善点）を見つけ、そ の是正をテストベース作成者に働きかける ⚫留意点 • テストベース作成時点で実施するのが理想。 作成作業やレビューに参加して、問題是正をサポートする 20
21. 【例】テスト対象を理解する ユーザーストーリ：検索履歴の呼び出し 「システム利用者として、過去の検索 履歴の一覧を表示し、履歴の検索構 文を選択して再実行できる。それによ り、以前検索した内容をすばやく実行 できるようにする」 表示履歴数の最小値・最大値を確認し、 本文や受け入れ基準に明記する (1)テストベースの内容をレビュー・理解する (2)問題の検出&改善しながら対象を理解 詳細なUI仕様を確保する 「検索履歴の削除」「検索履歴のセキュリ ティ」など、関連するユーザーストーリや仕様 の存在を確認する。 不足する仕様があればユーザーストーリの 発行など改善を促す 21
22. テストの責務を具体化する ⚫何をテストするか全体像を具体化する • テスト対象 • テストのスコープ • テスト分担の境界の明確化。制約やリスク・課題に応じたテストスコープの調整 • 例：自動テストとの分担、外部のサービスやコンポーネント（例：FLOSS）のテスト • テストの目的と十分性基準 • 何のためにどこまでテストすべきかの目安 • 特別に対応すべき重大なリスク・課題 ⚫留意点 • 方針レベルでは計画時に具体化しすり合わせする テスト分析では、目の前のテスト活動にフォーカスを当て、詳細度を高める • 責務が大きすぎる場合は事前に責務分担を工夫する（例：自動テスト充実など） 22
23. 【例】テストの責務を具体化する ・リリーススプリントはない。スプリン トでDoDを満たしたらインクリメント をユーザにリリースする ・担当のユーザーストーリーテストが リリース直前のテストである テストのコンテキスト •テスト対象とスコープ ・依存外部サービス含めた、プロダクトサービ ス総体を対象にする ・スプリント中の変更および変更の影響範囲 についてテストする •テストの目的と十分性基準 インクリメントがリリースできる品質であること を確認する。ユーザーストーリが適切に実現さ れていること、変更のプロダクトリスクがリリー スできるレベルであることを確認する 分析するテストの責務 23
24. プロダクトリスクを分析し対応方針をたてる ⚫テスト設計対象について、プロダクトリスク（あるいは想定される欠 陥）を分析し、必要なテストを検討する • プロダクトリスク： プロダクトの品質に影響をもたらす可能性のある事象や要因。その影響度 と発生可能性の組み合わせで程度を示す ⚫重大なリスクや制約・課題があれば、対策としてテストアプローチを 策定し運用する 24
25. 【補足】プロダクトリスクを分析し対応方針をたてる ⚫プロダクトリスクの分析アプローチ • 要素に分解し、要素ごとにリスク事象を分析する • 代表手法：FMEA • 仕様項目や、テスト対象の構成要素ごとに実施する • 回避したいリスク事象や危害を識別し、その発生要因を分析する • 代表手法：FTA • 蓄積された知識・経験や、その集合知でリスクを分析する • 代表手法：リスクストーミング ⚫テストでのプロダクトリスクへの対応 • プロダクトリスクのリスクレベルが一定以下であることを確認する（発生可能 性の確度を高める）。一定以上のリスクレベルであることが判明したら改善 フィードバックを提供する 25
26. 【例】プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加 変更影響マトリクスから、追加に伴う気がかりやリスクを分析する アカウント管理 セッション管理 UIフロントエンド ユーザ管理 バックエンド ・・・ 検索履歴保存・ 削除の追加 保存履歴の外部漏洩 未ログイン状態での履歴 表示 履歴のオーバーフロー 重複管理 履歴データの移行、バッ クアップ異常 検索履歴の表示・ 削除・選択UI追加 履歴の誤削除 ポップアップUIとの競合 検索履歴の実行 ・・・ 影響を受ける可能性のある構成要素 変更・ 変化点 26
27. 【例】プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加 要対応リスクに対し、リスクベースドテストとしてテストを用意したり、 テストの厚みや網羅基準の調整に用いたりする リスク事象 リスクレベル リスクに対するアプローチ 検索履歴データがユーザデータ操作と 連動して処理されない。例えばユーザ のコピーで履歴がコピーされない 5 ユーザデータの追加、移植、コピー、削除時に検索履 歴が連動して処理されること受け入れ基準に追記し、 ユーザーテストで確認 未ログイン状態で特定ユーザの検索履 歴が表示される 4 検索履歴に対するセッション管理のセキュリティ監査・ セキュリティテストを実施 リスクコントロールとしてハイレベルのリスクに対し対策アプローチを策定 27
28. テスト条件を分析する ⚫テスト対象をテスト条件に項目分けし、関心の分離を実施する • テストベースが項目分けされていればそれを流用できる • 例）ユーザーストーリで項目分けできていれば、それをテスト分析で流用する ただしテストの目線で項目不足や、仕様レベルの凝集性・結合性の問題があれば改 善する • テストベースの項目分けが不適切な場合、まずテストベースの改善を働きかける ⚫テスト条件を優先付けする 28 検索履歴の 再実行 テスト条件分析 検索履歴の保存 検索履歴の削除 検索履歴表示 検索履歴再実行 ・・・ テストすべき項目に分解 保存履歴の機密確保 履歴表示・実行UIの 統一性 重複履歴統一化
29. 【補足】テスト条件を分析する ⚫テスト設計視座での、仕様としての凝集性の高さと結合性の低さを 確保するように、項目分けする • 高い凝集性：意味のある分け方をしている • テスト条件が、密接に関連したテスト要求に集中しているかの程度 • ひとまとまりにテスト設計を進められる。関連性の低いテスト要求が混在していない • 低い結合性：以降のテスト活動を分けて進められる • テスト条件間の依存関係が少ない • テスト条件ごとに分けて別々にテスト設計・テスト実装作業を進められる 29
30. 【例】テスト条件を分析する ユーザーストーリー リスクマネジメント情報、アーキテク チャ仕様などユーザーストーリー以 外のテストベース ・項目分けにユーザーストーリー単位をそのま ま採用する ユーザーストーリー作成から参加し、ユー ザーストーリーの高凝集性・低結合性確保を 初期から働きかける ・項目の漏れが残った場合は、テストタスクと して追加発行する テストベース ・各ドキュメントの項目分けに従う 項目分けができていないテストベースにつ いては、テスト用に項目一覧を作り、テスト条 件とする 30
31. 基盤 【補足】機能抽象モデルを使ったテスト条件分析 入力 処理 間接 入力 状態 間接 出力 テスト対象の入力（インプット とアクション）を観点にテスト 条件を分析する 機能内の静的・動的な状態を観 点にテスト条件を分析する 全体の管理・調停・横断機能を観点にテ スト条件を分析する テスト対象の出力（アウトプットと アクション）を観点にテスト条件 を分析する 出力 入力から出力を得る処理を観点 にテスト条件を分析する 31
32. 基盤 【補足】機能抽象モデルを使ったテスト条件分析 ⚫「検索履歴保存」の機能テストのテスト条件 入力 処理 間接 入力 状態 間接 出力 出力 ・検索構文 ・異常操作（エラー推測） ・保存検索履歴（状態遷移） ・ログインユーザ（状態遷移） ・重複排除処理（エラー推測） ・FIFO処理（境界） 他でテスト： ・検索構文チェック ・セッション管理、ログイン管理（状態遷移） ・保存検索履歴（境界） 32
33. テストタイプを分析する ⚫採用するテストタイプを分析する • テストタイプ： 品質特性など、テストで着目する特性に紐づいたテストの種類 セキュリティテスト、ユーザビリティテスト、ストレステストなど • テストタイプも高凝集性・低結合性を確保するように分析する • 高凝集性：特定の特性に特化したテストタイプになっている • 低結合性：テストタイプ間の依存性が少なく、分けてテストの作成・実行を進められる ⚫テスト条件がどのテストタイプに紐づくかを分析する • テスト条件×テストタイプで関心の分離を実施する ⚫留意事項 • テスト計画や全体の基本分析で実施。テスト分析ではそのフォロー行う 33
34. 【例】テストタイプを分析する ⚫採用するテストタイプを選択し、各テスト条件をどのテストタイプでテ ストするか検討・明示化する ⚫テスト条件×テストタイプを単位に、以降の作業を進める ユーザーストーリー テスト ユーザビリティテスト セキュリティテスト ・・・ 検索履歴保存・ 削除の追加 • • 検索履歴の表 示・削除・選択 UI追加 • • • 検索履歴の実行 • 34
35. テスト設計 35
36. テスト設計：「どのようにテストするか」の具体化 ⚫テスト条件を単位に、テストケースを作成する • 探索的テストの場合は、テストチャータを作成する ⚫テストケース • 事前条件、アクション、入力、期待結果、事後条件のセット 36 事前条件 入力とアクション 期待結果 起動画面表示中 アカウント登録ボタンを押下 登録画面ページに遷移 起動画面表示中 ヘルプボタンを押下 ヘルプページに遷移
37. テストケースの設計 37 テスト条件の識別 検索履歴保存 ログインユーザ （状態） 履歴FIFO処理 （境界・状態） 文字種チェック （同値パーティション・異常系） ・・・ 本質的な テストモデルの識別 テスト設計アプローチと テスト網羅基準の具体化 状態遷移テスト 境界値分析 同値分割 ・・・ エラー推測
38. 【例】テストケースの設計：デシジョンテーブル ⚫テスト条件：料金計算機能 ⚫テストモデル：パラメータ組み合わせ・デシジョンテーブル ⚫テストケースの設計アプローチ： • デシジョンテーブルテストを選択。グレーボックスのテストアプローチで簡単化した デシジョンテーブルの各列をテストケース展開 38
39. 【例】テストケースの設計：状態遷移 ⚫テスト条件：給湯操作機能 ⚫テストモデル：状態 ⚫テストケースの設計アプローチ：状態遷移テストを選択 • 状態遷移図・状態遷移表を作成 • 全状態網羅、全遷移網羅する実行パスをテストケースに展開 39
40. スクラムでのテスト設計 ⚫ユーザーストーリーテストの設計の場合、ハイレベルテストケースやテ ストチャータを設計し、受け入れ基準や補足情報での補足や、テスト 情報への参照を取る 40
41. 【補足】テスト設計の工夫でテストの効率性を高めて チームの総合力に貢献する 【根拠なしに技法を使った一律網羅】 •オールペア法で2ワイズカバレッジ100%網羅 •状態遷移テストで2スイッチカバレッジ網羅 •制御フローテストで複合条件カバレッジ網羅 【目的やリスクに基づいたピンポイント確認】 •バグがありそうなところを確認 •テストの目的にとって重要な箇所を確認 •探索して怪しいところを深掘り △ ・根拠があっての選択ならば妥当だが、思考 停止で選択するのは危険 無駄が増えがちで、リソース浪費により、 必要なテストの欠落を誘発する場合も ・技法は明確な根拠に基づいて選択する 〇 ・ドメイン・プロダクト・品質リスクや不具合へ の精通が求められる。 経験、知識、技術の総合力が求められる ・本質的にこちらが重要。実際にプロダクト 開発を支えているのもこちら ・分析はこのアプローチを支えるために行う 41
42. 【補足】テスト実装 42
43. テスト実装：テスト実行の準備 ⚫テスト実行に必要なテストウェアを準備する ⚫テストケースを実行可能なテスト手順に変換する ⚫テスト手順を優先付け・選択する 43 テスト設計結果 テスト実装成果物 事前条件 アクション 期待結果 料金計算画面 を開く 1.年齢に5歳を入力する 2.クーポンなしを選択する 3.料金計算ボタンを押下する 料金欄に料金0円が 表示される ・・・
44. テスト設計プロセス 1. テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、十分性基準を設定する • テスト条件： テスト可能なテスト対象の要素。機能や品質特性、構造要素など 2. テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース： 実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット 3. テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃える テストケースを実行可能なテスト手順に具体化する 44
45. 【後半】 自動テストを対象とした場合の テスト分析・テスト設計の進め方 自動テストでのテスト分析・テスト設計の進め方 開発と並走して作成・実行する自動テスト 開発から独立して作成・実行する自動テスト 【補足】自動テストに合わせたテスト設計・テスト実装 45
46. 自動テストでの テスト分析・テスト設計の 進め方 46
47. 自動テストでのテスト分析・テスト設計 ⚫自動テストでも適切なテスト分析・テスト設計が必要 • テスト自動化は適切なテストケースを自動化してこそ価値がある ⚫アンチパターン：GIGO（Garbage In, Garbage Out） • 元々は情報システムで、ゴミのようなインプットをしたら、ゴミが出力される ことを指す • 自動テストでは「ゴミを自動化してもゴミのまま」という格言として知られる ⚫ただし自動テスト特有の事情がある。それに合わせて進める 47
48. 開発との併走要求に応じたテスト設計方針： 開発との併走程度でアプローチが変わる 48 システムテスト 統合テスト ユニットテスト 開発と並走して自動テストを 作成・実行 開発から独立して自動テストを 作成・実行 手動テストと同様の テスト設計プロセスをとる テスト設計方針を示し、 テスト設計を任せる テストレベルの 粒度の細かさ
49. 開発と並走して作成・実行する 自動テスト 49
50. 開発と並走して作成・実行する自動テストの例 ⚫テスト駆動開発 • ２つの活動を短期で繰り返すプログラミング手法 • テストファーストプログラミング まず失敗するテストを書き、プロダクトコードを追加変更して成功に変える • リファクタリング ⚫Cover ＆ Modify（保護して変更する） • 追加変更する際に、十分な自動化されたリグレッションテストで変えたくない ふるまいを保護（Cover）し、その成功状態を維持しながらプロダクトコードを 追加変更（Modify）するプログラミングプラクティス 50
51. 開発と並走して作成・実行する自動テスト ⚫プログラミングと並行してテストを作成する • 作成したテストはCI/CDに組込み、リグレッションテストや、以降の開発サ ポートの資産として活用する ⚫併走化は自動テストの理想 • 併走化でさまざまなメリットを実現できる。自動テストの費用対効果を確保 しやすい • テスト駆動開発として設計・実装を主導 • 無理のないテスト容易性の実現 • 自動テストの品質作りこみ • 高速なフィードバックの実現 • CI/CDのリグレッションテスト強化 51
52. 開発と並走して作成・実行する自動テストでの テスト分析・テスト設計 52 テスト分析 テスト設計 テスト実装 • テストレベルやテストタイプ を対象にテストの責務を 明確化する • テスト設計方針を立てる • テスト設計方針に基づいて、開発者に任せる。開発と並行し ながらテストを設計・実装する • モビング、PRレビューやカバレッジ監視で方針運用をモニ タリング・コントロールし、チームを啓蒙する • 詳細なドキュメント化は行わない。テストコード（TaD：Test as Documentation）やHWWWｎの原則で情報を表現する • 詳細なドキュメント化は作成・保守コストが大きく、細かく 変更される併走テストには適さない。スピードを損なう
53. 開発と並走して作成・実行する自動テストでのテスト設計方針 ⚫テスト設計方針の例：ユニットテスト • ユニットのふるまいやインターフェースの仕様が実現されているか確認する • 例）境界値を網羅する、同値パーティションを網羅する、有則を網羅する・・・ • プログラマが感じるリスク（いわゆる不吉な臭い）が許容できる水準であるこ とを確認する • 法規制など特別なテスト要求があれば対応する • 上記の対応の中で基準のテストカバレッジを満たす • 例）C0/C1カバレッジ80%以上 ⚫著名な原則論や設計パターンがあり活用できる • FIRSTの原則/xUnit Test Patternsの原則/AAAパターン/ 「DRYでなくDAMP」の原則 53
54. テスト駆動開発でのテスト設計プロセスの推進 ⚫全体のテスト分析 • テスト駆動開発の責務（目的、スコープ）、方針（例：ユニットテストは 整理してCI/CDに展開）を明確化する • テスト設計方針、テスト駆動開発のノウハウを明文化し展開する ⚫詳細なテスト分析 • テスト条件を識別し、テストリストにまとめる（コード中のコメントやIDE のタスク管理機能を活用） ⚫テスト設計・テスト実装 • テストリストを単位にテストファーストサイクルをまわす • テストコードとして実装する。テスト分析・設計の意図が明確になる ように命名や実装、コメントを工夫する • リファクタリングと同じようにテスト設計・テスト実装を改善する 54 事前に 実施 プログラミ ングの中 で実施
55. 開発から独立して作成・実行する 自動テスト 55
56. 開発から独立して作成・実行する自動テスト ⚫対象 • 開発から独立したテスト（例：WF開発でのシステムテスト）での自動テスト • セキュリティテストでのファジング、ストレステストといった特命的な自動テスト ⚫手動テストと同じテスト設計プロセスをとる ⚫開発から独立して作成・実行する自動テストは、費用対効果の確保 に課題が多くテスト分析に工夫が必要 • 自動テストの適切な目的設定 • 自動化環境実現のコストやリスク • テスト容易性・テスト自動化容易性の確保 • 自動テストの投入タイミングの調整 56
57. 開発から独立して作成・実行する自動テストでの テスト分析・テスト設計 57 テスト分析 テスト設計 テスト実装 • 手動テストと同様の分析実施 • 自動テストの適切な責務を具体 化し、目的設定する • テスト容易性・テスト自動化容易 性の要件を特定し、開発に確保 を働きかける • 自動テスト環境要件を分析し、 環境確保を手配する • 手動テストと同様のテスト設計実施 • ただし後述する自動テスト特有のテスト設計構造 や実装パターンに合わせる • モデル（モデルベーステスト）やテストコード（TaD）でテス ト設計・テスト実装の成果物管理を行う
58. 自動テストに合わせた テスト設計・テスト実装 58
59. 自動テストのテスト設計・テスト実装での工夫点 ⚫自動テストスクリプトが得意な設計構造・実装パターンに合わせて、テスト の保守性や効率性を確保する ⚫例）パラメータ化テストの活用 「共通の振る舞い＋パラメータのバリエーションのリスト」の形式になるようにテスト 設計、テスト実装を推進すると、パラメータ化テストの効果が活かしやすくなる 59
60. まとめ 【前半】 テスト分析、テスト設計、テスト実装の段取りの重要性を解説し、 スクラムでの具体的な流れを解説しました 【後半】 自動テストでのテスト分析・テスト設計の重要性を解説しました 自動テストにおけるテスト分析・テスト設計の進め方を解説しました 60