新卒QAエンジニア向けテスト分析演習[外部公開用]

このスライドは、freeeの新卒QAエンジニアを対象とした、ソフトウェアテストの「テスト分析」に関する入門的な演習資料です。

Transcript

1. 　 新卒向けテスト分析演習
 〜 テスト分析のための基礎知識 〜
 2025.05.02
2. 　 2 2024.04.01⼊社 freee初の新卒QAの1⼈ ◆ 担当プロダクト：freee振込 ◆ 趣味：ゲーム、映画、筋トレ、読書、etc ◆ 経歴：⽴命館⼤学⼤学院 情報理⼯学研究科 修了 ◆ 好きな⾷べ物：タコス、ステーキ、ハンバーガー、 ラーメン ◆ 最近あった嬉しかったこと：気に⼊る腕時計を⾒つ けられたこと(atelier coin) ◆ 最近あった悲しかったこと：switch2の抽選に外れ たこと 川端宏知（tonchan） エンジニアリング基盤船団/QA‧CRE船/ ⽀出管理QAヨット/⽀出統合QA Hiroto Kawabata
3. 3 1. テスト分析とは？
 2. テスト分析とテスト設計の違い
 3. テスト分析・設計・技法の関係性
 4. テスト分析のステップ例
 5. 例題：TODOアプリ
 
 アジェンダ

4. 　 はじめに

5. 5 学習⽬標： • テスト分析とは何か、なぜ重要かを理解する • テスト分析とテスト設計の違いを説明できるようになる • テスト分析の基本的な進め⽅を学ぶ 「テスト分析の領域を正しく理解し、抜け漏れなく実⾏できる」状態を⽬指す 本講座の⽬的について
6. 6 freee QAの標準テストプロセス 
 • 開発情報キャッチ
 • （オプション）テスト工数の概見積もりとメンバーアサイン
 • 開発内容理解／仕様把握
 • リスク洗い出し
 • テスト計画
 • テスト分析　←この活動についての説明 
 • テスト設計
 • テスト実装（テスト実行準備）
 • テスト実行
 • テスト完了（まとめ）

7. 　 テスト分析とは

8. 8 まず、テストについて 
 テスト実行では以下のことをする 
 ・事前条件を決めて、値を入力したうえで、テスト対象を動かす（アクション）。 
 ・出力結果の確認と、事後条件の確認をする。 
 
 
 
 
 
 
 テスト実行 テスト対象 ‧事前条件と⼊⼒ ‧アクション ‧出⼒結果確認 ‧事後条件確認
9. 9 テストでは、入力のパターンごとに出力を確認する 
 
 何を確認したい時でも、テスト対象に入力をして出力を確認する以外の方法はない。 
 出力を想定しておいて、実際の出力と比較をして良し悪しを判断する。 
 
 
 
 
 
 
 テスト実行 テスト対象 ‧事前条件と⼊⼒ ‧アクション ‧出⼒結果確認 ‧事後条件確認 ‧テストを作るために、テスト対 象をテストの観点で理解する ‧テスト対象の中⾝を分解して理 解する＝分析 ‧ブラックボックステストでは物 理的ではなく論理的に分解する ‧理解したアウトプットが、事前 ⼊⼒、⼊⼒やアクション、期待結 果と事後条件になる ‧テストのケース（具体例）は理 解した結果の１パターン テスト対象には、ちっさい機能がいっぱい ⼊ってるのを理解し、どういう⼊⼒をすれば ⼩さい機能が確認できるか理解する 画面 API DB 制御
10. 10 • 定義 ◦ テスト対象を分解して理解する作業 • ⽬的 ◦ テスト対象の機能、データ、状態、関連性などを分解し、テストが必要な箇所 （テスト条件、テスト観点）を洗い出すこと。 • ポイント ◦ 「何を（What）」テストするかを考える段階であり、「どうやって （How）」テストするか（＝テスト設計）とは区別する。 ◦ テストを作る前に、テスト対象を理解することが何より⼤切 テスト分析とは？
11. 11 最初に結論 「何をテストすべきか」を先に正しく決めておかないと、 品質‧コスト‧スピード‧説明責任 のすべてが損なわれる！ (1) 品質: 抜け漏れ防⽌とハッピー検出⼒の向上 • テスト対象を分解して理解→分解した分析を整理する→漏れ‧重複を潰せる (2) コスト: ⼿戻りコストの削減 • テスト分析＝設計フェーズと同等の早期活動 • → 仕様⽋陥を設計のタイミングで潰せるため、⼿戻りコストを⼤幅に削減できる なぜテスト分析が重要なのか？①
12. 12 (3) スピード: 限られた時間で“質を落とさず”完了する • すべてを⼗分にテストする時間は無い。全数テスト不可能の原則 • リスクの⾼い条件を先に抽出しておくことで、テスト設計‧実⾏の優先順位が明確 になり、限られた時間でも効果的に品質を確保できる なぜテスト分析が重要なのか？② (4) 説明責任: 合意形成 • QAだけが納得してテスト完了にはできない。チーム全員が納得で きる状態でないとリリースすることは不可能 • 「このケースはどの要求を保証しているのか」「この不具合はど の条件がカバーできていなかったのか」を辿れるようにする
13. 13 freee QAの標準テストプロセス（再掲） 
 • 開発情報キャッチ
 • （オプション）テスト工数の概見積もりとメンバーアサイン
 • 開発内容理解／仕様把握
 • リスク洗い出し
 • テスト計画
 • テスト分析　←この活動についての説明 
 • テスト設計
 • テスト実装（テスト実行準備）
 • テスト実行
 • テスト完了（まとめ）
 テスト分析はテストプロセス の中で⼀度だけでなく、 必要に応じて適宜やる
14. 14 ☓ テストケースを書きながら“思いつき”で⼤量に観点を⾜す  → 途中で漏れ発覚 → テスト設計などのテンプレ全崩し → テスト再実⾏  → 〆切炎上🔥 ☓ 「バリデーション全部 OK だよね？」と⼝頭確認のみ  → テスト分析‧設計への反映をしない → 旧仕様のままテスト実⾏  → リリース後に⼊⼒桁数ハッピー判明、、、 もし分析を⾶ばしたら？（アンチパターン）
15. 　 テスト分析とテスト設計の違い

16. 16 例 ⾷品の成分分析 • コーラに砂糖は何g⼊ってる？ • 砂糖は⼈間が吸収できる？ • 砂糖は1gあたり何kcal？ • 客観的に導き出すもの テスト分析とテスト設計の違い① 例 注⽂住宅の設計 • 顧客は3LDKで和⾵建築がいいらしい • 平屋建てにしつつ、地震が多い地域 だから耐震構造も⼊れよう • 主観的に導き出すもの
17. 17 デシジョンテーブルモデルを使った例 テスト分析とテスト設計の違い② ‧条件の曖昧な記述を⽌める ‧仮説で決めているものをやめ、 説明通りにする テスト分析 「納得できるテストをするためのモデリング講座実践編（株式会社ytteLab）テキストより抜粋
18. 18 デシジョンテーブルモデルを使った例 テスト分析とテスト設計の違い② テスト分析 簡単化の考え⽅で理解を深める ‧条件を明確に ‧重複条件を削除 ‧任意のものを「-」に 「納得できるテストをするためのモデリング講座実践編（株式会社ytteLab）テキストより抜粋
19. 19 ‧パターンの削除 ‧「何もしない」に返⾦レバーの 動作を追記 ‧返⾦できること テスト設計 デシジョンテーブルモデルを使った例 テスト分析とテスト設計の違い② 「納得できるテストをするためのモデリング講座実践編（株式会社ytteLab）テキストより抜粋
20. 20 テスト分析: • ⽬的：テスト対象を分解して理解し、テストすべきこと（観点、条 件）を洗い出す。（What） • 成果物イメージ：テスト観点リスト、テスト条件リスト、論理的機能 構造図を⽤いた分析結果など テスト設計: • ⽬的：テスト分析で洗い出した観点/条件を、どのようにテストする か（P-Vの組み合わせ、テスト⼿順など）を具体化する。（How） • 成果物イメージ：具体的なテストケース（⼿順、⼊⼒値、期待結 果）、テストデータ、テスト技法（同値分割、境界値分析など）の適 ⽤結果 テスト分析とテスト設計の違い③
21. 　 テスト分析・設計・技法の関係性

22. 22 以下、ISTQB⽇本語訳シラバスより抜粋 • テスト分析は、テストベースを分析して、テスト可能なフィーチャーを識別し、関 連するテスト条件を 定義して優先順位を付けるとともに、関連するリスクとリスク レベルを分析することを含む [1] • テスト技法は、テスト分析（何をテストするか）とテスト設計（どのようにテスト するか）において、 テスト担当者をサポートする [1] • テスト分析およびテスト設計の活動は、レビューおよび静的解析とテスト分析およ びテスト設計を組み合わせることにより強化できることがある。テスト分析および テスト設計を実施する活動の中でテストベースの問題を⾒つけることがあるため、 実際に、テスト分析およびテスト設計を⾏うことが静的テストの⼀形態となること がしばしばある [2] ISTQBで記述されているテスト分析 [1]: ISTQBテスト技術者資格制度 Foundation Level シラバス ⽇本語版 Version 2023V4.0.J02 [2]: ISTQBテスト技術者資格制度 Advanced Level シラバス ⽇本語版 テストアナリスト Version 3.1.1.J03
23. 23 • テスト分析とテスト設計を組み合わせることで互いの活動を強化することができる • テスト技法はテスト設計だけでなく、テスト分析においても役⽴てることができる テスト分析‧設計‧技法の関係性について テスト技法を知ることによってテスト分析‧設計の質を向上させることができる！ テスト技法 テスト設計 テスト分析 テストベース テスト 分析‧設計 静的テスト （レビュー, 解析） 動的テスト （実⾏, 評価） テスト分析‧設計‧技法の関係性 「静的テスト」と「動的テスト」の位置づけ
24. 24 • ブラックボックステスト技法 ◦ 同値分割法 ◦ 境界値分析 ◦ デシジョンテーブルテスト ◦ 状態遷移テスト ◦ クラシフィケーションツリー技法 ◦ ペアワイズテスト ◦ ユースケーステスト ◦ ドメイン分析テスト ◦ CRUDテスト ◦ シナリオベーステスト ◦ メタモルフィックテスト テスト技法⼀覧（ISTQBから抜粋） • 経験ベースのテスト技法 ◦ エラー推測 ◦ チェックリストベースドテスト ◦ 探索的テスト ◦ ⽋陥ベースのテスト技法 • ホワイトボックステスト技法 ◦ ステートメントテスト ◦ ブランチテスト
25. 25 技法名 (Technique Name) 適用場面 (Typical Application) 長所 (Advantages) 短所・注意点 同値分割法 (Equivalence Partitioning) 入力範囲や条件を持つ機能（例：年齢入力、料 金計算） テストケース数を大幅に削減できる 境界値付近の欠陥を見逃す可能性、単独 では網羅性が低い 境界値分析 (Boundary Value Analysis) 入力値の境界、条件の境界（例：有効範囲の 端、閾値） 境界付近の欠陥発見率が高い 境界から離れた箇所の欠陥は見つけにく い、同値分割との併用推奨 デシジョンテーブルテスト (Decision Table Testing) 複数の条件の組み合わせで動作が変化する機 能（例：割引ルール、承認プロセス） 条件の組み合わせの網羅性が高い、仕様の 曖昧さや矛盾を発見しやすい 条件やアクションが多いとテーブルが複雑 化・巨大化する 状態遷移テスト (State Transition Testing) 状態を持つシステム（例：ログイン状態、機器の 動作モード、ワークフロー） イベントの順序や状態の組み合わせに起因す る欠陥を発見しやすい 状態や遷移が多いと図や表が複雑化、全 ての遷移の網羅は困難な場合あり シナリオテスト (Scenario Testing) ユーザーが実際に行う操作の流れ、特定の業 務シナリオ（例：E2E自動テスト） 実際の使われ方をシミュレートできる、ユーザ ビリティの問題も発見しやすい シナリオの選択が重要、網羅的なテストに は不向き 探索的テスト (Exploratory Testing) 仕様書が不十分な場合、新しい機能、時間的 制約がある場合（例：テストチャーター） 予期せぬ欠陥や仕様書の不備を発見しやす い、テストの目的を考えるようになる テストの再現性が低い、網羅性の担保が 難しい、記録が重要
26. 　 テスト分析のステップ例
 

27. 27 1. テストベースの抽出 ◦ 要求‧要件定義書/アーキテクチャ図/シーケンス図/API 仕様/ER 図 … ◦ この段階でテストベースに対するレビューも実施する 2. リスク識別 ◦ リスクを発⾒し、認識し、および記述する 3. 優先度付け ◦ 発⽣確率 × 影響度 × 検出難易度 ▪ freeeには重篤度という考え⽅があるのでそれを活⽤します 4. テスト条件の導出 ◦ 今まで得られた情報を元にして、テスト条件を導出する テスト分析のステップ例
28. 28 テスト分析を始める前に必要な情報を集める • 情報源の例：Brief&PRD、DesignDocs、figma、既存資料、開発の 成果物（コードなど）、テスト対象物と類似するプロダクト • Eng、PM、PDなど関係者へのヒアリング ◦ 朝会などの定例、slack、昼ご飯、他愛のない会話などもテスト ベースになる • 「何を‧なぜ作るのか」「誰がどう使うのか」といった背景‧⽬的 の理解も⼤切 ◦ 何が魅⼒的品質なのか、当たり前品質なのかなども考えられる とGood！ 1. テストベースの抽出
29. 29 • リスク識別とは、リスクの包括的 なリストを作成すること • freeeではリスク洗い出し会を実施しており、この活動がリスク識別に該当する ◦ ハッピーを未然に防ぐため、また、注⼒してテストする部分を明らかにする ため、関係者で開発内容の不明点やリスクを洗い出す • リスク洗い出し会の⽬的 ◦ 開発の初期に関係者全員の知⾒をつかってリスクを検討することで、⽋陥が ⼊らないように開発を進める ◦ 「QAがどの程度テストをすべきか？」を判断する 2. リスク識別
30. 30 • freeeでは重篤度という概念を運⽤しているので今回はそれを利⽤しています ◦ ISTQBでは以下の項⽬で定量的なリスクアセスメントが実施できると記述さ れている ▪ リスク影響度‧リスク可能性‧レベル（影響＊可能性） 3. 優先度付け リスク 影響範囲 重篤度 優先度 1 外部 API が 5xx 応答 48 Critical Highest 2 Backend ダウン 30 Major High 3 DB レイテンシ >1s 20 Normal Normal 4 キャッシュ不整合 24 Normal Low 5 UI 表示崩れ（Chrome特定版） 4 Minor Lowest
31. 31 • テスト条件とは、「何をテストするか」を具体化したもので、テスト設計が可能 になるレベルまで詳細化されたもの • テスト対象が⼤きすぎると、何をどこまでテストすれば良いか分からなくなる。 そこで、テストしやすいように関⼼事（機能、特性など）で項⽬分けを⾏う • 項⽬ごとに、テスト設計に必要な詳細度のテスト条件（カバレッジアイテム）を洗 い出す ポイント: この段階で状態遷移図やデシジョンテーブルといった「テスト技法」の考え ⽅を活⽤すると、より体系的にテスト条件を洗い出すことができる 4. テスト条件の導出
32. 　 例題　TODOアプリ ①

33. 33 TODOアプリの仕様 アプリの概要 • Web上で TODO（やること）リストを管理できる アプリ。 主な機能 • TODO項⽬を⼊⼒し、リストに追加できる。 • リスト内のTODOを削除できる。 • リスト内のTODOの「完了‧未完了」状態を変更 できる。 • TODOを編集できる。 画⾯要素 • ⼊⼒欄 • 「追加」ボタン • TODOリスト表⽰（内容、状態、削除、編集ボタ ン） 挙動 • ⼊⼒欄に内容⼊⼒＋「追加」でリストに項⽬が追 加される。 • 各TODOには「完了」「未完了」の状態がある。 状態変更可能。 • 編集や削除を⾏うとリスト表⽰が変わる。 制約‧例外 • 各項⽬に対する制限（⽂字数‧記号‧空欄など） は未定義。 • TODO数に上限があるかどうか未定義。 • 順序や表⽰⽅法も特に決まっていない。 • その他の詳細（エラーメッセージ‧リロード時の 挙動等）は未定義。。 何からすれば いいんだろう？ テスト分析をしてみましょう！（スプシでもfigjamでもなんでもOK！）
34. 34 テスト分析例 1. 基本機能ごとに分解 • 追加機能‧削除機能‧編集機能‧状態変更機能 2. 主なテスト条件例 • 追加機能 ◦ ⼊⼒欄が空、⻑⽂、記号混⼊、スペースのみ、最⼤⽂ 字数 ◦ 連続/⾼速追加、同じ内容の重複追加 ◦ 項⽬数が増えた場合（上限？画⾯レイアウト？） • 編集機能 ◦ 機能が正常に動作する/キャンセルした場合 ◦ 編集で空欄や異常な値が⼊⼒された場合 ◦ 編集中に追加‧削除を実⾏ • 状態変更機能 ◦ 完了⇔未完了の正常切替 ◦ 状態変更後の表⽰や他操作との組み合わせ • 削除機能 ◦ 単⼀削除、連続削除、全件削除 ◦ 削除直後の表⽰/動作、削除と他操作（編集 ‧追加）の組み合わせ ◦ 表⽰‧リスト ◦ 順序確認（追加順？
35. 　 例題　TODOアプリ ②

36. 36 TODOアプリの仕様 アプリの概要 • Web 上で TODO（やること）リストを管理できる シングルページアプリケーション（SPA） • フロントエンド：React∕Vue 想定、バックエン ド：REST API • 「タスク管理」機能と「進捗ダッシュボード」機 能が相互に連携する 主な機能 A. タスク CRUD • TODO 項⽬を⼊⼒しリストに追加できる。 • リスト内の TODO を編集∕削除できる。 • TODO の「完了 ⇔ 未完了」状態を変更できる。 • B. フィルタ‧検索 • ‒ キーワード検索、ステータス（完了∕未完 了）、期⽇タグで絞り込み可能。 C. 進捗ダッシュボード • 未完了‧完了件数、達成率（％）をリアルタイム で集計し表⽰。 • 全タスク完了時は「おめでとうアニメーション」 が表⽰される D. 期⽇リマインド（NEW‧機能間連携） • 期⽇が設定された TODO が期限当⽇の 09:00 に バックエンドジョブから Slack∕メールに通知。 • 通知送信後、タスクに「通知済」フラグを⽴て⼆ 重送信を防⽌。 何からすれば いいんだろう？ テスト分析をしてみましょう！（スプシでもfigjamでもなんでもOK！）
37. 37 TODOアプリの仕様 アプリの概要 E. 外部カレンダー連携 • Google Calendar API を利⽤し、期⽇付き TODO をカレンダーに⾃動登録。 • TODO を更新∕削除した際、該当カレンダーイベ ントも同期して更新∕削除される。 画⾯要素 • タスク⼊⼒欄＋「追加」ボタン • TODO リスト（項⽬名、状態トグル、編集‧削除 ボタン、期⽇表⽰） • フィルタ∕検索バー • 進捗ダッシュボードウィジェット（未完了数‧完 了数‧達成率バー） • 機能間連携例（⼀部抜粋） • タスク状態を「完了」に変更 → ダッシュボードの 未完了数‒1∕完了数+1∕達成率再計算 → カレン ダーの該当イベントに “✔ Done” 接頭辞を付与 • タスクを削除 → ダッシュボード件数再計算 → 連 携済みカレンダーイベントを削除 • 期⽇前⽇ 09:00 のバッチ実⾏ → Slack∕メール通 知送信 → 送信結果をタスク詳細の「通知履歴」に 追記 ⾮機能要件（抜粋） • ダッシュボード更新は 1 秒以内に UI へ反映 何からすれば いいんだろう？ テスト分析をしてみましょう！（スプシでもfigjamでもなんでもOK！）
38. 38 ゆもつよメソッド使ってみた例
39. 39 テストをもっと詳しく知りたくなったら是非 
 他にもいくつかテクニックがありますが、同値分割と境界値分析は基本中の基本。それをいかに組み合わせるのが効率的か、とかい ろいろあります。
 
 参考書籍「ソフトウェアテスト読書マップ」（有志の方々が作成してくださっている読書マップです！）
 • ソフトウェアテストの世界をざっくり知る
 ◦ 「知識ゼロから学ぶソフトウェアテスト」 
 ◦ 「マインドマップから始めるソフトウェアテスト」 
 • テストの基本的な考え方を体系的に抑える
 ◦ 「ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス2023対応 (日本語) 単行本」
 • テスト技法を身につける
 ◦ 「ソフトウェアテスト技法ドリル」 
 ◦ 「ソフトウェアテスト技法練習帳」 
 ◦ 「ソフトウェア技術者のためのバグ検出ドリル」 
 • テストツールの基本的な考え方を抑える
 ◦ 「システムテスト自動化ガイド」 
 • ソフトウェア品質保証についての知識
 ◦ 「ソフトウェア品質知識体系ガイド」：読み物ではなく、技術カタログ・辞書として利用する 
 ◦ 「ソフトウェア品質保証の考え方と実際」 
 
 　　　　　　　　
 　　　　　　　　　

40. 　 Q&A

41. スモールビジネスを、世界の主役に。