#はじめに
今年2本目の記事は、モバイルゲーム開発におけるブラックボックステストの計画について記載していきたいと思います。
テストプロジェクトを開始する上で、テスト計画のプロセスはとても重要です。
これはゲーム開発においても同様だと私は考えています。
本記事では、テスト計画の標準的なフォーマットをベースに、モバイルゲームの新規開発時の流れを説明します。
特に重要だと考えるポイントにフォーカスしていきますので、テスト計画作成の一助になれば幸いです。
#テスト計画とは
ソフトウェアテストのプロセスの一つで、テストの目的と達成するための手段、スケジュールなどを策定するフェーズです。
テスト計画は、開発チームとゴールやアプローチのすり合わせでも活用できますが、テストチーム内の認識あわせにおいても重要です。
前回の記事で紹介した「知識ゼロから学ぶソフトウェアテスト」でも、テスト計画はテストチームにとって憲法みたいなものと記載されています。
テスト計画の詳細については、以下の記事が参考になると思いますのでご参照ください。
[参考記事]
・テスト計画を立てる目的
https://qiita.com/enoyuu/items/97ca24ad1493b47b50cd
・テストプロセスの流れと各プロセスの実施内容
https://www.qbook.jp/column/20190710_706.html
##テスト計画の標準
テスト計画をはじめて作成する場合、IEEE829のフォーマットを参考にすると良いです(JSTQBでも参考にしています)。
このフォーマットでは、テスト計画で考慮すべき要素が盛り込まれているため、弊社でもテスト計画書のベースにしています。
そのままだと抽象的すぎたり、過不足がある可能性があるので、現場にあわせてカスタマイズして使うことをおすすめします。
大事なのは組織として共通の枠組みを持つことです。
担当者が思い思いに作っていると抜け漏れや読みづらさにもつながるので、組織でテスト計画の標準となるフォーマットを用意しましょう。
#モバイルゲーム開発におけるテスト計画
モバイルゲーム開発では、仕様の変更が多発したり、未確定のままリリーススケジュールが近づいてくるケースが少なからず発生します。
上述したフォーマットに沿ってテスト計画を作成した場合、作成時点で不明瞭になっている箇所が多々あります。
だからといって作成しないままテストを進めてしまうと場当たり的な対応で工数が膨らむことや作業の抜け漏れが出たりします。
以下のポイントを意識しつつ、まずはテストチーム内であいまいな箇所がどこなのかと、いつまでにその情報がないとスケジュールに影響するかを認識しておくことが重要です。
[前提]
- 作成時に不明瞭な箇所があること
- 仕様が開発中に変更されること
[ポイント]
- いつまでに何をすべきかは明確にしておく
- 不明な箇所がいつクリアになるか認識をあわせておく
- テスト計画の内容を定期的に見直す
##テスト計画の流れ
テスト計画は以下の流れで進めます。
- 開発チームから開発概要(スケジュールや仕様など)を共有してもらう
- 開発概要にあわせて作成タイミングを決める
- テスト計画フォーマットに沿ってテスト計画を作成する
- テストチーム内でテスト計画のレビューをする
- 開発チームに共有する
※以降、状況にあわせてテスト計画の見直す
##作成タイミング
早ければ早いほど良い、というわけでもありません。
弊社では、大枠の仕様が決まってモック版のようにある程度動作するタイミング以降に開発チームと連携し始めます。
そこで開発スケジュールを確認し、テストのスケジュールを連動させていきます。
機能仕様がおおよそ確定したタイミングでテスト計画を進めると良いですが、仕様確定タイミングが不明瞭な場合は
全機能実装されるタイミングで、テスト実行が本格化するので、そこから逆算してテスト設計、テスト計画のタイミングを決定します。
[テストスケジュールのイメージ]
##作成内容
弊社では関係者に説明や共有しやすいようパワーポイント(またはGoogleスライド)で作成しています。
項目によってはスライドにおさまらないこともあるので、別紙でExcelなどを使うこともあります。
テスト計画で検討する内容は以下のとおりです。
| 項目 | 説明 |
|---|---|
| テスト目的 | テストを実施して何を実現したいかを明確にする |
| テスト方針 | どのようなテストをどこまで実施するかを明確にする |
| テスト範囲(する/しない) | テスト対象のうち、どの範囲をテストするか決める |
| 合否判定基準 | テスト実施結果等の情報から品質に関する合否基準を決める |
| 中止/再開基準 | テストの中止、再開基準を決める |
| テスト成果物の定義 | テストの最終的なアウトプットを定義する |
| テストのタスク検討 | テスト活動で発生するタスクを検討する |
| テスト環境、ツールの確認 | テストで使用する環境、デバッグツール、支援ツールなどを確認する |
| 責任範囲、ステークホルダーとQAフローの確認 | QA依頼のフロー、関係者を確認する |
| 要員計画とトレーニング計画 | 必要なリソースと、必要に応じてトレーニングの計画を立てる |
| スケジュール、費用 | 発生する作業の時期、コストを明確にする |
| リスクと対策 | 判明しているリスクの対策を検討する |
| 各項目について、どういったことを誰に確認するのか、といったノウハウもまとめておくと作成時のガイドになります。 |
テスト計画書はチーム内外で共有するドキュメントになるので、テスト管理者および有識者によるレビューを必須としています。
レビューを通して作成者の理解も深まり、成長にもつながるので一石二鳥です。
##共有方法
テスト稼働が本格化する前に開発チームに共有します。
このタイミングでは、未確定の要素も残っていることが多いため、どこが未確定かおよびいつ確定するか確認します。
また、開発状況にあわせてテスト計画も見直しが必要になるので共有タイミングの認識あわせをしておきます。
納品や開発承認など、明確なターゲットがある場合、そこに向けた開始点でテスト計画レビューをおこなうと良いです。
想定される質問や、確認しておきたいことは事前にリストアップしておくとスムーズに情報共有できると思います。
#まとめ
モバイルゲーム開発は状況やスケジュールが変動しやすいため、うまくコントロールしないとテスト工数が膨らんだり不具合が収束せず品質が安定しなかったりします。
テスト計画を立てる際には、そうしたリスクを視野に入れてこういうときどうするべきかを意識することが大切です。
特に新規開発や大規模なアップデートではテスト計画を立てることをおすすめします。
#参考資料
・テスト計画の構成や用語について
JSTQBシラバス、用語集
JSTQB教科書