ソフトウェアテスト戦略

この記事では、ソフトウェア テストに役立つ一連の戦術について説明します。これは、ソフトウェア品質保証(より一般的には品質保証(従来は頭字語「QA」で呼ばれる) として知られている)とテスト方法の一般的な適用(通常は単に「テスト」または「開発者テスト」と呼ばれる) に対する戦術的アプローチの包括的なリストとして意図されています。

インストール テストでは、システムが実際の顧客のハードウェアに正しくインストールされ、動作していることを保証します。

ソフトウェア テスト方法は、従来、ホワイト ボックス テストとブラック ボックス テストに分けられます。これら 2 つのアプローチは、テスト エンジニアがテスト ケースを設計する際の視点を説明するために使用されます。

ホワイト ボックス テスト (ソース コードを見ることで、クリア ボックス テスト、グラス ボックス テスト、透明ボックス テスト、構造テストとも呼ばれる) は、エンド ユーザーに公開される機能ではなく、プログラムの内部構造または動作をテストします。ホワイト ボックス テストでは、システムの内部的な観点とプログラミング スキルを使用してテスト ケースを設計します。テスターは入力を選択してコード内のパスを実行し、適切な出力を決定します。これは、回路内のノードをテストすること (たとえば、インサーキット テスト(ICT)) に似ています。

ホワイト ボックス テストは、ソフトウェア テスト プロセスのユニット レベル、統合レベル、システムレベルで適用できますが、通常はユニット レベルで実行されます。ユニット内のパス、統合中のユニット間のパス、システム レベル テスト中のサブシステム間のパスをテストできます。このテスト設計方法では多くのエラーや問題を発見できますが、仕様の未実装部分や要件の不足を検出できない場合があります。

ホワイト ボックス テストで使用される手法は次のとおりです。

• API テスト– パブリックおよびプライベートAPI (アプリケーション プログラミング インターフェイス)を使用したアプリケーションのテスト
• コード カバレッジ- コード カバレッジのいくつかの基準を満たすテストを作成します (例: テスト設計者は、プログラム内のすべてのステートメントが少なくとも 1 回実行されるようにテストを作成できます)
• フォールトインジェクション法 – テスト戦略の有効性を測定するために意図的にフォールトを導入する
• 突然変異検査法
• 静的テスト方法

コード カバレッジ ツールは、ブラック ボックス テストを含むあらゆる方法で作成されたテスト スイートの完全性を評価できます。これにより、ソフトウェア チームは、めったにテストされないシステム部分を調べ、最も重要な機能ポイントがテストされていることを確認できます。^{[1] [信頼できないソース? ]}ソフトウェア メトリックとしてのコード カバレッジは、次のパーセンテージとして報告できます。

• 関数カバレッジは実行された関数をレポートします
• ステートメントカバレッジは、テストを完了するために実行された行数を報告します。
• 決定カバレッジは、特定のテストのTrueブランチとFalseブランチの両方が実行されたかどうかを報告します。

100% のステートメント カバレッジにより、すべてのコード パスまたは分岐 (制御フローの観点から) が少なくとも 1 回は実行されることが保証されます。これは正しい機能を保証するのに役立ちますが、同じコードが異なる入力を正しくまたは誤って処理する可能性があるため、十分ではありません。

ブラックボックステストはソフトウェアを「ブラックボックス」として扱い、内部実装の知識やソースコードを見ることなく機能を検査します。テスターはソフトウェアが何をすべきかだけを認識しており、どのように実行するかは認識していません。^[2]ブラックボックステストの方法には、同値分割、境界値分析、全ペアテスト、状態遷移表、決定表テスト、ファズテスト、モデルベーステスト、ユースケーステスト、探索的テスト、仕様ベーステストなどがあります。

仕様ベースのテストは、適用可能な要件に従ってソフトウェアの機能をテストすることを目的としています。^[3]このレベルのテストでは通常、テスト担当者に徹底的なテストケースを提供する必要があります。テスト担当者は、特定の入力に対して、出力値 (または動作) がテストケースで指定された期待値と同じか同じでないかを確認するだけです。テストケースは、アプリケーションが行うことになっている仕様と要件を中心に構築されます。テストケースを導き出すには、仕様、要件、設計など、ソフトウェアの外部記述を使用します。これらのテストは機能テストでも非機能テストでもかまいませんが、通常は機能テストです。

仕様に基づいたテストは正しい機能を保証するために必要かもしれませんが、複雑な状況やリスクの高い状況を防ぐには不十分です。^[4]

ブラック ボックス テクニックの利点の 1 つは、プログラミングの知識が不要であることです。プログラマーがどのような偏見を持っていたとしても、テスターはおそらく異なる偏見を持っており、異なる機能領域を重視する可能性があります。一方、ブラック ボックス テストは、「懐中電灯なしで暗い迷路を歩くようなもの」と言われています。^[5] ソース コードを調べないため、テスターが 1 つのテスト ケースだけでテストできるものをチェックするために多くのテスト ケースを書いたり、プログラムの一部をテストしないままにしたりすることがあります。

このテスト方法は、ユニット、統合、システム、受け入れのソフトウェア テストのすべてのレベルに適用できます。通常、上位レベルのテストのほとんど、またはすべてで構成されますが、ユニット テストも支配的になることがあります。

ビジュアルテストの目的は、開発者が必要な情報を簡単に見つけることができ、その情報が明確に表現されるようにデータを提示することで、ソフトウェア障害が発生した時点で何が起こっていたのかを調査する能力を開発者に提供することである。^{[6] [7]}

ビジュアル テストの核となるのは、問題 (またはテストの失敗) を単に説明するのではなく、誰かに見せることで、明確さと理解が大幅に向上するという考えです。したがって、ビジュアル テストでは、テスト プロセス全体を記録する必要があります。つまり、テスト システムで発生するすべてのことをビデオ形式でキャプチャします。出力ビデオには、ピクチャー イン ア ピクチャー Web カメラによるリアルタイムのテスター入力と、マイクからの音声解説が補足されます。

ビジュアル テストには、多くの利点があります。テスターは開発者に問題 (およびそれに至るイベント) を単に説明するだけでなく、実際に見せることができるため、コミュニケーションの質が大幅に向上し、多くの場合、テストの失敗を再現する必要がなくなります。開発者は、テストの失敗について必要なすべての証拠を入手し、代わりに障害の原因と修正方法に集中できます。

アジャイル手法では、テスターと開発者間のコミュニケーションと小規模チーム内でのコラボレーションがより多く必要となるため、ビジュアル テストはソフトウェア開発にアジャイル手法を導入する環境に特に適しています。^[要出典]

アドホック テストと探索的テストは、ソフトウェアの整合性をチェックするための重要な方法です。実装に必要な準備時間が短く、重要なバグをすぐに見つけることができるからです。アドホック テストでは、即興で即興的にテストが行​​われるため、バグを発見するために実行された手順を文書化するために、システムで発生するすべての事象を視覚的に記録するテスト ツールの機能が非常に重要になります。^{[説明が必要] [引用が必要]}

ビジュアルテストは、開発プロセスに関わる多くの個人が使用できるため、顧客受け入れテストやユーザビリティテストで認知度が高まっています。 ^[要出典]顧客にとっては、詳細なバグレポートやフィードバックを提供することが容易になり、プログラムユーザーにとっては、ビジュアルテストによって画面上のユーザーアクションだけでなく、音声や画像も記録できるため、開発者はソフトウェア障害発生時の全体像を把握できます。

グレーボックステスト（アメリカ式綴り：グレーボックステスト）では、テストを設計するために内部データ構造とアルゴリズムの知識を持ち、それらのテストをユーザーレベルまたはブラックボックスレベルで実行します。テスターはソフトウェアのソースコードに完全にアクセスできる必要はありません。^[2]入力データの操作と出力のフォーマットはグレーボックスとはみなされません。なぜなら、入力と出力は明らかにテスト対象システムと呼ばれる「ブラックボックス」の外側にあるからです。この区別は、 2 人の異なる開発者によって書かれた 2 つのコードモジュール間の統合テストを実行するときに特に重要です。この場合、インターフェイスのみがテスト用に公開されます。

ただし、データベースやログ ファイルなどのバックエンド データ リポジトリを変更する必要があるテストは、通常の運用操作ではユーザーがデータ リポジトリを変更できないため、グレー ボックスとして分類されます。^{[引用が必要]}グレー ボックス テストには、境界値やエラー メッセージなどを決定するためのリバース エンジニアリングも含まれる場合があります。

ソフトウェアがどのように動作するかという基本的な概念を知ることで、テスターは外部からソフトウェアをテストする際に、より情報に基づいたテストの選択を行うことができます。通常、グレーボックステスターは、データベースのシードなどのアクティビティを含む分離されたテスト環境をセットアップすることが許可されます。テスターは、データベースに対してSQL文を実行し、クエリを実行して、予想される変更が反映されていることを確認するなどの特定のアクションを実行した後、テスト対象の製品の状態を観察できます。グレーボックステストは、限られた情報に基づいてインテリジェントなテストシナリオを実装します。これは、データ型の処理、例外処理などに特に当てはまります。^[8]

多くのプログラミング グループ、特にテスト駆動開発を使用するグループは 、自動テストにますます依存するようになっています。テストを記述するためのフレームワークは多数あり、継続的インテグレーションソフトウェアは、コードがバージョン管理システムにチェックインされるたびに自動的にテストを実行します。

自動化では、人間が実行できることすべて (および人間が考えつくすべての方法) を再現することはできませんが、回帰テストには非常に役立ちます。ただし、自動化が本当に役立つためには、十分に開発されたテスト スクリプトの テスト スイートが必要です。

プログラムのテストと障害検出は、テスト ツールとデバッガーによって大幅に支援されます。テスト/デバッグ ツールには次のような機能が含まれます。

• プログラム モニター。以下を含むプログラム コードの完全または部分的な監視を可能にします。
  • 命令セットシミュレーター、完全な命令レベルの監視とトレース機能を可能にする
  • ハイパーバイザーは、以下を含むプログラムコードの実行を完全に制御できます。
  • プログラムアニメーション、ソースレベルまたはマシンコードでのステップバイステップの実行と条件付きブレークポイントを許可
  • コードカバレッジレポート
• フォーマットされたダンプまたはシンボリックデバッグ、エラー時または選択したポイントでのプログラム変数の検査を可能にするツール
• 自動化された機能GUI（グラフィカルユーザーインターフェイス）テストツールは、GUIを介してシステムレベルのテストを繰り返すために使用されます。
• ベンチマークにより実行時のパフォーマンス比較が可能
• ホットスポットやリソースの使用状況を明らかにするのに役立つパフォーマンス分析（またはプロファイリングツール）

これらの機能の一部は、単一の複合ツールまたは統合開発環境(IDE) に組み込まれる場合があります。

一般的に、テストにはユニットテスト、統合テスト、コンポーネントインターフェーステスト、システムテストの 4 つのレベルが認められています。テストは、ソフトウェア開発プロセスで追加された場所、またはテストの特殊性のレベルによってグループ化されることがよくあります。SWEBOKガイドで定義されている開発プロセスの主なレベルは、ユニットテスト、統合テスト、システムテストであり、特定のプロセスモデルを暗示することなくテスト対象によって区別されます。^{[9]その他のテストレベルは}、テストの目的によって分類されます。^[9]

顧客の観点から見ると、テストには低レベルテスト (LLT) と高レベルテスト (HLT) の 2 つのレベルがあります。LLT は、ソフトウェア アプリケーションまたは製品のさまざまなレベルのコンポーネントに対する一連のテストです。HLT は、ソフトウェア アプリケーションまたは製品全体に対する一連のテストです。^{[引用が必要]}

ユニットテストとは、通常は関数レベルで特定のコードセクションの機能を検証するテストを指します。オブジェクト指向環境では、これは通常クラスレベルであり、最小限のユニットテストにはコンストラクタとデストラクタが含まれます。^[10]

これらのタイプのテストは通常​​、開発者がコード (ホワイト ボックス スタイル) で作業しながら作成し、特定の機能が期待どおりに動作していることを確認します。 1 つの機能に複数のテストがあり、コーナー ケースやコード内の他の分岐を捕捉する場合があります。 ユニット テストだけではソフトウェアの機能を検証することはできませんが、ソフトウェアの構成要素が互いに独立して動作していることを確認するために使用されます。

ユニット テストは、ソフトウェア開発のリスク、時間、コストを削減するために、幅広い欠陥防止および検出戦略を同期して適用するソフトウェア開発プロセスです。ソフトウェア開発ライフサイクルの構築フェーズでソフトウェア開発者またはエンジニアによって実行されます。従来の QA の焦点を置き換えるのではなく、それを補強します。ユニット テストの目的は、コードが QA に昇格される前に構築エラーを排除することです。この戦略は、結果として得られるソフトウェアの品質と、開発および QA プロセス全体の効率を向上させることを目的としています。

組織のソフトウェア開発に対する期待に応じて、ユニット テストには、静的コード分析、データフロー分析、メトリック分析、ピア コード レビュー、コード カバレッジ分析、およびその他のソフトウェア検証プラクティスが含まれる場合があります。

統合テストは、ソフトウェア設計に対してコンポーネント間のインターフェースを検証するソフトウェア テストの一種です。ソフトウェア コンポーネントは、反復的に統合することも、すべてまとめて統合することもできます (「ビッグバン」)。通常、前者の方がインターフェースの問題をより迅速に特定して修正できるため、より優れた方法であると考えられています。

統合テストは、統合されたコンポーネント（モジュール）間のインターフェースと相互作用における欠陥を明らかにするために行われます。アーキテクチャ設計の要素に対応するテスト済みのソフトウェアコンポーネントのグループが徐々に大きくなり、ソフトウェアがシステムとして機能するまで統合されテストされます。^[11]

コンポーネント・インターフェース・テストの実践は、ユニット間の完全な統合テストを超えて、さまざまなユニットまたはサブシステム・コンポーネント間で渡されるデータの処理をチェックするために使用できます。^{[12] [13]}渡されるデータは「メッセージ・パケット」と見なすことができ、あるユニットから生成されたデータについては範囲またはデータ型をチェックし、別のユニットに渡す前に有効性をテストできます。インターフェース・テストの1つのオプションは、渡されるデータ項目の別のログ・ファイルを保持することです。多くの場合、タイムスタンプが記録され、数日または数週間にわたってユニット間で渡される何千ものデータのケースを分析できます。テストには、他のインターフェース変数が通常の値として渡されている間に、いくつかの極端なデータ値の処理をチェックすることを含めることができます。^{[12]インターフェースの異常なデータ値は、次のユニットでの予期しないパフォーマンスを説明するのに役立ちます。コンポーネント・インターフェース・テストは}ブラックボックス・テストのバリエーションであり、^[13]サブシステム・コンポーネントの関連するアクションを超えてデータ値に焦点を当てています。

システムテストは、完全に統合されたシステムをテストして、システムが要件を満たしていることを確認します。^[14]たとえば、システムテストでは、ログオンインターフェイスのテスト、エントリの作成と編集、結果の送信または印刷、エントリの要約処理または削除（またはアーカイブ）、ログオフが行われます。

運用承認は、品質管理システムの一環として、製品、サービス、またはシステムの運用準備 (リリース前) を実施するために使用されます。OAT は、非機能ソフトウェア テストの一般的なタイプであり、主にソフトウェア開発およびソフトウェア保守プロジェクトで使用されます。このタイプのテストは、サポートされるシステム、および/または実稼働環境の一部となるシステムの運用準備に重点を置いています。そのため、運用準備テスト (ORT) または運用準備および保証(OR&A) テストとも呼ばれます。OAT内の機能テストは、システムの 非機能面を検証するために必要なテストに限定されます。

さらに、ソフトウェアテストでは、システムの移植性が期待通りに機能するだけでなく、動作環境に損傷を与えたり部分的に破損したり、その環境内の他のプロセスが動作しなくなったりしないことを確認する必要があります。^[15]

ソフトウェア障害(実際の障害または認識上の障害) の一般的な原因は、他のアプリケーション ソフトウェア、オペレーティング システム(またはオペレーティング システムのバージョン、新旧を問わず)、または元の環境とは大きく異なるターゲット環境 (デスクトップでの実行を意図した端末または GUI アプリケーションが、Web ブラウザーでレンダリングする必要がある Web アプリケーションになる必要がある場合など)との互換性の欠如です。たとえば、下位互換性がない場合は、プログラマーが最新バージョンのターゲット環境でのみソフトウェアを開発およびテストしているために、すべてのユーザーがそのバージョンを実行しているとは限らないために発生する可能性があります。その結果、最新の作業が以前のバージョンのターゲット環境、または以前のバージョンのターゲット環境で使用できた古いハードウェアでは機能しないという意図しない結果が発生します。このような問題は、オペレーティング システムの機能を別のプログラムモジュールまたはライブラリに積極的に抽象化することで修正できる場合があります。

健全性テストでは、さらにテストを進めることが妥当かどうかを判断します。

スモーク テストは、ソフトウェアを最小限の操作で実行し、ソフトウェアの動作を妨げる基本的な問題があるかどうかを判断することを目的としています。このようなテストは、ビルド検証テストとして使用できます。

回帰テストは、大規模なコード変更が発生した後の不具合の発見に重点を置いています。具体的には、古いバグが再発するなど、機能の低下や消失などのソフトウェアの回帰を明らかにしようとします。このような回帰は、以前は正しく動作していたソフトウェア機能が意図したとおりに動作しなくなったときに発生します。通常、回帰はプログラム変更の予期しない結果として、ソフトウェアの新しく開発された部分が以前から存在するコードと衝突したときに発生します。回帰テストの一般的な方法には、以前のテストケースセットを再実行し、以前に修正された不具合が再発していないかどうかを確認することが含まれます。テストの深さは、リリースプロセスのフェーズと追加された機能のリスクによって異なります。リリースの後半で追加された変更やリスクが高いと見なされる変更の場合は完全なテストになり、リリースの早い段階で変更が行われたかリスクが低いと見なされる場合は、各機能に対する肯定的なテストで構成される非常に浅いテストになります。回帰テストは、通常、商用ソフトウェア開発において最も大きなテスト作業です。^[16]これは、以前のソフトウェア機能の多数の詳細をチェックするためです。また、以前の機能が引き続きサポートされていることを確認するために、古いテストケースを使用して新しい設計の一部をテストしながら、新しいソフトウェアを開発することもできます。

受け入れテストは、次の 2 つのいずれかを意味します。

1. スモークテストは、新しいビルドをメインのテスト プロセスに導入する前、つまり統合または回帰の前に、受け入れテストとして使用されます。
2. 顧客がラボ環境で自社のハードウェアを使って行う受け入れテストは、ユーザー受け入れテスト(UAT) と呼ばれます。受け入れテストは、開発の 2 つのフェーズ間の引き継ぎプロセスの一部として実行されることがあります。^[要出典]

アルファテストは、潜在的なユーザー/顧客または開発者のサイトでの独立したテストチームによるシミュレーションまたは実際の運用テストです。アルファテストは、ソフトウェアがベータテストに進む前に、内部受け入れテストの一形態として市販ソフトウェアによく使用されます。^[17]

ベータ テストはアルファ テストの後に行われ、外部ユーザー受け入れテストの一種と考えることができます。ベータ バージョンと呼ばれるソフトウェアのバージョンは、ベータ テスターと呼ばれるプログラミング チーム以外の限られたユーザー向けにリリースされます。ソフトウェアはグループにリリースされ、さらにテストを行って製品に欠陥やバグがほとんどないことを確認できます。ベータ バージョンは、フィードバックフィールドを将来のユーザー最大数に増やし、より早く価値を提供するために、長期間または無期限 (永久ベータ) で一般に公開することができます。^{[引用が必要]}

機能テストとは、コードの特定のアクションまたは機能を検証するアクティビティを指します。これらは通常、コード要件ドキュメントに記載されていますが、一部の開発手法はユースケースまたはユーザー ストーリーに基づいて機能します。機能テストは、「ユーザーはこれを実行できるか」または「この特定の機能は動作するか」という質問に答える傾向があります。

非機能テストとは、スケーラビリティやその他のパフォーマンス、特定の制約下での動作、セキュリティなど、特定の機能やユーザー アクションに関連しない可能性のあるソフトウェアの側面を指します。テストでは、スケーラビリティやパフォーマンスが極端になると実行が不安定になる限界点を特定します。非機能要件は、特にユーザーの適合性の観点から、製品の品質を反映する要件になる傾向があります。

継続的テストとは、ソフトウェア配信パイプラインの一部として自動テストを実行し、ソフトウェアリリース候補に関連するビジネスリスクに関する即時のフィードバックを得るプロセスです。 ^{[18] [19]継続的テストには、}機能要件と非機能要件 の両方の検証が含まれます。テストの範囲は、ボトムアップ要件またはユーザーストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価にまで及びます。^{[20] [21] [22]}

破壊的テストは、ソフトウェアまたはサブシステムに障害を発生させることを試みます。無効または予期しない入力を受け取った場合でもソフトウェアが正しく機能することを検証し、入力検証およびエラー管理ルーチンの堅牢性を確立します。 ^[要出典] ファジング形式のソフトウェア障害注入は、障害テストの一例です。ソフトウェア障害注入ページには、さまざまな商用の非機能テストツールへのリンクがあります。また、破壊的テストを実行するオープンソースおよび無料のソフトウェアツールも多数あります。

パフォーマンス テストは、通常、特定のワークロードにおけるシステムまたはサブシステムの応答性と安定性のパフォーマンスを判断するために実行されます。また、スケーラビリティ、信頼性、リソース使用率など、システムのその他の品質属性を調査、測定、検証、または確認するためにも使用できます。

負荷テストは主に、大量のデータや多数のユーザーなど、特定の負荷の下でシステムが動作し続けることができるかどうかをテストすることに関係しています。これは通常、ソフトウェアのスケーラビリティと呼ばれます。非機能アクティビティとして実行される関連する負荷テスト アクティビティは、多くの場合、耐久テストと呼ばれます。ボリューム テストは、特定のコンポーネント (ファイルやデータベースなど) のサイズが大幅に増加した場合でもソフトウェア機能をテストする方法です。ストレス テストは、予期しないまたはまれなワークロード下での信頼性をテストする方法です。安定性テスト(多くの場合、負荷テストまたは耐久テストと呼ばれます) は、ソフトウェアが許容期間内またはそれ以上に継続的に正常に機能できるかどうかを確認します。

パフォーマンス テストの具体的な目標についてはほとんど合意が得られていません。負荷テスト、パフォーマンス テスト、スケーラビリティ テスト、ボリューム テストという用語は、多くの場合、同じ意味で使用されます。

リアルタイム ソフトウェアシステムには厳しいタイミング制約があります。タイミング制約が満たされているかどうかをテストするには、リアルタイム テストを使用します。

ユーザビリティ テストは、ユーザー インターフェイスが使いやすく、理解しやすいかどうかを確認することです。主にアプリケーションの使用に関係します。

アクセシビリティテストには、次のような標準への準拠が含まれる場合があります。

• 1990年アメリカ障害者法
• 1973年リハビリテーション法第508条改正
• ワールドワイドウェブコンソーシアム（W3C）のウェブアクセシビリティイニシアティブ（WAI）

機密データを処理するソフトウェアでは、ハッカーによるシステム侵入を防ぐためにセキュリティ テストが不可欠です。

国際標準化機構（ISO）はこれを「テスト項目および関連するデータと情報が、権限のない人物やシステムが使用、読み取り、変更できないように保護され、権限のある人物やシステムがアクセスを拒否されない程度を評価するために実施されるテストの種類」と定義しています。^[23]

ソフトウェアの国際化およびローカライズの一般的な能力は、疑似ローカリゼーションを使用することで、実際の翻訳を行わずに自動的にテストできます。疑似ローカリゼーションを使用すると、アプリケーションが新しい言語に翻訳されたり、新しい文化（異なる通貨やタイムゾーンなど）に適応された後でも、アプリケーションが引き続き機能することが検証されます。^[24]

実際の人間の言語への翻訳もテストする必要があります。ローカリゼーションの失敗として考えられるものは次のとおりです。

• ソフトウェアは、多くの場合、文脈を無視した文字列のリストを翻訳することによってローカライズされ、翻訳者はあいまいなソース文字列に対して間違った翻訳を選択する可能性があります。
• プロジェクトが適切な調整なしに複数の人によって翻訳された場合、または翻訳者が不注意であった場合、技術用語に一貫性がなくなる可能性があります。
• 逐語的な翻訳は、対象言語では不適切、不自然、または技術的すぎるように聞こえる可能性があります。
• 元の言語で翻訳されていないメッセージは、ソース コード内にハードコードされたままになることがあります。
• 一部のメッセージは実行時に自動的に作成され、結果の文字列が文法的に正しくなかったり、機能的に間違っていたり、誤解を招いたり、混乱を招いたりする可能性があります。
• ソフトウェアは、ソース言語のキーボード レイアウトでは機能しないが、ターゲット言語のレイアウトで文字を入力するために使用されるキーボード ショートカットを使用することがあります。
• ソフトウェアはターゲット言語の文字エンコードをサポートしていない可能性があります。
• ソース言語で適切なフォントとフォント サイズが、ターゲット言語では不適切である可能性があります。たとえば、フォントが小さすぎると、CJK 文字が判読できなくなる可能性があります。
• ターゲット言語の文字列がソフトウェアで処理できる長さを超えている可能性があります。これにより、文字列の一部がユーザーに見えなくなったり、ソフトウェアがクラッシュしたり誤動作したりする可能性があります。
• ソフトウェアには双方向テキストの読み取りまたは書き込みに対する適切なサポートがない可能性があります。
• ソフトウェアはローカライズされていないテキストを含む画像を表示する場合があります。
• ローカライズされたオペレーティング システムでは、システム構成ファイルと環境変数の名前が異なっていたり、日付と通貨の形式が異なっていたりする場合があります。

「開発テスト」は、ソフトウェア開発のリスク、時間、コストを削減するために、幅広い欠陥防止および検出戦略を同期して適用するソフトウェア開発プロセスです。これは、ソフトウェア開発ライフサイクルの構築フェーズでソフトウェア開発者またはエンジニアによって実行されます。従来の QA の焦点を置き換えるのではなく、それを補強します。開発テストの目的は、コードが QA に昇格される前に構築エラーを排除することです。この戦略は、結果として得られるソフトウェアの品質と、開発および QA プロセス全体の効率を向上させることを目的としています。

組織のソフトウェア開発に対する期待に応じて、開発テストには、静的コード分析、データフロー分析、メトリック分析、ピアコードレビュー、ユニットテスト、コードカバレッジ分析、トレーサビリティ、およびその他のソフトウェア検証プラクティスが含まれる場合があります。

A/B テストは基本的に、1 つの変数のみが変更された場合の 2 つの出力の比較です。テストを実行し、1 つを変更し、再度テストを実行し、結果を比較します。これは、より小規模な状況でより役立ちますが、あらゆるプログラムの微調整に非常に役立ちます。より複雑なプロジェクトでは、多変量テストを行うことができます。

同時実行テストでは、ストレス テストやファズ テストとは異なり、通常の入力と通常の動作条件で継続的に実行されているときのパフォーマンスに重点が置かれます。この方法では、メモリ リークや基本的な障害を見つけやすくなります。

ソフトウェア テストでは、適合性テストによって、製品が指定された標準に従って動作するかどうかが検証されます。たとえば、コンパイラは、その言語の公認標準を満たしているかどうかを判断するために、広範囲にテストされます。