はじめに
みなさんテスト計画書、作っていますか？
そして、テスト活動において有効に活用することができていますか？
テスト計画書とは、達成すべきテストの目的、およびそれらを達成するための手段とスケジュールを記述した、テスト計画およびテスト管理のための文書です。
テストの対象、リスクと対策、完了基準、使用するテスト技法、リソースとスケジュールなどを記載します。
過去に私がテスト計画書を作成した時は、フォーマットに沿ってとりあえず作ってみる程度で、その意義をしっかりとは理解できていませんでした。
実際にプロジェクトが始まって、上司や開発チームから報告を求められたり、自身でテスト活動の分析をしていく中で、事前に定義、認識合わせしておけば良かったなあと思う内容が多くありました。
最近またテスト計画書を作る機会があったため、ISO/IEC/IEEE 29119-3で標準となっている内容を踏まえつつ、自身の経験からゲームテストで特に有用だと感じる内容をまとめてみました。
補足
ISO/IEC/IEEEは、ISO・IEC・IEEEが共同で策定する国際技術標準の総称で、ソフトウェアやシステム工学の標準を統合的に管理する枠組みです。
ISO/IEC/IEEE 29119-3は、その中でソフトウェアテストにおけるテスト文書（ドキュメント）の標準構成と内容を定義した規格です。
テスト計画書、テスト設計書、テストケース仕様、テスト報告書などの標準テンプレートと記載要素を規定しています。
前提として私の所属する組織では以下の様なQA体制なので、開発会社のテストエンジニア、テスト管理者目線での記事となっています。
- QAチームは開発チームとは別組織
- テストベンダーの協力会社様も含んだQAチーム体制
29119-3の主要項目の重要度
29119−3でテスト計画書に記載するべきとされている主要な項目をベースに主観によるゲームQAでの重要度をつけてみました。
| 項目 | ゲームQAでの重要度 | 所感 |
|---|---|---|
| テストの目的・背景 | 高 | 仕様通りに動作することに加えてターゲットユーザーの「面白さ/体験」を担保することを目的に含めるべき |
| テストアイテム | 低 | 基本的にゲーム全体の機能、アセットが対象になり、追加や削除が起きやすいので計画段階での詳細化は必要ないと感じる |
| リスクと対策 | 高 | プロダクトの機能的なリスクはもちろんだが、ゲームには倫理表現など様々なリスクが存在する |
| 開始/終了基準 | 中 | 開発側なので責任分界の重要度は低い終了条件は品質の合意基準になるため必要 |
| 中止・再開基準 | 低 | 実際に止まることはあまりないが、中止になる様な状況を避けて欲しいことを開発チームに伝えるには良いと思う |
| テストレベル | 低 | ウォーターフォールでないため適用しづらい |
| テストタイプ | 中 | ゲームでは非機能要件を詳細化、重視したい |
| 使用するテスト技法 | 低 | 実務上あまり定義する必要を感じない |
| テスト成果物 | 中 | 報告すべき内容や収集するメトリクスに合わせて定義する |
| 収集するメトリクス | 高 | 流動的なプロダクトスケジュールに対して、進捗/品質状況と効率を可視化して素早く対応することは必須 |
| テスト環境 | 高 | モバイル・PCゲームでは端末のスペック、OSなどの要件が重要 |
| テスト体制・役割 | 中 | 協力会社も含む体制なので役割は明確化するべき |
| スケジュール | 中 | スケジュールの重要度は変わらない |
重要ポイントの詳細
テスト計画の目的
「欠陥検出」「リスク低減」などに加えてゲーム自体の面白さや、快適性を高めることも重要です。
例
- ユーザー不利益のある不具合を検知し、リリース時の重大障害を0件にする
- 推奨/最低スペック端末でのパフォーマンス基準を満たすことを確認する
- 「遊びやすさ」や「理解しやすさ」に関する課題をフィードバックし、ユーザ評価の向上を目指す
- 運営時の長期リスク（ゲームバランス、パラメータ設定）を可能な限り低減する
リスクと対策
ゲーム特有のリスクが多いため特に重要です。
例
- 配信プラットフォームによる審査リジェクトリスク
- ゲーム内表現の炎上リスク
- ゲームバランスの調整不足によるユーザー離脱リスク
- アプリ内課金アイテムの景表法違反リスク
収集するメトリクス
29119では必須とされていないと思いますが、経験上は計画段階で定義することを必須としたい内容です。
特にQAとして確認すべき数値をチームメンバーに認識してもらうためにも定義しておきたいです。
例
- テストケースバーンダウンチャート
- デイリー不具合起票状況
- 機能・優先度別不具合ダッシュボード
- 初回テスト合格率
- テスト実行生産性
テスト環境
これは特にモバイル・PC向けゲームでは動作させる端末に起因する不具合が見つかることが多く、
様々な端末を網羅的にテストする必要があり、どこまで対応するのかを開発チームとも合意しておかなければなりません。
例
- OSとバージョン
- CPU（SoC)
- GPU
- RAM容量
- 画面解像度
作成してみた手応え
今回のテスト計画書を作成した過程ですでにいくつかのポジティブな変化を感じています。
開発チームと計画書をベースに会話することで、QAはどこまで責任を持つのか、開発は何を協力すべきか、という、曖昧になりがちな境界線が明確になりました。 テスト目的に遊びやすさの観点や、バランスチェックの観点を加えることで、バグ潰しだけでなく、開発・QAがひとつのチームとしてプロダクトの品質に向き合う目線が揃えられると思います。
個人的に特に「収集するメトリクス」の定義は重要だと感じます。 必要なデータを事前に定義することで、各種フォーマットとフローを整備し、ダッシュボードやデイリーで通知する仕組みを作ることができています。テストを開始して、必要に迫られてからこういった仕組みを用意するのは大変ですので、効率化の効果も大きいです。
まとめ
テスト計画書を作成することは、形式的な作業ではなく、目指すべき品質や価値観の共有、そして変化への対応力を高めるための重要な準備作業であると感じました。
特にゲーム開発においては、ユーザー体験の価値向上や、高速で柔軟な開発サイクルへの対応が求められます。テスト計画書は、これらの要求に応えるためのQAの羅針盤となり得ます。
ISO/IEC/IEEE 29119-3のような標準規格は、テスト文書の「ひな形」として非常に有用ですが、その中から自身のプロジェクトやチームにとって何が重要かを考え、調整を加えて活用することで、さらにその価値を高めることができると思います。