ソフトウェアテストは、簡単にいうとソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する手助けとなるものです。

テストに関するよくある誤解の1つは、テストはテスト実行（ソフトウェアを実行しテスト結果を確認する）だけだというものがありますが、ソフトウェアテストには他の活動も含まれます。

テストに関するもう 1 つのよくある誤解は、テストはテスト対象の検証だけに重点を置くというものがあります。テストでは検証、つまり指定されている要件をシステムが満たすかどうかを確認することに加えて、妥当性確認も行います。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることを確認します。

テストには動的テストと静的テストがあります。動的テストはソフトウェアの実行を伴いますが、静的テス トはソフトウェアの実行を伴いません。

1.テストの目的

典型的なテスト目的を以下に示します。

　・要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
　・故障を引き起こし、欠陥を発見する。
　・求められるテスト対象のカバレッジを確保する。
　・ソフトウェア品質が不十分な場合のリスクレベルを下げる。
　・仕様化した要件が満たされているかどうかを検証する。
　・テスト対象が契約、法律、規制の要件に適合していることを検証する。
　・ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
　・テスト対象の品質に対する信頼を積み上げる。
　・テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。


このようにテストを行う目的はいくつもあり、テストがソフトウェア開発する上でとても重要な要素であることがわかります。

2.テストとデバッグ

テストとデバッグは別の活動になります。テストをすることで、ソフトウェアの欠陥によって引き起こされる故障を発生させたり（動的テスト）、テスト対象の欠陥を直接発見したりすることができます（静的テスト）。

動的テストが故障を引き起こす一方で、デバッグは、故障の原因（欠陥）を発見し、解析し、取り除くことになります。典型的なデバッグの流れは以下の通りです。

　・故障の再現
　・診断（根本原因を発見すること）
　・原因を修正すること


その後に行う確認テストは、修正によって問題が解決されたかを確認します。確認テストは、最初のテストを行った人と同じ人が行うのがよく、修正によってテスト対象の他の部分に故障が発生していないかを確認するために、続けてリグレッションテストを実施することもできます。

テストは品質コントロールの形式の1つで、設定された範囲、時間、品質、予算の制約の中で、ゴールを達成するために役立つものになります。

1.成功に対するテストの貢献

テストをすることは、欠陥を検出するためのコスト効果のある手段となります。この欠陥は、（テスト活動ではないデバッグによって）取り除くことができるため、テストをすることが間接的にテスト対象の品質向上に貢献することになります。

テストをすることは、SDLCのさまざまな段階において、品質を直接評価する手段となります。これらの測定結果は、より大きなプロジェクトマネジメント活動の一部として使用し、リリースの判定など、SDLCの次のステージに移行するための判定に使用されます。

テストをすることは、間接的にユーザーが利用した場合の状況を再現することになります。テスト担当者は、開発ライフサイクルを通じて、テスト担当者自身が理解するユーザーのニーズが考慮できていることを確認します。

※SDLC（ソフトウェア開発ライフサイクル）については別の記事で解説します。

2.テストと品質保証（QA）

「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいますが、テストと品質保証は同じではありません。テストは品質コントロール（QC）の形式の1つです。

QCは、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチです。テストは品質コントロールの主要な形式であり、その他に形式的手法（モデル検査や定理証明）、シミュレーション、プロトタイピングなどがあります。

QAは、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチです。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいています。

テスト結果は、QAとQCで使用します。QCでは欠陥の修正に使い、QAでは開発とテストプロセスがどの程度うまくいっているかについてのフィードバックに使います。

3.エラー、欠陥、故障、および根本原因

人間はエラー（誤り）を起こします。そのエラーが、欠陥（フォールト・バグ）を生み出し、その欠陥は、故障につながることもあります。人間は、時間的なプレッシャー、作業成果物、プロセス、インフラ、相互作用の複雑度、あるいは単に疲れていたり、十分なトレーニングを受けていなかったりなど、さまざまな理由でエラーを起こします。

欠陥は、要件仕様書やテストスクリプトのようなドキュメント、ソースコード、またはビルドファイルのような補助的なアーティファクトの中から発見できます。コードの欠陥が実行されると、システムが正常に動作せず、故障の原因となります。

故障の原因は、エラーや欠陥だけではなく、例えば、放射線や電磁波によってファームウェアに欠陥が生じる場合など、環境条件によっても故障が発生することがあります。

根本原因とは、問題（例えば、エラーにつながる状況）が発生する根底の理由のことです。根本原因分析によって特定され、故障が発生したときや欠陥が確認されたときに行われるのが一般的です。根本原因を取り除くなどの対処をすることで、さらに同様の故障や欠陥を防止したり、その頻度を減らしたりできると考えられています。

この記事で使用した用語を下記に示します。

・カバレッジ

カバーする範囲やカバー率などを表す言葉で、対象に対して全体の内どれくらい網羅しているかを示す指標です。
ソフトウェア開発の領域では主に、テストの実施状況を表します。ホワイトボックステスト時に用いられることが多く、論理構造全体に対してどれだけの実行ができたかの網羅性の尺度として使用されます。網羅性を把握することがソフトウェアの品質において重要な指標になります。

・ステークホルダー

株主・経営者・従業員・顧客・取引先のほか、金融機関、行政機関、各種団体など、企業のあらゆる利害関係者を指す言葉です。 利益でも損失でも、何らかの影響を企業に及ぼす存在であればステークホルダーであり、必ずしもその利害は一致しないということもあります。

・リグレッションテスト

ソフトウェアテストの一つで、機能の追加や変更、不具合の改修などに伴うプログラムの変更によって、その他のプログラムに意図しない影響が発生していないかどうかを確認するテストです。