テスト設計のとき何を考えてるの？ QA2年生が語ってみるの

Transcript

1. 　 テスト設計のとき何を考えてるの？ QA2年生が語ってみるの JaSST nano vol.16 2022.09.20
2. 　 2 • WEBエンジニアを経てQAエンジニアにジョ ブチェンジ（現在QA２年生） • 2022年1月からfreeeにジョイン • freeeでは人事労務を担当 • 趣味は美味しいご飯を食べることとお酒を飲 むこと • 最近はReactを勉強中 かいり QAエンジニア @QA_kairi プロフィール画像の トリミング方法
3. 3 はじめに みんな、テスト設計のときどんなことを考えているの？
4. 　 私はこんなことを考えてテス ト設計しているの！ （メソッドにまとめてみたの〜）
5. 5 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
6. 6 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
7. 7 1. ビジネス上の目的を明確に • 業務上のシステム作成は当然ながらビジネス ◦ 何のためのシステムなのか（＝誰にとっての価値なのか）が明確になっていないと後々困ることになる • 仕様が曖昧なのは仕方がないが、ここが曖昧なのはNG
8. 8 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
9. 9 2. システムの理想の姿を定める • ビジネス上の課題/目的と、考えうるユーザーストーリーから理想のシステムを定義する • その際には他社の類似システムも参照する • 仕様書がすでにあったとしても、それが目的に沿っていないことは珍しくない • このとき、ユーザーは純粋なユーザーだけでなく、全てのステークホルダーを意識する
10. 10 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
11. 11 3. パターンを使って課題を予測する • 理想の姿を求める時に異常系の確認が漏れる場合が多いので課題に焦点を当てて予想する • よくある課題はすでにある程度パターンがある（ex. エラーハンドリング、セキュリティ） • 自社事例（バグチケット）や社会的に問題になったバグ事例なども活用する
12. 12 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
13. 13 4. 理想と現実の間に課題はある • テスト工程（テスト対象は仕様書を含む） • 理想を頭に入れた状態でユーザーストーリーに沿ってチェックし問題がないか確認する • 理想と現実を比較すると、対応すべき課題が見えてくる
14. 14 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド （仮）
15. 15 5. 理想と現実で互いに歩み寄る • 課題をトリアージする（＝重篤度の決定） • 課題には「絶対に対応しなければならないもの」と「そうでないもの」の二種類がある • 絶対に対応しなければならないものは社会的信用に関わる場合もあるので現実を理想に寄せる • 全ての課題に対応していたら本来の目的を達成できない場合、理想を現実に寄せることも検討する（一部機能を切り落とす など）
16. 　 実践事例
17. 17 1. ビジネス上の目的を明確に • https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.files/01.pdf • 被扶養者（異動）届の扶養異動日の加入日・喪失日情報が不足しているので追加する。 • 最終的には電子申請を行えるようになるのが理想。電子申請はfreeeとして価値のあること。 • 書類が任意のタイミングで出力→提出できるようになるのも目的。本来ならそうあるべきなのでそれも価値のあること。
18. 18 2. システムの理想の姿を定める • 扶養異動日の加入日・喪失日情報が不足しているので追加する。 • 最終的な理想＝ユーザーストーリーは以下の通りになるはず ◦ 管理者が従業員の情報を収集して従業員画面から情報を保存し、最終的には書類を出力or電子申請を行う。今回は書 類の出力がゴール。 • 理想の姿＝正しい形の書類が出力できること、なので書類の記入ルールを隅から隅まで読む。一言一句見逃さない勢いで。 • https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.files/01.pdf • （ん？下の方に気になることが書いてあるな・・・気に留めておこう）
19. 19 3. パターンを使って課題を予測する • リスク洗い出し会を実施。影響範囲を確定。ヘルプページの修正が漏れる可能性が挙がる。 • 他に想像できるのは、書類のルール違反。書類データを後から変更した場合の処理でエラーなど。
20. 20 4. 理想と現実の間に課題はある • 当時のデザインを見ると、「該当」と「非該当」をごちゃ混ぜで出せる形になっていた。書類の注意文が頭に入っている状態だ と違和感があるので、質問。 • 結果としてその時点での仕様に考慮漏れがあったことが発覚。
21. 21 5. 理想と現実で互いに歩み寄る • この場合は「該当・非該当がごちゃ混ぜで書類が提出できない」という致命的な問題が発生しかねないので「絶対に対応しな ければならないもの」の分類。 • とはいえ、口を出すまでもなく修正（＝現実を理想に寄せる）の方向に話が行ったので質問後特にアクションはなし。この時点 で該当画面は未実装のため、実装の手戻りはなし。
22. 　 みんながテストのときに考えているこ とも聞きたいの〜
23. ご静聴ありがとうございました！