ソフトウェアのテストは事前に作成したテストケースに従って実施（またはテストコードを記述）するのが一般的です。（*1）つまり、「良いテスト（=ソフトウェアの品質向上に貢献するテスト）」が実施できるかはテストケースの品質に依存してきます。
これまでは、先輩に教わったり、プロジェクトメンバーがつくったテストケースを真似したりと、「自分が置かれている環境において、テストケースの作成技法を吸収する」というやり方で学んできましたが、このやり方だけだと、「知識が偏りがちだし、引出しも増えないな」と感じるようになりました。
実際に活用するかは別としても、体系的にテスト技法を学ぶ必要性を感じたので、テスト技法に関する書籍の中でも、たびたびお勧めされる『はじめて学ぶソフトウェアのテスト技法』を読んでみました。
どんな本か
- テスト設計技法の数々をまとめた本
- テスト技法をブラックボックス技法・ホワイトボックス技法に分類し、それぞれについて解説している
- テストのパラダイム（考え方）についても多少ページが割かれている
- 図解があるものの、訳書特有の言い回しで若干読みづらい（個人的主観ですが）
感想
誰でも使ったことのある技法から、採用されることの少ない技法まで一冊にまとまっているので、「体系的にテスト技法を学べる」本として、前評判通りの良書だと思いました。
技術を体系的にインプットしておくことは大事だと思っています。これまで経験則でなんとなく使ってきた技法についても、理屈や理論を知っておけば、自身のプロダクトやプロジェクトによりうまく適用できるようになるからです。
例えば本書では、「同値テスト」など、だれでも一度は使ったことがあるであろう超基本のテスト技法についても解説があります。「同値テストくらい知ってるし使ったことあるよ」と思うかもしれませんが、「数あるテスト技法の中から同値テストを採用している」という自覚があるのと、なんとなくテストケースをつくっているのとでは、長期的に見て、テストの品質が変わってくるはずです。
テスト担当者は、この単純な手法が正式なテスト設計技法の１つであると気づいていないかもしれませんが、ほとんどの人が無意識のうちに利用しています。（『はじめて学ぶソフトウェアのテスト技法』より）
ちなみに僕の場合、「状態遷移テスト」「ペア構成テスト」「ユースケーステスト」あたりは意識して使ったことがなく、新たな学びになりました。ペア構成テストについては先日記事にもしました。
ただ僕は訳書独特の言い回しが苦手で、特に未経験の技法のところは「頭に入ってこないなー」と感じることもありました。その点については都度読み返したり、業務で使ってみるなどして、徐々に理解を深める必要があると思ってます。
すべてをテストすることはできない
本書を読んでいて、僕が新入社員だった頃、「テストは100%網羅できるものであり、テストケースには正解がある」と思い込んでいたことを思い出しました。
そう思い込んでいたのは、先輩にテストケースをレビューしてもらい、毎回のように漏れのあるケースを指摘されていた経験からきています。（悪い意味で）真面目だった僕は、「100%網羅されたテストケースをつくらないとレビューが通らない、つまりテストケースには正解があるんだ」と勘違いしたのだと思います。
あらゆるインプットを考慮するとパターンは無限に大きくなるから、現実にはすべてのパターンを網羅したテストケースを作成するのは現実的に不可能です（作成できたとしてもパターンが多すぎて実施できない）。
大事なのは「どういう考えでテストケースをつくったか」なんですよね。当時の自分に本書を読ませたら、もう少しまともな仕事ができていたと思います（苦笑）
これらの技法をどう適用してテスト全体を構成するか？
テスト技法の紹介・解説の本なので、「それらをどういう基準で採用して、テストを構成するか」については強く触れられていません。
同値テストや境界値テストは無意識に使うくらい基本となる技法だけど、状態遷移テストやホワイトボックステストなど、これまで使った経験が少ない技法は、採用する基準が具体的にイメージできないな、、、と感じました。
ただ、「テストを構成する技術」はおそらく、本を読んでも習得できるものではなく（もしそういう本があるなら読みたい！）、業務経験で養っていくほかないのかな、とも思いました。仕様技術やプロダクトの特性、求められる品質水準など、プロジェクトによって多種多様のため、どんなテストをするのが最適か、プロジェクトごとに検討する必要があるからです。
「テストを構成する技術」を高めるためにできることは、「できるだけ学びの多い環境に身を置くようにする」事くらいかなあ。
*1:モンキーテストなど例外もありますが
