ソフトウェアが我々の生活に浸透し、あらゆるところで社会を支えています。日々新しいソフトウェアが開発されていますが、開発工程においてそれらが正常に動作するかどうかの確認を「ソフトウェアテスト」と呼んでいます。では、このソフトウェアテストではどのようなことに注意すればいいのでしょうか。
本記事では、ソフトウェアテストについて、その目的と心得ておくべき7つの原則、ソフトウェアテストの分類について解説します。
ソフトウェアテストとは
ソフトウェアテストとその目的は？
ソフトウェアをリリースする上で大切なことは「不具合のない製品」を作ることです。不具合が多く使えない機能が多いことは、品質が悪い製品を意味します。このことから、ソフトウェアテストは不具合を発見し、改善するために行わなければなりません。
ソフトウェアテストでは、テスト対象の特徴に合わせてテストケースを組み、さまざまなテストを繰り返して不具合を見つけ出すことで、ユーザーにとって有用なソフトウェアになることを目指します。人が作る以上、開発工程での不具合をゼロにすることは不可能であるため、ソフトウェアテストは質の良いソフトウェアを開発する上で重要なプロセスの1つです。
SHIFTが考える「良い」ソフトウェアテストに関してはこちらをご覧ください。
＞＞「良い」ソフトウェアテストの定義～プロが教える４つのポイント～のページへ
ソフトウェアテストの7原則
ソフトウェアテストでは、すべての担当者が心得ておくべき7つの原則があるとされています。これは、ソフトウェアテストの国際的な資格認定団体であるJSTQBのシラバスに記載されているものです。以下の7原則を頭に入れておくことで、より正確なテストが可能になるでしょう。
（参照元：テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01）
・テストは欠陥があることは示せるが、欠陥がないことは示せない
・全数テストは不可能
・早期テストで時間とコストを節約
・欠陥の偏在
・殺虫剤のパラドックス
・テストは状況次第
・不具合ゼロの落とし穴
それぞれ詳しく見てみましょう。
テストは欠陥があることは示せるが、欠陥がないことは示せない
ソフトウェアテストを行うことで不具合を見つけ出し、修正することができます。しかし、見つけたすべての不具合を排除しても「もう不具合がない」ことを証明することはできません。
たまたま不具合が出なかった可能性や、そのテストでは発見できなかったという可能性を否定することはできないからです。そのため、不具合は必ずあるもの、という心構えでソフトウェアテストへ臨む必要があります。
全数テストは不可能
ソフトウェアの処理におけるすべてのパターンをテストすることを全数テストと呼びますが、これは不可能だとされています。
例えば、四角形の左上の頂点から右下の頂点までを通る道筋のパターンを数えてみましょう。通常の四角形なら2通りですが、縦横2つに分割して2×2のマス目になると、同じ場所を通らない条件で考えても12通りにまで増えます。これが3×3のマス目になると184通り、4×4のマス目になると8,512通り、5×5のマス目になると126万2,816通りと爆発的に増えていくのです。
このように、組み合わせによってパターンの数は膨大になるため、全数テストは不可能とされているのです。実際にはソフトウェアの性質を考慮し、テストする箇所を絞ったり優先順位をつけたりします。
早期テストで時間とコストを節約
不具合ゼロのソフトウェア開発は不可能なため、不具合はできるだけ早く発見することが大切です。開発初期の不具合を時間が経ってから発見すると、その影響範囲も大きくなってしまうため、早期テストが特に重要だとされています。
欠陥の偏在
ソフトウェアの不具合はあちこちに散らばっているよりも、特定の箇所に集中しているのが一般的です。そのため、テスト計画では過去のデータや直近のテスト結果を参考に、不具合が起きうる箇所を予測してテストケースを絞り込んでいきます。
便利なテストケーステンプレートはこちらからダウンロードいただけます。
＞＞テストケーステンプレートのダウンロードページへ
殺虫剤のパラドックス
同じ殺虫剤を使っているとだんだんと害虫が耐性をつけてしまうことを、殺虫剤のパラドックスといいます。ソフトウェアテストも同じように、不具合を見つけて修正することで「開発段階で不具合を出しにくくする」ことが可能になるため、似たような性質のソフトウェアで同じテストを行い続けると不具合が発見しにくくなっていきます。
テストは状況次第
ソフトウェアの設計や使用目的・状況・期待する結果などに合わせ、テストケースは変えていく必要があります。全まったく同じテストを適用できるソフトウェアはほかに1つも存在しないのです。
不具合ゼロの落とし穴
ソフトウェアテストにより不具合をしらみつぶしにし、仮に不具合がない状態にまで修正できたとしても、本来の機能が使えなくなったり使い勝手に影響が出たりしては意味がありません。
そうなると、不具合はゼロでも良い製品とはいえません。ソフトウェアテストでは、不具合を修正することによる影響についても考慮する必要があります。
ソフトウェアテストの７原則についてはこちらもご覧ください。
＞＞ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説のページへ
ソフトウェアテストの種類と分類方法
ソフトウェアテストの種類や内容は多岐にわたりますが、以下にご紹介する4つの分類方法をおさえるとその全体像を把握しやすくなります。
・品質によるソフトウェアテストの分類
・工程によるソフトウェアテストの分類
・テストレベルによるソフトウェアテストの分類
・技法による分類
品質によるソフトウェアテストの分類
ソフトウェアの品質とは？
ソフトウェアの品質とは「システムやサービスを使う人の要求をどれだけ満足させられるか」という程度を指します。「お客様の満足度」といい換えることもできるため、システムの種類や関係者の立場によって要求や考え方はさまざまです。
そこで一定の基準を設けるために、ソフトウェア品質の評価に関する「ISO/IEC 25010:2011という国際規格が定められています。この規格では、以下のようにソフトウェアの品質特性を8つに分類しています。
ISO/IEC 25010:2011が示す8つの品質特性
| 品質特性 |
概要 |
| （1）機能適合性 |
実装された機能がニーズを満たす度合い |
| （2）性能効率性 |
システムの実行時の性能や資源効率の度合い |
| （3）互換性 |
他製品やシステムと機能や情報を共有、変換できる度合い |
| （4）使用性 |
効果的、効率的に利用できる度合い |
| （5）信頼性 |
必要時に実行できる度合い |
| （6）セキュリティ |
不正に悪用されることがなく、情報やデータが保護される度合い |
| （7）保守性 |
効果的、効率的に保守や修正ができる度合い |
| （8）移植性 |
効果的、効率的に他のハードウェアや実行環境に移植できる度合い |
出典：株式会社SHIFT、日経BP「駄目パターンに学ぶ 失敗しない ソフトウェアテスト 実践ノウハウ」12ページ 表1 「ISO/IEC 25010:2011が示す8つの品質特性」をもとに作成
開発するシステムには必ず目指すべき品質があります。その品質を曖昧にするのではなく、きちんと定義する必要があります。そこで、上記の8つの品質特性が参考になります。
品質を測るためのテストの具体例
工程によるソフトウェアテストの分類
実際には細かいプロセスがありますが、ソフトウェアテストには主に以下のような工程があります。
テスト計画
ソフトウェアテストはやみくもに必要なテストを行うのではなく、目標の期日までに十分なクオリティを確保するべく計画的に実施します。テスト計画においては、どのようなテストを行うのか、どのタイミングで行うのか、どの程度のリソースを確保するのかなどを設計します。具体的には、以下の6つの必須作業があり、それらを決定します。
| テスト計画 |
| （1）テスト対象の決定 |
| （2）テストのやり方の決定 |
| （3）役割分担の決定 |
| （4）準備対象の洗い出し |
| （5）スケジュールの決定 |
| （6）管理方針の決定 |
出典：株式会社SHIFT、日経BP「駄目パターンに学ぶ 失敗しない ソフトウェアテスト 実践ノウハウ」24ページ 図2 「テスト計画プロセスの作業」をもとに作成
テスト設計
テスト設計では、具体的にテストで確認したいことを詰めていきます。インプットとなる情報を入手、テストケースの作成方針の作成、それに従ったテストケースの作成の大きな3つの作業が、最低限すべきものとしてあげられます。
| テスト設計 |
| （1）インプット情報の入手と確認 |
| （2）テスト設計方針の決定 |
| （3）テストケースの作成 |
出典：株式会社SHIFT、日経BP「駄目パターンに学ぶ 失敗しない ソフトウェアテスト 実践ノウハウ」26ページ 図3 「テスト設計プロセスの作業」をもとに作成
テスト実行
テスト実行では、大きく6つの作業をおこないます。実行の前の準備作業が長くなりますが、基本的にはどの工程も着実なテストの実施に必要な作業になります。
| テスト実行 |
| （1）テスト環境の準備 |
| （2）テストデータの準備 |
| （3）実行手順の確認 |
| （4）ツールの準備 |
| （5）実行スケジュールの作成 |
| （6）実行 |
出典：株式会社SHIFT、日経BP「駄目パターンに学ぶ 失敗しない ソフトウェアテスト 実践ノウハウ」28ページ 図4「テスト実行プロセスの作業」をもとに作成
上記の作業にもプロジェクトの規模やシステム特徴によっては、省略できるものもあるかもしれません。しかし、脈絡なく省略してしまうとテストの進行に混乱が生じたり、進捗が遅れたり、目的が達成できなくなったりなどの問題の原因になる可能性があります。主要な工程を理解した上で目的を持って省略をする必要があります。
テストレベルによるソフトウェアテストの分類
テストレベルとは、段階ごとに分けられたソフトウェアテストのことです。開発の段階に応じて適合するソフトウェアテストが割り当てられています。具体的には次の通りです。
・詳細設計→単体テスト
・基本設計→結合テスト
・要件定義→システムテスト
・要求分析→受け入れテスト
V字モデル開発でよく引き合いに出されますが、大まかには上記の通りとなります。開発の段階に応じて対応するテストがあるため、それらを用いて不備がないかをチェックする必要があるのです。
単体テスト
結合テスト
単体テストを行った以降に実施されるテストです。単体で動作するようになったコンポ―ネントを組み合わせ、正常に動作するかを確認します。
単体テストでは問題がなかったとしても、２つ以上の組み合わせにした際に要件を満たさない動作をしてしまう可能性があります。これらの不具合を確認・修正するため、結合テストが実施されます。
結合テストについて詳しくはこちらをご覧ください。
＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説のページへ
システムテスト
受け入れテスト
受け入れテストとは、システムテストをクリアしたものを実際に業務で使用する環境で問題無く動作するかをテストする工程です。発注者側が本番環境で問題無く使用できるかをチェックします。
受け入れテストについて詳しくはこちらをご覧ください。
＞＞受け入れテスト（UAT）とは？実施の目的を観点別に紹介のページへ
技法による分類
ホワイトボックステスト
ブラックボックステスト
まとめ
人が作るものである以上何かしらの不具合は避けられませんが、すべてのパターンをテストすることはできません。ソフトウェアテストにおいてはそのソフトウェアの特性を理解し、どこに重点を置いてテストすべきかを判断する必要があります。
ソフトウェアテストに携わる方は、この記事でご紹介したソフトウェアテストの基本をぜひおさえておいてください。
ソフトウェアテスト入門動画
SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。
また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
資料ダウンロード/動画視聴
ダウンロード
