GENZ, Inc.

ゲームアプリ開発・運営向け ゲームアプリのソフトウェアテスト

仕様変更とアップデートが続くなかで、改修の影響がどこまで及ぶかを配信前に確かめます。仕様書のレビューから実機での実行まで行います。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

ゲームアプリでよくある不具合

ゲームアプリの不具合は、アップデートによる既存機能への影響、マルチプレイ時の状態同期、クエストの進行、数値計算、通信断からの復帰といった多様な場面で発生します。

アップデート後に既存機能が動かなくなるデグレードが起きる

確認する範囲を決めないまま機能追加や修正を配信すると、変更が既存機能へ波及し、以前は進めた画面が操作を受け付けなくなってしまいます。

デグレード

マルチプレイで他プレイヤーの状態が正しく同期されない

サーバーとクライアントのやり取りで処理の順序が競合すると、対戦相手の位置や体力が自分の画面だけ古いまま表示され、試合の結果にずれが生じます。

状態同期

特定の操作手順による進行不能および復帰不可の不具合

想定していない順序で操作したり中断を挟んだりすると、進行フラグが立たないままになり、クエストを進めることも前の状態へ戻ることもできません。

進行不能

ダメージ計算や報酬の付与量が仕様の数値と一致しない

マスタの設定値が仕様書の数値とずれていると、表示された攻撃力どおりのダメージを与えられず、クエストの報酬も設計した量どおりに付与されません。

数値不整合

通信断からの復帰でセーブデータが巻き戻る・消える

通信が切れた瞬間の進行状況を端末側で保持できないと、復帰後に読み込むセーブデータが保存時点まで巻き戻り、購入したアイテムを失うこともあります。

セーブ復帰
02 RISK

残存した不具合により生じる問題

配信後に残った不具合の影響は、運営チームの緊急対応にとどまらず、ストア評価とユーザーの信頼、そして補填費用を通じてタイトルの収益にまで及びます。

倉庫のバックヤードで担当者が在庫回収や棚卸差異の対応に追われている実写画像。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

企画書や仕様書が不十分な段階でも、画面構成案やマスタの設定データなどを手がかりに、確認すべき観点を先回りして組み立てます。配信事故につながりやすい5つのポイントを、実装前に仕様と設定値の両面から検証します。

画面・パラメータ設計の不一致を防ぐ

仕様書と実装対象の画面・パラメータ設計の突き合わせ

企画書と仕様書に書かれた画面遷移、表示項目、パラメータの初期値を、実装対象の設計と一件ずつ突き合わせます。解釈が分かれやすい箇所は、どの文書のどの記述が根拠かまで明確に記録します。

確認する資料
  • 企画書
  • 仕様書
  • 画面遷移図
  • パラメータ設計書
ゲームメカニクスの矛盾・定義漏れを防ぐ

ゲームメカニクスの仕様の矛盾・抜けを洗い出す観点

戦闘、育成、報酬などゲームメカニクスの仕様を横断して読み、記述の欠落や他のメカニクスとの矛盾を洗い出します。開発の早い段階でレビューしておくほど、後工程での作り直しを避けられます。

確認する資料
  • ゲームメカニクス仕様書
  • ルール・状態定義
クエスト進行の行き止まりを防ぐ

クエスト進行と状態遷移の設計に行き止まりがないかの確認

進行フラグの更新条件、解放条件、中断からの復帰経路を状態と遷移の一覧に置き換え、どの状態からも先へ進めるかを追います。無効な操作を受け取ったときの戻り先が設計側で決まっているかも確かめます。

確認する資料
  • 状態遷移図・状態遷移表
  • 進行フラグ一覧
報酬・ダメージ計算の数値ずれを防ぐ

報酬・ダメージ計算のマスタ設定値と仕様書の数値の照合

マスタや設定ファイルに入っている単価、倍率、抽選確率を仕様書の数値と一件ずつ照合します。計算式をどの順序で適用するかの定義も点検し、配信前に数値の不一致を見つけます。

確認する資料
  • マスタ設定一覧
  • 報酬・ダメージ計算仕様書
通信断・中断・同時操作の設計漏れを防ぐ

通信断・中断・同時操作など異常系の設計の抜けの確認

通信が切れた場合やゲームの中断時、複数端末で同時に操作されたときの挙動が、仕様として定義されているかを確かめます。正常なプレイだけでは通らない経路を、設計の段階から拾います。

確認する資料
  • 異常系仕様書
  • 通信・中断復帰設計書
04 TEST DESIGN

動的テストの設計・実行のポイント

仕様変更で膨らみ続ける確認範囲を、限られた期間で実行できるテストケースと、判定の割れない合否基準へ具体化します。

STEP 01 プレイ体験の流れに沿って確認対象の機能と場面を洗い出すプレイ体験に沿って機能と場面を可視化
どう確かめるか

プレイ体験の流れに沿って確認対象の機能と場面を洗い出す

機能の一覧からではなく、チュートリアル、周回、対戦、課金という一連のプレイ動線に沿って、確認する画面と操作、対象の端末を並べます。テストの範囲とする境界も、この段階で決めます。

  • 01チュートリアル・周回・対戦・課金の流れを整理する
  • 02画面・操作・端末とテスト範囲の境界を洗い出す
  • 03プレイシナリオごとの確認対象を一覧化する
OUTPUTプレイシナリオ・対象一覧
STEP 02 仕様変更の影響範囲から回帰テストの優先順位を決める変更影響から回帰の優先順位を決定
どう確かめるか

仕様変更の影響範囲から回帰テストの優先順位を決める

変更が波及する範囲を影響度分析で洗い出し、緊急メンテナンスへ発展しやすい箇所から回帰テストの順序を決めます。

  • 01仕様変更が波及するメカニクスと既存機能を特定する
  • 02ユーザー影響と復旧難度で優先度を付ける
  • 03優先度つきの回帰テスト範囲を確定する
OUTPUT回帰テスト計画
STEP 03 境界値と異常系を期待値付きのテストケースへ具体化する境界値・異常系を期待値つきで設計
どう確かめるか

境界値と異常系を期待値付きのテストケースへ具体化する

パラメータの上限と下限を境界として取り出し、レビューで拾った異常系とあわせて、期待する結果を付けたテストケースへ整理します。合格と不合格の判定が担当者で割れない粒度まで書きます。

  • 01パラメータの上限・下限と状態遷移の境界を選ぶ
  • 02通信断・中断・同時操作の条件を組み合わせる
  • 03操作手順ごとに期待結果と合否基準を定義する
OUTPUTテスト項目書(期待値つき)
STEP 04 実施結果と未実施範囲をリリース判断に使える証跡として残す未実施範囲も含めて配信判断へ
どう確かめるか

実施結果と未実施範囲をリリース判断に使える証跡として残す

実施した条件、期待した結果、実際の結果を一組にして記録し、確認していない範囲も同じ表へ書き添えます。配信の可否を判断する場でも、ユーザーへ経緯を説明する場でもたどれる状態にします。

  • 01実施条件・期待結果・実施結果の証跡を記録する
  • 02未実施の端末・メカニクスと残存リスクを整理する
  • 03配信可否の判断に使える報告へまとめる
OUTPUTテスト結果報告(未実施範囲つき)
05 RATIONALE

私たちGENZが、このようなソフトウェアテストを代行します

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

オフィスで担当者同士がノートPCを前に、在庫管理システムのテスト観点を相談しながら整理している風景。第三者視点のテスト支援を想起させる実写写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 開発側の思い込みや先入観に影響されず、仕様の抜け漏れを検出できる
  • テスト技法にもとづく境界値・異常系の網羅で、見逃しを減らせる
  • 開発チームがテスト工数から解放され、開発に専念できる
06 SERVICE

5,000件以上の実績に裏付けられた伴走型支援

GENZは既存の開発チームや内製のデバッグ体制と役割を分け、テスト計画の立案から実行、報告までを第三者の立場で引き受けます。アップデートが続く運営のなかで、配信のたびに確認する範囲と優先順位を組み直します。

SVC 01

観点設計から始めるテスト伴走

機材や人数をそろえる前に、追加したメカニクスと既存機能の接点、マスタ変更が影響する範囲、通信仕様の変更点を洗い出し、確認する順序を決めます。

在庫のリスク要因を並べ、優先順位を高低で示した赤白紙カード基調の無文字図解。
SVC 02

仕様書レビューまで含む支援範囲

実機での実行だけでなく、企画書や仕様書のレビューも支援の範囲に入れ、定義の抜けた進行フラグや、仕様書に整理されていないマスタ上の数値を指摘します。

仕様変更に応じて回帰テストの対象範囲が更新される様子を示した赤白紙カード基調の無文字図解。
SVC 03

開発・運営体制に合わせた役割分担

内製のデバッグ体制があるならテスト設計だけ、配信直前なら実行の増員だけ、開発と運営が別会社なら受け入れテストの補助を担います。

第三者の視点で計画・設計・実施・報告が一貫してつながる流れを示した赤白紙カード基調の無文字図解。
SVC 04

未確認範囲と残存リスクの報告

確かめた端末とメカニクスの組み合わせも、未確認の範囲も同じ一覧に並べ、影響範囲、重要度、再現条件、残るリスクを配信の判断へ渡します。

機能テストと関連テスト(性能・セキュリティ等)を並べて区分した赤白紙カード基調の無文字図解。
07 FLOW

ご相談から納品までの流れ

対象範囲と判断基準を先に合わせ、進捗と残るリスクを共有しながら進めます。

ヒアリングで対象範囲を具体化する

対象システム、拠点、扱うデータ、連携先、業務フロー、リリース時期を確認し、未検証領域を可視化します。

テスト計画と優先順位を合意形成

事故影響、変更量、利用頻度、代替手段の有無から優先順位を定め、必要な工数と計画を具体化します。

テスト実施と進捗・課題を毎回共有

実施状況、発見事項、阻害要因、追加確認が必要な仕様を共有し、終盤のまとめ出しを避けます。

報告書納品と再テスト支援まで実施

テスト完了レポートに結果、証跡、未実施範囲、残留リスクを整理し、修正後の再テスト条件まで引き継ぎます。

5,000件以上の対応実績

ゲームアプリのテスト範囲と優先順位をGENZに相談する

無料相談では、確認すべきゲーム機能、テスト範囲、優先順位、必要工数の考え方、負荷・脆弱性診断の要否を整理してお返しします。機能テスト・非機能テストも仕様書レビューも対象です。