海外市場で販売される複合機には、日本語や英語だけでなく、ドイツ語、スペイン語、中国語、韓国語、さらにはアラビア語など、多くの言語への対応が求められます。
実際、複合機やプリンターの公開マニュアルを見ると、日本語、英語、ドイツ語、スペイン語、簡体字・繁体字中国語、韓国語、アラビア語など、多数の表示言語を選択できる製品が存在します。
しかし、多言語対応で本当に難しいのは、翻訳された文字列が正しいかどうかだけではありません。
日本語では問題なく表示されていた画面が、ドイツ語に切り替えた途端にボタンからはみ出す。中国語では一部の文字が正しく表示されない。アラビア語では文字の方向だけでなく、アイコンやボタンの配置まで違和感のある画面になる――。
つまり、多言語GUIでは、
「正しい言葉が登録されていること」と「ユーザーに正しい画面として見えていること」は別の品質問題
として考える必要があります。
翻訳データが正しくても、画面が正しいとは限らない
例えば、複合機の設定画面に「セキュリティ設定」というボタンがあるとします。
日本語では十分な幅に収まっていたとしても、ドイツ語では同じ意味を表す文字列が長くなり、ボタン幅を超える可能性があります。
さらに言語が変われば、
- 文字列の長さ
- 改行位置
- フォント
- 文字サイズ
- 行間
- ボタン内の余白
- アイコンとの位置関係
なども変化します。
中国語・日本語・韓国語のようなCJK言語では使用するフォントや文字コードへの配慮が必要になり、アラビア語などRTL（Right-to-Left）の言語では、単に文字を右から左へ表示するだけでなく、画面レイアウトそのものへの考慮も必要になります。
したがって、多言語GUIの品質確認では「翻訳結果が正しい」というだけでは十分ではありません。
最終的にユーザーが見る画面が正しいか。
ここまで確認して、初めて多言語対応の品質を確認したと言えるのではないでしょうか。
多言語GUIで起きる代表的な表示不具合
正常な日本語表示に対し、ドイツ語での文字切れ、中国語での文字欠落、RTL言語でのレイアウト問題など、
文字列そのものが正しくても画面上では異常が発生する例を示しています。
Webアプリとは異なる、複合機GUIテストの難しさ
Webアプリケーションであれば、SeleniumやPlaywrightなどを利用し、HTMLのDOMや要素属性を基にボタン、入力フィールド、メニューなどを特定してテストする方法が一般的です。
しかし、複合機をはじめとする組込み機器では、必ずしも同じ方法が利用できるとは限りません。
操作パネルが独自GUIで構成されている場合や、テスト対象が実機、シミュレーター、リモート画面などにまたがる場合には、テストツール側からアプリケーション内部のオブジェクト情報を取得できないケースもあります。
そこで考えたいのが、
「内部構造を見る」のではなく、「ユーザーに見えている画面を見る」
というテストアプローチです。
T-Plan RobotはGUIの画面レベルで操作・検証を行うVisual UI Test Automationを特徴としており、画面上の表示を画像として認識し、ユーザーと同じ視点で操作や検証を実行します。T-Planの公式情報でも、ソースコードやオブジェクトIDに依存せず、画面上の要素を画像ベースで認識・検証する仕組みが説明されています。
この特性は、内部構造へのアクセスが難しい組込みGUIをテストする際に、大きな意味を持ちます。
「文字列」と「見え方」の2つを分けて検証する
多言語GUIテストでは、品質を大きく2つに分けて考えると分かりやすくなります。
一つ目は**文字列品質（Linguistic Quality）**です。
例えば、
- 正しい翻訳が表示されているか
- 翻訳漏れがないか
- 別言語の文字が残っていないか
- 文字が欠落していないか
といった確認です。
ここではOCRを利用して画面上の文字を読み取り、あらかじめExcelなどに用意したGolden Dataと比較する方法が考えられます。
二つ目はVisual品質です。
例えば、
- 文字がボタンからはみ出していないか
- 不自然な位置で改行されていないか
- 他の文字やアイコンと重なっていないか
- ボタンやアイコンの位置が崩れていないか
- RTL表示時の配置が適切か
といった確認です。
こちらはOCRだけでは十分ではありません。
文字列が正しく認識できたとしても、その文字が画面上で適切な位置に表示されているとは限らないからです。
そこで、OCRによる文字列確認と画像ベースのVisual Checkを組み合わせるという考え方が有効になります。
T-Plan Robotは画像認識による画面検証に加え、OCRによるテキスト認識もサポートしています。
OCR＋画像比較で「2つの正しさ」を確認
Golden DataとOCR結果を比較する「文字列品質」の確認と、画像ベースで画面の見え方を確認する
「Visual品質」の確認を組み合わせます。
ExcelのGolden Dataを基準に多言語画面を確認する
例えば、Excelに次のようなGolden Dataを用意します。
| ID | 日本語 | English | Deutsch | Español |
|---|---|---|---|---|
| M01 | コピー | Copy | Kopieren | Copiar |
| M02 | スキャン | Scan | Scannen | Escanear |
| M03 | 設定 | Settings | Einstellungen | Configuración |
テストでは複合機の言語設定を変更し、対象画面を表示します。
T-Plan Robotが指定された画面領域をOCRし、取得した文字列をGolden Dataと比較します。
例えばドイツ語画面で本来「Einstellungen」と表示されるべき場所に「Settings」が残っていれば、翻訳漏れとして検出できます。
一方、OCR結果が「Einstellungen」で一致していたとしても、文字がボタンからはみ出していればVisual品質としてはNGです。
このように、
Text PASS ＋ Visual PASS ＝ GUIとしてPASS
という品質基準を設定することができます。
これが、多言語GUIを単なる翻訳確認から「ユーザーが見る最終画面の品質保証」へ発展させる重要なポイントです。
1つの操作シナリオを複数言語で繰り返す
さらに大きなメリットは、同じテストシナリオを言語ごとに繰り返せることです。
例えば、
- 複合機を起動
- 言語設定を日本語へ変更
- ホーム画面を確認
- コピー画面を開く
- OCRと画像比較を実行
- スキャン画面を確認
- 結果を記録
というシナリオを作成します。
その後、同じ操作をEnglish、Deutsch、Español、中文、한국어、Arabicなどに切り替えて実行します。
仮に50画面を10言語で確認するとすれば、それだけで500画面分の確認が必要になります。
さらにソフトウェア更新のたびに同じ確認を繰り返すとなれば、人の目だけで継続的に確認する作業負荷は小さくありません。
自動化の目的は、人による確認を完全になくすことではありません。
機械が繰り返し確認できる部分を自動化し、人は「差分」や「異常が検出された画面」を重点的に確認する。
この役割分担こそ、多言語GUIテスト自動化の現実的な使い方ではないでしょうか。
多言語GUIのE2E自動検証イメージ
同じE2Eテストシナリオを言語設定だけ切り替えて繰り返し、
言語ごとのPASS／FAILやVisual差分をレポートとして確認します。
複合機の「機能」だけでなく「見え方」も品質保証の対象へ
複合機の品質保証では、コピーできる、スキャンできる、印刷できるといった機能確認はもちろん重要です。
しかし、ユーザーが実際に操作する製品である以上、正しい文字が、正しい位置に、正しく読める状態で表示されていることも製品品質の一部です。
特にグローバル展開される製品では、対応言語が増えるほど、人の目による確認だけではテスト工数も増大します。
そこで、OCR、Golden Data、画像認識、E2E自動操作を組み合わせ、「ユーザーに何が見えているのか」を継続的に確認する仕組みを構築することが重要になります。
T-Plan RobotのVisual GUI Testingは、DOMや内部オブジェクトだけに依存するのではなく、ユーザーと同じ画面を基準としてGUIを検証するというアプローチです。
複合機の多言語テストを、
「翻訳文字列の確認」から「多言語GUI全体の品質保証」へ。
それが、T-Plan Robotを複合機のLocalization Testingに活用する際の一つの考え方です。
チャネルブリッジでは、T-Plan Robotを活用した組込み機器・複合機・タッチパネルGUIなどのVisual GUI Test Automation、および多言語GUI検証についてご紹介しています。
「現在行っている目視テストのどこまでを自動化できるのか」「実機やシミュレーターを使った検証が可能か」など、ご興味がございましたらお気軽にお問い合わせください。
T-Plan Robotの導入・技術検証をご検討中ですか？
T-Plan Robotのデモ、1ヶ月間無償体験については、下記よりお気軽にお問い合わせください。