私たちの生活のあらゆる面を支えるソフトウェア。ソフトウェアを安心・安全に利用するためには、開発工程においてソフトウェアが正常に動作するかを確認する「ソフトウェアテスト」が欠かせません。
本記事では、「ソフトウェアテスト」とはどのようなものか？という基礎的なことから、ソフトウェアテストに関わる人が知っておくべき重要な7原則、またテストの種類について、初心者の方にもわかりやすく解説します。
なぜ「ソフトウェアテスト」をするのか
ソフトウェアテストとは、開発したソフトウェアが想定どおりに動作するかを評価・検証することを指します。テスト実施の目的としては、主に以下が挙げられます。
・ソフトウェアの正常な動作を保証する
・ソフトウェアの欠陥やバグを発見する
・意思決定の材料となる情報を提供する
・欠陥の発生を防ぐ
ソフトウェアをリリースする上で「不具合のない製品づくりを目指すこと」は非常に大切です。
不具合が多く期待通りに動作しないソフトウェアは、利用者の不満が増大し使い物にならず、クレームや企業の信用失墜にもつながりかねません。
そんな事態を防ぐためにも、ソフトウェアテストで不具合を発見し、品質不良を防ぐことが重要なのです。
しかしながら、人が開発する以上、開発工程での不具合をゼロにすることはほぼ不可能です。
そのためソフトウェアテストでは、不具合をゼロにすることではなく、ユーザーの期待に沿う形になっているかどうかを確認することも非常に重要です。
ソフトウェアテストの7原則
ソフトウェアテストを行う上で、理解しておくべきガイドラインが存在します。
それが、JSTQB（ソフトウェアテスト技術者の資格認定組織）のシラバスにも記載される「ソフトウェアテストの7原則」です。
原則1 テストは欠陥があることは示せるが、欠陥がないことは示せない
テストで欠陥が見つかったとしても、それはソフトウェアに欠陥があったという事実に過ぎず、逆にテストで欠陥が見つからない場合でも、テストを実施していない範囲に欠陥があるかもしれません。
レアなテストケースが抜け漏れており、そこに欠陥が潜んでいた等の話はよく耳にしますし、リリース前にどれだけ手厚くレビューをしても、バグは発生するときは発生するものと思っておくのがよいでしょう。
原則2 全数テストは不可能
ソフトウェアテストにおいて、すべてのパターン（入力と事前条件の組み合わせ）を網羅することはほぼ不可能です。
小規模な製品テストで、入力される可能性のあるデータパターンがある程度限られているような場合であれば可能かもしれません。しかし大規模システムの場合、全ての条件の組み合わせ、入力条件の組み合わせでのテストは現実的ではありません。
そのためソフトウェアの性質やリスクなどを勘案し、実施可能なテスト範囲に絞り込んで優先度をつけテストするのが定石です。
原則3 早期テストで時間とコストを節約
欠陥を見つけるのが早ければ早いほど、修正コストは少なくなります。逆に言えば、開発が進むほど修正・手戻りのコストが多くなります。開発工程のなるべく早い段階でテストを行うことで、早期に不具合を潰しておきましょう。
原則4 欠陥の偏在
欠陥というのは、ソフトウェア全体に均等に分布しているのではなく、特定の機能やモジュール、クラスに集中するものです。特に、ひっ迫したスケジュールの中で作られた機能や、有識者が少なく十分なレビューが出来ていない機能などが代表的です。
効率的にテストを行うためには、テスト結果を都度分析し、欠陥が多発している箇所がないか確認し、重点的にテストする箇所を絞り込みます。
原則5 殺虫剤のパラドックスにご用心
同じ殺虫剤を使い続けることで虫が耐性を持ち、いずれ駆除できなくなります。同様に、おなじ観点のテストを何度も繰り返していると、新しい欠陥が見つからなくなることがあり、これを「殺虫剤のパラドックス」と言います。
これには、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりすることが重要です。特に、開発経験の少ないメンバーで構成されたチームの場合、相対的に視野が狭くなる傾向にあるため注意しましょう。
原則6 テストは状況次第
状況が異なればテストの方法も変わります。
例えば、金融系のシステム構築であれば、金額計算やデータの整合性を確保する点に重きを置いてテストをする必要があります。個人情報を大量に扱うシステムであれば、セキュリティに重きを置いてテストをします。
テストの効果は、テストの方法や技法、テストケースの選択や作成、テストの実行や評価など、テストの実施内容によって大きく変わります。テストの目的や状況に応じて最適な手法を選択しましょう。
原則7 「バグゼロ」の落とし穴
「バグ0＝高品質なシステム」というわけではありません。極端な例ですが「バグ0です、でも画面表示するのに30秒もかかります」といったシステムは高品質とは言えません。
テストの目的は、ソフトウェアに欠陥がないことを証明することではなく、ソフトウェアの品質を評価することです。テストで欠陥が見つからなくても、それはソフトウェアが完璧であることを意味しないため注意が必要です。
ソフトウェアテストの種類
次に、ソフトウェアテストの種類について見ていきます。
テストには様々な種類がありますが、大きく以下のように分類できます。それぞれ詳しく見ていきます。
開発工程別
●単体テスト
単体テストは開発工程で最初に行うテスト。作成したプログラムを一つずつ単体でテストして正常に動作するかを検証し、個々のモジュールについて機能や性能、運用性などをチェックします。
●結合テスト
単体テストで確認した複数のモジュールを組み合わせて、不具合がないか、連結がうまくいくかを検証します。小さな結合から大きな結合まで、いくつかの段階に分けて実施します。
●システムテスト
プログラムとハードウェアを合わせてシステム全体のテストを行います。
システムテストが開発者側の最終テストです。ハードウェアを実際に動かしながら、すべてのサブシステムで想定される処理を一通り実施します。
システムテストは結合テストの修正が完了したタイミングで行いますが、テスト計画自体はシステムの基本設計の段階からすでにスタートしています。何故ならシステムテストの目的は、要件定義で決めた要件が満たされているかどうかを確認することだからです。
●受け入れテスト（顧客側）
システムテストで問題がなければ発注者側に納品され、実際に稼働して受け入れテストに移ります。ここで問題がなければ、そのまま本番に移行します。
テストの目的別
テストを行う目的（テストタイプ）別の分類です。なおソフトウェア品質に関する詳しい解説については、以下の記事を参照してください。
●機能テスト
機能が仕様どおりに実装されているかを検証するテスト
●非機能テスト
どのように動くか、という機能以外の動作についての不具合を検証するテスト
●構造テスト
ソースコードやデータなどソフトウェアの内部構造を検証するテスト
●確認テスト
欠陥が正しく修正されていることを確認するテスト
●回帰テスト
修正や追加等の変更を行った際に、他の機能に意図しない変更が起こっていないことを確認するテスト
ソフトウェアテストの実行方法
●動的テスト
テストのためにソフトウェアを実行するテスト方法のこと。プログラムコードを実行し、その結果によってバグ検出や品質評価、動作確認を行います。
●静的テスト
ソフトウェアを実行せずに行うテストのこと。プログラムコードを実行せず、ドキュメントやソースコードのチェックから不具合を検出します。
ソフトウェアのテスト技法
ソフトウェアテストの品質は、テスト項目の抽出に大きく依存しています。テストデータの抽出以降の作業が正確であっても、テスト項目の抽出が不十分であれば、テストに漏れが生じることになり、本来の目的を達成できません。
そこで、どのような操作をして何を確認するかを定めた「テストケース」を作成します。テストケース作成に用いる技法は以下の通りです。
●ホワイトボックステスト
ホワイトボックステストはプログラムの論理構造（プロセス）が正しいかどうかのテストです。ここでは処理が正しく行われていることを確認し、このテストによってカバレッジ（網羅率）が算出され、プログラムの品質を計る一つの指標となります。
ただし、ホワイトボックステストで焦点となるのはあくまでプログラムの論理構造であり、以下のような不具合は見つけることはできません。
・要求仕様自体の誤りや不備
・データに関するバグ
・マルチタスクや割込みに関するバグ
●ブラックボックステスト
ブラックボックステストは、プログラムを中身の見えない箱＝ブラックボックスとして扱うテストで、様々な入力に対して妥当な出力が返されるかどうかを確認します。ここでは中身の処理に関係なく、期待通りの結果となることを確認します。
ブラックボックステストには、「同値分割」「境界値分析」「デシジョンテーブルテスト」などの技法があります。
同値分割
同じような結果になる入力値をグループ分けし、各グループから1つずつテストすることで効率的に不具合が発見できます。このグループを「同値クラス」と呼びます。
それぞれの入力項目ですべてのクラスの入力を行えば、あらゆる入力に対してテストされたことになります。
境界値分析
ソフトウェアは入力した値によって動きが変わります。例えば、年齢を入力すると大人か子供かでメッセージが変わるツールがあるとします。大人と子供の境目を20歳に設定した場合、20歳は大人と子供どちらと判定されるでしょうか。このように、動きが変わる境目の値を境界値と言います。
境界値分析では、バグの起こりやすい境界値とその前後の値をテストすることで、ソフトウェアにバグがないかを調べます。これは同値分割と組み合わせることで、より効果的なテストになります。
デシジョンテーブルテスト
想定される様々な条件に対し、どのように動作するかを整理した表をデシジョンテーブル（決定表）と呼びます。このデシジョンテーブルを用いて行うテストをデシジョンテーブルテストと言います。
さいごに
さて、ここまでソフトウェアテストの重要な原則や手法の種類について解説してきましたが、いかがでしたか？
ご紹介したのはごく初歩的なものですが、テストには様々な決まりや手法があり、対象によって実施すべき内容やボリュームは実に様々です。
弊社、株式会社QualityCubeではチケット制のテスト工程代行サービス「クオリティドクターテスト」を提供しております。
工数単位のチケットをあらかじめ購入しておき、テストが必要となった際に、必要な部分だけを委託することが可能で、開発コスト削減にもぴったりです。
ご興味をお持ちの方は、ぜひお気軽にご相談ください。
