2021/05/19
【読書感想】ソフトウェア品質を高める開発者テスト
先日「ソフトウェア品質を高める開発者テスト」を読みました。
この本では、日本のソフトウェア開発の問題点は要求～コーディングまでで仕込まれた全てのバグを最後のテスト工程で潰そうとしていることだと述べています。
自分も最後のテスト工程でテスト要因として人員が大量に投入され、長時間残業しながら山のようなテストケースを消化する羽目になった現場に立ち会ったことがあります。
品質はどうしても低下するし、何よりとても辛い思いをしました。(毎日終電帰り、土日出勤もざら)
この本ではバグは上流工程でテストを行うことで品質を向上（Shift Left）させ、開発・テストエンジニアが長時間残業せずに楽をするためのTipsが書かれています。
書かれている内容は筆者の経験に基づくことも多いですが、きちんとデータに基づいて書かれているのでとても参考になりました。
テストを書くことに前向きになり、希望を持てる内容だったのでテストに嫌な印象をもっている方は是非読んでほしいと感じました。
誰向けか
この本はこんな方にはピッタリの本ではないかと思います。
- 単体テストとは何か、どこをどのようにテストをすれば良いのかを知りたい人
- 品質を保証する（バグを出さない）ためにはどうすれば良いかを知りたい人
- 迫りくるテスト工程におびえ、疲弊している方
面白かったところ
開発者がやるべき単体テスト
単体テストをやるにしても、何をテストすれば良いか分かりません。
単純にコードをなぞってカバレッジを計測するだけなら、やらないほうがマシだと思っています。
筆者は本の中で「境界値テスト」「組み合わせテスト」は最低限やるべきだと書いています。
境界値テストが何か、組み合わせテストが何かは本の中で書かれているので触れませんが
、組み合わせは必ずしも全てのケースでやる必要はないと記載されているのがとても面白いと感じました。
ざっくり言うと**組み合わせが1個、2個の場合は確実に調べ、そこからn数は適切な数で良い(全てでなくてよい)**と書かれています。
これまで全ケース愚直にテストしていましたが、とても疲弊するのでこれからは適切なケース数を考えてテストを書いていこうと思うきっかけになりました。
おそらくこれもスキルの一つで、身に着ければ効率よく品質を向上させることが出来るなと感じました。
バグはどこから出るか？
本の中ではソフトウェアの2割の部分から8割のバグが出ると書かれています。
これはまあそうかなと思っているのですが、筆者は加えて**「ファイルの直近変更回数が多い所からバグが出る」**ことが最近の研究で分かってきたと述べています。
コードの複雑さ = バグの発生しやすさだと思っていたので、これにはかなり衝撃を受けました。
バグの出やすさ(HotSpot)の計算方法が書かれており、それをどうリファクタしていくかも書かれています。 筆者曰く「おおきなファイルは単純に2ファイルにぶった切れ」だそうで、乱暴だけど効果的で分かりやすいTipsだなと思いました。
疑問に思ったところ
- hotspos値を計測するbugspots があるが開発止まっていそう。
hotspos値が有用であれば開発続いてそうだけど、何故？
- キーワード駆動型自動テストについて述べられていたがイメージしずらい
筆者はアクションとデータを一つのドライバースクリプトに纏めることと述べていたが、結局どうすれば良いのか？
PageObjectパターンのようなものを想像すればよい？
最後に
サクサクと読め、とても面白く参考になる本でした。
最後の章では開発者テストを導入するサンプルがとても詳しく書かれているので、「で、実際にどうやるの？」と思った方にもピッタリです。
筆者は「ソフトウェア工学の基礎研究は2000年代前半に終了している感がある」と述べています。
これが本当であればとても嬉しいニュースで、過去の良書を読んでいけば充分ソフトウェア基礎力を向上させることが出来るということです。
参考文献のリンクが大量にあるので読んでいない本は一通り読みたいと思います。
