概要
これまでやってきたテスト計画についてまとめたいと思います。
テスト計画の作業内容を知ってもらうことで、誰でもテスト計画の作業ができるようになれたらなと。
ゴール
- テスト計画についてわかる
- テスト計画の作業がわかる
テスト計画とは
テスト計画とは、テストする対象を把握した上でテスト漏れが出ないようにどんなテストが必要なのか計画すること。
そのため、テストの種類だけでなくテストする対象の設計を理解して、必要なテストの洗い出しとそれにかかるテストコストを可視化して共有することなどが問われると思います。
また、テストケースを作る必要がある場合、テスト要件の洗い出しも一緒にやっておくとテストケース作りがスムーズになります。
次の記事は、基礎と応用の知識がまとめられているので把握しておいてください。
前提知識
誰でもテスト計画の作業ができるようにしたいものの作業条件があります。
例えば、ECサイトにレビューコメントの機能追加する新機能をテスト計画するとします。
ECサイトは、ユーザーが扱うサービス画面ページとお店側が扱う管理画面ページの２種類あり、それぞれ別の機能を提供しています。
Wordpressで例えると、https://DOMAIN がサービス画面で https://DOMAIN/admin が管理画面でどちらにもそれぞれ機能提供できるように開発すると思います。
この新機能を作るにあたって新機能のテストとデグレーション防止のリグレッションテストがサービス画面と管理画面の両方で必要になります。
また、レビューコメント機能がYouTubeのコメント機能と似たような要件だと、作成・編集・削除・返信・禁止ワードなどの機能テストだけでなく、公開・非公開やユーザー権限によって制御される機能で影響する要因などテストだけでなく、プロダクト全体の品質を懸念する必要が出てきます。
このように必要な前提知識があり、以下のどちらかの条件が考えられます。
- ユーザー以上にプロダクトを熟知しているPO/PMやテスター/デバッガーなど（もしかしたらCSも入るかも？）
- エンジニアリングのスキルがある
テストを計画する以上、サービス全体を把握していたりどんな設計で作られているのかなどの理解がないと最適なテストを洗い出すことが非常に難しいと思います。
そのため、冒頭に「誰でもテスト計画の作業ができる」と言ったものの正確には、「（プロダクト全体を熟知している又はエンジニアスキルを持っている人なら）誰でもテスト計画の作業ができる」となります。
ワークフロー
QAは、要件定義や設計から参加することで後半のテストを最適化することができます。
ただし、アジャイルをやっていると予期せぬ変更が発生して、要件や設計が開発してても途中で変わって作り直しが発生することが珍しくない中、QAがどこのタイミングで参加するのかとても難しいです。
だとしても、予期せぬ変更で発生しているコミュニケーションの場に参加すればいいですし、できてから共有してもらうようにしてエンジニアが作り直し中に仕様や設計を把握しつつ、二人三脚で開発とQAが同時並行して進められればいいと思います。
テスト計画は、次のような段取りで作業していきます。
- 設計（中盤〜後半）または開発途中などから参加して仕様や開発状況を把握する
- 1をもとにテスト要件を洗い出す
- 2を開発やQAのメンバーに共有してレビュー
- 3をもとにリソースやスケジュールなどを決めてテストコストを算出する
- 4を開発やQAのメンバーに共有してレビュー
すでに完成しているものがテスト依頼がきたとしても1から順番に作業することになります。
テスト計画は、主にテスト要件とテストコストの洗い出しがメインとなり、後からテスト漏れやコスト大にならないように必ずメンバー共有してレビューを入れてテスト計画の質を上げるようにしましょう。
テスト要件
先ほどの条件が必要になってくるテスト要件の洗い出し作業ですが、例であげたECサイトのレビューコメント機能の場合、例えば次のようなテスト要件を洗い出せると思います。
- レビューコメント作成
- 入力フォームページ遷移、各バリデーション、各ボタン、作成後の挙動、作成日時の表示
- レビューコメント編集
- 入力フォームページ遷移（またはレビューコメントのタグ内で切り替えなど）、各バリデーション、各ボタン、編集後の挙動、編集日時の表示
- レビューコメント削除
- 削除確認ダイアログ、各ボタン、削除後の挙動
- 禁止ワード
- バリデーションの他に禁止ワードのトラッキング、禁止ワードを使ったユーザーとその履歴のログ
- 運用削除
- 禁止ワードでは防げない文章を把握できる何らかの機能、不適切な文章は管理画面上などから削除
Amazonのレビュー機能では、レビューをした直後すぐにはレビュー上に反映されず、運用側でレビュー内容が適切なものか確認されて問題なければ数時間後にレビューが反映されるようになっています。
このような仕様の場合は、上記にテスト要件にさらに追加の要件が出ますし、運用サイドともコミュニケーションを取ってテスト要件を洗い出してレビューしてもらうことになると思います。
また、あくまでも例えになります。
上記のテスト要件以外にもバリデーションの種類や禁止ワードの運用など開発メンバーと一緒に考える要件が多く、先ほども話した通り完成後にテスト依頼きてから作業になるとテスト期間が逼迫することになるので、開発と同時並行して動けるかによってリリース前テストを最小限のコストできると思います。
テストコスト
全体のテストコストで考えると、テスト計画の段階からカウントすることになります。
リリース前テストのコストだけ算出することもあるので、今回は、テスト計画後のテストコストについて話します。
- テストケース作り
- テスト準備
- テスト
- フィードバック
- 再テスト
- インシデント対応
4以降の作業は、予測できないコストになるため無視しますが、リリース前で発生することなので仮の数値を決めて概算で出すことがあります。
テストケース作りは、E2Eテストのサービスを使っているとシナリオ登録になり、従来のやり方だとExcelまたはスプレッドシートなどに洗い出したテスト要件を入れて、そこから期待値を言語化していくことになります。
テスト準備では、どんなテストデータやテストアカウント、テストする環境（アプリやサーバなど）を洗い出したテスト要件をもとに準備するのか決めて用意することになります。
特に1~3の工程でどのくらいリソースが必要になるのか可視化していきますが、テストコストは、最終的に管理職層（スクラムだとPOやスクラムマスターなど）も把握する情報なのでいい加減な計算ができないので注意しましょう。