ソフトウェアテストとは？

ソフトウェアテストのタイプによる違い

ソフトウェアテストのタイプは主に手動テストと自動テストに分けられます。この2つの違いを理解することが重要です。

手動テストでは、人間のテスターがアプリケーションやAPI全体を実際に操作します。テスターは、アプリケーションのすべての基本機能をチェックし、テストケースを実行して、テストレポートを作成します。

自動テストでは、テスターがソフトウェアを評価するためのテストスクリプトを記述し、自動化ツールを使ってスクリプトを実行します。スクリプトでは、予測される結果とテスト結果を比較して、アプリケーションが意図したとおりに動作しているかどうかを確認します。

手動テストと自動テストのどちらにもメリットとデメリットがあります。手動テストのメリットは、人間がテストを行うため、実際のユーザーがアプリケーションを操作する状況に近く、日常使用で発生する可能性のあるバグを発見しやすい点です。また、自動化ツールと違ってテストケースを事前に決めておく必要がなく、テスターがテスト中に状況に合わせてテストケースを考えて実行する探索的テストが可能で、柔軟性が高いというメリットもあります。一方でデメリットは、テスターがテスト環境を整え、ソフトウェアに変更があるたびに手動でテストを実行する必要があるため、コストが非常に高い点です。また、タイプミスや手順の抜けなど、人的ミスが発生しやすいという欠点もあります。

自動テストのメリットは、手動テストよりも高速に実行でき、一般的に信頼性が高い点です。自動化ツールの設定には時間とコストがかかりますが、幅広くテストできる点を含め、長期的に見ればコスト効率に優れています。人間のテスターよりもすばやく不具合を発見できる分、対応も迅速に行えるため、時間とコストを節約できます。いったんテストケースを定義すれば、アプリケーションに変更があっても簡単に再テストできるため、時間に無駄がありません。さらに、テスターしか結果をすぐに見ることができない手動テストとは異なり、自動テストではソフトウェアテストプロセスに関わるすべての人が結果をすぐに参照できます。一方でデメリットは、テストスクリプトの良し悪しがテストの品質を大きく左右するため、スクリプトの質が悪いと自動テストの多くのメリットが薄れてしまう点です。

重要なのは、手動テストと自動テストを適切に使い分けることです。自動テストはその効率の良さから、CI/CD (継続的インテグレーション/継続的デリバリー)の主要なプロセスの1つになっています。一方で、アプリケーションの視覚要素(色、フォント、サイズ、ボタンの大きさなど)の評価、1回限りのテスト、小規模な変更のテストなど、範囲が限定される場合には手動テストの方が適しています。

ソフトウェア開発におけるテストの役割

ソフトウェア開発におけるテストの役割は、ソフトウェアの信頼性、品質、パフォーマンスを向上させることです。ソフトウェアにバグが多いと、組織全体に大きな悪影響を及ぼすことがあります。プロジェクトレベルであっても、ソフトウェアでエラーが頻発すれば遅延につながりかねません。さらに、不具合が残されたままアプリケーションがユーザーに配布されると、エンドユーザーエクスペリエンスが低下し、企業の評判が損なわれて、収益の損失につながる可能性もあります。

そのため、ソフトウェアテストはソフトウェア開発ライフサイクル(SDLC)の要素として欠かせません。ソフトウェア開発のあらゆる工程にテストを組み込むことによって、設計どおりに動作することをコンポーネントごとに確認できます。これにより、バグやミスを早期に特定して、アプリケーションの他の領域に影響が及ぶ前に修正できます。効果的なソフトウェアテストは、最終的に、組織全体のコスト節約、ユーザーエクスペリエンスと顧客満足度の向上、収益の増加というメリットをもたらします。

ソフトウェアテストの重要性

品質の低いソフトウェアは組織の評判を損ね、収益の損失につながる可能性があります。それを避けるためにソフトウェアテストが重要になります。不具合が放置されると、アプリケーション自体のパフォーマンスだけでなく、関連するシステムのパフォーマンスも低下する恐れがあります。パフォーマンスが低いと、顧客は不満を感じ、アプリケーションの使用をやめたり、さらに悪い場合には別の企業のサービスに乗り換えたりしてしまうこともあります。ソフトウェアテストを効果的に行えば、ソフトウェアのバグやミスを適切に検出して、アプリケーションが顧客に配布される前に修正できます。ソフトウェアの信頼性の高さは、最終的に、顧客満足度の向上につながります。

ソフトウェアテストの実行者

ソフトウェアテストは、通常、開発チームとテストチームが協力して開発プロセスの全工程で実行します。

開発チームの主な役割はソフトウェアの開発ですが、新しい機能を追加するたびにテストを実行します。この場合のテストには、デバッグ、新しいコードのパフォーマンス確認、アプリケーションのリソースチェック、他のソフトウェアとの互換性検証などが含まれます。ただし、開発者は成果物に対する厳しい基準を満たすことが求められるため、詳細なソフトウェアテストを実行する時間的余裕がない場合がほとんどです。

テストチームの役割は、専門家として製品のあらゆる側面を幅広くテストして、製品が要件を満たしているかどうかを確認することです。開発チームと密接に協力して製品の設計を理解し、多くの場合、自動化ツールを使ってテストを実行します。

誰がソフトウェアテストを実行するかは、通常、実行するテストの種類によって決まります。ソフトウェアテストは一般的に、ブラックボックステストとホワイトボックステストの2種類に分けられます。ブラックボックステストでは、ソフトウェアの内部構造を考慮せずにテストを行います。Webインターフェイスのテストなどがこれに該当します。アプリケーションコードに触れないため、このテストは誰でも実行できますが、通常はソフトウェアテストを専門とする人が実行します。一方、ホワイトボックステストでは、アプリケーションの内部構造を精査して、コードのロジックや流れを検証します。テスターはプログラミング言語に精通し、アプリケーションのコードベースを理解している必要があります。そのため、ホワイトボックステストは通常、ソフトウェア開発者が実行します。

ソフトウェアテストのメリット

ソフトウェアテストにはさまざまなメリットがあります。

• 製品の品質の向上：ソフトウェアの開発中にバグを特定して修正できるため、ユーザーに高品質な製品を提供できます。また、品質の向上はユーザーエクスペリエンスの向上につながるだけでなく、アプリケーションを組織内の他のシステムと統合したときにサービスの問題が発生するリスクを減らすためにも役立ちます。
• セキュリティの強化：アプリケーションのセキュリティの重要性は、Cambridge Analytica社とFacebook社のデータ不正使用事件を見れば明らかです。ソフトウェアテストとセキュリティテストを行えば、アプリケーションにセキュリティを効果的に組み込み、カスタマーエクスペリエンスに影響する可能性のある脆弱性を特定できます。
• コスト削減：アプリケーションのリリース後に問題が見つかったときの影響は計り知れません。ユーザーは不満を感じてそのアプリケーションの使用をやめ、従業員は問題解決のために大きな負担を強いられます。金銭的な影響も深刻で、2020年には米国でソフトウェアの不具合によって組織が負ったコストは合計2兆800億ドルにのぼりました。ソフトウェアテストを行い、アプリケーションのリリース前に問題を発見して修正することで、こうした損失を軽減できます。
• 顧客満足度の向上：Webアプリケーションなどの使い勝手が悪いと、ユーザーはその企業に対して悪い印象を抱き、他社のサービスに乗り換えてしまう可能性があります。ソフトウェアテストでユーザーインターフェイスや使いやすさを検証して製品の品質を確保することは、顧客満足度を高めるために効果的です。長い目で見れば、ソフトウェアテストへの投資は、企業評価の向上と顧客関係の醸成という利益を生みます。

ソフトウェアテストのツールと技法

テストの技法や手法には、ソフトウェア開発の工程に応じていくつかの種類があります。たとえば、以下のようなものがあります。

• 単体テスト：アプリケーションの最小部品単位(コンポーネント)を個別にテストして、単体で動作に問題がないことを確認します。自動化することでコストを抑え、すばやく実行できます。単体テストは最初に行うソフトウェアテストです。
• 結合テスト：アプリケーション内の複数のモジュール(サービス)を組み合わせて正しく動作することを確認します。結合テストの代表例に、アプリケーションとデータベースの連携テストがあります。アプリケーションの複数のコンポーネントを用意して実行する必要があるため、単体テストよりもコストがかかります。
• 機能テスト：アプリケーションがビジネス要件を満たしていることを確認します。アプリケーションのすべての機能について、適切なテストデータを入力し、その出力と予想される出力を比較して、各機能が期待どおりに動作することを確認します。複数のコンポーネントが適切に連携することを確認する点は結合テストと同じですが、機能テストでは操作の出力結果を検証するだけで、その過程は検証しません。たとえば、結合テストではアプリケーションがデータベースに正しくデータを問い合わせているかどうかを確認するのに対して、機能テストではデータベースから返された値が事前の想定と一致するかどうかだけを確認します。
• 回帰テスト：コードを変更したときに、それによってアプリケーションの機能に不具合が生じないかを確認します。コード変更には、バグの修正、機能の更新、その他の改善が含まれます。アプリケーションのコードを変更するたびに、以前実行して合格したテストケースを再度実行して、アプリケーションの動作に影響がないことを確認します。
• エンドツーエンドテスト：システムテストとも呼ばれ、アプリケーションのワークフローを最初から最後まで確認して動作を評価します。一般的なユーザーシナリオを実行して、実際の使用環境におけるアプリケーションの動作を再現し、問題がないかどうかを調べます。個々のモジュールと機能すべてを組み合わせて行うこのソフトウェアテストは、開発の最終段階に行います。
• 受け入れテスト：アプリケーションがビジネス要件を満たし、ユーザーに提供しても問題がないかどうかを確認します。このテストでは、アプリケーション全体を実行して、ユーザーが行う操作を再現することが中心になります。受け入れテストには、ユーザー受け入れテスト(UAT)、ビジネス受け入れテスト(BAT)、運用受け入れテスト(OAT)、契約による受け入れテスト(CAT)、アルファテスト、ベータテストなど、いくつかの種類があります。
• パフォーマンステスト：非機能テストとも呼ばれ、予測される負荷の下でシステムが正常に動作するかどうかを確認します。このテストによってアプリケーションの速度、拡張性、安定性、信頼性について定められた要件への適合/不適合を評価できます。パフォーマンステストには、ロードテスト、ストレステスト、耐久テスト、スパイクテスト、ボリュームテスト、拡張性テストなど、さまざまな種類があります。
• スモークテスト：ソフトウェアビルドにエラーがなく、後工程に送っても問題がないかどうかを確認します。アプリケーションの基本機能を評価し、主要機能が期待どおりに動作することを確認するための簡易テストです。通常は、新しいビルドの作成後、より詳細で広範なテストに移る前に実行するか、導入直後にその環境でアプリケーションが適切に動作することを確認するために実行します。

ソフトウェアテストの戦略

ソフトウェアテストの戦略では、アプリケーションを包括的にテストするための技法とツールの組み合わせを考えます。ソフトウェアをテストするときは、まず戦略を検討します。テスト技法によって、ソフトウェアシステムの内部構造をテスターが理解している必要があるものや、手動で実行する必要があるもの、自動化できるものなどがあります。また、必要な技術スキルやツールも戦略によって異なります。

ソフトウェアテストの一般的な戦略には以下のものが含まれます。

• 静的テスト：アプリケーションコードを実行せずにソフトウェアの欠陥を特定します。これとは対照的に、動的テストでは、プログラムを実際に動かしてテストを行います。静的テストは、通常、開発の初期段階で実行し、レビューと静的解析の2つの技法を用います。レビューでは、アプリケーションコードやサポートドキュメント(ソフトウェア要件定義書など)のミスや欠陥を見つけて修正します。レビューには、非公式レビュー、ウォークスルー、ピアレビュー、インスペクションなどの種類があります。静的解析では、自動化ツールを使って、開発者が記述したコード内の構造的な欠陥を検出します。静的テストの目的は、できるだけ早い段階で問題を見つけることです。
• 構造テスト：すべてのバグを見つけるには、最終的にアプリケーションを実行してみる必要があります。構造テストはホワイトボックステストとも呼ばれ、ソフトウェアのソースコードの構造に注目して欠陥を見つけます。通常は、ソフトウェアのコンポーネントごとに、そのコードの記述直後に実行します。構造テストでは、テスターはさまざまなプログラミング言語に精通し、ソフトウェアコードを深く理解している必要があります。そのため、通常は、テスト対象のコードを記述した開発者もテストに参加します。
• 動作テスト：ブラックボックステストとも呼ばれ、構造テストとは対照的に、内部の構造を考慮せずにアプリケーションの動作を中心にテストを行います。目的は、ユーザーの観点でアプリケーションを評価することです。そのため、テスターはソースコードを気にせず、インターフェイスの問題やパフォーマンスの問題、機能の不足など、ユーザーエクスペリエンスに関する不具合を探します。動作テストは、ソフトウェアテストの各段階で行われます。

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

ソフトウェアテストのライフサイクルにはいくつかのベストプラクティスがあります。たとえば、以下のようなものがあります。

• 計画を立てる：効果的なソフトウェアテストの第一歩は、テスト計画を定めて文書化することです。テスト時に参照するチュートリアルもこの段階で作成します。事前に詳細を決めておけば、その場の思いつきでテストを行うような状況を回避できます。適切なテスト/QA計画は組織によって多少異なるため、まずは、各テストプロセスの目標、テストで満たす必要のある基準や条件、テスト結果の記録および文書化方法などを明確にして、各テストで有意義な成果を得られるように方針を定めることをお勧めします。
• テストを早い段階から頻繁に行う：テストを開発プロセスの最後に先延ばしすると、途中でボトルネックが生じ、進捗が滞る可能性があります。テストは、開発ライフサイクル全体を通じて小さい単位でこまめに行うことをお勧めします。これにより、各工程で発生したバグやミスを後の工程に影響が及ぶ前に見つけて修正できます。また、テストを早い段階から頻繁に行えば、終盤に納期を気にしながら山積みの問題に対処するのではなく、欠陥を発見した時点で余裕をもって修正できるメリットもあります。
• テストスクリプトの作成をプログラマーに任せない：プログラマーに自身の書いたコードのテストスクリプトの作成を任せるのは避けましょう。無意識のうちに条件やパラメーターの設定に先入観が入り込み、自身の担当外のアプリケーションコンポーネントとの関係を見落としてしまいがちです。第三者であるテスターに任せれば、より広い視点でテストスクリプトを作成して、プログラマー自身が行ったテストで見過ごされていた欠陥を検出できる可能性が高まります。
• 回帰テストを実行する：ある問題を修正したら別の問題が生じたということは珍しくありません。更新や機能の追加後にアプリケーションの動作に影響がないことを確認するため、回帰テストを欠かさず実行するのが基本です。
• 探索的テストを導入する：自動テストはソフトウェア開発ライフサイクルの重要な要素の1つですが、限界もあります。事前に定義するテストケースでは、実際のユーザーによるアプリケーション操作を網羅することはできません。定められたシナリオを使わずに人間がソフトウェアを評価する探索的テストなら、人間の発想力を活かして、体系化されたテストでは見つけられない欠陥を発見できる可能性があります。テスターは、想像や勘に基づいてテスト内容をその場で考え、実行して、結果を観察できます。探索的テストは、実際の使用状況を想定してアプリケーションを評価するために最適な方法の1つです。
• 導入後テストを実施する：計画とテストを適切に行っても、アプリケーションのすべてのバグや欠陥を見つけ出すことはできません。ソフトウェアの導入後にテストを行えば、導入前のテストでは検出できなかった不具合を見つけるとともに、アプリケーションの改善に関する意見をユーザーから得ることができます。導入後に機能を再度テストし、ユーザーからフィードバックを収集します。また、アプリケーションを監視して、設計どおりに動作することを確認します。このプロセスを定着させ、新機能の開発とリリースを継続的に行うことで、アプリケーションに最新機能を組み込み、収益性を保つことができます。
• すべてのテストを文書化する：テストの文書化は、ソフトウェアテストプロセスの長期的な成功に欠かせません。文書には、プロジェクトごとに、ソフトウェアテストの戦略、環境、進捗、指標、結果に関する情報を記録します。テスト文書を作成してテストプロセスの透明性を確保すれば、プロダクト担当者やビジネスマネージャーがテスト仕様を理解して、テストの効果を評価できます。また、効果が高かったテスト手法を再利用したり、テストの成功率向上や改善に役立てたりすることもできます。

ソフトウェアの動作を適切に保つことは、開発プロセスの重要な目標の1つです。1つの欠陥が満足している顧客を顧客離れにつなげる可能性があります。ソフトウェアテストを効果的に行えば、アプリケーションの欠陥、不具合、要件への不適合を発見して修正し、顧客が満足する製品を提供できます。