自分たちのテスト設計プロセスを作ろう

開発者でも良いテスト設計が行えるようにするため、私が所属する組織の状況に合わせたテスト設計プロセスを明文化しました。
本資料では、テスト設計プロセスを作る上で考えたことを発表しています。

Transcript

1. 自分たちのテスト設計プロセスを 作ろう 2022.12.12 QA Test Talk Vol.2 コミューン株式会社 QA　須賀康行
2. 自己紹介 • 経歴 ◦ Web系のQA（主にテストエンジニア系）を約 10年 ▪ 第三者検証（1年半） → 医療系事業会社（7年半） → 現職（2022年1月〜） ◦ 業務経験は、テスト設計、テスト実施、 Selenium、QAチームマネージャーなど • コミューン株式会社の業務内容（2022年12月現在） ◦ QAチームのマネージャー ◦ プレイヤーとしてネイティブアプリ開発のテスト設計・テスト実施 ▪ （以前はWebアプリケーション開発のテスト設計レビューを実施） • 電車と仮面ライダーが大好きな小学一年生の息子がいます
3. 本日の発表のゴール 私の考えた最強のテスト設計プロセスを使ってほしい みなさんが自分たちのテスト設計プロセスを作るきっかけになる ※　諸々検討した上で他の方のプロセスをそのまま利用するのは問題ありません
4. 本日の発表内容 • 本発表における前提知識の共有 ◦ 本発表における「テスト設計プロセス」の定義 ◦ 本発表に関係する開発組織の紹介 • テスト設計プロセスを作るための準備を紹介 ◦ テスト設計プロセス作成の目的（ゴール）を決める ◦ 他の人の事例を調査する • テスト設計プロセスを作る際に考えたことを紹介 ◦ 目的と自社のコンテキストにあったテスト設計プロセスを作る
5. 本日の発表における「テスト設計プロセス」の定義 http://www.aster.or.jp/business/contest/tutorial_chibicon.html 「テスト設計チュートリアル ちびこん編資料」より引用 どのような条件でテストするか を決めるまでのプロセスが対象 テストスクリプト（テスト手順、期 待結果等を記載したもの）作成 は対象外
6. 本発表に関係する開発組織の紹介 • Webアプリケーションの開発組織（2022年12月現在） ◦ 5人以下の開発者が所属する小規模な開発チームが 3チーム　※一部例外あり ◦ 短い期間に細かくリリースする。スクラム、または、スクラムに類似したスタイル ◦ 同一プロダクトに対して改修を行うため、既存機能・データを考慮した改修が必要 ◦ テスト設計、テスト実施は開発者自身が行い、 QAはテスト設計レビューを行う ◦ 将来的には、QAによるテスト設計レビューが不要な体制を目指す • プロダクト（commmune） ◦ ノーコードでオンラインの顧客コミュニティ（ Web、ネイティブアプリ）を構築する SaaS ◦ オンラインの顧客コミュニティとは、企業と顧客・顧客と顧客の間で、企業の製品に関して情報交換 や交流などを行うことを目的とした SNSのようなイメージ
7. テスト設計プロセスを 作るための準備
8. テスト設計プロセス作成の目的を決める • Version 1のゴール ◦ 開発者が60点以上のテスト設計を行える状態にする。なるべく早くその状態を目指す。 ▪ 『テスト設計難易度が「中」までの機能テスト』（後述）のテスト漏れをなくす • 単一画面に対する機能テストをうまく行えるようにする ◦ テスト設計に必要な工数を増やしすぎない • ゴール達成のために必要な要件 ◦ QA未経験の人が容易に習得できるプロセスにする ◦ 属人化しにくいプロセスにする ▪ ある程度機械的にテストする条件を洗い出せる ▪ 経験や記憶になるべく頼らない ◦ 目的達成のために必要最低限のプロセスにする
9. テスト設計プロセス作成の目的を決める テストタイプはhttps://www.qbook.jp/academy/curriculum/0002/lessons/6664-2より一部引用 よく発生したテスト漏れの種類 難易度 テストタイプの例 テスト対象の漏れ 低 機能テスト 1つの画面上の操作における前提条件や入力パターンの漏れ 中〜高 機能テスト 複数の画面・機能の操作を合わせた動作確認の漏れ 高 シナリオテスト 性能面の動作確認漏れ 中〜高 性能テスト 仕様を変更していない既存機能が壊れていないことの動作確 認漏れ 高 リグレッションテスト
10. 他の人の事例を調査する（巨人の肩に立つ） • 主な調査対象　※詳細は割愛 ◦ テスト設計チュートリアル ▪ https://www.aster.or.jp/testcontest/tutorial.html ◦ ゆもつよメソッド（JaSST’21 Tohoku） ▪ https://www.jasst.jp/symposium/jasst21tohoku/report.html ◦ HAYST法（JaSST'18 Tohoku） ▪ https://www.jasst.jp/symposium/jasst18tohoku/report.html 　　　※　関係者の皆様、ありがとうございます！
11. 他の人の事例の調査結果のまとめ • 他の人のプロセスを統合して抽象的にまとめる　※私個人の解釈 ◦ 機能の目的や使われ方などを洗い出す ◦ テスト対象を洗い出す ◦ テストする条件に関する情報を洗い出す ◦ テストすべきテスト観点（テストすべきこと。テストする条件を抽象化したもの）を決める ◦ テスト観点を整理して構造化する ◦ 各テスト観点に対してどこまでテストするかを決める ◦ テストする条件を具体化する • これらを自分の組織に合わせたものにしていく ◦ 特に既存機能の改修をする際の観点は独自で考えた
12. テスト設計プロセスを 作る際に考えたことを紹介
13. 機能の目的や使われ方などを洗い出す • テスト設計時ではなく仕様検討時に洗い出すべきだと考えたので、今回のテスト設 計プロセスでは対象外とした • テスト設計プロセスでは、機能の目的や使われ方が明らかになっている前提で進 める ◦ もちろん、後工程で気づきがある場合もある
14. テスト対象を洗い出す • 画面がある機能は、画面＞部品の階層でテスト対象を洗い出すようにした ◦ 理由　 ▪ テスト対象自体のテスト漏れを防ぎたい • 画面という区切りがあった方が、テスト対象のスコープがわかりやすそう ◦ テスト漏れが発生しにくそう ▪ 1画面＝大きな1機能になっていることが多い ◦ 考えられるデメリット ▪ 画面の視点に思考が引っ張られて内部構造視点のテストが漏れる可能性がある ▪ テストスクリプトが細かくなりがち ▪ 複数画面をまたがる機能はどう表現する？
15. テスト対象を洗い出す • テスト対象を洗い出した例（ログイン画面） ◦ ロゴ（「sample」部分） ◦ ページ名（「ログインする」部分） ◦ 「メールアドレス」の入力フォーム ◦ 「パスワード」の入力フォーム ◦ 「ログインする」ボタン ◦ 「パスワードを忘れた場合」リンク
16. テストする条件に関する情報を洗い出す • HAYST法では仕様書に書いていない組み合わ せのテスト（無則）の組み合わせを洗い出すた めにラルフチャートを用いている • 詳細な仕様書を管理していない、自分が触った ことがない機能を改修することが多い現場で、 既存機能のことを配慮したテストを行う際に有 用そうだったので参考にした • テストが漏れがちな観点を独自に枠組みに追 加 ◦ 操作するユーザーの属性 　右画像は以下より引用 　https://www.jasst.jp/symposium/jasst18tohoku/pdf/S3-3-3.pdf
17. テストする条件に関する情報を洗い出す • 情報を洗い出す枠組み ◦ テスト対象を操作する人 ◦ テスト対象に対して入力するもの ◦ テスト対象が出力するもの　※　テストスクリプトにおける期待結果にもなる ◦ テスト対象が出力内容を決めるためのロジック ◦ テスト対象が参照・更新するデータ
18. テストする条件に関する情報を洗い出す • 情報を洗い出す枠組みを用いた例 ◦ テスト対象を操作する人 ▪ 管理者、一般ユーザー ◦ テスト対象に対して入力するもの ▪ 文字列、クリック ◦ テスト対象が出力するもの ▪ エラー表示、Cookie、画面遷移、ログイン履歴 ◦ テスト対象が出力内容を決めるためのロジック ▪ ID/PWのチェック ▪ クエリパラメータに応じた画面遷移先 ◦ テスト対象が参照・更新するデータ ▪ ユーザ情報（ID、PW、退会の有無、ログイン履歴） ▪ ブラウザのURL ▪ Cookie ※　本来はテスト対象ごとに枠組みがツリー構造になる予定
19. テストすべきテスト観点を決める • リスクベースドテストの考え方を参考に、テストすべきテスト観点を決める ◦ 「リスク = 不具合発生時の影響度 x 不具合発生確率」と考え、リスクの高低でテストの要否を考え る ▪ 新規機能は、基本的に不具合発生確率が一定以上あるので全体的にテストを実施する ▪ 既存機能の振る舞いを改修する場合は、リスクを考慮してテストの要否を決める • 理由は、可能ならば不要なテストを減らしたいため ◦ リスクベースドテストの参考資料 ▪ https://qiita.com/freddiefujiwara/items/44882bb35e000d9cb546 ▪ https://www.nttdata.com/jp/ja/data-insight/2016/071401/
20. テストすべきテスト観点を決める • 2要素認証追加時にリスクが高いもの ◦ テスト対象を操作する人 ▪ 管理者、一般ユーザー ◦ テスト対象に対して入力するもの ▪ 文字列、クリック ◦ テスト対象が出力するもの ▪ Cookie、画面遷移、ログイン履歴（ DB更新） ◦ テスト対象が出力内容を決めるためのロジック ▪ ID/PWのチェック ▪ クエリパラメータに応じた画面遷移先 ◦ テスト対象が参照・更新するデータ ▪ ユーザ情報（ID、PW、退会の有無、ログイン履歴） ▪ ブラウザのURL ▪ Cookie 2要素認証に関する処理は ID/PWの 認証が成功した後に実行される。 そのため、テストすべきテスト観点 は、認証処理が成功した後の振る舞 い（赤字）に限定される。 テストすべきテスト観点は、赤字のも のに関するテスト観点
21. テスト観点を整理して構造化する • 今回は特にルールを決めないことにした ◦ 小規模な開発を繰り返す前提なので、整理の仕方をルール化しなくてもテスト観点の全体像を俯瞰 できると考えたため ◦ 運用してみた結果、将来的には何かルールを考える可能性はある
22. 各テスト観点に対してどこまでテストするかを決める • リスクベースドテストの考え方や発生しそうな不具合から網羅基準を決める ◦ 発生しそうな不具合が特定の条件に限定されそうであれば、代表値をテストする ▪ 特に既存機能の振る舞いを変更する改修の場合に考慮する ◦ 上記以外で、リスクが高ければ網羅度の高い網羅基準を選ぶ ▪ 「テスト設計チュートリアルちびこん編」にテスト観点の種類（テストモデル）に応じた網羅基準 の説明があるので、そちらのアイデアを参考にした • 例） ◦ 数値などの範囲タイプ（代表値網羅、境界値網羅、全網羅） ◦ ブラウザの種類などの一覧タイプ（代表値網羅、境界値網羅、全網羅）
23. 各テスト観点に対してどこまでテストするかを決める • 不具合が発生しそうな条件を考慮した例 ◦ テスト対象を操作する人 ▪ 管理者、一般ユーザー ◦ テスト対象に対して入力するもの ▪ 文字列、クリック ◦ テスト対象が出力するもの ▪ Cookie、画面遷移、ログイン履歴（ DB更新） ◦ テスト対象が出力内容を決めるためのロジック ▪ ID/PWのチェック ▪ クエリパラメータに応じた画面遷移先 ◦ テスト対象が参照・更新するデータ ▪ ユーザ情報（ID、PW、退会の有無、ログイン履歴） ▪ ブラウザのURL ▪ Cookie 不具合が発生する確率が高いのは 複雑なクエリパラメータの時で、単純 なクエリパラメータの時だけ不具合が 発生する可能性は低い。 そのため、複雑なクエリパラメータだ けテストを実施する
24. テストする条件を具体化する • テスト技法を用いるなどしてテストする条件を具体化する • テスト観点に関するナレッジを貯めていき、参照できるようにすることである程度の 属人化を防ぐ（予定） ◦ 汎用性のあるテスト観点、プロダクト固有の既存機能・データに関するテスト観点と具体的なテスト する条件を蓄積していく。この資料は他の工程でも用いて良い ▪ 例）テキスト入力 • 文字種、文字数、未入力、など ▪ 例）URLのクエリパラメータ • なし、あり（&が0個、&が1個、&が複数、URIエンコードされたもの） ▪ 例）ユーザー情報 • 会員種別（一般、管理者、退会者、ミュートした人）
25. 他の人の事例の特徴の中で取り入れなかったもの • テスト設計チュートリアル（≒VSTeP）のテストコンテナなどの図 ◦ 規模の大きい開発は少なく、図を作成しなくても全体像を俯瞰しやすいと考えたため • ゆもつよメソッドの論理的機能構造の利用・テストカテゴリの作成 ◦ 論理的機能構造が有効な事例の割合が少なそうに感じたため、現段階では省略 ◦ 私自身の理解が不足しており、他の人にすぐに身につけてもらうことが難しいため • HAYST法の6W2H ◦ テスト設計時よりも仕様策定時などの前工程で用いたいため
26. テスト設計プロセス作成の成果 • QA未経験からQAに転向した方に試した結果、2ヶ月でほぼ一人前に ◦ プロセスの文書化と説明、私自身によるデモを数回、ペアテスト設計やレビューを 2ヶ月実施 ◦ ※　正確には、本発表で紹介した Version1の前に作成した叩き台の成果です • 開発者の方でも成果が出るかは、2023年1月以降に検証予定
27. まとめ • テスト設計プロセスを作るためにやったこと ◦ テスト設計プロセスを作る目的を明確にする ◦ 同じ課題の解決方法を考えた他の人の事例を調査する ◦ 自分たちと他の人の事例のコンテキストの違いを理解する ◦ テスト設計プロセスを作る目的や自分たちのコンテキストにあったプロセスを作る • みなさんもぜひ自分たちのテスト設計プロセスを作ってみてください！ 　※　作成したテスト設計プロセス自体の説明は、近日弊社のブログで公開予定です
28. 参考資料 • テスト設計チュートリアル ◦ https://www.aster.or.jp/testcontest/tutorial.html • ゆもつよメソッド（JaSST’21 Tohoku） ◦ https://www.jasst.jp/symposium/jasst21tohoku/report.html • HAYST法（JaSST'18 Tohoku） ◦ https://www.jasst.jp/symposium/jasst18tohoku/report.html
29. 参考資料 • 実践リスクベーステスト-PRISMAメソッド-というpdfを原著者から翻訳と公開に関し て許可をとって翻訳してみました ◦ https://qiita.com/freddiefujiwara/items/44882bb35e000d9cb546 • リスクベースドテストの活用でビジネススピードを上げる ◦ https://www.nttdata.com/jp/ja/data-insight/2016/071401/ • 「テスト計画」テンプレート 作成方法を解説（29119規格対応） ◦ https://www.qbook.jp/academy/curriculum/0002/lessons/6664-2/