「知識ゼロから学ぶソフトウェアテスト」を読んだ

この本は、専門のテスト担当者、テストエンジニアに向けてかかれている本です。

著者の高橋寿一先生の経歴を書籍から引用させてもらいます。

情報工学博士。フロリダ工科大学大学院にてCem Kaner博士、James Whittaker博士にソフトウェアテストの指導を受けた後、広島市立大学にてソフトウェア研究により博士号取得。米Microsoft社、独SAP社でソフトウェアテスト業務に従事後、日本大手電気会社勤務（現職）

私自身はテストの専門家にはお目にかかったことはありません。そんなエンジニアでもこの本から学べることは多いと思います。

テスト専門の担当者の仕事の一端が見える
テスト担当者から視点から見るソフトウェアがわかる
テストスキルが高いというのはどういうことかわかる
テスト、ソフトウェアの品質に関して考える機会が得られる

これらの点だけでもこの書籍の内容を活かせる場面は十分あると思います。

本書はまず、品質とは何か、バグとは何かを考えるところから始まります。というより本書を読んでいると何度も考えさせられます。

1999年に起こったNASAの火星探索衛星がソフトウェアトラブルで落ちてしまった事故を例が挙がっています。原因はプログラム内でのマイルとメートルの単位変換の問題。

NASAといえば、トップレベルの技術者が集まっているはずですが、どんなソフトウェアにもバグが潜んでいる。世界でもトップレベルの能力を持っていてもすべてのバグから逃れるのは難しいということもわかる例です。

このようなことを受けてテスト担当者の心得に繋がります。心得は以下の格言から始まります。

バグを全て見つけるのは無理だと心得ろ！
Cem kaner

　
身も蓋もない話と思うかもしれませんが、この後に読者に実際の簡単なプログラムのテストケースを書かせる質問が続きます。確かに簡単なプログラムでも正しいテストケースを書くのは簡単では無いです。そして簡単なプログラムでも多くのテストケースが必要になることがわかると思います。十分に複雑な製品であるソフトウェアでは100％のバグを見つけることは現実的に不可能です。

そして、時間や予算の制限が有る以上、無限にテストケースを増やす訳にもいかない。効率的に重大なバグを見つけ出すテストを行う必要があり、それがテスト担当者の腕の見せ所となります。

テスト担当ととして優秀とはどういうことか。以下の高橋先生の言葉にも表れています。

ソフトウェアテストで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるかをしることである

開発者の場合個人のスキルの差が24倍あると言われているのは聞いたことあると思いますが、テストの分野でも10倍はあるだろうと著者は書いています。そのスキルの差は具体的にどのような部分にあるのかは本書を読んでいくとわかってきます。

例えば4章まるまる使って説明されている「探索テスト」はそのスキルの一端を示していると思います。

探索テストという言葉、恥ずかしながらよく知らなかったのですが、このような定義のようです。

探索テストとはソフトウェアの理解とテスト設計とテスト実行を同時に行うテストである Cem Kner

スキルの高いテスト担当者なら、製品を自分で学習し良く知ることで、バグが潜んでいそうなところからテストを行い効率的にバグを出すことができるということです。

SlideShareにも探索テストに関して纏められているスライドがありました。

探索的テスト入門 from H Iseri

ここまで読んで「なるほど」と思い、今度は自分のことを振り返ってみました。テストケースの中身を考える時には、情報処理試験や、IT雑誌などに書いあるような基本的な知識と経験で何とかしていた気がします。それでも、品質を確保できていたのは、たまたま設計や開発にも関わっているソフトウェアだったからこそ、バグが出そうな臭いところもわかっていてテストケース組んだから、リリース前にバグを潰していけたのかなと。つまりは、図らずも探索テストをしていたのかと思いました。

しかし、それは自分が深く知っているソフトウェアだからできたことで、もし、見たことも触ったことも無いソフトウェアを渡されてテストしてくれと言われたとして、更に著者のようにMSやSAPの作っているような複雑で大きなシステムだったとしたら。どんなやり方でテストケースを考えるだろう。

そんな本当のブラックボックステストの時に、どんなテスト手法が存在していて、どんな考え、方針、理論や方法でテストケースを考えて、限られたリソース内でどのように品質を最大化していくのか、本書全体を通して書かれています。

TDDやテストの自動化に関して書かれている部分も必見です。どうやればテストの自動化ができるのかという、「機能」の話は良く見たり聞いたりするのですが、本書では、現実としてその自動化したテストを品質改善につなげるにはどうすれば良いのか、そもそも品質改善につながるのか。そんなことが書かれています。
　

高橋先生自身が以下の引用にあるようにテスト自動化に対する失敗経験豊富のようです。

もう時効になっているとは思うので告白しますが、著者のお行ったかなりの自動化プロジェクトはコスト的に見合うものではありませんでした（日本でも自動化失敗率ではワースト３に入るテストマネージャと自負しています）

失敗から学ぶものは多いと思います。だからこそ、失敗したが故の陥りやすい罠、本当に品質改善に繋がる自動化について書かれている内容は勉強になりました。誤解の無いように書いておくと、本書はテスト自動化に反対しているということは全くなく、適切にテスト自動化を利用し、ソフトウェアの品質を高めるにはどうすれば良いかという視点が書かれています。

内容そのものとは別なのですが、本書の表現全体として「現場の声」的な臨場感があるところも面白いです。

鍵かっこ（「」）で書かれている台詞が多く出てくるのですが、どれも現場の声であることが感じられます。こんなところに本質があったりすると思います。いたるところで著者の上司や部下、他部門・チームとのやりとりが書かれているのも生々しくて説得力があります。

現場の視点豊富に書かれているかなり実践的な内容になっているのですが、それだけではなく博士としての理論的な裏付けも踏まえられているので、内容にもとても信頼がおけます。