答え。

問題の経緯:

グローバリゼーションの時代において、ますます多くの製品が多言語化されています。ローカリゼーションのテスト（翻訳、日付、数値、通貨などのフォーマット）は、特に新しい市場へのリリースがUIやロジックの変更を伴う場合、手動テスト担当者にとって重要なタスクです。ローカリゼーションの確認は、誤解を招くエラー、不正確な翻訳、ユーザーエクスペリエンスの問題を防ぐために必要です。

問題:

この種のテストを自動化するのは難しいです。視覚的、意味的、文化的な側面が重要です。「長い言葉のためにレイアウトが崩れる」、「不一致な測定単位」、「日付フォーマットの変更による機能の停止」などのエラーがよく発生します。テスターはしばしばテキストの表面的な確認のみを行うことに限られます。

解決策:

プロセスの組織には以下が含まれます：

- 用語集に従ったすべての翻訳の正確性の確認
- 長い文字列と短い文字列のテスト（ドイツ語、フィンランド語などに重要）
- 選択されたロケールのコンテキストでの日付、数字、通貨の表示の確認
- UIの正確性の確認：切り捨てられたテキストがないか、折り返しがあるか、画面上のすべてが読みやすいか
- "異なる"言語でのすべての変更のテスト（例えば、RTL表示を必要とするアラビア語）

主な特徴：

視覚的アーティファクトと非標準シナリオの手動確認
ロケールの詳細（日付、通貨、呼称の形式）への注意
承認された翻訳用語集による検証

トリッキーな質問。

翻訳の品質を確認するために、ローカライズされたテキストと英語の元のテキストを単純に比較するだけで十分ですか？

いいえ、意味、言語の特性、フォーマットのニュアンス、UIとの統合を考慮する必要があります。翻訳は文字通り "正しい" かもしれませんが、言語のネイティブスピーカーにとっては完全に不適切な場合があります。

製品がヨーロッパの言語で機能している場合、RTL言語のテストをスキップできますか？

いいえ、RTLサポート（アラビア語、ヘブライ語）は、レイアウトの特別な変更を必要とし、手動テストなしでは要素の再配置や機能の喪失が発生する可能性があります。

テスト担当者の慣れ親しんだ言語だけでローカリゼーションをテストするべきですか？

いいえ、ネイティブスピーカーを引き込み、特に異なる文化や測定システムの市場では言語学者のサービスを利用する必要があります。

一般的なエラーとアンチパターン

用語集と比較せずに「目視」でのテスト
非標準の長さの文字列のテストをスキップ
ロケールの特有の特徴（通貨、複数形、日付のフォーマット）の無視

実生活の例

ネガティブケース

テスターはアプリケーションの英語版とロシア語版のみを確認し、ドイツ語をテストしませんでした。リリース後、ユーザーはボタンの切り捨てられたテキストと読みづらいメッセージについて不満を述べました。

長所：

短時間でテストを通過

短所：

プロダクションでのレイアウトの問題
ユーザーの忠誠心の低下

ポジティブケース

テスターは全てのサポートされているロケールでUIを確認し、ドイツ語の長い単語の問題を記録し、修正後に再テストしました。全ての修正は時間通りに行われました。