ローカリゼーション テストとはテストケースとチェックリストの例

ローカリゼーションテスト

ローカリゼーションテスト は、特定の地域、ロケール、または文化に対してソフトウェアの動作をテストするソフトウェア テスト手法です。 ソフトウェアのローカリゼーション テストを行う目的は、特定のロケールに適切な言語的および文化的側面をテストすることです。 これは、対象の言語と国に応じてソフトウェアをカスタマイズするプロセスです。

ローカリゼーション テストの影響を受ける主な領域には、コンテンツと UI が含まれます。

これは、UI、デフォルト言語、通貨、日付、時刻形式、およびドキュメントが対象国または地域に従って設計されたグローバル化されたアプリケーションをテストするプロセスです。 これにより、アプリケーションがその特定の国で使用するのに十分な能力があることが保証されます。

例：

1. プロジェクトがインドのタミル・ナドゥ州向けに設計されている場合、設計されたプロジェクトはタミル語である必要があり、タミル語仮想キーボードが存在する必要があります。

2. プロジェクトが米国向けに設計されている場合は、米国標準時に従って時刻形式を変更する必要があります。 また、言語と通貨の形式は米国の標準に従う必要があります。

下の図は、同じ製品が異なる地域向けに調整される様子を示しています。言語、通貨、書式設定ルールは変更されますが、基盤となるビルドは同じままです。

ローカリゼーション テストを行う理由

ローカリゼーション テストを行う目的は、特定のロケールに適切な言語的および文化的側面をチェックすることです。 これには、ユーザー インターフェイスの変更や、要件に応じた初期設定の変更も含まれます。

このタイプのテストでは、多くの異なるテスターが同じ機能を繰り返します。 彼らは、タイプミス、UI の文化的適切性、言語的エラーなど、さまざまなことを検証します。

「ローカライゼーション」という単語のLとNの間に10文字あることから、「L10N」とも呼ばれます。

この取り組みには商業的な理由もある。ラベルの誤訳や、日付が03月ではなく04月と誤って表記されているといったことは、チームが既に参入費用を支払った市場における信頼を損なう。そして、こうした欠陥は、ターゲット地域にいるテスターに​​よって発見されるのであって、 GUIテスト 英語で上演されました。

ローカリゼーションテストと国際化テスト

この2つの作業は競合するのではなく、連続して行われます。国際化テスト（I18N）では、コードベースがあらゆるロケールに対応できることを確認し、次にローカライズテスト（L10N）で、特定のロケールが正しいことを確認します。

ローカリゼーションテスト（L10N）	国際化テスト（I18N）
製品が特定の対象地域で自然に感じられることを検証します。	製品が再開発なしで多くの地域をサポートできることを検証する
翻訳されたテキスト、通貨、日付、時刻、文化的な適合性をチェックします。	文字エンコーディング、文字列の外部化、ロケール対応コードをチェックします。
その市場向けの翻訳済みビルドが存在する場合に実行されます。	翻訳のためにテキストが送信される前に最初に実行されます
現地語を話せるテスターまたはレビュアーが必要です	コアチームが擬似翻訳ビルドを使用して実行できます。

このチュートリアルを確認してください ローカリゼーションとグローバリゼーションのテストの違い.

ローカリゼーション テストの方法

一般的なローカリゼーション テストでは、ビルド検証テストを設定します。 機能テスト, 回帰テスト、最終承認。

1. ビルド検証テストは、次の小さなサブセットです。 機能テストこれは、QAが詳細なテストを開始する前に実施されるものです。精神的には、 煙テスト言語パックの読み込みに全く失敗した場合、ローカライズされたビルドはすぐに拒否されます。

2. 通常のテストは、通常のテスト ケースを実行し、実行中にログの欠陥を見つけるステップです。

3. 回帰テストは 欠陥 回帰プロセスを使用して、修正された欠陥が周囲の領域に影響を及ぼさないようにしながら、欠陥が修正されていることを確認します。

4. 最終サインオフでは、クライアントに配信する前にビルドの最終チェックを実行します。

各フェーズは製品ごとに一度ではなく、ロケールごとに繰り返されます。フランス語ビルドで修正された不具合は、ドイツ語ビルドと日本語ビルドでも再発させる必要があります。これは、同じ文字列リソースがこれらのビルド間で共有されていることが多いためです。

ローカリゼーションテストにおける自動化

プロジェクトが大きく、頻繁にテストする必要がある場合は、次のようにします。 自動化テスト.

• スクリプトを作成する自動化ツールを選択します。
• ローカリゼーション戦略をテストするシナリオを考えてみましょう。
• それに従ってスクリプトを書きます。
• 結果を収集し、合格/不合格としてシナリオを更新します。

注意： Selenium は、この分野における先駆的なツールの XNUMX つです。 非常に機能が豊富ですが、使用するにはより専門的な知識が必要です。

自動化には、明確に述べておくべき限界がある。スクリプトは通貨記号が変更されたことや文字列が途中で途切れていないことを証明できるが、翻訳が自然に読めるかどうか、アイコンが不適切かどうかを判断することはできない。機械によるチェックは機械的な側面を処理するが、言語的な側面は依然としてネイティブのレビュアーが担当する。

ローカリゼーションテストツール

ローカライズ作業では3種類の異なるツールが使用され、ほとんどのチームは最終的にこれら3種類すべてを使用することになる。

• 機能自動化フレームワーク： Selenium, Appium また、同様のフレームワークでは、各ロケールビルドに対して同じスイートが再実行されるため、反復的な検証の大部分が発生します。
• 翻訳管理システム： 文字列リソースを保持するプラットフォームを使用することで、翻訳者、開発者、テスターは単一の用語集に基づいて作業できるため、同じ用語が2つの画面で2つの異なる方法で翻訳されるといった事態を防ぐことができます。
• 擬似位置特定ユーティリティ： これらは、実際の翻訳が始まる前に、英語の文字列をアクセント付きの長いプレースホルダーに置き換えるため、ハードコードされたテキストや、より長い単語を処理できないレイアウトが露呈する。

デバイスとブラウザの対応状況は、ツールと同じくらい重要です。フォント、入力方法、デフォルトのロケールはプラットフォームごとに異なるため、ローカライズされたビルドは実際のターゲットデバイスでテストする必要があります。 モバイルテスト ブラウザセット全体で定義されています Webアプリケーションのテスト.

ローカライゼーションテストのベストプラクティスチェックリスト

• i18nエンジニアリングの専門知識を持つローカライズ会社を雇う
• ローカリゼーション テスト戦略で、2 バイト言語に十分な時間を確保できるようにしてください。
• DBCS のコードを適切に国際化してから実行してください。trac翻訳のために送信するテキストを入力してください
• ユーザーが目にするテキストがソースコードにハードコーディングされないように、まずすべての文字列をリソースファイルに外部化してください。
• 翻訳費用をかける前に、擬似ローカライズ版を早めに実行してください。そうすることで、翻訳の切り捨てやハードコードされたテキストの問題を特定できます。
• 英語からの翻訳は元のラベルよりも長くなることが多いため、テキストの拡張に備えてレイアウトスペースを確保しておきましょう。
• アラビア語やヘブライ語など、右から左に書く言語は、実際の画面でテストしてください。左右反転したレイアウトや、左右が混在するテキストは、最も頻繁に不具合を起こします。
• 日付の順序、小数点区切り記号、住所の形式、敬称、トーンなどを網羅した、地域ごとのスタイルガイドを作成・維持する。
• 完成した画面はネイティブスピーカーに確認してもらいましょう。なぜなら、文化的な適合性は脚本だけでは証明できないからです。

これらの項目のうち2つは言語ではなくプラットフォームに依存するため、ローカライズされたビルドは通常、 互換性テスト (NAIST) と 構成テスト 彼らの後ではなく、彼らの後を追う。

ローカリゼーション テストのテスト ケースの例

以下の表は、チェック項目の初期セットを示しています。各行は完全な テストケース 特定の地域における期待される結果が入力されたら。

S.No	テストケース Descriptexpression CMS
1	用語集は参照および確認のために利用できます。
2	時刻と日付はターゲット地域に合わせて適切にフォーマットされます。
3	電話番号の形式は対象地域に応じて適切です。
4	ターゲット地域の通貨。
5	ライセンスとルールは現在の Web サイト (地域) に従っていますか。
6	ページ内のテキスト コンテンツのレイアウトにはエラーがなく、フォントは独立しており、行の位置も調整されています。
7	特殊文字、ハイパーリンク、ホットキー機能。
8	入力フィールドの検証メッセージ。
9	生成されたビルドには、必要なファイルがすべて含まれています。
10	ローカライズされた画面には、ソース製品と同じタイプの要素と番号が含まれます。
11	ソフトウェアまたは Web アプリケーションのローカライズされたユーザー インターフェイスが、ターゲット オペレーティング システムおよびユーザー環境のソース ユーザー インターフェイスと一致していることを確認します。
12	並べ替えやアルファベット順の順序付けは、原文言語ではなく、翻訳先言語の規則に従います。
13	右から左への表示形式の場合、ナビゲーション、アイコン、左右混合の文字列を含め、レイアウトが正しく反映されます。
14	キーボード入力、スペルチェック、検索機能は、アクセント付き文字とマルチバイト文字に対応しています。

ローカリゼーション テストの利点

ローカリゼーションテストの利点は次のとおりです

• 全体的なテストコストの削減
• 全体的なサポートコストの削減
• テスト時間の短縮に役立ちます。
• より高い柔軟性と拡張性を備えています。

これらのコスト削減は、地域ごとの不具合を市場サポートキューごとに一度ずつではなく、中央で一度だけ検出することによって実現されます。アクセシビリティの向上も多くの場合伴います。なぜなら、長いドイツ語文字列でもレイアウトを維持する規律は、拡大されたテキストでもレイアウトを維持するからです。 アクセシビリティテスト.

ローカリゼーション テストの欠点

ローカリゼーションテストの課題は次のとおりです。

• ドメインの専門家が必要
• 現地の翻訳者を雇うと手続きに費用がかかることが多い
• DBCS 文字の格納方法は国ごとに異なります
• テスターはスケジュールの問題に直面する可能性があります

スケジュールのプレッシャーは、ほとんどのチームが過小評価しているものです。翻訳は定義上サイクルの後半に行われるため、ローカライズの欠陥はリリース直前に表面化します。まさにその時期にレイアウトの変更が最もコストがかかるのです。ロケールの計画は、より広範な計画に含まれます。 ソフトウェアテストの種類 その窮屈さを管理可能な範囲に保ち、一般的な ソフトウェアテスト 序論では、この段階が全体的にどのような位置づけにあるのかを説明する。

よくあるご質問