こんにちは、QAのゆーすけです。
私は今でこそソフトウェアテスト会社の一員として日々努めていますが、元々はゲームテストがメインの会社のメンバーでした。
ゲームテストの会社自体はコンシューマーゲーム→PC→携帯（FP/スマホ）とテストを渡り歩いてきましたが、元々はガチガチのゲーム好きからゲームデバッグに応募した経歴になります。
今はゲームテストに関わることが全くないですが、元々のゲーム好きの興味として最近JSTQB※1のゲームテストシラバスを眺める時間を設けるようにしています。
※1 JSTQB認定テスト技術者資格
日本におけるソフトウェアテスト技術認定資格運営組織。ISTQBの加盟組織でもあるので、その資格および教育は国際的にも有効
ゲームテストの思い出
私がゲームテストを主戦場としていたことは、ゲーム機がネットワークに繋がるといったことはほぼなく（PlayStation 2では別売のBBユニットが必要な時代……）、
ゲームの重篤な不具合＝回収、リマスターの販売
といったことが当たり前でした。
※担当案件でリマスター版が出たことが一度だけあります（広い意味なら2回ですが）
※PlayStationの某大型RPGの進行不能不具合は新聞にまで載った最も？有名な不具合だと思います。
- 直すためにはメモリーカード（PS）の発送、修復が必要
- この不具合は今の市場流通版（アーカイブス版）でも修正されていない
また、発売日というものが明確に決められるので、その発売日何カ月前には開発・テストが収束し、製品を量産（カートリッジもしくはROM）し、出荷して、流通させる、というスケジュールが必須でした（これは多分今もそう）。
※とあるメーカー、とあるゲームタイトルのキックオフで
「すでに発売日を決めて広告をxxxxx円かけて大体的に行っているので、
くれぐれも発売遅延がないように品質管理を徹底してください」
と言われたのは今ではとてもいい思い出。ネタになってます（ちゃんと当初の予定日に発売しました）。
ゲーム特有の観点として
閑話休題、
JSTQBのゲームテストシラバスに以下のような文章が記載されています。
ブラックボックステスト技法（black-box test technique）を使ったテストでは、プラットフォームによる 違いはほとんどない。しかし、各ゲーム機メーカーは、ビデオゲームが公開される前に準拠しなければならない独自の要件を定めている場合がある。これらの要件は、秘密保持契約に基づいて開発者やパブリッシャーに提供される独自の文書である。各要件のチェックリストはいくつかのカテゴリーで構成されており、ゲーム機メーカーに拒否されないためには、ゲームソフトウェアはそれらに準拠しなければ ならない
ゲームテストシラバスより抜粋
PC・webサービス系のテストを行っていると意識することがないですが、
ゲーム業界のような3rdパーティーがいるものでは、一般のテストと同様もしくはそれ以上に強く意識しなければならないのが上記のようないわゆる「作成基準」というものになります。
※1stパーティーがプラットフォーマー（任天堂、ソニー、マイクロソフトなど）
2ndパーティーがユーザーとして、
3rdパーティーはゲーム開発企業と言われています。
つまり、ゲームとしての品質がどんなに高水準であっても、メーカー側の作成基準に抵触事項が1件でも存在した場合はリジェクトを受けてしまうわけです。
前述した広告費をかけた、とプレッシャーをかけていただいたプロジェクトでも、機能部分の重篤な不具合よりも、作成基準を通過できるか、という点の方が気になって胃がキリキリとしたものです。
この各種作成基準はひとつひとつを詳細に覚えておく必要まではありませんが、品質基準、観点、方針として心に留めておくと有益なものばかりなので、思い出話を含めて軽く紹介していきたいと思います。
作成基準例
正しい用語を使う
何を当たり前のことを、と思われるかもしれませんが、意識しないと正しい用語を使うことは結構難しかったりします。
「取り扱い説明書を見て、playstation2のコントローラーで十字ボタンのことを調べた」
昔の知識に偏っていて申し訳ないですが、
上記のような文章がゲーム中にあると、即再生基準でリジェクトを受けること間違いなしです。
正しくは
・
・
・
「解説書を見て、”PlayStation🄬2”のコントローラで方向キーのことを調べた」
となります。
複数のプラットフォームがある場合、それぞれで使用される用語は差別化されていることが多いので、自分の使っている言葉がその環境において本当に適切なものであるか、ということは非常に大事な要素です。
こういったことは作成基準など関係なく、普段の日常やビジネス上の会話や、論文、レポート作成でもかなり有効になる意識となります。
中断再開、復元を意識する
とあるハードの作成基準では、
「ディスクトレイの開閉を行った後でも適切にゲームに復帰できること」
というものがあります（今もあるかもしれませんが）。
流石にPC・webサービス系のテストでは上記のような開閉を直接的に使うことはないかもしれませんが、携帯電話系のテストでは
- 携帯（フィーチャーフォン）の開閉を行っても正しく動作が復帰すること
（いわゆるサスペンド／レジュームの観点） - Androd端末において、端末デバイス側にバックキーが搭載されている場合、デバイス側からのインプットを受けて画面遷移を行った場合でも、適切な動作を保つこと
などが派生観点としてあげられるかと思います。
画面端に重要な情報の表示、描画を行わない
重要情報の見逃しによる不利益防止のための観点になりますが、こういった内容もUI/UXなどの観点から意識できるとよりよい製品、品質構築に寄与できる観点だと思います。
このチェックを漏れなく行うために、液晶ディスプレイ上に透明テープを貼っている人をみたことは今でも忘れられない衝撃として記憶に残っています。
過剰の演出、画面描写を行わない
これは1997年に某テレビ番組で起こった光過敏性発作が有名だと思いますが、いわゆる激しい画面の明滅を禁止する、という内容です。
こういったその時々に起こった事象なのが制約・規約として盛り込まれるということもあります。
また仮に明記された制約がなかったとしても、現在および過去の事象と照らし合わせて問題だと思われることを指摘していくことも、品質観点からは重要な活動になりますので、品管に携わる人達には幅広く、そして深い知識が求められることになります。
まとめ
今現在、元々ゲームデバッグからキャリアの始まった自分が、今こうしてソフトウェアテストに携わって少なからず活躍できている？ことを考えると、何のデバイスにどう関わってきたかはそこまで重要ではないのかもしれません。
品質的な考え方は別分野別デバイスでも有益だということが分かりますし、より大事なのは関わったものを柔軟に適用し、様々な知識を多角的に広く深く吸収し続ける、ということなのかもしれませんね。
