こんにちは！ QAを担当している青柳です。
アソビューではプロダクトの品質を向上させるために、品質管理系のドキュメントを有効活用しています。 前回の記事では質問リストの内容をご紹介させていただきましたが、この記事では他のドキュメントについてご紹介できればと思います！
ドキュメント一覧
プロジェクトの規模、内容によって作成するドキュメントは異なりますが、基本的には以下の一覧にあるものを作成するケースが多いです。
- 品質計画書
- 質問リスト
- テストケース ←今回ご紹介するドキュメント
- 進捗管理表
- スケジュール表
アソビューにおけるテストケース
QAで活用しているテストケースは、基本的にはGoogleスプレッドシートで作成しています。
テストケースを用意する目的の一つは、テストすべき内容の見落とし、抜け漏れを未然に防ぐことです。仕様書に基づくテスト（正常系・異常系）だけではなく、ユーザーシナリオに基づくテストもテストケースとして作成しています。
またテストをどのように行ったか、誰が見ても分かるように明確化しておくこともテストケースを用意する目的の一つです。テスト後にバグが発見された場合に、どのようなテストを行ったか見直すこともテストケースがあると容易に行えます。
プロジェクトの規模・テストの粒度によってカスタマイズをしたりしますが基本的には上記の内容で作成します。
テストケースの項目一覧
- プロダクト
- 大項目
- 中項目
- 小項目
- 条件
- テスト項目
- 確認日
- テスト結果（OK / NG / 保留）
- 確認者
- 備考
テストケースのテンプレートです。
テストケース作成時の注意点
- テストは誰がやっても同じ内容になるよう記述する
- テスト項目とテスト結果は1対1になるように記載
抽象的・曖昧な表現では、テスト設計の担当者とテスト実行者で解釈が異なってしまうことが起こり得ます。誤った解釈のままテストが行われ、テスト結果NGとして報告されるべきケースが結果OKとして報告されてしまい、不具合を見逃してしまう原因にも繋がります。また、余計なコミュニケーションが発生することを防ぐために必要な注意点となってきます。
テスト項目とテスト結果を1対1で記載する理由は、複数のテスト項目が含まれているとき、項目のうち1つでも結果NGがあれば該当のテスト項目は結果NGとなってしまうためです。項目数が増えてしまうデメリットもありますが、テスト結果OK・NGを明確にするためにも意識して作成している点となります。
実際の活用事例
日時指定チケットのプロジェクトでQA実施時に使用したときのテストケースです。
ダイレクト導線*からの各種テストについて記載しています。それぞれの項目は以下の観点となっています。
*ダイレクト導線：パートナー施設、アクティビティパートナーが直接所有するチャネルでの販売を指す
- 大項目：テスト対象の画面タイトル（機能名）
- 中項目：機能・項目
- 小項目：操作・動作
- 条件：結果にブレが出ないようにテストの前提となる条件は必ず記載
- テスト項目：テスト項目は必ず1つになるように記載
今後の展望
実際に活用してみると、この型で作りやすいテストケースもあれば作り方を工夫しなければいけない内容もあったりしました。
決済手段多様化プロジェクトでは、チケットを購入するための条件が複数ありサンプルのテストケースではパッと理解できる内容で記載することが難しかったため、テストケース上では1項目（テスト項目に別シートのリンクを記載）として、別シートで以下のようなマトリクスを用意しました。
効率良くテストケースを作成できるようにカスタマイズ可能なフォーマットの準備も進めなければと思っています。
また、現在の形で完成系ではないので、時間を見つけて集計ページ・品質分析シート(仮)の作成を進めています。品質分析シートでは、テスト実施状況・障害一覧・障害傾向・バグ密度などの内容を盛り込む予定です。
最後に
アソビューでは、より良いプロダクトを世の中に届けられるよう一緒に挑戦していくエンジニアを募集しています。カジュアル面談もやっていますので、気になった方はぜひエントリーください！お待ちしております。
