多言語リリースのテスト計画 — 組み合わせ爆発を減らすマトリクスの作り方
12言語。4プラットフォーム。コントローラーとキーボード。新規セーブと引き継ぎセーブ。3種類のアスペクト比。2段階の文字サイズ設定。正直に全部掛け合わせると数千通りのテストになり、こちらにあるのは3週間とテスター4人です。
つい「とりあえず始めて、どこまで行けるか見る」という進め方をしがちです。しかしそれで出来上がるのは、誰が速く消化したか、どの順で手をつけたかで形の決まった結果です。リリース判定の会議で言えるのは「何が見つかったか」だけで、「何をカバーしたか」は誰にも言えません。そして、その計画は誰も到達しなかった言語がフォント崩れのまま出荷されるまで、問題なさそうに見え続けます。
仕事は全部テストすることではありません。何をテストしないのか、そしてなぜかを、意図的に、文書として決めることです。ローカライズのテストマトリクスは、その判断を目に見える形にしたものです。そしてこれはゲーム全体のQA計画ではなく、ゲームの「言語という次元」の計画であること、最後までやり切れる大きさに保つべきものであることは、作業中ずっと意識しておく価値があります。
組み合わせはどこから来るのか
爆発が起きるのは、思いつく限りの軸を全言語に掛けてしまうからです。掛ける前にまず軸を書き出すことが、削減を可能にします。
- 言語 — ゲーム側の表示言語設定
- OS・システムロケール — 上とは別の軸で、忘れられやすい
- プラットフォームとストアビルド — PCの各ストア、コンソール、モバイル
- 入力デバイス — コントローラー、キーボードとマウス、タッチ
- 表示 — 解像度、アスペクト比、DPIスケーリング、ゲーム内の文字サイズ設定
- セーブ状態 — 新規、途中セーブ、旧バージョンからの引き継ぎ
- 所有状態 — 本編のみ、DLC所持、予約特典、体験版からの引き継ぎ
- ネットワーク状態 — オンライン、オフライン、サーバーから配信されるテキスト
この中で最も見落とされやすいのが、ゲーム内の言語設定とは独立した軸としてのシステムロケールです。プレイヤーはOSを一つの言語で、ゲームを別の言語で動かせます。その状態では、日付書式、数値の区切り、キー名の表記、場合によってはどのシステムフォントが選ばれるかまでが、ゲームの言語設定ではなくOS側から来ます。しかもこれは、テスト機のOS言語とテスト対象の言語を揃えているテスターには、書式のバグが最も見えにくくなる構成でもあります。
とはいえ、すべての軸を掛け合わせる必要はありません。そこが唯一にして最大のレバーです。
言語と相互作用しない軸を落とす
軸ごとに問いは一つです。これを変えると、表示されるテキストの内容、レイアウト、使われるフォントのいずれかが変わるか。答えが「いいえ」なら、その軸はローカライズのマトリクスではなく通常のQAに属します。言語固有の不具合を生み得ない軸に12言語を掛けることが、何も見つけないまま3週間の計画を3か月にする方法です。
この問いを一般的な軸に当てはめると、対象はかなり絞られます。
- 入力デバイス — 基本は「いいえ」。ただし例外が一つ、ボタン表示やキー名はローカライズ対象のテキストなので、言語ごとに全デバイスではなく、表示系統ごとに1デバイスをカバーする
- アスペクト比・解像度 — 「はい」。折り返し位置と使える幅が変わる。文字量に敏感な言語が壊れるのはまさにそこ
- 文字サイズ・アクセシビリティのスケーリング — 「はい」。手持ちの中で最も厳しいはみ出しテストになる。既定サイズで収まる言語が一段上げると収まらないことは珍しくない
- OSロケール — 書式とフォント選択について「はい」。ただし全言語ではなく代表的な数言語で確認すれば足りる
- セーブ状態 — 基本は「いいえ」。重要な例外は、表示時に引き当てるのではなく言語依存のテキストをセーブに書き込んでしまっている箇所
- 所有状態・ネットワーク状態 — 言語の挙動としては通常「いいえ」。例外はサーバーから配信されるテキストで、これは独自の言語判定とフォールバック経路を持つ
落とした軸は、黙って省略するのではなく理由とともに計画に書いてください。「入力デバイスは言語と掛け合わせない。ボタン表示の文字列はPCとコンソールで表示系統ごとに1回ずつカバーする」という一文は、リリース判定の場で説明できる判断です。行が無いだけの状態は説明になりませんし、半年後に「あのケースは確認したのか」と聞かれたとき、意図的な省略と単なる見落としを区別できません。
全言語を平等に扱わず、階層に分ける
全言語に等しくカバー範囲を割り当てるのは公平に聞こえますが、固定された工数の使い方としては良くありません。言語ごとにリスクの量は実際に違い、その違いはテスト開始前に計画に織り込める程度には予測可能です。
その言語を厚めに見るべき方向へ押す要因はこうです。
- 文字体系とレイアウト挙動 — CJKの行分割、右横書きの反転、字形の結合や整形を必要とする文字は、原語では一度も通らない失敗経路を作る
- 文字量の膨張 — 原語よりかなり長くなる言語は、余白のないUI要素をすべて見つけ出してくれる
- 文法の負荷 — 複数の複数形、文法上の性、格変化は、英語では表面化しない形で文字列の単純連結を壊す
- 翻訳の作られ方 — 軽いポストエディットのみの機械翻訳は、レビュー済みの人手翻訳よりリスクが高く、その前提でテストすべき
- 今回が初出荷かどうか — 初めて出す言語はプレイヤーに一度も叩かれていない。長く出している言語には何年分の報告が蓄積している
- 翻訳者がゲームを見ているか — 文脈なしにスプレッドシートだけで訳されたテキストは、文脈の中で壊れる頻度が高い
- 利用者の規模 — 品質の議論ではないが、不具合1件のコストを左右する現実的な要因
これらから3つの階層に分けます。Aは全体パス — 通しプレイ、あるいは相当量の縦切りを、実際の文脈で。Bは重点画面への的を絞ったパスと、自動チェックで挙がった箇所の確認。Cはスモークテストのみ — 起動する、メニューが正しい言語で出る、初回フローが最後まで通る、明らかな未翻訳や見切れがない。
階層分けを健全に保つ条件は2つです。各言語がその階層にいる理由を記録すること。そうすれば次のリリースで既定事実として引き継ぐのではなく、もう一度議論できます。そして根拠が変わったら階層を変えること。C階層の言語からプレイヤー報告が続いているなら、それは配置が間違っていたという知らせですし、初出荷でA階層に置いた言語は、安定した実績ができれば通常は一段下げられます。
機械的な行は自動チェックで先に消す
人がマトリクスの1マスを実行する前に、機械的に検出できる種類の問題はゼロになっているべきです。ここに挙げたものをテスターが見つけた場合、それはスクリプトのほうが速く、早く、しかも全言語同時に見つけられるものに工数を使ったということです。しかも遅く見つかるということは、修正がテスターの使っていたビルドより後に届くということでもあります。
- いずれかの言語での未翻訳・空欄・一部欠落したエントリ
- 原文と訳文の間でのプレースホルダ・変数の不一致
- 壊れた、欠けた、対応が取れていないマークアップやリッチテキストのタグ
- 文字化けや、出荷するフォントで表示できない文字
- マージ後の重複キー・孤立キー
- UIの枠に対して宣言した文字数上限を超えている文字列
一方、どんなチェックにもできないことがあります。その一文が自然かどうか、その状況に対して用語が適切かどうか、その画面に置かれたときに意味が通るかどうか、冗談や文化的な言及が生き残っているかどうか、そして推定値ではなく実際の描画幅で本当に切れているかどうか。人手のパスは限られた時間をここに使うべきであり、だからこそ機械的な種類の問題が同じ時間を奪い合ってはいけないのです。
順序もカバー範囲と同じくらい重要です。自動チェックはビルドごとに走らせ、人手のマトリクスはそれを通過したビルドに対して走らせます。未翻訳が200件残っているビルドに対してマトリクスを実行すると、一つの問題について200件の報告が積み上がり、本当に見つけるべき5件がその下に埋まります。
マトリクスを書き出す
マトリクス自体は退屈でよいものです。1マス1行、担当者、状態、そして空欄なし。空欄は、これまでに開かれたあらゆる進捗会議で「合格」として読まれてきました。「未実施」を、誰かが自分で入力しなければならない明示的な値にしてください。
# ローカライズテストマトリクス — 1マス1行、空欄は禁止 # 範囲: full = 通しプレイ | hrs = 重点画面 | smoke = 起動確認 言語 階層 環境 設定 範囲 担当 状態 en A pc 1080p / kb+mouse full ai 合格 ja A pc 1080p / pad full ko 合格 ja A console-a 1080p / pad hrs ko 未解決2 de A pc 1080p / kb+mouse hrs ms 未解決3 de A pc 1080p / 文字サイズ大 hrs ms 未実施 ar A pc 1080p / kb+mouse hrs ms 未解決5 zh-Hans B pc 1440p / pad hrs lin 合格 ru B pc 1080p / kb+mouse hrs lin 未実施 ko B console-a 1080p / pad hrs rt 合格 fr C pc 1080p / kb+mouse smoke rt 合格 es C pc 1080p / pad smoke rt 合格 pt-BR C pc 1080p / kb+mouse smoke rt 未実施 # 横断行 — 代表言語に対して1回だけ実施する OSロケール不一致 (OS=ja/ゲーム=en, OS=en/ゲーム=de) ai 合格 サーバー配信テキストとオフライン時のフォールバック lin 未解決1
文書のもう半分が重点画面のリストで、これがB階層とC階層を安くします。階層に関係なく全言語が必ず通る、短く固定されたリストにしてください。選ぶ基準は、そこでの失敗が起きやすいか、起きたときに高くつくかです。
- 初回フロー — 言語選択、規約や同意の画面、チュートリアルの指示
- 動的な値が入る画面 — カウンター、タイマー、通貨、所持数、プレイヤー名
- 手持ちで最も情報密度の高い画面 — 多くの場合、インベントリ、設定、ステータス
- エラー・切断・購入失敗のメッセージ — 到達しづらく、そのぶん見られていない
- セーブ、ロード、言語切り替えの流れ — プレイ途中での切り替えを含む
- ストア掲載テキストと実績・トロフィーの文字列 — ビルドの外で入稿するため、典型的な抜け
実行の順序と、「合格」の意味
作業は、後続を解放するものから順に並べてください。深いパスを始める前に、まず全階層の全言語でスモークテストを終えます。起動しない、違う言語で表示される、豆腐(□)が並ぶ、といった言語は、その上に組んだ計画をすべて無効にします。それを9日目ではなく初日に見つけられることが、マトリクスを作る価値のかなりの部分です。
1マスが「合格」とはどういうことかを、誰かが実行する前に定義してください。定義がなければ、テスターはそれぞれ自分の基準を発明します。使いやすい定義はこうです。範囲内のすべての画面にその構成で到達した。見つかった問題はすべて、ビルド・言語・環境・画面を明記したスクリーンショットとともに記録した。残っている未解決の問題は深刻度で分類されている。証拠が付いていない合格は記憶であり、記憶は修正後に確認し直せません。
そして、埋まらなかったマスを、恥ずかしい残りではなく主要な成果物として扱ってください。リリース判定の場で有用なのは「すべて合格しました」ではありません。「これらの言語は全体パス、これらは重点カバー、これらはスモークのみ、この3マスは未実施で、それでも出すことで受け入れるリスクはこれです」です。この一文なら、チーム全員で決められる判断になります。静かな空白の残った緑のグリッドは、疲れた一人が深夜2時に一人で下した判断であり、それに依存していることを会議室の誰も知らないままになります。