ソフトウェアテストは、さまざまな専門分野に分類されるのが一般的です。

ゲームにはさまざまなジャンルがあり、シングルプレイやマルチプレイなどの違いがありますが、テスト手法はこれらに左右されず共通していると考えられています。

※本サイトでは「コンピュータゲーム」「ビデオゲーム」は、まとめて「ゲーム」と翻訳しています。
ゲームはあくまでソフトウェアとして定義され、スポーツゲームやギャンブルとは区別されます。

ゲーム業界の急速な成長により、現在ではゲームは多様なプラットフォームで提供されています。

ゲームの規模は拡大し、内容も複雑化しています。それに伴い、ハードウェアやネットワークの要求スペック[1]も増大しています。
また、プレイヤー数の増加に伴い、ゲームの品質に対する期待も高まっています。

ソフトウェア開発に共通する「リスク」は、ゲーム開発にも当てはまりますが、ゲーム特有のリスクも存在し、特に注意が必要です。

以下に、代表的なリスクの例を示します。

テスターは以下の領域で欠陥を見つけることができます。

ゲームにはよく見られる欠陥がいくつか存在します。



これらの欠陥は発見しやすいものの、再現方法を特定するのが難しいことがあります。
これがゲームテストを難しくしている要因の一つです。

優秀なテスターは、設計されたゲームシナリオに基づいてテストを計画し、仕様に沿っているかどうかを確認します。
もし想定されたシナリオから逸脱した場合、その原因や影響を分析し、報告します。

ゲームテストでは、通常のテストでは見つけにくい「開発者が意図していないプレイ」を積極的にテストすることが重要です。



本来、敵を倒すか鍵を使って進むべき場面で、ゲームの進行条件を無視して木箱を積み重ね、壁を越えるというプレイ。

欠陥[5]を利用し、キャラクターが壁の中に隠れたまま敵を一方的に攻撃するプレイ(いわゆる「不公平な安全地帯」)。
この問題は、特にFPSなどのオンライン対戦ゲームで不正に有利な状況を作り出し、ユーザー体験を損なう可能性があります。

このようなリスクを防ぐためには、ネガティブテスト(意図的に欠陥を突くテスト)が非常に重要です。
プレイヤーの中には、開発者の意図に反して、ゲームの仕組みを悪用して利益を得ようとするプレイヤーも存在します。
しかし、こうした「不正な利益」を得るためには、特別なツールや高度なスキルは必要なく、単に「都合のよい欠陥」を見つけるだけで簡単に実現できてしまうのです。

悪意のあるプレイヤーはゲームの欠陥を意図的に探し、「アイテムを無限に入手する」や「通常では手に入らない強力な武器を取得する」などの行為を行います。
その結果、ゲームの運営者(ゲーム会社や個人開発者)は利益の減少にもつながります。

ゲームは「プレイヤーの主観や感情」によって評価されます。

業務向けシステムでは「機能性」が最も重要ですが、ゲームにとって最も大切なのは「どれだけ楽しめるか」です。
プレイヤーは多少の「機能上の欠陥」には我慢できても、ゲームが面白くなかったり、グラフィックの質が低かったりすると、そのゲームをやめてしまうかもしれません。

大部分のプレイヤーはゲームを選ぶ際に、「批評家」「レビュアー」「インフルエンサー」などの意見を参考にしています。

ゲームは、複数のプラットフォームでプレイされることが一般的です。

できるだけ多くのプレイヤーに遊んでもらうために、「ゲームスタジオ」や「パブリッシャー」は、さまざまなプラットフォームでゲームをリリースすることを目指しています。
(例：PC、ウェブ、モバイルデバイス、家庭用ゲーム機など)

もちろん、各アップデートごとに「すべてのプラットフォーム」でテストが必要になります。
そのため、重大なリスクが発生し、テストに膨大な時間がかかることもあります。


たとえば、「標準的なスペックのPC」では問題なく動作するのに、「最新の家庭用ゲーム機」では多くの欠陥が発生することがあります。
また、異なる技術間での通信不全や、外部(サードパーティ)への移植時の要件不足が原因となる問題も珍しくありません。

これらのリスクを減らすためには、「多様なハードウェア構成」で機能やパフォーマンスをテストし、各プラットフォームの特性に合わせた検証を行うことが推奨されています。

テスターにとって、家庭用ゲーム機でのテストは特に注意が必要です。
家庭用ゲーム機はゲーム専用のデバイスであり、モバイルデバイスやPCのような多目的な機器ではありません。

ブラックボックステスト[6]ではプラットフォームごとの差は少なく見えますが、実際には、各メーカーごとにゲーム発売前に遵守すべき厳格な独自要件「メーカー規約(チェックリスト形式)」があります。

※メーカーチェック、ロットチェックと呼ばれることもあります

これらの規約は機密保持契約のもとで提供され、チェックリストを全てクリアしないとゲームの販売許可を得ることができません。
そのため、テスターは通常のテストに加えて、「規約を満たしているかどうか」も確認する必要があります。

また、欠陥の特定や原因の分析には、認定された開発者やテスターだけが使用できる「開発・テスト専用の特別なモード」が搭載された専用機材が用いられます。
※専用サイトで認証・登録し、開発・テスト用モードへのアクセスが許可されます。

ほとんどのゲームでは「オブジェクト」「イベント」「要素」のすべての組み合わせをテストすることは不可能です。
(特にオープンワールドゲームは組み合わせが非常に複雑です)

各組み合わせを個別にテストするだけでも膨大な時間がかかるうえに、
ゲームのアップデートで仕様が変更された場合、「確認テスト」に追加の工数が必要となります。

リスク管理では「発生確率」と「影響度」に基づいて欠陥を評価します。
各テストケースでは「テストの優先順位」を決定するために次の2つの要素に注目します。

たとえば、ステージを順番に進めていくようなゲームでは、最初の方で発生する欠陥は優先度が高くなります。
この欠陥は多くのプレイヤーが遭遇する可能性が高く、50時間くらいプレイした後で発生する欠陥よりも優先的に修正する必要があります。
(ただし、常に重大度が高いわけではありません)

すでに長時間プレイしている好意的なプレイヤーは、欠陥が発生しても冷静に受け止めてくれる可能性が高く、その影響は比較的小さいと考えられます。
しかしチュートリアルや初期段階での不具合は、新しく始めたプレイヤーの離脱を招く大きなリスクとなります。

テストによってリスクを効率的に軽減するためには、ゲーム内の個々の欠陥を探すのではなく「欠陥のグループ」を特定することが重要です。

「欠陥のグループ」とは、重要な領域に集中して発生している「欠陥のまとまり」を指します。
グラフィックやサウンドなど、同じ領域に欠陥が集中している場合、一度の修正で複数の問題をまとめて解決できるため、品質改善の効果が高まります。

ゲームには以下のような欠陥が発生しやすい領域があります。

特にゲーム開始直後のチュートリアルや操作説明は、プレイヤーがゲームを評価する最初の段階であり、
多くの機能が短期間に体験できるため、この段階での問題はプレイヤーの離脱リスクが高く、最重要とされています。

ゲームテスターは、一日中同僚とゲームを楽しんでいると思われがちですが、実際は全く違います。

テスターが自由にゲームを楽しめるのは、「新規プロジェクトの仕様把握」や「開発チーム内でのプレイテスト」など、限られた状況に限られます。
ゲームテストは一見特別に思われがちですが、基本的なテストの考え方や方法は、他のソフトウェアテストと多くの点で共通しています。
(例：要件確認、バグ修正確認、性能・使いやすさの評価など)

一般のプレイヤーは、ゲームをクリアしたり、対戦相手を倒したりして楽しむためにゲームをプレイします。
しかし、テスターは仕様書に記載された要件を満たしているかどうかを確認するためにゲームをプレイします。


また、テスターが個人的に「苦手なゲーム」を担当することもあります。
担当するゲームが自分の好みに合わない場合でも、客観的な観点でテストしなければなりません。

「ゲームオブジェクト」が正しく表示されるかどうかをテストするために、同じステージやシーンを何度も繰り返すこともあります(何十回、何百回と繰り返すことも)。
これらの繰り返し作業は単調で辛く感じるかもしれませんが、「欠陥を発見すること」で、達成感や満足感を得られることもあります。
(中には、欠陥を見つけること自体をゲームのように楽しんでいるテスターもいます。)

なお、このシラバスで説明しているアプローチはゲームテスト特有のものであり、ソフトウェアテスト (例：ゲームメカニクスのテスト)やハードウェアテスト(例：コントローラーのテスト)双方に適用されます。
また、回帰テスト・性能テスト・ユーザビリティテストなど、基本的なテスト技法や非機能テスト手法、モバイルプラットフォーム特有の特徴は、 ISTQB®の他のシラバスで詳しく解説されています。

基本的に、ゲーム開発チームのメンバーの役割は、他のソフトウェア開発チームと大きくは変わりません。


小規模なチームでは、1人が複数の役割を担当することもあります。
以下に、ゲーム開発プロジェクトでの各役割とその主な職務をまとめます。

この段階で重要なのは、「開発チーム」が作ろうとしているものと「プレイヤー(場合によってはパブリッシャーやステークホルダー)」が望んでいるものが一致していることです。
アイデアは、ゲームの全体的なビジョンやジャンル、設定、ゲームプレイの本質、メカニクス(ゲームの基本的な動作やルール)、主要な特徴を簡潔に記述した文書としてまとめられます。
(提案書や企画書にあたるものです)

この段階でレビューされる可能性のある成果物には、以下のものがあります。

この段階で作成されるテストウェア[9]には、以下のものがあります。

この段階の主な目標は、ゲームのプロトタイプ(試作品)を開発することです。

プロトタイプはプレイ可能な「製品の初期バージョン」であり、主要機能を中心に実装されます。
この段階では「コアゲームメカニクス(ゲームの主要ルール)」と「初期構想[10]」がテストされ、ここで「チームの開発技術力」も評価されます。
※テスター、ゲームデザイナー、その他の開発チームメンバーがプロトタイプのテストに参加することもあります。

開発チームは「草案レベルの要件」をレビューして実装可能かどうかを判断します。
テストチームは「メカニクス間の相互作用」や「プロトタイプの機能」を把握するためにレビューを行います。
さらに、テスターは「テスト計画」および「テストスケジュール」の作成に関与します。

ゲームに関する「ドキュメント」が作成されると「テスト計画」が作成され、「ドキュメント」がレビューされます。
これらの対応は「プレプロダクション段階」での製品の技術的リスクを軽減します。

この段階でレビューされる可能性のある成果物は以下の通りです。

この段階で作成・更新されるテストウェアには以下が含まれます。

プロダクション段階では、ゲーム開発が本格的に進行します。
この段階は最も長期間にわたり、通常は「アルファ版」および「ベータ版」に分かれます。

この段階で、テスターは「チェックリスト」や「テスト条件」を確定し、「機能テスト」および「非機能テスト」を実施します。

また、「統合テスト」「システムテスト」「受け入れテスト」も実行されます[11]。
この段階では、最も多くの欠陥が発見され、テスターは「確認テスト」および「回帰テスト」を行います。

この段階で作成・更新されるテストウェアには、以下のものが含まれます。

ポストプロダクション段階では、ソフトウェア保守期間中(サービス提供中)に行われる一般的なテスト活動が実施されます。
これには通常、「更新テスト」および「回帰テスト」が含まれます。

International Software Testing Qualifications Board(以下、ISTQB®)
ISTQB®はInternational Software Testing Qualifications Boardの登録商標です

Certified Tester Game Testing (CT-GaMe) Syllabusの著作権 ISTQB®、著者 Andrey Konushin(議長)、Alexander Alexandrov、Evgeny Glushkin、Dmitriy Karasev、Elena Karaseva、Elizaveta Kruchinina、 Vadim Lukovaty、Dmitry Melishev、Maxim Nikolaev、Alexander Prokhorov、Anton Savvateev、Ayrat Sayfullov、 Pavel Sharikov、Kirill Shevelev、Artyom Stukalov、Nikita Sysuev、Tatiana Tepaeva、Alexander Torgovkin、 Margarita Trofimova、Yaroslav Vereshchagin、Svetlana Yushina、Lyubov Zhuravleva

画像は「Microsoft Designer」 「ChatGPT」にて生成しております。意図せず権利関係を侵害しておりましたら大変申し訳ございません。