ソフトウェア・テストとは何か

ソフトウェアのエラーを発見し、アプリケーションまたはシステムが使用可能であることを確認します

コードの刺さったコンピューターの前に座りながら、コードの付いたスマートフォンを持っているプログラマー

ソフトウェア・テストの仕組みとは

ソフトウェア・テストは、ソフトウェア製品またはアプリケーションが想定どおりに機能することを評価および検証するプロセスです。 テストのメリットには、バグの防止、開発コストの削減、パフォーマンスの向上などがあります。


ソフトウェア・テストの種類

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

  • 受け入れテスト:システム全体が意図したとおりに機能するかどうかを確認します。
  • 統合テスト:ソフトウェア・コンポーネントまたは機能が集合体として動作することを確認します。
  • 単体テスト:各ソフトウェア・ユニットが期待どおりに動作することを検証します。 ユニットは、アプリケーションのテスト可能な最小コンポーネントです。
  • 機能テスト:機能要件に基づいて、ビジネス・シナリオをエミュレートすることで機能を確認します。 ブラックボックス・テストは、機能を検証するための一般的な手法です。
  • 性能テスト:さまざまなワークロードでソフトウェアがどのように動作するかをテストします。 たとえば、負荷テストは、実際の負荷条件下でのパフォーマンスを評価するために実施されます。
  • 回帰テスト:新機能が機能性を破壊または低下させるかどうかを確認します。 本格的な回帰テストの時間がない場合は、健全性テストを使用して、メニュー、機能、およびコマンドを表面レベルで検証できます。
  • ストレス・テスト:システムに障害が発生するまでに、システムがどれだけの負荷に耐えられるかをテストします。 これは非機能テストの一種と見なされます。
  • ユーザビリティー・テスト:顧客がシステムまたはWebアプリケーションを使用してタスクを完了することができるかどうかを検証します。

いずれの場合も、基本要件の検証が重要な評価項目となります。 同様に重要な探索的テストは、テスターまたはテスト・チームが、ソフトウェア・エラーにつながる可能性のある予測困難なシナリオや状況を発見するのに役立ちます。

単純なアプリケーションでさえ、数多くのさまざまなテストの対象となる可能性があります。 テスト管理計画は、利用可能な時間とリソースを考慮して、どのタイプのテストが最大の価値を提供するかを優先順位付けするのに役立ちます。 テストの有効性は、最も少ない数のテストを実行して最大数の欠陥を見つけることによって最適化されます。


ソフトウェア・テストの歴史

ソフトウェアのテストは、第二次世界大戦の直後に始まったソフトウェアの開発と共に誕生しました。 コンピューター科学者のトム・キルバーンは、1948年6月21日にイギリスのマンチェスター大学で披露された、世界初のソフトウェアを書いたことで知られています。 このソフトウェアは、機械語命令を使用して数学計算を実行しました。

デバッグは当時の主要なテスト方法であり、その後20年間はその状態が続きました。 1980年代には、開発チームはソフトウェアのバグを切り分けて修正するだけでなく、実際の設定でアプリケーションをテストすることを目指しました。 これが、ソフトウェア開発ライフサイクルの一部である品質保証プロセスを含む、より広い視野に立ったテストの舞台を整えました。

Alexander Yaroshko氏は、uTest開発者サイトの投稿で次のように述べています。「1990年代には、テストから品質保証と呼ばれるより包括的なプロセスへの移行がありました。これは、ソフトウェア開発サイクル全体をカバーし、テストケースの計画、設計、作成、実行や、既存のテストケースおよびテスト環境に影響を与えています。

テストは質的に新しいレベルに達し、方法論のさらなる発展や、テスト・プロセスを管理するための強力なツールおよびテスト自動化ツールの出現につながりました。」 1

継続的テスト

ソフトウェア・テストはこれまで、他の開発から分離されてきました。 多くの場合、製品のビルドまたは実行段階を経た、ソフトウェア開発ライフサイクルの後半で実行されます。 テスターには、コードをテストするための小さなウィンドウしかない場合があり、アプリケーションが市場に出る直前の場合もあります。 欠陥を発見しても、再コーディングまたは再テストする時間がほとんどないこともあります。 ソフトウェアを予定どおりにリリースすることは珍しくありませんが、バグと修正が必要となります。 または、テストチームがエラーを修正しても、リリース日を逃す場合があります。

サイクルの早い段階でテスト・アクティビティーを実行することは、テスト作業を開発の後付けとしてではなく、最前線に留めるのに役立ちます。 早期にソフトウェア・テストを実施すれば、欠陥の修正にかかる費用も少なくなります。

現在、多くの開発チームが継続的テストとして知られる方法を採用しています。 これはDevOpsアプローチの一部であり、そこでは製品ライフサイクル全体にわたって開発と運用とが連携します。 その目的は、コスト、品質、およびリスクのバランスを取りながら、ソフトウェア出荷を早めることにあります。 このテスト手法を使用すると、チームはテストを開始する前にソフトウェアが構築されるのを待つ必要がありません。 サイクルのかなり早い段階でテストを実行することで、修正が容易なときに欠陥を素早く発見できます。


ソフトウェア・テストが重要な理由

ソフトウェアを開発する際の品質管理の必要性に異議を唱える人はほとんどいないでしょう。 納期の遅れやソフトウェアの欠陥は、ブランドの評判を傷つけ、顧客の不満や喪失につながる可能性があります。 極端な場合、バグや欠陥によって相互接続されたシステムが劣化したり、重大な誤動作が発生したりする可能性があります。

日産自動車がエアバッグ・センサー検出器のソフトウェアの欠陥のために、100万台以上の車をリコールしなければならない状況を考えてみてください。 また、12億米ドルの軍事衛星の打ち上げ失敗の原因となった、ソフトウェアのバグの事例もあります。 2  数字はそれ自体を物語っています。 米国でのソフトウェア障害は2016年に、1.1兆米ドルの資産の損失をもたらしました。 さらに、障害によって44億人の顧客に影響が出ました。 3

テスト自体には費用がかかりますが、優れたテスト手法とQAプロセスが整っていれば、企業は開発とサポートにおいて年間数百万ドルを節約できます。 早期にソフトウェア・テストを実施することで、製品が市場に出る前に問題を発見できます。 開発チームがテストのフィードバックを受け取るのが早ければ早いほど、次のような問題に素早く対処できます。

  • アーキテクチャー上の欠陥
  • 不十分な設計上の決定
  • 無効な、または欠陥のある機能性
  • セキュリティーの脆弱性
  • スケーラビリティーの問題

開発に十分なテストの余地が残されている場合、ソフトウェアの信頼性が向上し、エラーの少ない高品質のアプリケーションが提供されます。 顧客の期待に応える、あるいはそれを超えるシステムは、潜在的な売上増と市場シェア拡大につながります。


ソフトウェア・テストのベスト・プラクティス

ソフトウェア・テストは一般的なプロセスを踏襲します。 こうしたタスクまたはステップには、テスト環境の定義、テスト・ケースの開発、スクリプトの作成、テスト結果の分析、および欠陥レポートの送信が含まれます。

テストには時間がかかる場合があります。 小規模なビルドには、手動テストまたはアドホック・テストで十分かもしれません。 ただし、大規模なシステムでは、タスクを自動化するためにツールが頻繁に使用されます。 自動テストは、チームがさまざまなシナリオを実装し、差別化要因(コンポーネントをクラウド環境に移動するなど)をテストし、機能するものと機能しないものに関するフィードバックをすばやく取得するのに役立ちます。

優れたテスト・アプローチには、アプリケーション・プログラミング・インターフェイス(API)、ユーザー・インターフェイス、およびシステム・レベルが含まれます。 同様に、自動化され、早期に実行されるテストが多いほど、優れたアプローチと言えます。 一部のチームは、社内のテスト自動化ツールを構築しています。 ただし、ベンダー・ソリューションは、次のような主要なテスト管理タスクを合理化できる機能を提供します。

  • 継続的テスト:プロジェクト・チームは、利用可能になった各ビルドをテストします。 このタイプのソフトウェア・テストは、実装プロセスと統合されたテスト自動化に依存しています。 これにより、プロセスの早期段階で、現実的なテスト環境でソフトウェアを検証できるようになり、設計が改善され、リスクが軽減されます。
  • 構成管理:組織はテスト資産を一元的に維持し、テストするソフトウェア・ビルドを追跡します。 チームは、コード、要件、設計ドキュメント、モデル、テスト・スクリプト、テスト結果などの資産にアクセスできます。 優れたシステムには、ユーザー認証と監査証跡が含まれており、チームが最小限の管理作業でコンプライアンス要件を満たすのに役立ちます。
  • サービスの仮想化:テスト環境は特にコード開発の初期段階において、利用できない場合があります。 サービスの仮想化は、欠落しているかまだ完了していないサービスとシステムをシミュレートし、チームが依存関係を減らしてより早くテストできるようにします。 元の環境を変更することなく、構成を再利用、展開、および変更して、さまざまなシナリオをテストできます。
  • 欠陥またはバグ追跡欠陥の監視はテスト・チームと開発チームの双方にとって、品質の測定と改善のために重要です。 自動化されたツールにより、チームは欠陥を追跡し、その範囲と影響を測定し、関連する問題を明らかにすることができます。
  • 指標とレポート:レポート作成と分析により、チーム・メンバーはステータス、目標、およびテスト結果を共有できます。 高度なツールはプロジェクトの指標を統合し、結果をダッシュボードに表示します。 チームはプロジェクトの全体的な状態をすばやく確認し、テスト、開発、およびその他のプロジェクト要素間の関係を監視できます。

関連ソリューション

IBM Rational Test Workbench

IBM Rational Test Workbenchは、APIテスト、機能UIテスト、パフォーマン・ステスト、サービス仮想化などのDevOpsアプローチをサポートするソフトウェア・テスト・ツールを提供します。


IBM Rational Test Virtualization Server

IBM Rational Test Virtualization Serverソフトウェアは、開発ライフサイクルにおける早期の頻繁なテストを可能にします。


IBM Rational Performance Tester

IBM Rational Performance Testerは、ソフトウェア・テストチームがDevOpsアプローチの一環として、より早期かつ頻繁なテスト実施を支援します。


IBM Engineering Workflow Management

1つのツールを使用して、チーム間でのコラボレーション、コードの管理、スタンドアップ・ミーティングの実行、スプリントの計画、作業の追跡を行います。 オンプレミスとクラウドで利用可能です。


IBM Rational ClearCase

IBM Rational ClearCaseは、コード、要件、設計文書、モデル、テスト計画、テスト結果などのソフトウェア資産への制御されたアクセスを提供します。


IBM Engineering Test Management

IBM Engineering Test Managementは、要件から欠陥まで、エンドツーエンドのテスト計画とテスト資産管理を提供する、協調的な品質管理ソリューションです。