「知識ゼロから学ぶソフトウェアテスト【改訂版】」を読んだ

www.shoeisha.co.jp

目次

はじめに

忘れないために読んだ感想、心に止めて留めておきたい内容を書いていく、要約ではない

前提

このブログを書いた時点での私のレベル感
テストに関する知識は記憶にあるかぎりでは書籍を1冊

また、ヒンシツ大学の体験型講座の機能テストと非機能テストの講座を受講したことがある

なぜ読もうと思ったのか

職場の同僚が、ソフトウェアテストの歩き方 みたいなマインドマップをslackに貼っていて、そのスタートがこの本だった
※多分 SlideShareで公開されているものだった気がする
スクラムだ!TDDだ!という気運から、テストに関する知見をもっと深めねばと感じていたので買ってみたという運び

感想

リファクタリングユニットテストの本質について

TDDの本質は確実に品質保証するというより、スピードを持って開発し、そして変更に対して耐性を持つことです。

TDDの説明をされると、ユニットテストをちゃんと組んでいれば結合テストはそこそこでいいよね?というように聞こえていた
その違和感が解消された

探索的テスト

探索的テストとはソフトウェアの理解とテスト設計とテスト実行を同時に行うテストである

探索的テストという単語を初めて知った
また、自身が結合試験などを行うときにやっていた手法がこれに当たることを理解した
テストケースを書いていない(工数的に報告しずらい)ので、こっそりやっていた
これからは工数をもらって作業しよう
※現職では、スクラムを採用しているため、開発とテストは同じメンバーが担当する

信頼性について

いわゆるバグ曲線ってあんまり意味ないのでは?という話
バグMTBFの話は面白かったので、メトリクスを取って見たいと思う

コストと品質のバランス

現職では考慮する必要が薄い話だったが、心に止めて置きたい話だったのでメモ

「できません」と言えない日本人

テストというよりもスケジュール管理と交渉の話
なんか、この手の交渉を上手に通す方法があれば知りたい

テスト自動化の罠

テスト自動化は以外と失敗するというお話
向き不向きがあるので、自動化に向いているテストをしましょう
また、UIを含む回帰テストは自動化に向かない、保守コストが高すぎるから

まとめ

テスト手法にばっかり目が向いていたが、体型的にソフトウェアテストについて学ぶことができた気がする
ここから気になった方面(テスト手法や自動化、テスト計画etc)に知見を伸ばして行くのが正解だったなと感じる
文章も硬すぎず(柔らかすぎるくらい)非常に読みやすかった。私には合っていた。