ソフトウェアテストとは

今日のソフトウェアテストは、継続的に行うことが最も効果的とされています。つまりソフトウェアの設計段階中、構築中、本番環境へのデプロイ中、デプロイ後にも評価・検証を実施します。継続的テストでは、組織はすべてのパーツがデプロイされるまでテストを待つ必要がありません。最近では、より初期工程に近い段階でテストを行う「シフト・レフト」や、エンドユーザーが検証を行う「シフト・ライト」というテスト哲学もソフトウェア業界で注目を集めています。テスト戦略と管理計画を理解すると、求められる配信速度に合わせてテストのあらゆる側面を自動化することが不可欠になります。

ソフトウェアテストには、特定の目的と戦略を有する以下のさまざまな種類があります。

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

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

シンプルなアプリケーションであっても、多数かつ多様なテストの対象となる可能性があります。テスト管理計画は、利用可能な時間とリソースを考慮し、最大の価値を提供するテストの優先順位を決定するのに役立ちます。実行するテストの数を最小限に抑えながら、特定できる欠陥数を最大化できるのが理想的です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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