s

ソフトウェアテスト293の鉄則-Cem Kaner-James Bach-Bret Pettichord

ソフトウェアテスト293の鉄則

あいかわらずというか、私はテストが苦手です。結論をいうと、どうしてもテストパターンを全て洗い出すことができず、漏れが後から見つかったりしています。今回はそんなことがないようにと、かなり気合を入れましたがテスト終了と報告したその日に自分で漏れに気づきました。ここで気づいたことは、私はテストパターンがあまりにも多いとそれをひとつずつ洗い出す作業が我慢できず、少ないテストで満足してしまっていることです。今回は自分で気づき再度洗い出し、パターンは分かる範囲で全て洗い出すことができました。でも実際に全てのパターンを動作確認したかというと、はぶいた箇所もあります…わかりきった箇所なので省略したのですが(手を抜いたともいえます)そういうことの繰り返しでバグが発生するのかなぁと反省しています。

テストパターンはIF文の分岐全てを通す。というのが分かりやすいのですが、実際にその方法で洗い出すと膨大な量のテスト項目が出てきてしまい、ほんとにこれでいいの?と思ってしまいます。でも本来はそんなものなんでしょうか?

開発しているときは自信を持って作業できるのですが、テストになるとからっきしです。でも、これを機会に逆にテストが得意になることができれば私の強みにもなると思います。ソフトウェアテスト293の鉄則を少し読みました、心得的なことは書かれているので、もう一冊実際にどういう手法で洗い出せば良いのかといった本をもう一冊買おうと思っています。漏れのないテストをすることが第一の目標です。ただ、だらだらと膨大なテスト項目を洗い出し作業時間を増やすことは本意ではないため、より効率よく少ない作業で漏れのないテストをすることを目指します。まず始めに漏れのないテスト、次に効率よく、次にテストの体系化、そして…とステップアップを目指します。