「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶ
ソフトウェア開発において切っても切り離すことのできないのが不具合（バグ）。そして、そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。
ソフトウェアテストの実力診断
この本は「完全無欠なソフトウェアテストは可能か？」という問いかけから始まります。そして、いかに完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。
このプログラムでは、ユ ーザーが三つの整数を入力します。この三つの値は 、それぞれ三角形の3辺の長さを表すものとします 。プログラムは、三角形が不等辺三角形 、二等辺三角形 、正三角形のうちのどれであるかを決めるメッセ ージを印字します 。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。
いかがでしょうか。テストケースのイメージ、湧きますか？僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。
どう思いますか？これで適切にテストパターンの洗い出しが出来ていると思いますか？...残念ながら答えは「いいえ」です。例えば、僕が書いたコードだと"0, 0, 0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。
こうして実際に自分でやってみるとテスト設計の難しさがよくわかります。やはり専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。
では、次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。
ブラックボックステスト
ブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず（見ずに）行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。さっそく詳細を見てみましょう。
同値分割法と境界値分析法
同値分割法
同値分割法は大きく次のような手順で進んでいきます。
- 同値分割
- 有効同値、無効同値に分類
- テストケースを書く
同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。先ほどの三角形判定プログラムのUIが、ユーザーが任意の値を自由に入力できるフォームであると仮定すると、「数字」「文字」「記号」というようにクラス分けできると思います。
次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。三角形判定プログラムでは、三つの整数が求められている値ですから、有効同値が「数字」、無効同値が「文字」「記号」ということになります。
最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。しかし、実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。ちなみに、僕が書いた三角形判定プログラムでは「あ、あ、あ」と入力しても正三角形と出力されます。苦笑
境界値分析法
境界値分析法は、入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か？というところに視点を切り替えるべきでしょう。そうすると、入力領域は整数の中の「正の数（1以上の数値）」となります。
では、正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。一方、上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。しかし、システム的に処理できる数値には上限があります（JavaScriptの場合は 2^53 - 1）。なので、仕様ではどこかに上限を設定しておくべきだと思います。
実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。
ディシジョンテーブル
ディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。三角形判定プログラムでは、数値によって、「正三角形」「二等辺三角形」「不等辺三角形」と出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。基本のアイディアは同値分割法・境界値分析法と同じですが、多数の入出力をチェックするときに有効な手段となります。
自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。しかしまあ散々な結果ですね。ひどい。苦笑
状態遷移テスト
状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。どういうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。
ランダムテスト（モンキーテスト）
これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。
以上がブラックボックステストの手法として紹介されているものでした。ソフトウェアの複雑さにもよりますが、「同値分割と境界値分析 → ディシジョンテーブル → 状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。
まとめ
本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています（詳細はぜひ本をお読みください）。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。
