ソフトウェアテストとは

まず「ソフトウェアテスト」とは、ソフトウェアテスト技術者の国際的な資格認証団体であるISTQB（International Software Testing Qualifications Board：国際ソフトウェアテスト資格認定委員会）によれば、以下のように述べられています。

上記はソフトウェアテストの定義ともいえるものですが、こちらについてもう少し詳しく見ていきましょう。

現代を生きる私たちにとって、あらゆる分野・領域においてソフトウェアが必須なものとなっていることは疑いようがありません。
いまや、ソフトウェアはビジネス分野だけでなく、スマートフォンのアプリケーションをはじめ消費者の日常生活にいたるまで必要不可欠なものとなっており、社会的なインフラの一つになっているとも言えます。

こうした世の中において、もしソフトウェアが正しく動作しない場合、さまざまな問題が発生することは想像に難くありません。
ビジネスに関わるソフトウェアはもちろんのこと、人命や安全、金融といった正常動作が欠かせない領域に関するソフトウェアであればなおさらであり、ソフトウェアの故障によって発生した問題によって甚大な影響を及ぼすこともあります。
ビジネスの領域であれば、経済的な損失や会社の信用の低下などを招く恐れもあります。
特に近年では、大手通信会社や証券・金融システムなどで大規模な障害が発生し、多くの人々に影響があったことは記憶にも新しいでしょう。

そして、ソフトウェアが正しく動作しないことによってこのような問題が発生するリスクを低減する手段の一つこそがソフトウェアテストなのです。

ソフトウェアテストに関する２つのよくある誤解

「ソフトウェアテスト」と聞くと、「ソフトウェアを実際に動かしてみて、それが仕様通りに動くかどうかを確認すること」を指すと考える方が多いかもしれませんが、ソフトウェアテストはそれだけにとどまりません。

ISTQBによれば、ソフトウェアテストについてよくある誤解として、以下のようなポイントが挙げられています。

テストはソフトウェアを動作させ、その結果を確認するだけではない

ソフトウェアテストにはさまざまなプロセスが存在し、多くの方が想像するような「テストを実行すること」はソフトウェアテストのプロセスの一つにしか過ぎません。

テストプロセスにはテストの実行だけでなく、テストの計画や分析、設計、実装、進捗と結果の報告、テスト対象の品質評価といった作業も含まれます。

また、ソフトウェアを動かして動的にテストすることを「動的テスト」と言いますが、ソフトウェアを動かさずに行うテストもあります。
例えば、要件定義書やユーザーストーリー、テスト設計書（テスト仕様書）、仕様書、ソースコードといった成果物をレビューする活動もテストに含まれ、こういったテストは「静的テスト」と呼ばれます。

なお、私たちSHIFT ASIAでもテスト設計書（テスト仕様書）や仕様書といったドキュメントを中心に誤りや抜け漏れ、仕様バグ等が無いかを確認するドキュメントインスペクションというテストソリューションを提供していますが、こちらは静的テストに該当します。

テストは要件やユーザーストーリー、仕様等の検証だけがすべてではない

ソフトウェアテストには、ソフトウェアが要件を満たすのか、ユーザーストーリーや仕様通りに動くのかといった検証だけではなく、「そのソフトウェアは妥当か」といった妥当性の確認も含まれます。

具体的にいえば、ソフトウェアテストには「ユーザーのニーズやステークホルダーの目的を満たすことができているか」といった観点でのテストも含まれるということです。
仮にそのソフトウェアが正しく動作したとしても、それがユーザーやステークホルダーのニーズを満たすものでなければそもそもの意味がありません。

したがって、ソフトウェアは正しく動作するだけではなく、その妥当性も重要であり、双方を確認することがソフトウェアテストということになります。

ソフトウェアテストの目的

上でも述べたとおり、ソフトウェアテストの目的としては「ソフトウェアの故障が発生するリスクを低減すること」がまず挙げられます。

特に金融や医療に代表されるようなミッションクリティカルなソフトウェアで故障が発生した場合、時にはユーザーの人生や人命にも関わるような問題につながることもあります。
そういったことが発生するリスクを軽減することが、ソフトウェアテストの第一の目的といえます。

そして繰り返しになりますが、「ソフトウェアの妥当性を確認すること」もまた重要な目的となります。

なおISTQBによれば、より具体的に以下のようなことがソフトウェアテストの目的として挙げられています。

つまりISTQBによれば、ソフトウェアテストの目的とは、開発されたソフトウェアを含む成果物が要件や期待を満たし、品質が一定以上の水準にあることを検証することであり、そのために欠陥や故障を早期に検出することや、法規制や契約上の要件への適合性を確認することと言えます。

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

ここまでソフトウェアテストの概要や目的についてご紹介してきましたが、一口に「ソフトウェアテスト」といっても、ソフトウェアテストにはさまざまな種類があります。
例えば、あるコンポーネントが仕様通りに動作するかを確認するテストや、あるシステムが要件としている性能（反応速度など）を満たすかを確認するテストなど、テストの目的や、何をいつどのように確認するかによってソフトウェアテストの種類は変わってきます。

しかし、「ソフトウェアテストの目的」で挙げたような目的を達成するためには、テスト対象や開発・テストフェーズに合わせて適切なソフトウェアテストを行うことが重要であり、そのために参考となるのが多種多様なソフトウェアテストをグループに分けて整理した「テストレベル」と「テストタイプ」という考え方です。
そこで、続いてはソフトウェアテストにはどのような種類があるのか、「テストレベル」と「テストタイプ」をもとにご紹介します。

ただし、テストレベルとテストタイプには明確な定義があるわけではなく、書籍や組織などによって細部が異なることもあります。
そこで、本記事ではこれまでと同様にISTQBのシラバスを参考にテストレベルとテストタイプについてご紹介します。

テストレベルとは

はじめに、テストレベルについてご紹介します。
テストレベルとは、ISTQBによれば以下のように定義されています。

また、同じくISTQBのシラバスによれば、テストレベルには以下の4つのレベルがあると述べられています。

• コンポーネントテスト
• 統合テスト
• システムテスト
• 受け入れテスト

つまりテストレベルとは、さまざまなテストの活動を「コンポーネントテスト」「統合テスト」「システムテスト」「受け入れテスト」の4つのレベルに分類したものと言えます。
それでは、それぞれのテストレベルについてみていきましょう。

コンポーネントテスト（単体テスト、ユニットテスト）

コンポーネントテストとは、ソフトウェアを構成する最小単位であるコンポーネント（ユニットやモジュールとも呼ばれる）が、仕様どおりに動作することを検証するテストです。
コンポーネントテストは、単体テストやユニットテスト、モジュールテストなどとも呼ばれ、特に「単体テスト」「ユニットテスト」という名称が広く用いられています。

コンポーネントテストによってコンポーネント内の欠陥を検出し、機能的・非機能的な品質を高めることができます。
コンポーネント単位での欠陥は後の工程の不具合発生に大きく影響するため、一般的にはテスト工程の最初に実施されます。

単体テスト（ユニットテスト）とは | 目的や結合テストとの違い、メリット・デメリットまで詳しく解説

統合テスト（結合テスト）

統合テストとは、複数のコンポーネントを組み合わせて、それらが相互に連携した際に仕様通りの動作をするかどうかを検証するテストです。
コンポーネントを統合・結合した際の動作をテストすることから、「結合テスト」とも呼ばれます。

統合テストは、コンポーネントテスト（単体テスト、ユニットテスト）の後に実施するのが一般的です。

システムテスト（総合テスト）

システムテストは総合テストとも呼ばれ、開発されたシステムやプロダクト全体が機能的・非機能的に定義された要件を満たし、期待通りの動作をするかどうかを検証するテストです。
システムテストのテスト環境は、最終的な環境となる本番環境に準じたものとすることが理想的です。

システムやプロダクトに対する全体的なテストとなるため、システムテストの結果はリリース可否の判断における重要な要素となります。
一般的には、システムテストは統合テスト（結合テスト）の後に実施されます。

受け入れテスト

受け入れテストとは、開発されたシステムが実際の運用環境において顧客の要求や期待を満たし、支障なく利用できることを確認するテストです。
一般的には、システムテストを経てシステムが完成した状態で行われ、顧客やエンドユーザーが実施します。

受け入れテストでは、システムが正しく動作することだけでなく、操作性や使いやすさ、性能、保守性などの評価や確認に加えて、法的・規制的要件や契約で定めた基準を満たすかどうかを確認する場合もあります。

テストタイプとは

続いては、テストタイプについてご紹介します。
ISTQBによれば、テストタイプとは以下のように定義されています。

上記の4つのテストの目的に対するテストタイプとして、「機能テスト」「非機能テスト」「ホワイトボックステスト」「変更関連のテスト」の4つのテストタイプがあるとされています。一つずつ見ていきましょう。

機能テスト

機能テストとは、開発されたシステムが事前に定義された機能要件どおりに動作するかどうかを検証するテストです。

機能テストはすべてのテストレベルで行うべきとされており、要件に基づいてテスト対象のシステムが「何をすべきか」に着目してテストを実施します。

非機能テスト

非機能テストとは、システムやソフトウェアの性能効率性や互換性、使用性、信頼性、セキュリティ、保守性、移植性などの非機能的な特性が要件を満たしているかを検証するテストです。

機能テストではテスト対象が「何を（What）」すべきかに着目するのに対して、非機能テストはテスト対象が「どのように（How）」動作するかに着目します。
例えば、あるシステムが「Aというインプットに対してBという値を出力する」ことを確認するのは機能テストですが、その出力のスピードや、インプットを同時に多数行ったときのシステムの振る舞いなどを検証するのは非機能テストとなります。

非機能テストもすべてのテストレベルで行うことができ、非機能的な欠陥の検出が遅れることは大きなリスクとなることから、可能な限り早期に行うことが推奨されています。

ホワイトボックステスト

ホワイトボックステストとは、システムの内部構造や実装に着目し、それらが設計どおりに動作するかを検証するテストです。
内部構造には、コードやアーキテクチャー、ワークフロー、データフローなどが含まれます。

ホワイトボックステストの設計や実行には、関係するプログラムや内部構造などに関する知識や理解が必要となることから、開発者自身が実施することも多いテストです。

なお、ホワイトボックステストと対比されるテストとして「ブラックボックステスト」があります。
ブラックボックステストについては、以下の記事をご参照ください。

ソフトウェアテスト技法のひとつ、ブラックボックステストとは｜その特徴や技法について

変更関連のテスト

変更関連のテストとは、システムに対して修正や機能追加などを行った際に、変更が意図した効果をもたらし、かつ既存のシステムに想定外の悪影響を与えていないことを確認するためのテストです。

変更関連のテストには、主に確認テストとリグレッションテストの2種類があり、確認テストでは修正された箇所が正しく動作するかどうかを検証し、欠陥が確実に修正されたことを確認します。
またリグレッションテストでは、変更によって他の部分に意図しない影響（デグレ、リグレッション）が発生していないかを確認します。

デグレおよびリグレッションテストについては以下の記事で詳しく紹介していますので、ぜひあわせてご参照ください。

デグレ（デグレード）とは｜デグレのリスクや原因、対策

リグレッションテスト（回帰テスト）とは｜目的や重要性、実施のポイント

『ソフトウェアテストの7原則』とは

最後に、ソフトウェアテストにおける原則である『ソフトウェアテストの7原則』について詳しく解説します。

『ソフトウェアテストの7原則』とはISTQBテスト技術者資格制度 Foundation Level シラバスに記載されている、ソフトウェアテストを行う上で共通して理解しておく必要がある一般的なガイドラインです。

テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03 (PDF)

本シラバスに記載のあるテストの7原則を引用しながら、実務上生じやすい課題やソフトウェアテスト実施上の留意点などを例示します。

関連記事
ソフトウェアテスト資格「JSTQB認定テスト技術者資格」とは｜Foundation Levelを中心に概要からメリット、勉強方法をご紹介

原則1 | テストは欠陥があることは示せるが、欠陥がないことは示せない

陥りがちなポイントとソリューション例

[陥りがちなポイント]
必要かつ充分だと考えられるテストケースを消化してもなお、対象範囲に欠陥（バグ）が存在しないことの証明とはなりません。
「欠陥が存在しないこと」の証明はいわゆる「悪魔の証明」であり、証明することは不可能です。
例えば本番稼働後に想定しえなかった処理や極めて稀な条件や特定の状況下でのみ欠陥が検知される、といったケースも起こりえます。

[ソリューション例]
テスト計画を策定し、テストカバレッジを高める工夫をすると同時に、リリース時および本番稼働後の障害対応について予め計画しておく必要があります。
機能の追加実装時やデバッグ後に該当箇所のテストだけではなく、リグレッションテストを実施するなどの対策を講じることで、欠陥を検出できる可能性を予め高めておくことが重要になります。

原則2 | 全数テストは不可能

陥りがちなポイントとソリューション例

[陥りがちなポイント]
根拠なく「充分なテストを行った」と判断することや、反対にステークホルダーから「問題がないことを証明する」よう求められることがあります。
しかし原則1の通り、ソフトウェアテストでは「欠陥が存在しないこと」は証明できません。
ソフトウェアテストを通じて保証できるのは、「ある時点のある特定の機能や画面に対して、特定の手順で実施したテストにおいて不具合が発生した/発生しなかった」ということであり、その積み重ねになります。
それゆえに、ソフトウェアテストにおいてはテストの目的や範囲、優先順位、テスト観点といったテストの計画についてしっかりと検討しすることが重要なのです。

[ソリューション例]
プロジェクトスケジュールや工数は有限であることから、効果的なテスト計画を策定し適切にテストを実行することが肝要となります。
機能の重要度や、各工程における不具合検知率などからそれぞれのフェーズでどのようなソフトウェアテストを行う必要があるか常に検討・検証し、またプロジェクト関係者内で適切に開示・合意を行うことでステークホルダー間の合意形成や開発フェーズをまたがる手戻りなどを抑止することができます。

原則3 | 早期テストで時間とコストを節約

陥りがちなポイントとソリューション例

[陥りがちなポイント]
社外のソフトウェア開発会社に委託をされる際に、一般的には以下のような役割分担になることが多いです。
・要件定義と基本設計、および受入テストを自社で行う
・詳細設計、開発(コーディング)、単体・結合・システムテストを開発会社に委託

プロジェクトのスケジュールや工数に影響するような課題が、得てして結合テストやシステムテストで顕在化し、受入テスト時にはスコープやスケジュール調整、追加工数のリクエストが必要となるケースが散見されます。
その結果としてリリーススケジュールの大幅な遅延や、コストの膨大化が発生することがあります。

[ソリューション例]
インスペクションを実施し、基本設計や詳細設計のフェーズから静的テストを実施することで、要件漏れや記載の誤りを低減します。
いわゆる仕様バグを早期に取り除くことができ、後工程での手戻りの削減や、全体としての生産性の向上が期待できます。

原則4 | 欠陥の偏在

陥りがちなポイントとソリューション例

[陥りがちなポイント]
エンジニアのスキルが不足していたがレビュー可能なメンバーを配置できなかった、業務要件が複雑である、実装難易度が高い、プロジェクトのリソースなどに起因して充分な開発リソースを手当てできなかった、など様々な要因によって、問題が特定の領域に偏って発生することがあります。

[ソリューション例]
機能の重要度や、各工程における不具合検知率などからそれぞれのフェーズでどのようなソフトウェアテストを行う必要があるか常に検討・検証し、機能ごとにテストの実施内容の濃淡をつけるなど、テストにかかるリソースの最適化を検討する必要があります。

原則5 | 殺虫剤のパラドックスにご用心

陥りがちなポイントとソリューション例

[陥りがちなポイント]
開発した方がテストもあわせて対応される場合、該当の開発者の方の経験に依存してテストの観点やバリエーションなどの不足が生じてしまうことがあります。
また、スケジュールなどのプレッシャーや大丈夫だろうといった思い込みなどから確認がおろそかになったりすることも起こりえます。

[ソリューション例]
開発者とQA担当者を分けておく、またはレビュープロセスを定義する、といった方法で、複数人でのレビュー・チェック体制を構築することでリスクを低減することができます。
また定期的にテスト仕様を見直しテストの範囲や観点などを調整することにより、パラドックスを回避しテストの有効性を長期的に維持改善することが可能です。

原則6 | テストは状況次第

陥りがちなポイントとソリューション例

[陥りがちなポイント]
開発手法に応じたテスト、とくにアジャイル開発においてどのようにテストするかという点などはイメージがつきにくいこともあるかもしれません。

[ソリューション例]
アジャイル開発において、スプリント期間中にQA要員をチームに投入し、開発と並行してソフトウェアテスト（検証）を行います。
またアジャイル開発のスピードに合わせてソフトウェアテストを実施する必要があること、開発対象のシステムは随時アップデートされテスト対象の範囲が拡大し続けることから、適切にテストの自動化を行い、テストの効率化をはかることが重要です。

原則7 | 「バグゼロ」の落とし穴

陥りがちなポイントとソリューション例

[陥りがちなポイント]
欠陥を0にすることにこだわりすぎると、要件定義やソリューション選定時に保守的になりがちだったり、リリースまでに過剰なチェックポイントを設けるケースなども起こりえます。また、この原則は逆に「テストをしたから大丈夫」という慢心に陥ることも想定されます。

[ソリューション例]
前者については非常に難しい問題で、かつ大規模プロジェクトほど発生しがちな課題です。各フェーズでいかにビジネスとITがコミュニケーションや合意形成を行うかなど、様々な工夫が必要となります。
また、欠陥は0にならない前提でプロジェクトトランジッションや、本番稼働後の運用プロセスを規定することはとても重要です。リリース判定に紐づくテストについてもCI（継続的インテグレーション）の観点から制度設計が求められます。

おわりに

完ぺきなソフトウェアが存在しえないように、完ぺきなソフトウェアテストもまた存在することが難しいのが現実です。
一方で、ソフトウェア開発の各フェーズにおいて適切な品質保証対策を講じることで、成果物の品質を保ちながらプロジェクトにおける工数や納期を適切にコントロールしやすくなります。

そのためにはテスト計画や、それに基づいた各フェーズごとのテストの設計・実行が重要ですが、それらはすべてこの7つの原則が前提になっていることをまず確認することが肝要です。

SHIFT ASIAのテストソリューション一覧

なお、本記事ではソフトウェアテストの種類として「テストレベル」と「テストタイプ」を取り上げてご紹介しましたが、テストを技法によってカテゴライズした「ソフトウェアテスト技法」という分類もあります。

ソフトウェアテスト技法については以下の記事で詳しく紹介していますので、こちらもぜひあわせてご参照ください。

ソフトウェアテスト技法とは | 主な技法の種類や特徴について解説