◆はじめに
初めましての人は初めまして。
ソフトウェアテスト Advent Calendar2016 の16日目の記事です。
以前、 WACATE というテスト勉強会に参加した時に、テスト業界とゲーム業界とのギャップに「こんなに違うんだ」と衝撃を受けたことがあります。
今回は、そんなゲーム業界のテスト事情を簡単に紹介したいと思います。
結論
ゲームアプリは、ソフトウェア業界が想像するであろう「普通のテスト」は、ほぼやっていません。
代わりにあるのが「デバッグ」と呼ばれる作業です。
サーバ・ライブラリ・ツール あたりは、単体テストがよく行われています。
結合テストとか、テスト設計、テスト仕様書などの高尚な代物は、ほぼ存在しないと思っていいでしょう。
誰だよ
ゲーム業界で、自称・Jenkinsお兄さん やっています(特定必死)
なお、この記事は個人的にやっているもので、会社を代表しているつもりは毛頭ありません。
全て私個人の独断と偏見によるものとなっております。
自分とテストとの関わり
CI(継続的インテグレーション)/CD(継続的デリバリー) の一連の流れを円滑に動かすお仕事をしています。
大雑把に言ってしまえば、Jenkins や スクリプトを駆使して、自動ビルド そして 自動テスト を動かす人です。
・・・という建前の元、実際はCIに関わりそうなことを手広くやらされる雑用系エンジニアをしています。
極稀ではありますが、Jenkins から呼び出す 単体テストやスモークテストを書くこともあります。
最も最近では、bash でスクリプトを作っていたら、うっかり千行近くの代物になってしまったので、流石にこれは適当に済ます訳にはいかないな・・・ということで、テストケースを洗い出して、動作チェックを繰り返しました。
◆ゲーム業界のテスト事情
さて、本題です。
ゲームのバグ
ゲームは遊んでもらってなんぼです。
なので、「ゲームのバグ」を定義するなら、遊びを阻害する要素 という所でしょうか。
具体的なバグとしては、例えば以下のようなものが挙げられます。
| 呼称 | 現象 | 具体例 | 原因の例 |
|---|---|---|---|
| Aバグ / 停止バグ | ゲームプレイ中に停止やループなどに陥り、進行不可能になる | フリーズ、石の中にいる | ぬるぽなどメモリアクセス違反、無限ループ |
| シーケンス バグ | 進行は出来るが、意図しないシーケンスになってしまう | 終わらない夏休み(8月32日)、ポ〇モンをLv100にする、タイトル画面から進むと即エンディング | メモリアクセス違反に起因してフラグ管理に失敗する |
| グラフィック/サウンド バグ | 意図通りに描画/再生されていない | 3DキャラがT字のポーズに、湖が血の池に | GPUに転送するメモリレイアウトがずれた |
| 仕様バグ | 仕様から間違っている、仕様通りだけど面白くない | キャラを動かしている感覚がしない、当たり判定がそんざいしない | 必要なところに効果を表すエフェクト(SEも含む)がない |
Aバグという名前から分かるように、ゲームプレイへの影響度合いで、バグ対処の優先度が決められて、それぞれ対処していきます。
体験したことがある方は分かると思いますが、ゲームが停止すると、ソフトウェアをリセットしてやり直す羽目になります。
そうなってしまうと、ユーザはせっかくゲームに割いた時間が水の泡になってしまい、開発者も楽しんでもらうために作った部分を遊んでもらえず、両者とも不幸な気持ちになってしまいます。
そんなわけで、停止バグはどのゲーム開発現場でも最優先に対処する代物だと思われます。
「一般的なテスト」はあまりしない
当然ながら、ゲームでバグが出たところで、医療や公共交通機関のシステムのように生命を脅かすことはありません。
また、近年の追加コンテンツに課金するビジネスモデルが出てくるまでは、ソフト買い切りビジネスが当たり前でしたので、バグによってユーザが直接お金の損失を受けることもありませんでした。
80-90年代には、ホームページ作成ブームに伴ってか 「ゲームの裏技・バグ・チート」を紹介するサイトや書籍が流行していました。
ソフトウェアのバグが、まるでイースターエッグみたいな扱いです。
そんな制約の緩い文化や、娯楽という緩い性質もあってか、ゲーム開発ではIT業界のシステムのような厳格な開発を取りません。
テストはおろか、設計書も無いに等しい環境です。
そもそも開発スタイルからしてアジャイルが当たり前です。
「こうしたら面白い」というアイディアを仕様書(※)にして、それを元に実装し、実際にプレイして、見た目や音、遊び心地などの感触を確かめて、何か違ったら治して・・・の繰り返しで開発を進めます。
(※ なけなしの設計書のようなもの。 本質的には「アイディアを発案者から実装者に伝えるための文書」なので、設計書と言うのは違うかも)
デバッグ
ゲームが一通り出来上がると、テストの代わりに デバッグ を実施します。
NEW GAME でねねっちが頑張っていましたが、延々と壁にぶつかって壁抜けできる場所を探したり、おもむろにスカートの中を覗いてみるなど、バグがないか探す作業です(たぶん違う)。
一般業界でいうところの、受け入れテストに近い立ち位置だと思います。
バグを見つけたら、デバッガー(≒テスター)は各プロジェクトで使うBTS(Bug Tracking System) にバグの現象と再現手順(不明の場合もある)を報告します。
エンジニアは報告を手がかりに、再現して、原因特定し、バグを修正して、再度確認してもらいます。
開発後の作業なので、ゲーム開発が遅れると、デバッグ時間が短くなり、世にクソゲーと呼ばれるものを送り出してしまったり、デバッグが間に合わず発売延期することや、大規模な0day patchが配信されることもしばしばありします。
なお、世の炎上しているゲーム開発プロジェクトは、たいていデバッグ作業も炎上します。システム開発もたぶん同じですかね。
開発中の品質管理
テストらしいテストこそしないものの、普段の品質管理活動は行っています。
特に代表的なのが、 静的解析 です。
有償の Coverity が業界内にかなり広まっています。対応はやや遅いですが、いくつかのゲームプラットフォームにも対応していることもあり、重宝しています。
※なお、解析はされても、問題が直されるかは別です。
他にも C++ の cppcheck や、 Python 向けの Flake8 や PyLint なども活用されています。
静的テストに対して、動的テストの事例 も存在しています。
◆テスト最先端事情
プラットフォームによるテストの差
モバイル系のテスト
Web業界に近く、Selenium とかなんか凄そうなものを使っているイメージ。
サーバはテスト事例豊富です。外の業界と大差はないはずですし、調べるに困らないでしょう。
クライアントのテストは事例が少ないですが、直近の CEDEC 2016 で OpenCVを活用して自動テストシステムを作り上げたというツワモノ事例 が紹介されていました。
コンシューマ系
アプリ層はこれまで書いた通り、テストらしいテストは少な目です。
最近はAIによる自動実行の事例 をちらほら見かけます。
それよりハードに近い、ミドルウェア層やライブラリ層では、単体テストや受け入れテストもこまめにやっています。
アーケード系
組み込み系のテストに近いと思われます。
大抵、エージングと呼ばれるテストモードがあったりします。
中身はパソコンなので、コンシューマ系と似たようなテストはできるんじゃないかと思われます(よく知らない)
ゲームセンターが開店してから、閉店するまで、長時間稼働し続ける必要があるので、その分はコンシューマより厳しい部分もあるでしょう。
どんな人がテストに取り組んでいるの？
ゲーム業界ではなぜか、リードプログラマ(≒ベテランの人)が、片手間にやっていることが多いです。
若手が「テストやりたい」というのは奇特な部類になります(失礼)
非常にニッチというか、業界内でも人口が少ないので、CEDEC の関連セッションに行くと、有名人とお近づきになれたりします。
余談ですが、IT業界だと「テストから入って、設計に行く人が多い」と聞いたことがあり、完全に逆だな～ と衝撃を受けました。
おすすめ資料
ゲーム業界のカンファレンスである「CEDEC」 の中でおすすめのものを紹介します。
CEDECには、公式の資料サイトもあります。
興味のある方は、CEDiLに登録して、探してみてください。
◆まとめ
ということで、簡単ですが、ゲーム業界の紹介をさせていただきました。
「ゲームのQA」は最近になってようやく注目されてきた、比較的歴史の浅い分野だと思っています。
つまり、この記事を読んでくだすったテストに興味のあるエンジニアの方が、その気になれば天下取れるかもしれません。
もっといいゲームを世に送り出すためにも、この分野を盛り上げてくれる人が増えてくれたらな と期待しております。