読書メモ。2025年30冊目。
『テスト自動化実践ガイド』を読んでの感想となります。（2025/4/24記載）
本の概要
本書は、Webアプリケーションのテスト担当者や開発者が、自身のプロジェクトにスムーズに自動テストを導入し、自動テストに支えられた開発プロセスを実現できるようになる実践的なガイドブックです。主に下記に挙げるような内容を解説します。
・自動テストに取り組むための心構えや考え方、マインドセット
・テスト全般や自動テストに関する基本的な知識
・E2E自動テストの実践方法
・自動テストや開発プロセスの改善方法
・様々なトラブルシューティングの技術「なぜ自動化が必要なのか？」という目的の理解に重きを置き、ただ自動化して終わりになるのではなく、自動テストを軸にしながらプロダクトを継続的に改善していくための考え方や技法を解説しています。
E2Eテストの実践方法の解説では、手を動かして学べるハンズオンパートを用意しました。サンプルアプリケーションにE2Eテストを導入する流れを体験しながら、必要な考え方やTIPSが学べます。実装手段には「CodeceptJS」と「Playwright」を用いていますが、特定のWebアプリケーションや、特定のフレームワークでのみ適用可能な手法ではなく、様々な状況下で応用できる普遍的・汎用的なテクニックを紹介しています。
引用：
動機
- E2E自動化に対する知識が10年ぐらいから止まっていてそろそろまずいと思っている。
- E2Eテスト自動化の議論になると、いまいち足場のないやり取りになりがち。
- E2Eテストに対する今の知見を吸収したい。
感想
E2Eテストについて。
私が初めて知ったころは、実装が大変だから改修頻度の高い画面にテストを適用することで、コストパフォーマンスが見合うとされていました。
ただ、IT系カンファレンスで最新の情報を聞く中で、自分の知識がすでに使い物にならなくなっていることに気付きました。
当時はどこに適用するかがフォーカスされていましたが、今は目的を柔軟に考えられる時代になったのだと理解しました。
特に、従来の受け入れテストを自動テストに置き換える（リリースサイクル）のだと、充分なフィードバックは実現できないため、なるべく開発サイクル内で実現すべき、という話は考えるところが多くありました。
そもそも私の頭の中では、まだスプリント内が小さなフォーターフォールのように捉えてしまっているところがあるので、刷新したほうが良いのだと思います。
また、E2Eテストが中心の本ですが、単体テストも含め自動テストはソフトウェアの振る舞いをテストするものとの説明がありました。
これは、もっと早く意識しておけばより良い判断ができたかもしれないと感じました。どうしてもプロダクトコードの詳細の確認に寄ってしまうので、目の見えるところに付箋ででも張り出しておきたいです。
本書を通して自分の理解をアップデートすることができたと思っています。
ただ、今の把握に満足せず定期的に追っていきたいと思いました。
忘れたくないメモ
■リグレッションテストにおける自動テストの目的
少なくともリグレッションテストにおける自動テストの目的とは、成長し続けるプロダクトを安全にリリースできる状態を、持続可能なコストにキープし続けること
■開発者に対する自動テストからのフィードバック
開発者にとっては、自動テストを書くことでテストからフィードバックを素早く受けられるようになります。
自分たちが今まで作ってきたものが、今も正しく動いていることを、いつでも教えてくれます。
同時に、それぞれの機能がどのように動くのかも教えてくれます。
■手動テストと自動テストの棲み分け
「知られていないリスクやバグを見つける」ような活動は、人間が知恵を絞ってやるべきです。そのため、自動テストがきちんとバグを見つけてくれるようにするには、人間があらかじめテスト対象やテストそのものに対する要求を明らかにして、どんなテストが必要なのか詳細まで煮詰めておかなければなりません。
■スモークテストによる認知負荷軽減
スモークテストはバグをリリースすることを防ぎませんが、開発効率を高めてくれます。開発者がこれまで手動でやってきたごく簡単な確認手順を置き換えて、開発をスムーズに進める手助けをしてくれます。これは開発者にE2Eテストを広めるのにも効果的です。
■腐るテストコード
機能に一切変更を加えていないにもかかわらず、自動テストが失敗してしまうことをテストコードが腐ると表現することがあります。
テストコードは、ソフトウェアの振る舞いが変わらないことを保証するためのものであるべきなので、機能や振る舞いに変更がないにもかかわらず、内部構造の変更がテストコードに影響を及ぼしているとしたら、何かがおかしいサインだといえます。
