#はじめに
弊社では複数の協力会社様と一緒に携帯ゲームのテストをつくっています。
本記事では、その中で見えてきたゲーム開発に共通するテストケースの構成とか、
今後どうやってより良いテストをつくっていったらよいかを検討してみた結果を書いてみます。
ちなみに、ここで取り扱うテストケースは、
新規開発ではなく、リリースしてしばらく経った運用フェーズでのものとなりますのでご留意ください。
#時間的な制約と仕様的な制約
携帯ゲームの開発において、テストケースの作成工数を十分に取ることは可能でしょうか？
何をもって十分かはありますが、私の経験上、十分ではないと思っています。
(これはこれで課題ではあるのですが)
携帯ゲームのテストでは、大きく2つの制約があると考えています。
1つは時間的な制約で、これは携帯ゲームの開発に携わったことがある方ならご理解いただけると思いますが、
週に複数の施策(いわゆるガチャとかイベント)や、月数回のバージョンアップがあり、
開発スケジュールは常にカツカツです。
弊社では、仕様書が共有されてから、約2日間の期間をテストケース作成に割り当てています(※定常的なイベントの例で、新規機能はもう少しあります)。
しかも、その2日間では並行してテスト実行も稼働しているので、
テスト設計者はテスト管理と並行してテストケースを作成します。
加えて2つ目の制約である仕様的な制約です。
多くの施策では、仕様書がテスト開始ギリギリまで完成しません(もちろんしっかりと作成してくれる方もいますが)。
細かな設定値や、遊び感に関するバランス周りは、けっこうな確率で未Fixで共有されたりします。
これを1つ目の制約とあわせると、約2日間でテストケースを作成したいが、仕様書は一部未Fixという条件で
テスト実行の開始までに作成をしないといけないので、前述のとおり不十分と考えたわけです。
#テストケースの構成
ちょっと前置きが長くなりましたが、上記制約のもとテストケースをつくるとどうなるのか
事例をもとに紹介したいと思います。
ちなみに弊社では、基本的なテストケースの構成は以下としています(一部、実際のものと異なります)。
##事例1.更新箇所は関数使って効率化型
基本的にはこの方法を取ることが多いです。
携帯ゲームでは、イベントの基本ロジックはほぼそのままに、
画像や設定値を差し替えて更新する箇所があります。
そうした箇所は、テストケースと別のシートでマスタデータとして管理しておいて、
テストケースはそこから関数でデータを引っ張り、作成工数を効率化します。
一番最初の作成工数はそこそこかかってしまいますが、一度データ化してしまえば以降の作成はスムーズになります。
仕様書を作成する方と、どこをデータとして引っ張るから、
どういうつくりにしてほしいかを事前に認識あわせしておくと、マスタ部分は仕様書からコピペすることも可能になります。
##事例2.慣れたテスト実行者がいるからセーフ型
あまり望ましくないですが、熟練したテスト実行者に頼るかたちで、確認手順などを省略することがあります。
ただ、この方式は属人化が進むことや、テスト結果の再現性を低くすることにもつながるので、極力避けたいところではあります。
実際のところ、この方法は意図してやるものではなく、テスト設計者の余裕がなくてやむをえずこうなっているケースが多いので、
気づいたタイミングでテストケースを整備したりしています。
##事例3.諦めて探索的テストっぽくする型
これは本当にやばいとき(仕様書がほぼない、もしくは更新されていないときや、テスト設計者が未熟だった場合など)に発生したりします。
そういうときは、最低限何をどれくらい確認したかわかるくらいにはしておきます。
(なんか1000hくらいテストしたから大丈夫でしょう、的な考えは危険)
いくら仕様が決まらない、テスト設計者が未熟とはいえ、大枠の基本機能自体は変わらない(変わりにくい)ので、
縦軸に基本機能、横軸にテスト観点(できれば観点も定義したいところです)や結果を記入する欄くらいは用意して、
どの機能をどれくらいテストして、結果どうだったのかを記録できるようにします。
めったに発生しませんが、発生した場合には開発とテスト範囲とテストの進め方の認識を合わせて実施します。
#今後どんなテストケースをつくっていくべきか
正直なところ、現在も試行錯誤中ではありますが、できるだけ事例1の方法を取り入れたいと思っています。
一方で新規要素も入ったりするので、そこはデータ引用だけではなくしっかりとテスト設計をしたいところです。
新規要素を時間がない中で、どうテストしていくかが今後の大きなポイントです。
(特に、協力会社様と一緒に取り組んでいくことが重要)
##テスト観点の整備
新規周りで一からテストをつくっていると、多めに工数を確保しているとはいえ抜け漏れのリスクが大きくなります。
そのため、短期間でも抜け漏れ少なくテストを設計するためにテスト観点を整備しています。
(例えば、「表示：画像が正しいこと、文言のテキスト内容が正しいこと」、「設定：設定内容が仕様と合致していること」、
「条件：複数条件で動作する機能の場合、各条件の組み合わせで正常に動作すること」など)
テスト観点は、ゲーム開発の変化にあわせて更新していく必要があるため、
今後も継続的に整備して、うまく運用していきたいと思います。
##影響範囲の考慮
こちらは、12/1の記事にて詳しく紹介がされていたので割愛します。
(大変参考になる記事でしたので、ぜひ見てください。)
#さいごに
思うままに書いてしまったので、読みづらいところも多々あるかと思いますが、
またどこかでまとめとかやってみたいと思います。
引き続きよろしくお願いいたします。