あなたは「ソフトウェアテスト」に対してどのようなイメージをお持ちだろうか。「難しい」といったイメージだろうか？それとも「よくわからない」といったイメージだろうか？

ソフトウェアには、“目に見えない” “触れることができない” “自由度が高い（法律がない）” といった特徴があり、それだけでも「難しい」「わかりにくい」と思わせてしまう原因を作っているのだが、多人数で開発するときには、そこに “個人への依存度が高い” といった要素も出てくるため、個人差まで考慮しなければならなくなる。そのようなソフトウェアを相手に、“どのようにテストをすればよいのだろうか？” また、“どのようなテストをすればよいのだろうか？”

さて、現実に目を移すと、私たちの生活は好き好まずソフトウェアに依存している。スマートフォンのアプリからオンライン銀行、さらには医療機器の制御システムに至るまで、ソフトウェアがあらゆる場面で使われているのは皆さんもご承知のことだろう。このような状況であるため、もしもソフトウェアが正しく機能しなかった場合には、企業はユーザーに深刻な影響を及ぼしてしまいかねない。たとえば、オンライン銀行で不具合が発生した場合、ユーザーはお金の振込や引き出しができなくなるとともに、振込先の企業や、ひいては世の中全体に大きな影響を与えることとなり、その企業の信頼は、そのまま一直線に失墜してしまうといったリスクに迫られる。

このような背景からわかるとおり、ソフトウェアテストはシステム開発における品質管理の重要な要素となる。ソフトウェアが意図した通りに動作し、不具合や脆弱性がないことを確認するテストプロセスは、ユーザー体験を向上させるのみならず、企業のブランド価値を守るためにも正しく実施すべきこととして、肝に銘じておきたい。

本記事では、ソフトウェアテストの基本概念から様々なテスト技法、ドキュメント、プロセス、タイプ、ツール、定量的品質管理、はたまた新しい手法や原則に至るまで、初心者でも理解できるようなるべく平易な言葉を用いて解説する。さらに、具体的な事例や手順も交えて、より実践的な知識が得られる内容になることも目指す。長い記事になってしまったが、ブックマークをするなどして最後まで目を通していただければ幸いである。

ソフトウェアテストの基本概念

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

ソフトウェアテストは、開発されたソフトウェアが顧客の要求、あるいは仕様に基づいて、正しく実装されているかどうかを確認するプロセスである。このプロセスは、製品をリリースするまでになるべく早期に不具合を発見、修正し、リリース可否の判断材料を得ることを主な目的としている。以下は、ソフトウェアテストの実行プロセスの概念を図式化したものである。

▲図１：ソフトウェアテスト実行プロセスの概念図

• ソフトウェアテストの全体像

ソフトウェア開発におけるテスト体系を図式化すると以下のようになる。これらの関係性は是非覚えておこう。

さらに、ソフトウェア開発全体とソフトウェアテストとの関係についても図式化したので、テストの全体感も掴んでおこう。

▲図2：ソフトウェアテストの全体図

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

ソフトウェアテストの目的は、次の3点に集約できる。何事も目的を抑えることがもっとも重要なことであることから、ソフトウェアテストにおいても、まずは目的からしっかりと押さえよう。

• 動的テストと静的テストの比較

テスト体系図の中に動的テストと静的テストが出てきたが、これらは以下のように比較して覚えておくとよい。

テストレベル

では、ここからソフトウェアテストの各論の説明に入っていく。まず初めに、「テストレベル」から解説する。

テストレベルとは、ソフトウェアテストを実行する各段階（フェーズ）を示したものである。テストレベルには、それぞれ異なる目的とアプローチがあり、ソフトウェアの品質を確保するためにはそれぞれのテストレベルのテストを段階的に実施することが重要となる。

一般的に、４つのテストレベルがあるので順に見ていこう。

• 単体テスト（UT＝Unit Testing）

• 結合テスト（IT＝Integration Testing）

• システムテスト（ST＝System Testing）

• 受け入れテスト（UAT＝User Acceptance Testing）

ちなみに、結合テストは厳密には内部結合テストと外部結合テストに区分できるので、ここで触れておきたい。以下、そのイメージを図解で示す。

▲図3：内部結合テストと外部結合テストのイメージ図

このセクションの最後に、テストレベルの振り返りとして４つのテストレベルを一覧にしておく。

テストドキュメント

品質は一般的に、プロダクト品質とプロセス品質の両方の結果が揃ってはじめて、より正確な品質判断が可能になると言われている。これはソフトウェアテストでも同様で、テストドキュメント（プロダクト）はソフトウェアテストの良し悪しの一翼を担っている。よって、ソフトウェアテストをよりよくしていくためには、テストドキュメントの品質を向上させる必要があるのだが、そのポイントは「標準化」で、今から紹介する「IEEE829」という規格がそれに該当する。

• IEEE829とは

IEEE829は、ソフトウェアテストにおけるドキュメント標準を定めた規格である。この規格は、テストプロセスの各ステップにおいて作成される文書の種類や内容を明確にし、テスト活動の計画、実行、結果の記録を効率化することを目的としている。

IEEE829をベースに作成したテストドキュメントは、テストのフレームワークとしてテストの透明性と一貫性が確保できるため、プロジェクト内や異なるプロジェクト間での情報共有が容易になる。また、将来的なメンテナンスや監査を容易にすることも可能になる。

• テストドキュメントの概要

では、まずテストドキュメントのイメージを掴かむところから始める。
IEEE829には、ソフトウェアテストの標準化されたテストドキュメントについて記載されており、そのドキュメント群から抜粋したドキュメント（成果物）を、テストプロセスに沿って並べたものが下図である。

▲図4：テストドキュメント（成果物）の流れ

• テストドキュメントの種類

以下に、IEEE829の中で定義されている実際のドキュメント名を示すので、まずはそこから確認してほしい。英語なのでイメージしにくいだろうか？それぞれの右手に、本記事の中で紹介するドキュメントを並べておいたので、記事全体を通して理解を進めていってもらえればと思う。

ちなみにIEEE829は、ソフトウェア開発における各テスト工程で作成が必要とされるドキュメントの信頼できる指針の一つとして、世界中の開発現場で利用、参照されていることを付け加えておく。

• テストドキュメントの体系

テストドキュメント全体の関連性については、以下のような体系となる。なお、単体テストでもテスト設計をする場合はあるが、一般的に行わないことの方が多いため、ここでは省略しているのであしからず。

▲図5：ソフトウェアテストのドキュメント体系

ではさいごに、テストドキュメントのポイントとなるテスト計画の概要を見て、このセクションを締めくくる。

• テスト計画の概要

テスト計画とは、ソフトウェアの品質目標を効率的に達成するために作成するもので、以下のようなテストの指針や概要をまとめたものである。

なお、テスト計画書にはプロジェクトに対する全体テスト計画書と、各テストレベルに対する個別テスト計画書がある。「図5：ソフトウェアテストのドキュメント体系」に示してあるので、再度確認しておいてほしい。

テストプロセス

テストドキュメント（プロダクト）とともに、ソフトウェアテストの良し悪しのもう一翼を担うのがテストプロセスである。ソフトウェアテストの品質（良し悪し）はこの両輪がバランスよく回ってこそ良くなるわけだが、「よいプロダクト（成果物）はよいプロセスがあってこそ成り立つ」ことから、まずはテストプロセスの確立から取り組んだ方が効率がよい。

このテストプロセスについては、「JSTQB」というソフトウェアテスト資格のシラバスに「テスト活動とタスク」という見出しで触れられている。よかったらそちらも確認してみてほしい。

参考：テスト技術者資格制度 JSTQB　Foundation Level シラバス Version 2023V4.0.J02 P.19
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

テストプロセスもテストドキュメントと同様でポイントは「標準化」となるが、テストは体系立てて順序よく進めていくことが鉄則というふうに覚えておいてほしい。以下にテストプロセスを示したので、順に見ていこう。

これらのテストプロセスはどれも欠かせないが、もっとも重要なプロセスは、やはり効率的なテストを行うためのテスト計画の立案である。なぜなら、「テスト計画を立てること」は「テスト戦略を立案すること」とイコールであるため、テスト計画が不十分であったり、計画自体がなかったりすると、次に示すような、なかなか判断し難い（コントロール不能な）事態に対応しきれなくなるからである。

結論として、逆説的な言い方で恐縮だが、このような事態の対応方法までが書かれているテスト計画書が、本来求められているテスト計画ということになる。

ではさいごに、テストプロセスのポイントを示してこのセクションを締めくくる。

• テスト分析・設計をしないことによるデメリット

テスト分析とテスト設計を行う理由は、テストの目的や確認ポイントをより明らかにしたいからである。テスト分析・設計を行わなかった場合、以下のような不都合が出てくるので注意しよう。

結論、テストケースを作成するまでに至った意図や過程がわからないと、後々問題になる可能性がある。覚えておこう。

テストとV&V（検証と妥当性確認）の関係

ソフトウェアテストとはつまり、「ソフトウェア品質を確認すること」である。そして、そのソフトウェア品質を確認するための観点に、「検証（Verification）」と「妥当性確認（Validation）」の2つのプロセスが存在する。この２つのプロセスは、それぞれが補完し合いながら品質が確保される仕組みとなっており、この２つのプロセスを併せて「V＆V」と呼ぶ。このV＆Vの概念もソフトウェアテストにとって非常に重要なことであるため、しっかりと押さえておきたい。

まず、V＆VのそれぞれのVの説明から行う。

この説明で理解できただろうか。では、以下のような不具合が検出された場合は、V＆Vのどちらで確認すべきだったか？少し考えてみてほしい。

どうだろう？簡単すぎただろうか？では、答えを見ていこう。

１と２の不具合は、どちらも機能が実現できていないことから、検証（Verification）で確認すべき不具合である。

一方、３と４の不具合は、要求が満たせていない内容であることから、妥当性確認（Validation）で確認すべき不具合ということになる。

これらの不具合はどちらもあってはいけないのだが、テストの順番としては、機能をテストして検証レベルの不具合を潰してから、システム全体の振る舞いについての妥当性を確認するといった順番になることを覚えておこう。もしこの順番通りにテストを進めなかった場合、いつまでたっても不具合が収まらなくなるといったことになりかねないので、十分に注意してほしい。

▲図６：V字モデルとV＆Vの関係

ソフトウェア品質

合わせて読みたいV＆V（Verification＆Validation／検証と妥当性確認）とは？│IT初心者のための基本ガイド

ソフトウェア開発プロジェクトの品質課題を解決するQualityCubeのサポートサービスについて、その特徴や他社との違いについて、導入するメリットを解説します。...

▲こんな記事も読まれています

テストファースト

唐突だが、あなたはW字モデルのことをご存じだろうか？簡単に説明すると、V字モデルの進化形で、開発とテストを同時並行的に進める形を概念化したもので、「開発フェーズもテスト視点を持って進めよう」といったことを強調したモデルである。（いわゆるテストファーストと考え方は同じ）

要するに、W字モデルでは、開発中は終始テストをしているような恰好になるため、このモデルを採用すると、もちろん高品質な製品が出来上がる確率が高くなる。

しかしながら、W字モデルも万能というわけではなく、プロジェクトの特性によっては向き不向きがある。以下にその事例を挙げておく。

ソフトウェア品質

合わせて読みたいW字モデルとは？│IT初心者のための基本ガイド

ソフトウェア開発プロジェクトの品質課題を解決するQualityCubeのサポートサービスについて、その特徴や他社との違いについて、導入するメリットを解説します。...

▲こんな記事も読まれています

テストタイプ

テストタイプは、特定の目的や方法に基づいて分類されるテストの種類のことを指す。平たく言えば、「テストの狙いで区分した各テストの集合体」ということである。

テストタイプは更に、異なるテストタイプを組み合わせることでより効果的なテストができるようになるため、どのようなテストが有効か？といったテストの狙いをよく考慮して選択するようにしたい。

では、次に代表的なテストタイプを選んで説明する。

• 機能テスト

• 画面テスト

• 回帰テスト（リグレッションテスト）

• シナリオテスト

• ユーザビリティテスト

• 負荷テスト

• パフォーマンステスト

• 探索的テスト

• マニュアルテスト

テスト技法

テスト技法とは、テスト分析やテスト設計を行う際に効率のよいテストを実施するための手法やテクニックのことである。ソフトウェアテストは一般的に、すべての条件の組み合わせをテストしようとすると、その数が膨大になりすぎて現実的ではなくなる。そのため、効率的かつ効果的なテストを実施するためにテスト技法を用いる。

では、テスト技法について解説していく。

• テスト技法の分類

テスト技法は、大きくブラックボックステストとホワイトボックステストに分類される。（その間に位置するグレーボックステストも存在はする）以下、それぞれの概要を説明する。

▲図７：ブラックボックステスト、ホワイトボックステスト、グレーボックステストのイメージ図

• ブラックボックステストの代表例

次に、ブラックボックステストの中でよく用いられるテスト技法を説明する。

同値分割

同値分割は、入力項目が連続する値を持つ場合に、入力領域を同値クラス（同様の出力結果が得られる部分集合）に分けて、それぞれの同値クラスに代表値１つをテストする技法である。このテスト技法により、テストケースは3つに圧縮できる。

▲図８：同値分割のイメージ図

境界値分析

境界値分析は、入力項目が連続する値を持つ場合に、入力領域を同値クラスに分けて、それぞれの同値クラスの境界の値をテストする技法である。このテスト技法により、テストケースは4つに圧縮できる。

▲図９：境界値分析のイメージ図

デシジョンテーブル

デシジョンテーブルは、テスト対象の条件と結果の組み合わせをデシジョンテーブルで整理して、その組み合わせに基づいてテストケースを作成するテスト技法である。

▲図１０：デシジョンテーブルのイメージ図

以上、ブラックボックステストの代表的な技法を紹介したが、もちろんブラックボックステストには、それ以外のテスト技法もある。以下に、それ以外のテスト技法も含めて一覧にしたので、必要なときに見直してほしい。ソフトウェアテストは、限られた時間の中でいかに有効なテストができるか？ということが求められるため、テスト技法は効果的に活用できるようにしよう。

テスト仕様書（テストケース）の作成（ポイントのみ）

テスト仕様書（テストケース）は、設計したテストケースをテスト実施者が間違いなく実行できるよう、手順や期待結果などをまとめたものである。組織によっては、「テストケース」や「チェックリスト」など様々な呼び名が付いているようだが、全て同じものである。ここでは、テスト仕様書作成時に押さえておきたいポイントをまとめておく。

▲図１１：テスト仕様書（テストケース）のイメージ

ちなみに厳密には、「テストケース」はひとつひとつのケースのこと、「テスト仕様書」は作成したテストケースの集まり（全てのテストケース）のことを指す。これも覚えておこう。

不具合管理

ここからは、テストで検出した不具合の管理について一通りのことを解説する。

• 不具合の定義

不具合とは、ソフトウェアが「期待通りに動作しない状態」や、「ユーザーの要求とは異なった振る舞いをする状態」のことを指す。

• 不具合管理のプロセス

不具合は、基本的に以下の流れで管理する。以下、ステップごとに説明する。

▲図１２：不具合対応フロー（イメージ）

• 不具合管理表への記載内容

不具合報告（不具合管理表への記載内容）は具体的かつ明確でないと、修正作業を行う開発者に「何をどのように修正すればよいか」が正確に伝わらないことがある。そのようなことが起こらないよう、不具合報告には最低限、以下の情報を含めること。

▲図１３：不具合管理表のイメージ

• 不具合管理ツール

不具合管理は、エクセルなどのテンプレートで管理する場合やツールを利用する場合など、その組織によってさまざまだが、ツールを利用した方が作業を効率化できる要素は多い。無料で使えるもの（例えば“Redmine無料版”など）もあるので、まだ試したことがない方は一度試してみてほしい。

５分でわかるRedmineの概要
https://redmine.jp/gofun/overview

• 不具合のパターン

ソフトウェア開発とは、顧客の要求から要件を定義して、それをプログラムで実現しようとする一連の活動である。この活動途中で何らかのヒューマンエラーが起きたときに不具合が混入してしまうわけだが、その原因は一つとは限らない。一度じっくりと下図をみながらその原因を考えてみてほしい。きっと新しい発見があると思う。

▲図１４：不具合のパターン

ブログ

合わせて読みたいシステム開発の要件定義とは│成功のもとは要件の不備をゼロにすること

要件定義では、知らず知らずに顧客の思い描いている絵と異なった絵を描いてしまうことがあります。これを本文では「要件の不備」として説明しています。本記事ではシステム開発の最初の入り口で躓かないための要件定義の基本について解説していきます。...

▲こんな記事も読まれています

テストの定量的品質管理

ソフトウェアには“目に見えない”という特徴がある。そのため、管理するためにはソフトウェアの状況を目に見えるようにする必要がある。ここで登場するのが定量的品質管理である。ソフトウェア品質を取り扱う上で一番重要なことは品質を見える化することであり、中でも数値化がポイントとなる。

数値への置き換えが可能になると、グラフ形式にして上がり下がりの推移がわかり、比較もできる。そして、比較により分析も可能になり、客観的な評価も可能になる。それを体系的にしたものが定量的品質管理である。

定量的品質管理の第一歩目は、適切なメトリクスを定義することから始まる。メトリクスはあまり聞き慣れない用語だと思うので、まずはメトリクスの意味から確認しよう。

では、次からメトリクスの具体例をみていこう。テストで定量的品質管理を行う上では、以下のメトリクスが代表的で、実際のプロジェクトでも用いられる場合が多い。それぞれがどのような指標なのかを解説する。

あと、あまり知られていないが、不具合を修正するまでの時間をメトリクスとして収集するのも、テストプロセスを見直したい組織にとっては意味があったりする。

実際の分析方法には、管理図分析やゾーン分析等があるが、ここではイメージだけをお伝えする。特にIPAの資料にとても詳しく書かれているので、そちらを参考にしてほしい。

▲図１５：モデルを用いた分析方法（続 定量的品質予測のススメ　P.14から抜粋）

【IPA】定量的品質予測のススメ
https://www.ipa.go.jp/archive/publish/qv6pgp0000000yw8-att/000005133.pdf

【IPA】続 定量的品質予測のススメ
https://www.ipa.go.jp/archive/publish/qv6pgp0000000zi2-att/000005143.pdf

テストチームの構築と管理

ソフトウェアテストは一人でやることよりも、チームを組んで進めるシチュエーションの方が圧倒的に多くなる。そのため、テストチームについても触れておく。

• タスクと役割分担

テストを進めるうえで発生する主なタスクとその役割分担は、だいたい以下のようになる。

• テストチームのスキルセット

上表のとおり、テストチームはテストの実務全般に携わるため、一般的なテストの技術以外にも求められるスキルがある。テストチームの一員になったら、テスト技術以外の以下のスキルも身に付ける必要がある。

• テストチームの管理

テストチームを効果的に管理するため、テストマネージャーになったら以下のポイントに留意しよう。

 手動テスト vs 自動化テスト

ここからは、テスト関連で知っておいたほうがよいことを解説していく。まずは自動テストから見ていこう。

これまで説明してきたような、テストケースを一つ一つ人の手で行うテストを手動テスト、一方、スクリプトやツールを利用して人の手を介さずに行うテストを自動化テストと呼ぶ。いま世の中的には、「テストが早く大量にこなせる」「コストが安くなる」といった呼び声でテスト自動化の風潮に流れつつあるようだが、本当にその流れに従うことはよいことなのだろうか。以下に、自動化テストと手動テストを項目ごとに並べ、それぞれを比較しながら考察してみたいと思う。

このように、自動化テストは万能ではなく、手動テスト、自動化テスト、それぞれに利点もあれば欠点もある。自動化テストが効果的な繰り返しできるテストにおいてはとても有効な手段となるが、ツールの導入やスクリプトの準備、メンテナンス等に結構な額のコストがかかることもあり、自動化の導入を進める際は、十分に検討したうえで手を打つようにしたいところだ。

テスト自動化の８原則

「テスト自動化の８原則」についてはご存じだろうか。テスト自動化の８原則は、テスト自動化研究会により導き出された、さまざまなテスト自動化に共通する原則のことで、テスト自動化に取り組む際の注意点が網羅的に書かれている。

テスト自動化については、この８原則も紹介しておきたいと思う。なお、詳細については下記URLから確認してもらえればと思う。

• テスト自動化の８原則

引用：テスト自動化の８原則https://sites.google.com/site/testautomationresearch/test_automation_principle

アジャイル開発とテスト

さて、ここからはアジャイル開発とテストについて見ていこう。

アジャイル開発と言えば、俊敏さ、柔軟性、頻繁なリリースといったイメージだと思うが、ソフトウェア品質を「品質＝顧客満足」と単純化して考えた場合、アジャイル開発ほど高品質な開発手法はないと考えている。なぜなら、アジャイルの特徴である「俊敏さ」「柔軟性」「頻繁なリリース」はすべて顧客が喜ぶ要素だからである。

例えば、頻繁なリリースについては、顧客がその都度動くものに対してOKサインを出していることになる。つまり、アジャイル開発とは、常に顧客を満足させながら開発を進める高品質な開発手法だと言える。

また、アジャイル開発に合わせたテスト方法に、いくつかのベストプラクティスも存在するので、以下に紹介しておく。

▲図１６：テスト駆動開発（TDD）のイメージ図

新しいテスト手法とツールの登場

これからのテクノロジーの進化と共に、ソフトウェアテストもより変化が求められるようになるはずだ。実際にAIを活用したテストも登場しており、今後AIにより、ソフトウェアテストがもっと楽に、もっと効率的になる日はそう遠くないのかもしれない。では、いま注目されているテストをざっと確認しておこう。

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

５章テストプロセスで採り上げたJSTQBには、「テストの原則」についても書かれている。

参考：テスト技術者資格制度 JSTQB　Foundation Level シラバス Version 2023V4.0.J02 P.18
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

実際には７つの原則が示されているが、ソフトウェアテストに携わる者としてはどれもこれも最低限知っておくべきことなので、最後に紹介しておく。それぞれその意味するところをしっかりと吟味しながら読み進めてほしい。

▲図１７　１：１０：１００の法則

引用：「ソフトウェア品質保証の方法論、技法、その変遷」P.31を参考に作図
https://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf

ソフトウェアテストに関するその他（Q＆A形式）

この記事で書ききれなかったことをQ&A形式でまとめたので、よかったらここもチェックしておいてほしい。

編集後記

ソフトウェアテストのテストレベル、テストタイプ、テストプロセス、テストドキュメント、テスト技法などを理解することは、効果的なテストを実践するための知識であるとともに、スキルでもあることをお伝えしてきた。また、単体テストから受け入れテストまで、各テストレベルには特有の目的とアプローチがあること、アジャイル開発は高品質な開発手法であること、テスト（自動化テストも含め）には原則があることも、お伝えしてきたとおりである。私にできるのはここまでで、今後この情報をどう活かすかはあなた次第である。

さあ、いますぐ行動しよう！

お問い合わせ

QualityCybeの提供するテスト支援サービスでは、専門的な知見をもとに、貴社のテスト戦略や実務の最適化をサポートいたします。

下流工程支援には、テスト計画作成支援、テスト設計・仕様書作成支援、テスト実施支援、品質強化テスト支援など、さまざまなパターンをご用意しています。もちろんサービスの組み合わせも自由自在です！

また、ソフトウェアテストに関する知識を深めるためのeラーニングやセミナーサービスもご用意しております。このサービスにより、チーム全体のテストスキルを向上させ、品質向上を実現することが可能です。

テスト講座とは、ソフトウェア開発の品質保証において必要な知識とスキルを習得する研修です。IEEE8829をベースとしたテスト3表（テスト計画・テスト設計・テスト仕様書）についてポイントを解説していきます！

ぜひ、この機会にQualityCubeのサービスをご利用いただき、ソフトウェア品質を向上させましょう。あなたからのお問合せをお待ちしています。

ご相談は無料で承っております！

なお、ブログの最新リリース情報につきましては、当社メルマガでリアルタイムにご確認いただけますので、本記事がよかった、ためになった、という方はぜひ、メルマガ登録もお願いします。

最新IT情報やお役立ち情報をコンサルタントが配信中！

本記事では、「ソフトウェアテスト」とはどのようなものか？という基礎的なことから、ソフトウェアテストに関わる人が知っておくべき重要な7原則、またテストの種類について、初心者の方にもわかりやすく解説します。 

なぜ「ソフトウェアテスト」をするのか 

ソフトウェアテストとは、開発したソフトウェアが想定どおりに動作するかを評価・検証することを指します。テスト実施の目的としては、主に以下が挙げられます。

・ソフトウェアの正常な動作を保証する
・ソフトウェアの欠陥やバグを発見する
・意思決定の材料となる情報を提供する
・欠陥の発生を防ぐ

ソフトウェアをリリースする上で「不具合のない製品づくりを目指すこと」は非常に大切です。
不具合が多く期待通りに動作しないソフトウェアは、利用者の不満が増大し使い物にならず、クレームや企業の信用失墜にもつながりかねません。
そんな事態を防ぐためにも、ソフトウェアテストで不具合を発見し、品質不良を防ぐことが重要なのです。

しかしながら、人が開発する以上、開発工程での不具合をゼロにすることはほぼ不可能です。
そのためソフトウェアテストでは、不具合をゼロにすることではなく、ユーザーの期待に沿う形になっているかどうかを確認することも非常に重要です。

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

ソフトウェアテストを行う上で、理解しておくべきガイドラインが存在します。
それが、JSTQB（ソフトウェアテスト技術者の資格認定組織）のシラバスにも記載される「ソフトウェアテストの7原則」です。

原則1 テストは欠陥があることは示せるが、欠陥がないことは示せない
テストで欠陥が見つかったとしても、それはソフトウェアに欠陥があったという事実に過ぎず、逆にテストで欠陥が見つからない場合でも、テストを実施していない範囲に欠陥があるかもしれません。
レアなテストケースが抜け漏れており、そこに欠陥が潜んでいた等の話はよく耳にしますし、リリース前にどれだけ手厚くレビューをしても、バグは発生するときは発生するものと思っておくのがよいでしょう。

原則2 全数テストは不可能
ソフトウェアテストにおいて、すべてのパターン（入力と事前条件の組み合わせ）を網羅することはほぼ不可能です。
小規模な製品テストで、入力される可能性のあるデータパターンがある程度限られているような場合であれば可能かもしれません。しかし大規模システムの場合、全ての条件の組み合わせ、入力条件の組み合わせでのテストは現実的ではありません。
そのためソフトウェアの性質やリスクなどを勘案し、実施可能なテスト範囲に絞り込んで優先度をつけテストするのが定石です。

原則3 早期テストで時間とコストを節約
欠陥を見つけるのが早ければ早いほど、修正コストは少なくなります。逆に言えば、開発が進むほど修正・手戻りのコストが多くなります。開発工程のなるべく早い段階でテストを行うことで、早期に不具合を潰しておきましょう。

原則4 欠陥の偏在
欠陥というのは、ソフトウェア全体に均等に分布しているのではなく、特定の機能やモジュール、クラスに集中するものです。特に、ひっ迫したスケジュールの中で作られた機能や、有識者が少なく十分なレビューが出来ていない機能などが代表的です。
効率的にテストを行うためには、テスト結果を都度分析し、欠陥が多発している箇所がないか確認し、重点的にテストする箇所を絞り込みます。

原則5 殺虫剤のパラドックスにご用心
同じ殺虫剤を使い続けることで虫が耐性を持ち、いずれ駆除できなくなります。同様に、おなじ観点のテストを何度も繰り返していると、新しい欠陥が見つからなくなることがあり、これを「殺虫剤のパラドックス」と言います。
これには、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりすることが重要です。特に、開発経験の少ないメンバーで構成されたチームの場合、相対的に視野が狭くなる傾向にあるため注意しましょう。

原則6 テストは状況次第
状況が異なればテストの方法も変わります。
例えば、金融系のシステム構築であれば、金額計算やデータの整合性を確保する点に重きを置いてテストをする必要があります。個人情報を大量に扱うシステムであれば、セキュリティに重きを置いてテストをします。
テストの効果は、テストの方法や技法、テストケースの選択や作成、テストの実行や評価など、テストの実施内容によって大きく変わります。テストの目的や状況に応じて最適な手法を選択しましょう。

原則7 「バグゼロ」の落とし穴
「バグ0＝高品質なシステム」というわけではありません。極端な例ですが「バグ0です、でも画面表示するのに30秒もかかります」といったシステムは高品質とは言えません。
テストの目的は、ソフトウェアに欠陥がないことを証明することではなく、ソフトウェアの品質を評価することです。テストで欠陥が見つからなくても、それはソフトウェアが完璧であることを意味しないため注意が必要です。

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

次に、ソフトウェアテストの種類について見ていきます。
テストには様々な種類がありますが、大きく以下のように分類できます。それぞれ詳しく見ていきます。

開発工程別

●単体テスト
単体テストは開発工程で最初に行うテスト。作成したプログラムを一つずつ単体でテストして正常に動作するかを検証し、個々のモジュールについて機能や性能、運用性などをチェックします。

●結合テスト
単体テストで確認した複数のモジュールを組み合わせて、不具合がないか、連結がうまくいくかを検証します。小さな結合から大きな結合まで、いくつかの段階に分けて実施します。

●システムテスト
プログラムとハードウェアを合わせてシステム全体のテストを行います。
システムテストが開発者側の最終テストです。ハードウェアを実際に動かしながら、すべてのサブシステムで想定される処理を一通り実施します。

システムテストは結合テストの修正が完了したタイミングで行いますが、テスト計画自体はシステムの基本設計の段階からすでにスタートしています。何故ならシステムテストの目的は、要件定義で決めた要件が満たされているかどうかを確認することだからです。

●受け入れテスト（顧客側）
システムテストで問題がなければ発注者側に納品され、実際に稼働して受け入れテストに移ります。ここで問題がなければ、そのまま本番に移行します。

テストの目的別

テストを行う目的（テストタイプ）別の分類です。なおソフトウェア品質に関する詳しい解説については、以下の記事を参照してください。

ソフトウェア品質

合わせて読むソフトウェア品質とは～IT初心者向けに分かりやすく解説～

急速にデジタル化が進む現代社会においてシステムやアプリを動かす重要な役割を担うソフトウェアですが、それ自体はプログラムなので目には見えません。ソフトウェア品質はどのように担保されているのか具体例をあげながら、IT初心者にもわかりやすく解説します。...

●機能テスト
機能が仕様どおりに実装されているかを検証するテスト

●非機能テスト
どのように動くか、という機能以外の動作についての不具合を検証するテスト

●構造テスト
ソースコードやデータなどソフトウェアの内部構造を検証するテスト

●確認テスト
欠陥が正しく修正されていることを確認するテスト

●回帰テスト
修正や追加等の変更を行った際に、他の機能に意図しない変更が起こっていないことを確認するテスト

ソフトウェアテストの実行方法

●動的テスト
テストのためにソフトウェアを実行するテスト方法のこと。プログラムコードを実行し、その結果によってバグ検出や品質評価、動作確認を行います。

●静的テスト
ソフトウェアを実行せずに行うテストのこと。プログラムコードを実行せず、ドキュメントやソースコードのチェックから不具合を検出します。

ソフトウェアのテスト技法

ソフトウェアテストの品質は、テスト項目の抽出に大きく依存しています。テストデータの抽出以降の作業が正確であっても、テスト項目の抽出が不十分であれば、テストに漏れが生じることになり、本来の目的を達成できません。
そこで、どのような操作をして何を確認するかを定めた「テストケース」を作成します。テストケース作成に用いる技法は以下の通りです。

●ホワイトボックステスト
ホワイトボックステストはプログラムの論理構造（プロセス）が正しいかどうかのテストです。ここでは処理が正しく行われていることを確認し、このテストによってカバレッジ（網羅率）が算出され、プログラムの品質を計る一つの指標となります。
ただし、ホワイトボックステストで焦点となるのはあくまでプログラムの論理構造であり、以下のような不具合は見つけることはできません。

・要求仕様自体の誤りや不備
・データに関するバグ
・マルチタスクや割込みに関するバグ

●ブラックボックステスト
ブラックボックステストは、プログラムを中身の見えない箱＝ブラックボックスとして扱うテストで、様々な入力に対して妥当な出力が返されるかどうかを確認します。ここでは中身の処理に関係なく、期待通りの結果となることを確認します。
ブラックボックステストには、「同値分割」「境界値分析」「デシジョンテーブルテスト」などの技法があります。

同値分割
同じような結果になる入力値をグループ分けし、各グループから1つずつテストすることで効率的に不具合が発見できます。このグループを「同値クラス」と呼びます。
それぞれの入力項目ですべてのクラスの入力を行えば、あらゆる入力に対してテストされたことになります。

境界値分析
ソフトウェアは入力した値によって動きが変わります。例えば、年齢を入力すると大人か子供かでメッセージが変わるツールがあるとします。大人と子供の境目を20歳に設定した場合、20歳は大人と子供どちらと判定されるでしょうか。このように、動きが変わる境目の値を境界値と言います。
境界値分析では、バグの起こりやすい境界値とその前後の値をテストすることで、ソフトウェアにバグがないかを調べます。これは同値分割と組み合わせることで、より効果的なテストになります。

デシジョンテーブルテスト
想定される様々な条件に対し、どのように動作するかを整理した表をデシジョンテーブル（決定表）と呼びます。このデシジョンテーブルを用いて行うテストをデシジョンテーブルテストと言います。

さいごに

さて、ここまでソフトウェアテストの重要な原則や手法の種類について解説してきましたが、いかがでしたか？
ご紹介したのはごく初歩的なものですが、テストには様々な決まりや手法があり、対象によって実施すべき内容やボリュームは実に様々です。

弊社、株式会社QualityCubeではチケット制のテスト工程代行サービス「クオリティドクターテスト」を提供しております。
工数単位のチケットをあらかじめ購入しておき、テストが必要となった際に、必要な部分だけを委託することが可能で、開発コスト削減にもぴったりです。
ご興味をお持ちの方は、ぜひお気軽にご相談ください。