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

by freee

Slide 1

Slide 1 text

　テスト設計のとき何を考えてるの？ QA2年生が語ってみるの JaSST nano vol.16 2022.09.20

Slide 2

Slide 2 text

　 2 ● WEBエンジニアを経てQAエンジニアにジョブチェンジ（現在QA２年生） ● 2022年1月からfreeeにジョイン ● freeeでは人事労務を担当 ● 趣味は美味しいご飯を食べることとお酒を飲むこと ● 最近はReactを勉強中かいり QAエンジニア @QA_kairi プロフィール画像のトリミング方法

Slide 3

Slide 3 text

3 はじめにみんな、テスト設計のときどんなことを考えているの？

Slide 4

Slide 4 text

　私はこんなことを考えてテスト設計しているの！（メソッドにまとめてみたの〜）

Slide 5

Slide 5 text

5 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 6

Slide 6 text

6 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 7

Slide 7 text

7 1. ビジネス上の目的を明確に ● 業務上のシステム作成は当然ながらビジネス ○ 何のためのシステムなのか（＝誰にとっての価値なのか）が明確になっていないと後々困ることになる ● 仕様が曖昧なのは仕方がないが、ここが曖昧なのはNG

Slide 8

Slide 8 text

8 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 9

Slide 9 text

9 2. システムの理想の姿を定める ● ビジネス上の課題/目的と、考えうるユーザーストーリーから理想のシステムを定義する ● その際には他社の類似システムも参照する ● 仕様書がすでにあったとしても、それが目的に沿っていないことは珍しくない ● このとき、ユーザーは純粋なユーザーだけでなく、全てのステークホルダーを意識する

Slide 10

Slide 10 text

10 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 11

Slide 11 text

11 3. パターンを使って課題を予測する ● 理想の姿を求める時に異常系の確認が漏れる場合が多いので課題に焦点を当てて予想する ● よくある課題はすでにある程度パターンがある（ex. エラーハンドリング、セキュリティ） ● 自社事例（バグチケット）や社会的に問題になったバグ事例なども活用する

Slide 12

Slide 12 text

12 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 13

Slide 13 text

13 4. 理想と現実の間に課題はある ● テスト工程（テスト対象は仕様書を含む） ● 理想を頭に入れた状態でユーザーストーリーに沿ってチェックし問題がないか確認する ● 理想と現実を比較すると、対応すべき課題が見えてくる

Slide 14

Slide 14 text

14 01　ビジネス上の目的を明確に 02　システムの理想の姿を定める 03　パターンを使って課題を予測する 04　理想と現実の間に課題はある 05　理想と現実で互いに歩み寄る As-Is To-Be テストメソッド（仮）

Slide 15

Slide 15 text

15 5. 理想と現実で互いに歩み寄る ● 課題をトリアージする（＝重篤度の決定） ● 課題には「絶対に対応しなければならないもの」と「そうでないもの」の二種類がある ● 絶対に対応しなければならないものは社会的信用に関わる場合もあるので現実を理想に寄せる ● 全ての課題に対応していたら本来の目的を達成できない場合、理想を現実に寄せることも検討する（一部機能を切り落とすなど）

Slide 16

Slide 16 text

　実践事例

Slide 17

Slide 17 text

17 1. ビジネス上の目的を明確に ● https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.ﬁles/01.pdf ● 被扶養者（異動）届の扶養異動日の加入日・喪失日情報が不足しているので追加する。 ● 最終的には電子申請を行えるようになるのが理想。電子申請はfreeeとして価値のあること。 ● 書類が任意のタイミングで出力→提出できるようになるのも目的。本来ならそうあるべきなのでそれも価値のあること。

Slide 18

Slide 18 text

18 2. システムの理想の姿を定める ● 扶養異動日の加入日・喪失日情報が不足しているので追加する。 ● 最終的な理想＝ユーザーストーリーは以下の通りになるはず ○ 管理者が従業員の情報を収集して従業員画面から情報を保存し、最終的には書類を出力or電子申請を行う。今回は書類の出力がゴール。 ● 理想の姿＝正しい形の書類が出力できること、なので書類の記入ルールを隅から隅まで読む。一言一句見逃さない勢いで。 ● https://www.nenkin.go.jp/service/kounen/todokesho/hihokensha/20141224.ﬁles/01.pdf ● （ん？下の方に気になることが書いてあるな・・・気に留めておこう）

Slide 19

Slide 19 text

19 3. パターンを使って課題を予測する ● リスク洗い出し会を実施。影響範囲を確定。ヘルプページの修正が漏れる可能性が挙がる。 ● 他に想像できるのは、書類のルール違反。書類データを後から変更した場合の処理でエラーなど。

Slide 20

Slide 20 text

20 4. 理想と現実の間に課題はある ● 当時のデザインを見ると、「該当」と「非該当」をごちゃ混ぜで出せる形になっていた。書類の注意文が頭に入っている状態だと違和感があるので、質問。 ● 結果としてその時点での仕様に考慮漏れがあったことが発覚。

Slide 21

Slide 21 text

21 5. 理想と現実で互いに歩み寄る ● この場合は「該当・非該当がごちゃ混ぜで書類が提出できない」という致命的な問題が発生しかねないので「絶対に対応しなければならないもの」の分類。 ● とはいえ、口を出すまでもなく修正（＝現実を理想に寄せる）の方向に話が行ったので質問後特にアクションはなし。この時点で該当画面は未実装のため、実装の手戻りはなし。