#はじめに
元組み込みQA、現ゲームQAの私が、これまでの経験を踏まえて、
組み込み開発のどういう良いところを持ってくれば
ゲーム開発がもっとハッピーになるのかとかを考えながらまとめてみます。
ちなみに、ここでのゲーム開発は主にスマホ向けアプリゲームの運用フェーズを指していますのでご承知おきください。
#組み込み開発とゲーム開発の違い
主観になりますが、一番大きいなと思ったのは、**「スケジュール感」です。
組み込み開発では、いったんリリースしてしまえばデータ更新の頻度はそこまで多くなく、更新版でも開発期間は数か月かけることもあります(不具合修正のアップデートではなく、機能更新のようなものを想定しています)。
一方ゲーム開発は、毎週のようにデータ更新が入り、開発期間はQA含めて1週間というのもあります。
スケジュールが変われば、関連するプロセスやドキュメントの類も特徴が変わってきます。
運用中のゲーム開発では、ウォーターフォール型の開発はほぼないのでは、とか思っています(アジャイルっぽいとか、スクラムで、とかは聞いたことありますが)。
企画も大枠は決まっていますが、細かい部分は日ごとに変化したりしますし、
予期せぬ影響範囲が見つかって、急遽実装に変更が入ることだってあります。
組み込みでももちろん発生したりしましたが、QA期間が多くて4日のゲームタイトルで発生すると結構修羅場になったりします。
そのため、ドキュメント類の構成管理はそこまで厳密ではなかったりします。
(過去のアドベントカレンダーで、仕様書の件も少し触れているので、
興味ある方は御覧いただけますと幸いです。)
あとは、品質の定義もけっこう違うと思いました。
組み込み製品では、リリース前にしっかりと品質を保証し、万が一にも不具合が発生しないよう高いカバレッジのテストを複数サイクル実施します(製品にもよりますが)。機能更新のようなリリース後のアップデートも同様です。
ゲームでもカバレッジは意識しますが、開発期間自体が短く、開発中の仕様や実装の変動も多いので、
基本機能のカバレッジがどうしても低くなりがちです(特に条件の組み合わせを網羅したような設計が困難)。
その分、探索的なテストだったりでカバーすることが多いと思います。
ちょっとまとめてみると、以下の表のようなイメージです(会社さんによって、違うとは思います)。
#どうしたらゲーム開発がハッピーになるか考える
ではQAの側面で組み込み開発から見習うと良さそうな点を考えてみます。
見習う点の一例として上述したような組み込み開発の高いトレーサビリティと、カバレッジ基準に沿ったテストをつくる方法とは・・・
##トレーサビリティを確保してみる
ゲームQAで特におさえるべきポイントとしては、「変更点」**です。
最低限、ここだけは変更したときに追えるようにしたいところになります。
テストでも、変更点については新たにテストケース化しておかないとテスト漏れのリスクが高まります。
(実装に手を入れた箇所には不具合が入り込む可能性がある)
こっそり変更されてしまうと、QAでも検知が難しくなる(過去のテストも無意味になる)ので、更新したかを追える仕組みを入れてみると良さそうです。
とはいえ、仕様書を更新するたびにバージョン〇〇、更新日mm/dd、更新者〇〇、更新内容ほげほげ、というのを
毎回やっていると、工数がいくらあっても足りないので、実装に影響するような変更点の仕様変更に対してのみ適用するなど、
範囲をある程度決めておくのが良いと思います。
例)
・テストケースに、「参照仕様書」と「仕様書最終更新日」の欄を設ける
・仕様書に、変更点に関する「最終更新日」と「更新内容」の欄を設ける
コンフルみたいな共有ツールを使用している場合は、コメントを利用するのも手だと思います。
トレーサビリティを確保できているか、と問われると悩ましいところではありますが、
少なくとも更新漏れを検知するための1つのシステムとしては機能しそうです。
##カバレッジを考えてみる
変更点をちゃんとテストできているのか。ここについても課題がありそうです。
ゲームの定常機能更新の場合、変更の多くはデータ設定部分になると思います。
一方で、機能的な改修も少し入れたりもします(ゲーム自体に変化が少ないと飽きちゃいますよね)。
全機能のカバレッジとなると大変ですが、機能改修箇所に焦点を当ててカバレッジを考えるだけなら、なんとかなるかもしれません。
こんなフォーマットを考えてみます。
変更内容は、仕様書のコピペでも大丈夫です。
大事なのはすべての変更点がリストアップされ、それぞれに対してどんなテストをするかが明示されていることです。
変更内容部分を詳細化する余裕があれば、もう少し細かく書いた方が、よりテスト観点を洗い出せると思います。
開発担当者と、このレベルで認識あわせができれば、大枠での漏れが発生しにくくなります。
##結局何がハッピーなのか
ゲーム開発で不具合になりやすいところは、変更点とその影響範囲です。
変更点に対するトレーサビリティとカバレッジを意識することで、QAで拾える可能性も上がります。
リリース前に不具合を検知し修正できれば、リリース後に検知されるよりも少ないコストで対応ができます。
原因の調査や、再発防止策の検討に時間を費やすことも少なくなります。
結果として、モノづくりに集中する時間を確保でき、より良い品質のゲームを世の中に出せるわけです。
こうなれば開発もQAもハッピーになりそうですね。
#さいごに
組み込みQAの(おそらく)堅牢なテストケースの仕組みを、全て導入するのは限られた工数の中では困難です。
が、一部の仕組みをうまく流用できれば、ゲームQAのテストケースも堅牢にできるかもしれません。
少なくとも、経験者による探索的テストに頼るしかない状況を打破できるかもしれません。
本エントリーでは、組み込みQAの一部分だけ切り出してみましたが、
他にも参考になる仕組みはたくさんあります。
別の機会で、うまくいったこととか、ダメだったこととか触れてみようかなと思います。
それでは、良いクリスマスを。