ほのぼの日記

都内在住のプログラマーの日記。

「ソフトウェアテストをカイゼンする50のアイデア」を読む

 テスト手法についての本を読みたくなり、目次をみてゆるく読めそうだったので購入。

amzn.asia  アジャイルスクラムといった反復的なチーム開発でのテストを想定した本で、テストケースの書き方からメトリクスの計測方法まで幅広いトピックを取り扱っている。自分はテスト専門ではないが読みやすい印象を受けた。各トピックは独立しているのでつまみ食いもしやすいのが良かった。

 テストとはソフトウェアの品質を担保するための工程だが、品質の定義はチームの各員によって異なるという話から本書は始まる。

テスターは、開発者が自分たちの意見を聞いてくれないと感じているし、開発者は、テスターが重要でない問題を細かく確認していると感じているのです。ビジネスのステークホルダーは、時間が迫っているときにデリバリーチームがソフトウェア製品にメッキを施していることに憤慨し始め、デリバリーチームは、ビジネスのステークホルダーが持続不可能なデリバリーのペースを主張していることに憤慨し始めます。 (中略) 本当の問題は、人々は品質について単純な見方をしていることが多く、全体像をほとんど見ないことにあります。この誤解に対するよい解決策は、さまざまなグループが合意できる品質の多層的で多面的なビューを作成することです。

 

Gojko Adzic,David Evans,Tom Roden. ソフトウェアテストカイゼンする50のアイデア (Japanese Edition) (p.16). Kindle 版.

 この話を読んで思い出したのが大量のバグを抱えたまま出荷されたWindows95の話や昨年にあった防衛省のワクチン予約システムの炎上だ。

zuuonline.com

togetter.com

 大抵のテスターや開発者なら到底許容できないような品質であっても運用後の混乱のコストが利益を上回ればGOという判断はあり得る(もちろん判断ミスによる爆死もあり得る)。何が最適解かはビジネスや開発などの一方的な視点では決定できず、だからこそチーム開発が重要なのだ。

 他にも、『「どうやって」ではなく、「何を」テストするのか説明しよう』のトピックがなるほどなーと感銘を受けた。テストケースの記述について、個別具体的な操作手順を書くのではなく「何をテストすべきか」を焦点にして書かれるべきという内容だ。

ユーザーストーリーでテストを実行する仕組みや実装の詳細を説明するのは避けましょう。何をどのようにテストするかを説明するのではなく、テストの目的に焦点を絞った議論を続けてください。例えば次のとおりです。

 

シナリオ:プリペイドアカウントでの支払い

Given プリペイドアカウントで1ドルを持っているユーザー

When ユーザーが7ドルのチケットを購入する

Then 支払い方式が承認され、

And そのアカウントのユーザーは3ドル残っている

 

Gojko Adzic,David Evans,Tom Roden. ソフトウェアテストカイゼンする50のアイデア (Japanese Edition) (p.96). Kindle 版.

 「7ドルのチケットのチェックボックスを選択する」「承認ボタンを押下する」「残高の欄に3ドルと表示される」と延々と操作を記載する書き方は、手順そのものに気をとられ肝心のテストの目的そのものを見失いやすい。 ユーザーストーリーやスクラムのプロダクトバックログの書き方でも同様のことは言われるし、テストケースも言われてみればそりゃそうだという内容だがそのような記述に慣れていたのでなかなかに目から鱗体験だった。

 といった様々なテストにまつわる示唆を与えてくれる本であり、つまみ食いで終わらせるつもりが一気読みしてしまった。 とはいえ本書で提示される改善案はそこまで具体的ではないので、Howを学ぶというよりもインスピレーションを受けるためという読み方が良さそうに思えた。

良い本だった。