ソフトウェア・テストにはさまざまな種類があり、それぞれに特定の目的と戦略があります。

• 受け入れテスト：システム全体が意図したとおりに動作するかを検証します。
• コード・レビュー：新しいソフトウェアや変更されたソフトウェアが組織のコーディング基準に従い、そのベスト・プラクティスに沿っていることを確認します。
• 統合テスト：ソフトウェアのコンポーネントや機能が連携することを確認します。
• ユニット・テスト：各ソフトウェア・ユニットが意図したとおりに動作することを検証します。 ユニットとは、アプリケーションの中のテスト可能な最小コンポーネントを意味します。
• 機能テスト：機能要件に基づき、ビジネス・シナリオを想定して機能を確認します。 ブラックボックス・テストは、機能を検証するために一般的に使用されている方法です。
• パフォーマンス・テスト：さまざまなワークロードでソフトウェアがどのように動作するかをテストします。 例えば、負荷テストは、実際の負荷条件下でのパフォーマンスを評価するために使用されます。
• 回帰テスト： 新しい機能が壊れたり、機能が低下していないかを確認します。 健全性テストは、回帰テストをすべて行う時間がない場合に、メニュー、機能、コマンドを表面レベルで検証するために使用できます。
• セキュリティー・テスト：ハッカーやその他の悪意のある攻撃者が脆弱性を悪用して、サービスへのアクセスを拒否したり、誤った動作をさせたりする可能性がないことを確認します。
• ストレス・テスト：システムが故障するまでにどれだけのストレスに耐えうるかをテストします。 ストレス・テストは、非機能テストの一種とみなされています。
• ユーザビリティー・テスト：顧客がシステムやWebアプリケーションを使用してタスクを完了できるかを検証します。

いずれの場合も、基本要件の検証は欠かせません。同様に重要なことは、探索的テストは、テスト担当者や担当チームがソフトウェアのエラーにつながりうる予測困難なシナリオや状況を明らかにするのに役立ちます。

単純なアプリケーションであっても、多数のさまざまなテストが行われる可能性があります。 テスト管理計画は、利用可能な時間とリソースを念頭において、どのタイプのテストが最も有用か、優先順位付けするのに役立ちます。 実行するテストの数を最小限に抑えながら、特定できる欠陥数を最大化できるのが理想的です。

ソフトウェア・テストは、第二次世界大戦直後、ソフトウェアの開発と同時に登場しました。コンピューター科学者であったTom Kilburn博士が、1948年6月21日に英国のマンチェスター大学で発表された最初のソフトウェアを開発したとされています。 このソフトウェアは、マシン・コードで欠かれた指示に基づき、数学的計算を実行しました。

ソフトウェア・テストの誕生時から約20年間、主流はデバッグ・デスとでした。1980年代頃までには、開発チームはソフトウェアのバグの切り分けと修正にとどまらず、本番環境でアプリケーションをテストできるよう取り組むようになっていました。これにより、ソフトウェア開発ライフサイクルの一部である品質保証プロセスを含む、テストをより広範に捉えるための準備が整いました。

ソフトウェアを開発するにあたり、品質管理の必要性に異論を唱える人はほとんどいません。 配信日程の遅れやソフトウェアにおける欠陥はブランドの評判を傷つけ、顧客の不満や喪失につながる可能性があります。 最悪のケースでは、バグや欠陥により、連携先のシステムの機能が低下したり、重大な誤動作が発生したりする可能性があります。

日産が100万台以上の自動車をリコールせざるを得なかった原因は、エアバッグ・センサー検知器のソフトウェアにおける欠陥や、12億米ドルの軍事衛星の打ち上げに失敗したソフトウェアのバグでした。¹ 数字がそれを物語っています。2016年、米国で起きたソフトウェア障害により、1兆1,000億米ドルの資産が失われ。さらに、44億人の顧客に影響を与えました。²

テスト自体には費用がかかりますが、優れたテスト技術とQAプロセスを導入していれば、企業は開発とサポートに年間数百万ドルのコストを削減できます。 初期段階でソフトウェア・テストを行うことにより、製品が市場に出る前に問題を発見することができます。 開発チームがテストのフィードバックを早い段階で受け取れるほど、次のような問題に早く対処できるようになります。

• アーキテクチャー上の欠陥
• 設計上の判断ミス
• 無効または正しくない機能
• セキュリティーの脆弱性
• 拡張性における問題

開発中にしっかりとテストを行えるようにすることで、ソフトウェアの信頼性が向上し、エラーのほとんどない高品質のアプリケーションを提供できるようになります。また、顧客の期待に応え、あるいはそれを上回るシステムは、潜在的な売上増と市場シェアの拡大につながります。

ソフトウェア・テストは、一般的なプロセスに従い行います。テストには、テスト環境の定義、テスト・ケースの開発、スクリプトの作成、テスト結果の分析、および欠陥レポートの提出が含まれます。

テストの実施には時間がかかる場合があります。 小規模なシステムの場合は、手動テストまたはアドホック・テストで十分な場合があります。 ただし、大規模なシステムでは、タスクを自動化するために複数のツールが使用されることが一般的です。 自動テストは、チームがさまざまなシナリオを実装し、差別化要因（コンポーネントをクラウド環境に移行させるなど）をテストし、何が機能し、何が機能しないのかに関するフィードバックを迅速に得るのに役立ちます。

優れたテスト手法には、アプリケーション・プログラミング・インターフェース（API）やユーザー・インターフェース、およびシステム・レベルでのテストなどがあります。 テストを自動化し、早期に実行され、回数が多ければ多いほど、より良い結果が得られます。 テスト自動化ツールを社内で構築するチームもありますが、ベンダーは次のような主要なテスト管理タスクを効率化できるソリューションを提供しています。

継続的なテスト

プロジェクト・チームは、各ビルドが利用可能になる度にテストします。 このタイプのソフトウェア・テストは、デプロイメント・プロセスに組み込まれたテストの自動化に依存します。 これにより、プロセスの早い段階でソフトウェアを現実的なテスト環境で検証できるようになり、設計が改善され、リスクが軽減されます。

コンフィグレーション管理

組織はテスト資産を一元管理し、テスト対象となるソフトウェアのビルドを追跡します。 チームは、コード、要件、設計文書、モデル、テスト スクリプト、テスト結果などの資産にアクセスできます。 優れたシステムには、最小限の管理労力でチームがコンプライアンス要件を満たすのに役立つユーザー認証機能と監査証跡機能が含まれています。

サービス仮想化

特にコード開発の初期段階では、テスト環境が利用できない場合があります。 その場合に、サービス仮想化を使用することで、欠落しているサービスやシステム、または未完成のサービスやシステムをシミュレートし、チームが依存関係を減らし、より早くテストできるようにします。 元の環境を変更することなく、構成を再利用、展開、変更して、さまざまなシナリオをテストできます。

欠陥またはバグの追跡

欠陥のモニタリングは、テストチームと開発チームが品質を測定および改善するために重要です。 自動化ツールを使用すると、チームは欠陥を追跡し、その範囲と影響を測定し、関連する問題を明らかにすることができます。

メトリクスとレポート

レポートと分析により、チーム・メンバーはステータス、目標、テスト結果を共有できます。 高度なツールはプロジェクトのメトリクスを統合し、結果をダッシュボードに表示します。 チームは、プロジェクトの全体的な健全性を迅速に把握し、テスト、開発、その他のプロジェクト要素間の関係を監視することができます。