Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト設計のとき何を考えてるの? QA2年生が語ってみるの
Search
freee
September 27, 2022
Technology
0
25k
テスト設計のとき何を考えてるの? QA2年生が語ってみるの
freee
September 27, 2022
Tweet
Share
More Decks by freee
See All by freee
freee請求書のSLO違反改善活動について / SLO violation remediation activities for freee invoices
freee
0
330
freee + Product Design FY25Q4
freee
4
14k
10分でわかるfreeeのQA
freee
1
14k
freee Movement Deck
freee
1
200k
freeeのモバイルエンジニアについて
freee
1
580
10分でわかるfreee エンジニア向け会社説明資料
freee
23
560k
freeeの福利厚生と働き方
freee
1
79k
品質の高速フィードバックへの取り組み / Commitment to Fast Quality Feedback
freee
4
1.5k
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incorporating the “essence of product development” into organizational development and continuing to face uncertainty
freee
1
6.6k
Other Decks in Technology
See All in Technology
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
LLM時代の検索
shibuiwilliam
2
170
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
110
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
450
品質と速度の両立:生成AI時代の品質保証アプローチ
odasho
1
360
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
1
190
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
7.1k
怖くない!はじめてのClaude Code
shinya337
0
400
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
150
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
77
9.5k
Producing Creativity
orderedlist
PRO
346
40k
Speed Design
sergeychernyshev
32
1k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Writing Fast Ruby
sferik
628
62k
For a Future-Friendly Web
brad_frost
179
9.8k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Transcript
テスト設計のとき何を考えてるの? QA2年生が語ってみるの JaSST nano vol.16 2022.09.20
2 • WEBエンジニアを経てQAエンジニアにジョ ブチェンジ(現在QA2年生) • 2022年1月からfreeeにジョイン • freeeでは人事労務を担当 •
趣味は美味しいご飯を食べることとお酒を飲 むこと • 最近はReactを勉強中 かいり QAエンジニア @QA_kairi プロフィール画像の トリミング方法
3 はじめに みんな、テスト設計のときどんなことを考えているの?
私はこんなことを考えてテス ト設計しているの! (メソッドにまとめてみたの〜)
5 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
6 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
7 1. ビジネス上の目的を明確に • 業務上のシステム作成は当然ながらビジネス ◦ 何のためのシステムなのか(=誰にとっての価値なのか)が明確になっていないと後々困ることになる • 仕様が曖昧なのは仕方がないが、ここが曖昧なのはNG
8 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
9 2. システムの理想の姿を定める • ビジネス上の課題/目的と、考えうるユーザーストーリーから理想のシステムを定義する • その際には他社の類似システムも参照する • 仕様書がすでにあったとしても、それが目的に沿っていないことは珍しくない •
このとき、ユーザーは純粋なユーザーだけでなく、全てのステークホルダーを意識する
10 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
11 3. パターンを使って課題を予測する • 理想の姿を求める時に異常系の確認が漏れる場合が多いので課題に焦点を当てて予想する • よくある課題はすでにある程度パターンがある(ex. エラーハンドリング、セキュリティ) • 自社事例(バグチケット)や社会的に問題になったバグ事例なども活用する
12 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
13 4. 理想と現実の間に課題はある • テスト工程(テスト対象は仕様書を含む) • 理想を頭に入れた状態でユーザーストーリーに沿ってチェックし問題がないか確認する • 理想と現実を比較すると、対応すべき課題が見えてくる
14 01 ビジネス上の目的を明確に 02 システムの理想の姿を定める 03 パターンを使って課題を予測する 04 理想と現実の間に課題はある 05 理想と現実で互いに歩み寄る As-Is To-Be テストメソッド (仮)
15 5. 理想と現実で互いに歩み寄る • 課題をトリアージする(=重篤度の決定) • 課題には「絶対に対応しなければならないもの」と「そうでないもの」の二種類がある • 絶対に対応しなければならないものは社会的信用に関わる場合もあるので現実を理想に寄せる •
全ての課題に対応していたら本来の目的を達成できない場合、理想を現実に寄せることも検討する(一部機能を切り落とす など)
実践事例
17 1. ビジネス上の目的を明確に • https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.files/01.pdf • 被扶養者(異動)届の扶養異動日の加入日・喪失日情報が不足しているので追加する。 • 最終的には電子申請を行えるようになるのが理想。電子申請はfreeeとして価値のあること。 •
書類が任意のタイミングで出力→提出できるようになるのも目的。本来ならそうあるべきなのでそれも価値のあること。
18 2. システムの理想の姿を定める • 扶養異動日の加入日・喪失日情報が不足しているので追加する。 • 最終的な理想=ユーザーストーリーは以下の通りになるはず ◦ 管理者が従業員の情報を収集して従業員画面から情報を保存し、最終的には書類を出力or電子申請を行う。今回は書 類の出力がゴール。
• 理想の姿=正しい形の書類が出力できること、なので書類の記入ルールを隅から隅まで読む。一言一句見逃さない勢いで。 • https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.files/01.pdf • (ん?下の方に気になることが書いてあるな・・・気に留めておこう)
19 3. パターンを使って課題を予測する • リスク洗い出し会を実施。影響範囲を確定。ヘルプページの修正が漏れる可能性が挙がる。 • 他に想像できるのは、書類のルール違反。書類データを後から変更した場合の処理でエラーなど。
20 4. 理想と現実の間に課題はある • 当時のデザインを見ると、「該当」と「非該当」をごちゃ混ぜで出せる形になっていた。書類の注意文が頭に入っている状態だ と違和感があるので、質問。 • 結果としてその時点での仕様に考慮漏れがあったことが発覚。
21 5. 理想と現実で互いに歩み寄る • この場合は「該当・非該当がごちゃ混ぜで書類が提出できない」という致命的な問題が発生しかねないので「絶対に対応しな ければならないもの」の分類。 • とはいえ、口を出すまでもなく修正(=現実を理想に寄せる)の方向に話が行ったので質問後特にアクションはなし。この時点 で該当画面は未実装のため、実装の手戻りはなし。
みんながテストのときに考えているこ とも聞きたいの〜
ご静聴ありがとうございました!