会社で自分たちがアプリケーションの品質を担保していく際に、どのようなことを考えてなければならないか改めて見直したいと思い読んでみました。

ソフトウェア品質を高める開発者テスト改訂版アジャイル時代の実践的・効率的でスムーズなテストのやり方

読書時間

3～4時間　

感想

内容的には概念的な部分を分かりやすく少し工学的に説明している感じの本なので初心者でもわかりやすく、ITエンジニアならさらっと読めてしまう本かなと思いました。

気づき

単体テストには２種類ある

筆者は「単体テスト」という言葉について、「コードベースの単体テスト」と「単機能ベースの単体テスト」の2種類の文脈で使われている、と紹介していました。私は以前はウォーターフォールの現場（手動テスト）にて現在はアジャイルにチャレンジする職場にいることもあり、言われてみると確かにそうだな、と思いました。というか、ウォーターフォールの現場居た時はSTEAD（NTTデータ社の開発標準）を採用しており「PD/M/UT」という工程がありました。このUTがUnit Testを指しているのですが、システムごとに指しているものが異なっており理解するまで本当に時間がかかったのを思い出しました。今後は相手のバックボーンに応じてどの文脈で話しているかきちんと理解した上で会話しようと思いました。

Shift Leftについての認識が誤っていた

自分は、Shift Leftは「早い段階からちゃんと確認をしようね」ぐらいの理解をしていました。しかし実際はそうではなく、Shift Leftをすることで後工程でのバグ発生確率が下がってくる、また、テスト自体の実施効果についても、前工程で実施することの方が効果があるということをこの本を読んでようやく理解できました。

　古き良き？日本のウォータフォールを長く経験していたので（特に私は金融システムに居たのもあって）、「単体テストも統合テストもシステムテストもすべて同じレベルで網羅的にやらなければならない」という強迫観念があり、アジャイルの単体テストについては「自動化することでリグレッションテストも素早くできるようになるからデグレードを防げる」という役割でしかない、とすら思ってしまってました。その点はすごく助かりました。

複雑度を測定して効果的にテストをしていく

それでも限りある人的リソースの中でテストの全てを網羅的にやるのは大変、じゃあせめて重要なところから優先順位をつけてやれたら。というところで複雑度やバグが多く発生しているモジュールを定量的に計測しあたりをつける、というアイディアについてもやりたいと思いました。サイクロマティック複雑度等の概念は知ってはいたものの本気で測るには至ってませんでした。このあたりをしっかり計測していければ、高品質なアプリケーションになっていくのもうなずけます。

　また、ミューテーションテストについても実際のやり方やツールがあることを知らなかったので今動いているコードに適用してみてどんな挙動を示すか試してみたいと思いました。