ソフトウェアのテスト方法について知っておくべきことすべて
コンテンツ
ソフトウェアが公共または商業用に出荷される前に、プログラマーはすべてのバグを解決するのに何時間も費やし、すべての利害関係者が満足するまで製品は不安定なままです。
GoogleやFacebookのようなシリコンバレーソフトウェアの巨人は、ソフトウェアの優先度の低いバグにもかかわらず、人気のある製品を市場に出荷することがよくあります。投資家や何百万人もの忠実なユーザーは、これらのバグがデータ侵害や悪い宣伝につながる場合でも、これらの会社が提供する無料の製品でソフトウェアの更新や一時的なねじれを許容します。
ソフトウェア企業の大多数は、このような贅沢を持っていません。顧客は、製品が販売ページで主張することを実行することを期待しており、ビジネスの知的財産と機密データの脆弱性について当然のことながら警告しています。非常に多くのソフトウェア開発オプションを利用できるので、製品が時間とお金の浪費に悪臭を放っていても、顧客は出荷を急いで考えることはありません。したがって、ソフトウェアビジネスは、顧客にリリースする前に、製品に対して厳密なテストを実行する必要があります。これらのテストは以下の洞察を提供します：
- 元のコンセプトと最終出力の違いを強調します。
- ソフトウェアが設計者の計画どおりに機能することを確認します。
- 機能と品質を評価します。
- 最終製品が顧客の要件を満たしていることを確認します。
テストは厳密な青写真に従って、ワークロード、時間、およびお金を最適化すると同時に、製品を前進させるための重要な情報を関係者に提供します。目標は、徹底した品質保証（QA）プログラムを維持することで、エンドユーザーのエクスペリエンスを向上させることです。開発者にとっての大きな賭けを考えると、QAマネージャーはテクノロジー業界でトップの稼ぎ手です。テストは通常、次の手順に従います。
- 要件分析。マネージャーは、適切なテスト戦略を導入するための計画の概要を示します。
- テストが始まり、結果が分析されます。
- 欠陥は修正され、ソフトウェアは回帰テスト（プログラムが変更後も動作することを確認するシステム）を実行します。
- プロセスと結果を詳しく説明するテストクロージャレポート。
個人は、BCS、チャータードインスティテュートフォーIT、ISTQB®（International Software Testing Qualifications Board）、ASQ（旧称American Society for Quality）などの組織を通じて、認定ソフトウェアテスターになることができます。
ソフトウェアのテスト方法
ブラックボックスとホワイトボックスのテストは、製品の動作とパフォーマンスを判断するための2つの基本的な方法ですが、他の方法もあります。
- ブラックボックステスト： 機能テストまたは仕様ベースのテストとも呼ばれるこのメソッドは、出力に重点を置いています。テスターは内部メカニズムに関与していません。彼らは、ソフトウェアが想定どおりの動作をすることを確認するだけです。コーディングの知識は必要なく、テスターはユーザーインターフェイスレベルで作業します。
- ホワイトボックステスト： この方法では、テスト手順の一部としてコーディング経験を使用します。製品が失敗すると、テスターはコードを深く調べて原因を見つけます。ソフトウェア開発者は、製品がどのように機能するかを決定することを委託されているため、これを自分で行います。ホワイトボックステストは、「構造ベース」または「ガラスボックス」テストとも呼ばれます。
- 静的テスト： テスターは、ソースコードと付随するドキュメントを調べますが、プログラムは実行しません。静的テストは、検証プロセス中の製品開発の初期に開始されます。
- 動的テスト： ソフトウェアはさまざまな入力で実行され、テスターは出力を期待される動作と比較します。
- グラフィカルユーザーインターフェイス（GUI）テスト： テキストの書式設定、テキストボックス、ボタン、リスト、レイアウト、色、フォント、フォントサイズなどの特性をテストします。 GUIテストには時間がかかり、開発者の代わりにサードパーティ企業がこのタスクを実行することがよくあります。
テストレベル
さまざまなレベルのテストを使用して、ソフトウェア開発ライフサイクルの各フェーズにおける弱点と重複の領域を特定します。
- 単体テスト： 開発者は、クラス、インターフェース、関数/手順など、コードの最も基本的な部分をテストします。彼らはコードがどのように反応するかを知っており、出力に応じて調整を行うことができます。
- コンポーネントテスト： このステップは、「モジュール」または「プログラム」テストとも呼ばれます。単体テストに似ていますが、より高いレベルの統合が含まれています。ソフトウェアのモジュールは、個々の機能を検証するために欠陥がないかテストされます。
- 統合テスト： これは、モジュールが統合されているときのエラーを識別します。統合テストのさまざまな方法には、「ボトムアップ」、「トップダウン」、「機能インクリメンタル」があります。
- システムテスト： プロジェクトのコンポーネントは、さまざまな環境で全体としてテストされます。システムテストはブラックボックス方式に該当し、プロセスの最終テストの1つです。システムがビジネスおよびユーザーのニーズを満たす準備ができているかどうかを判断します。
- アルファテスト： 内部のスタッフが、シミュレートされた環境または実際の環境で開発者のサイトでソフトウェアをテストします。その後、開発者はバグやその他の問題を修正します。
- ベータテスト： フィールドテストとも呼ばれ、クライアントは実際の条件で自社のサイトで製品をテストします。クライアントは、エンドユーザーのグループにプレリリース版またはベータ版を介してソフトウェアをテストする機会を提供する場合があります。可能な改善に関するフィードバックが開発者に送信されます。
- 受け入れ試験： また、ブラックボックステストの範囲内で、クライアントはソフトウェアをテストして、開発者が目的の仕様に合うようにプログラムを完全に開発したかどうかを確認します。
テストの種類
さまざまな種類のソフトウェアテストが、特定の目的に焦点を当てるように設計されています。
- インストールテスト： テストエンジニアと構成マネージャーがこのテストを実行して、エンドユーザーがプログラムをインストールして実行できることを確認します。インストールファイル、インストール場所、管理者権限などの領域をカバーしています。
- 開発テスト： これにより、さまざまな同期戦略が実装され、欠陥を検出して防止します。これには、静的コード分析、ピアコードレビュー、トレーサビリティ、およびメトリック分析が含まれます。リスクを軽減し、コストを削減することを目的としています。
- ユーザビリティテスト： このテストでは、ユーザーエクスペリエンスが脚光を浴びています。 GUIの使いやすさを測定します。テストでは、機能の正確さと効率、および被験者の感情的反応をチェックします。
- 健全性テスト： これは、ソフトウェアがさらなるテストを継続するための時間とコストに見合うかどうかを示します。欠陥が多すぎると、より積極的なテストは行われません。
- 煙のテスト： 煙のテストは、放出を防ぐのに十分深刻な基本的な障害を明らかにします。これが新しいビルドで実行される場合、「ビルド検証」テストと呼ばれます。
- 回帰試験： システムが変更されると、回帰テストは予期しない動作を監視します。モジュールまたはコンポーネントへの悪影響を指摘します。
- 破壊試験： テスターは異常なエントリを入力し、予期しない入力を管理するソフトウェアの能力を見極めます。これは、プログラムがエラー管理でいかに堅牢であるかを開発者に示します。
- 回復テスト： ハードウェアまたは他の機能に障害が発生した場合、このテストは、ソフトウェアが回復して動作を継続できるかどうかを示します。
- 自動テスト： これは、手動で実装するのが難しい機能を実行します。特定のソフトウェアを使用してテストを実行し、実際の結果と期待される結果のデータを提供します。
- 互換性テスト： ソフトウェアはさまざまなコンピューティング環境で実行する必要があるため、さまざまなシステムとの互換性を確認します。たとえば、さまざまなオペレーティングシステムやWebブラウザでソフトウェアをテストします。
- 性能試験： これは、さまざまなシナリオでソフトウェアのパフォーマンスを調査する詳細なテストです。応答性、安定性、リソース割り当て、および速度に関する情報が収集されます。ボリューム、容量、スパイクテストなどのサブテストは、このプロセスの一部です。
- セキュリティテスト： これは、ユーザーのセキュリティを保護するソフトウェアの能力を測定します。これは、承認機能、認証、機密性、整合性、可用性、および否認防止を意味します。
- アクセシビリティテスト： これは、ユーザビリティテストとは異なります。これは、さまざまな能力、学習および身体障害を含むユーザーがソフトウェアを使用できる範囲を決定します。
- 国際化およびローカリゼーションテスト： 結果は、ソフトウェアがさまざまな言語や地域の要求にどのように適応できるかを示しています。これには、特定の場所とテキスト翻訳のためのコンポーネントの追加が含まれます。
