『知識ゼロから学ぶソフトウェアテスト』読んだ
値下がりしていたので『知識ゼロから学ぶソフトウェアテスト』読んだ。親しみを持ってもらおうという気持ちで所々に暴言が入っているのがウケる。まあそれは置いておくとして、知識ゼロの人にテスト界隈説明しようとするとこうなるのかとか、テスト設計者はこういうこと考えてるのかという点では面白かった。
なぜソフトウェアテストの本なんか読んだかというと、普段つくっているライブラリを、もっとテストしなくていい形で抽象化したかったからというのが理由の一つにある。より良いテストを設計しようとすれば、自然とテストフレンドリーなライブラリが出来るだろうという仮定のもとで読んだ。autodoc みたいにメタテストツールみたいなものを作る上でも考えたいことが多い。
他の理由として、アプリ開発がメインじゃなくてテスト設計がメインの人の考え方を知りたかったといのもある。大きな組織になればよりテストに特化した役職の人間も存在してくるので、その辺りで思想の食い違いから断絶が生まれてはいけないなという気持ちがある。あとは単純に、テスト書くのサボりたいという気持ちがある。単純に書かないというのでは良くないが、テスト書く文化が定着してきてテスト書こうという圧力はそろそろ飽和してきていると思うので、非効率な部分とかでテスト書くのやめようという側の圧力も知りたい。あわよくばテストディレクトリ捨てたい。
モジュール指向のテスト
モジュール指向のテストの話はちょっと面白かった。まあそれほど大した話ではなくて、コード書いているとアプリをモジュールやコンポーネントといった単位に分割していくという手法は当たり前なんだけど、モジュールに分割することでテストを行うのも効率化できるつまりサボれるというのは改めて捉えると確かにという感じ。
あまり関係無いんだけど、Webアプリのフレームワークつくるときに1エンドポイント1クラスで設計されてるとテストすごい楽なのになと思うことがたまにある。特にRESTful APIとかだと共有できる / しないといけないロジックが沢山あるので、それらが独立したモジュールに分割されていて、モジュールの組み合わせでエンドポイントのほとんどの部分が表現できるとテストもしやすいのになと思う。
テストケースの分け方
読む前は特にこういう感じでテストケースの分け方の話が気になっていた。
@r7kamura 同値分割? http://t.co/BjJHo8DLkc
— 趣味はマリンスポーツです (@hitode909) 2015, 1月 6
@r7kamura 入力全部やると終わらないので、間違いそうなところを重点的にテストする、そのときに同値分割がヒューリスティックに役立つ、と思ってた。カバレッジC2まで全部テストするとわりにあわない。ちゃんとしたSIerの人はちゃんとC2までやってるって聞いた
— 趣味はマリンスポーツです (@hitode909) January 6, 2015
本文中にわかりやすい説明があって、少し理解が明瞭になったのが良かった。
同値分割法で実践的にテストケースの数を減らすにはどうしたら良いかというやつ、一つのテストケースでカバー出来る範囲を面で捉えて、異常値の全部の面がカバーされるように減らしていけば効率が良くなるということだった
— ダメになるクッション (@r7kamura) January 12, 2015
おわり
そもそも初心者向けの本なので、知識の偏りを是正して安心するために保守的に読んだ側面がある。実際読んでみた結果、今まで適当にやってたことがまあ大体正しいとされている手法に則ったやり方であって、特に異端という訳ではないということが確かめられたのは良かった。この本は取っ掛かりを掴むのに便利という感じで、ここから拡げてソフトウェアテストの他の情報源を見ていくことにしたい。次はもう少し実践的なところを見ていくために『ソフトウェアテスト技法ドリル』を読むことにした。