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
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
130
Lazy application authentication with Tailscale
bluehatbrit
0
210
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
7.1k
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
390
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
4
13k
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
7
1.1k
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
110
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
120
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
7.7k
CRE Camp #1 エンジニアリングを民主化するCREチームでありたい話
mntsq
1
130
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
Typedesign – Prime Four
hannesfritz
42
2.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Producing Creativity
orderedlist
PRO
346
40k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Unsuck your backbone
ammeep
671
58k
Docker and Python
trallard
44
3.5k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
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. 理想と現実で互いに歩み寄る • この場合は「該当・非該当がごちゃ混ぜで書類が提出できない」という致命的な問題が発生しかねないので「絶対に対応しな ければならないもの」の分類。 • とはいえ、口を出すまでもなく修正(=現実を理想に寄せる)の方向に話が行ったので質問後特にアクションはなし。この時点 で該当画面は未実装のため、実装の手戻りはなし。
みんながテストのときに考えているこ とも聞きたいの〜
ご静聴ありがとうございました!