ゲームは『ソフトウェア』と呼ばれるもののひとつであることはご存じでしたか？
ゲームは『ゲームソフト』とも呼ばれますが、『ソフト』の部分は『ソフトウェア』のことを意味しているのです。
ゲームは『ゲーム』という固有のものと捉えられることがありますが、実はソフトウェアのひとつであるため、ソフトウェア開発やソフトウェアテストなどの考え方や手法を活用することができます。
ソフトウェアテストには、どのソフトウェアにも共通する『テストの7原則』という考え方があり、ゲーム=ソフトウェアのため当然ゲームにも通じます。
ここでは、『テストの7原則』についてご紹介したいと思います。
テストの7原則①テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
プログラムの不備がバグであり、バグ（プログラムに不備）があるからといって必ずしもユーザーにわかる形で表れるわけではありません。プログラム的には問題だったとしても、ユーザーにはなんら影響のないバグも考えられます。
ゲームデバッグはバグ出し活動が主になりますが、見えないものは無いと証明することができません。強いて証明できるとしたら確認する範囲や方法を限定する形で、テストケースを活用する理由がまさにこれになります。
テストケースを活用しないバグ出し活動（=ゲームデバッグ）は何をどう確認したら記録が残らないため、限定的な証明をすることが難しいのです。
テストの7原則②全数テストは不可能
すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
プレイヤーの分身としてゲーム内でアバターを作成するケースはよくあると思います。
その際、頭部、腕部、胴部、脚部などの部位ごとに分かれ、頭部の中でも髪、目、鼻、口などさらに細かく設定することができます。
ゲームにもよりますが、ひとつのパーツあたり少なくとも10種類はあるでしょう。
では、髪、目、鼻、口などですべてのパーツの組み合わせを確認しようとすると、どうなるでしょうか？
数万～数十万通りの組み合わせとなり、頭部の確認だけでも相当な時間がかかってしまいます。
このように現実的な組み合わせ数ではなくなってしまうため、テスト技法などを活用してテストのポイントを絞って効率的・効果的な確認を行っていく必要があります。
テストの7原則③早期テストで時間とコストを節約
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる（3.1節を参照）。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
ゲームは動くものが出来てからテストをする傾向が非常に強いですが、もっと早くからテスト活動をすることでバグの少ないゲームの開発に繋がったり、結果的にテストにかかるコストの低減にも繋がります。
ゲーム開発の中でもアジャイル開発の形を取っているケースもありますが、アジャイル開発でも仕様書を作らなくて良いということではありません。
プログラムを実装する前段階の仕様書が出来た段階で仕様書の内容を確認し、曖昧な記載や整合性の取れていない内容の指摘、またテストするうえでの観点を開発担当者にフィードバックすることで、初期品質の向上とコストダウンに繋がっていく形です。
テストの7原則④欠陥の偏在
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則 2 で触れたことと同様）。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
特定のモード、機能、ポイントなどにバグが多く出るという考え方ですね。テストに関わったことがある方だと実感するものがあるかもしれません。
ゲーム外の話にはなりますが、プログラマーのスキルや経験値なども影響するかもしれません。
テストの7原則⑤殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
ゲーム開発の初期段階ではただプレイするだけでも大量のバグが発生します。しかし、バグが修正されてくるとただゲームをプレイするだけではなかなかバグは出なくなっていきます。
新しいバグを見つけるためには、ユーザーや他のテスターが思いもしないようなことをしていく必要があります。
テスト活動は意外と創造力が大事なのです。
テストの7原則⑥テストは状況次第
状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1 節を参照）。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
例えば、CBT（クローズドベータテスト）に向けたテスト活動であれば、ユーザーにそのゲームの面白さを体験してもらうことが重要になるため、ゲームシステムがしっかり機能しているかという確認が大事になり、イレギュラーな状態・状況で発生するようなバグ探しは重要度が下がるでしょう。
テストの7原則⑦『バグゼロ』の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。
ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 概要 Version 2018.J01
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
仮にバグがゼロだったとしても、ユーザーのニーズを満たしていなければ意味がないということですね。
起動に長い時間がかかる、画面切り替えの読み込みに時間がかかる、UIの階層構造がわかりにくいなど、ゲームを遊んでいて感じたことがある方は多いと思います。
バグがゼロだったとしても上記のようなゲームであった場合、ユーザーの支持は得られにくいでしょう。
まとめ
このテストの7原則は『当たり前』と感じる内容もあるかと思いますが、『当たり前』ではない人もゲーム開発に関わっていることがあります。その多くはマネジメント層ではないかと思いますが、その方たちに理解してもらおうとすると非常に苦労します。
他者に納得してもらいやすくするために、ソフトウェアテストの原則やテスト技法の効果などはしっかり理解しておく必要があります。自分が理解していないことを他者に理解させるのは難しいですからね。
コメント