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