ソフトウェアテストとは何か？テストの内容や実施するタイミングについて

ソフトウェア開発を行う際には、ソフトウェアが正しく動いているかどうかを確認するソフトウェアテストの工程が必ず存在します。

ソフトウェアテストは開発したソフトウェアが期待通りに動作することを確認する行為であり、ソフトウェアテストの実施には様々なメリットがあります。

本記事では、開発の現場では軽く見られがちなソフトウェアテストの目的、実施内容、タイミングなどについて、JSTQBの内容を参考にして詳しく解説します。

ソフトウェアテストとは

本記事の書き出しでも説明しましたが、ソフトウェアテストは開発したソフトウェアが期待通りに動作することを確認する行為になります。
ソフトウェアテストの実施には下記のようなメリットがあります。

文言だけでは想像が難しいかもしれませんが、正しいソフトウェアテストを実施することで数百万、数千万のコスト軽減に貢献することがあります。
特に中規模、大規模な開発になると、大きなメリットを感じることができると思います。

そんな大きなメリットを生み出すソフトウェアテストに関して、本章では「ソフトウェアテストの目的」「ソフトウェアテストの7原則」「ソフトウェアテストの範囲」の3点について解説します。

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

JSTQBのシラバスでは、ソフトウェアテストが正しく動作しないことにおけるリスクを下記のように説明しています。

ソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など、さまざまな問題が発生し、時には傷害や死亡事故になることもある。

出典：JSTQB認定テスト技術者資格｜ISTQBテスト技術者資格制度
Foundation Level シラバス 日本語版 Version 2018V3.1.J03

上記の通り、経済的な損失、時間の浪費、信用失墜のリスクを可能な限り最小限に留めることがソフトウェアテストの目的になります。

ソフトウェアテストの7原則

「ソフトウェアテストを完璧に行えば、欠陥のない完璧なソフトができる」と思う人はいるかもしれません。
ですが、実際にはそのようなことはなく、ソフトウェアテストには実現できることとできないことがあります。

JSTQBでは、「ソフトウェアテストはこういうものである」ということを示すガイドラインとして、下記の7つの要因に絞った「ソフトウェアテストの7原則」について解説しています。

ソフトウェアテストには「これだけやればOK」というテンプレートは存在せず、ソフトの目的や作り方に応じて最適なテストを行う必要があります。

ソフトウェアテストの7原則を意識しながら、限られた予算と時間の中で重要度や優先度を決めて効率的にテストを行うことが、ソフトウェアテストにおいて非常に重要な作業になります。

ソフトウェアテストの範囲

ソフトウェアテストの範囲を説明する前に、まずはソフトウェア開発の基本的な工程について説明します。

ソフトウェア開発における開発手法には「ウォーターフォールモデル」と呼ばれる開発方法があります。

ウォーターフォールモデルは、下記のような工程で順に開発を進めるような開発手法のことを指し、作業の流れが上流工程から下流工程へ滝のように流れて進むことから「ウォーターフォール（滝）」という名前が付いた開発モデルになります。

ウォーターフォールモデルに対して、どの作業がどのテストに対応するかをわかりやすく示したものが下図の「V字モデル」になります。

※出典：大西 建児,佐々木大西 建児,佐々木 方規,鈴木 三紀夫,中野 直樹,福田 里奈,町田 欣史,湯本 剛,吉澤 智美. 「ソフトウェア開発とソフトウェアテスト」.『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』.翔泳社,第4版 (2019/9/17),86

V字モデルはウォーターフォールモデルの上流工程（開発工程）と下流工程（テスト工程）の関係性を明確に示すものになります。
具体的には、V字モデルは「要求分析」は「受け入れテスト」、「要件定義」は「システムテスト」、「基本設計」は「統合テスト」、「詳細設計」は「コンポーネントテスト」に対応していることを示すモデルになります。

V字モデルで示す通り、ソフトウェアテストの範囲は上流工程の「要求分析」「要件定義」「基本設計」「詳細設計」の範囲を含むことになります。

開発の現場でよくあることとして、「完成したソフトの動作チェック」のことを「ソフトウェアテスト」と認識している方もいますが、この認識は誤りではないのですが正しくもありません。

「完成したソフトの動作チェック」はテストの一部分であり、「ソフトウェアテスト」の全てではありません。
V字モデルで示している通り、「要求分析」「要件定義」「基本設計」「詳細設計」など、完成に至る全ての工程で得られる成果物がテスト対象であり、成果物が作られる全ての工程がソフトウェアテストの範囲となります。

ソフトウェアテストで実施するテストとは

ソフトウェアテストには様々なテスト手法、テストタイプ、テスト技法があります。
各種テストの詳しい解説は別の記事にて作成しますので、今回は一部のテスト手法とテストタイプに関して解説します。

静的テストと動的テスト

ソフトウェアテストには「静的テスト」と「動的テスト」の2種類のテスト手法があります。

静的テストはプログラムを動かさずに行うため、プログラムを組み込む前に欠陥を見つけることができます。

動的テストはプログラムを動かして行うため、実際の動作を見ながらユーザービリティの評価やパフォーマンスの測定などが行えます。

静的テストと動的テストはメリットやデメリットを互いに補い合うような関係にあるため、両方行うことでより質の高いテストを行うことが可能となります。

機能テストと非機能テスト

ソフトウェアテストには「機能テスト」と「非機能テスト」の2種類のテストタイプがあります。

機能テストと非機能テストは確認できる内容が異なりますので、開発するシステムによってどちらのテストを重点的に行うかを明確に決める必要があります。

例えば、EC系のサービスであれば、システムが仕様通りに動くことを確認するために機能テストを実施しますが、それ以上に、サービスを利用するカスタマーに直接影響を及ぼす性能、使用感、セキュリティなどが十分に考慮されているか否かを確認する非機能テストの方に重点を置く場合もあります。

このように、機能テストと非機能テストに関してはどちらもバランスよく実施することを考えるのではなく、システムの特性を考えてどちらを優先すべきか考えてテストを実施することが大事になります。

ソフトウェアテストを行う理想的なタイミングとは

ソフトウェア開発の現場では、下記のような会話が行われることがあります。

企画者A

想定よりも開発コストがかかっているなぁ…。どうにかして工数を軽減できないものか。

企画者B

開発そのものの工数は減らせませんからね…。
最後にしっかりテストをして、途中のテストは減らしましょうか。

ソフトウェアテストを単に「動作確認」と認識していると、上記のような判断でテスト工数が減らされてしまう場合があります。
ですが、仮に上記の通り進めたとして、開発の最後の工程となる「受け入れテスト」で仕様漏れが見つかった場合はどうなってしまうでしょうか…？

「ソフトウェアテストの範囲」のV字モデルにて解説しましたが、受け入れテストに対応する開発工程は「要求分析」となりますので、要求分析の工程まで戻って仕様を確認することになります。
また、漏れていた仕様に関わる箇所は全て見直しとなり、関係するテストは全てやり直しとなります。

このように、開発コストを軽減するために決定した判断が、逆に開発コストを増やす要因となってしまう場合があります。

「急がば回れ」という言葉の通りで、ソフトウェア開発においてソフトウェアテストは必要な作業となりますので、安易にテスト工数の削減を検討することは危険な行為となります。

このようなトラブルを回避するためにも、本章ではソフトウェアテストを行う理想的なタイミングと、早期テストの実施におけるメリットとデメリットについて解説します。

Wモデルからテストを実施するタイミングを考える

「ソフトウェアテストの範囲」で解説したV字モデルでは、テストを下流工程として記載しているため、「要求分析」「要件定義」「基本設計」「詳細設計」の工程ではテストをしないという誤解を与えてしまうことがあります。

実際には、「要求分析」「要件定義」「基本設計」「詳細設計」の工程でも仕様の抜け漏れを確認するテストを実施しなければなりません。

このような誤解を解消するために、テスト活動が上流工程でも実施されることを明確に示したのが下図の「Wモデル」になります。

※出典：大西 建児,佐々木大西 建児,佐々木 方規,鈴木 三紀夫,中野 直樹,福田 里奈,町田 欣史,湯本 剛,吉澤 智美. 「ソフトウェア開発とソフトウェアテスト」.『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』.翔泳社,第4版 (2019/9/17),88

全体的な開発の流れはV字モデルと変わらないのですが、テスト活動を下流工程のみに置くのではなく、上流工程の作業とセットで置くことで上流でもテストを実施していることを示しています。

Wモデルの見方としては、「要求分析」は並行して「受入テスト 計画・設計」のテスト活動を行うことを示していて、「要件定義」「基本設計」「詳細設計」も同様に、並行してテスト活動を行っていることを示しています。

下流工程も上流工程と同じように、「受け入れテスト」の際は並行して「デバッグ・修正」の作業を行い、「システムテスト」「統合テスト」「コンポーネントテスト」も同様に並行して「デバッグ・修正」の作業を行っていることを示しています。

Wモデルで示しているように、テスト活動は開発の初期工程である「要求分析」から行うことができますので、ソフトウェアテストの理想的な実施タイミングは「要求分析」の段階であることが考えられます。

早期テストのメリットとデメリット

「Wモデルからテストを実施するタイミングを考える」の項目でも解説した通り、テストは開発の上流工程「要求分析」の工程から行うことが理想となります。

早期テストの実施は、開発の工程において下記のようなメリットがあります。

上記は開発の工程に絞ったメリットを記載していますが、早期テストを実施して開発したソフトウェアは高品質なものとなりますので、お客様の満足度や信頼度は高いものとなり、良好な関係を築くことも可能となります。
このように、早期テストは開発の工程におけるメリットだけでなく、開発後に得られるメリットもあります。

一方で、早期テストの実施には下記のようなデメリットもあります。

入念なテストはソフトウェアの品質を高めますが、代わりに開発スピードが遅くなり、見かけ上のコストが多く見えてしまいます。
ですが、これらのデメリットは本来やるべき工程を省いて実施するからこそ実現するものとなりますので、本質的なデメリットとは異なります。

仮に、開発スピードを優先してテスト工数を削減した開発を行ったと仮定します。
開発したソフトウェアは十分なテストを実施していないため、故障発生のリスクが高いものとなります。

もし故障が発生すれば、ユーザーやお客様への対応に加えて、修正に必要な工数を割く必要もありますので、追加で開発コストがかかってしまいます。
また、リリース後の修正は影響範囲が大きくなりがちなので、修正には多くの開発コストがかかることとなります。

故障が発生した場合は上記のように追加でコストがかかってしまいますが、運よく故障が発生しなかった場合はテスト工数を抑えた最小工数の開発を実現することとなります。

開発スピードを優先してテスト工数を減らすようなソフトウェア開発は、故障が出なければ最小のコストで最大の利益を得る開発となり、故障が出れば本来の開発以上のコストを払って利益を減らす開発になります。
表現の仕方が良くないですが、このような開発は故障が出るか否かのギャンブルを行うような開発になります。

上記のようなギャンブルではない品質の高いソフトウェア開発を行うためにも、早期テストのメリットを正しく理解して、十分なテストが実施できるようなスケジュールを組むことが大切になります。

まとめ

本記事のまとめは下記の通りとなります。

ソフトウェア開発にはソフトウェアテストが必須の作業となりますが、そこに「開発スピードの向上」「開発費の軽減」という要因が加わると、テスト工数の確保が難しくなってきます。

費用的にも時間的にも余裕のある開発というのはなかなかないので、開発するソフトウェアにとって重要なことは何かをしっかりと見極めて、プロダクトごとに適切なテストを考えることもソフトウェアテストの重要な作業になります。

本記事に掲載したようなソフトウェアテストのメリットをしっかりと理解して、できる限り品質の高いソフトウェア開発を実施するように心がけましょう。