読書メモ: テスト自動ガイド実践ガイド

app/routes/posts/auto-test-guide-book-memo.mdx

@@ -0,0 +1,106 @@
+---
+title: "読書メモ: テスト自動化実践ガイド"
+description: "テスト自動化実践ガイドという本を読んだのでその読書メモです。"
+date: "2024/08/13"
+published: true
+---
+
+## Intro
+
+[テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法](https://www.amazon.co.jp/dp/4339027081?psc=1&ref=ppx_yo2ov_dt_b_product_details)という本を読みました。
+社内の方におすすめいただき、今のプロダクトのテスト環境で何か活かせるものもありそうだと思い購入し読みました。
+
+大きく3章あり、2章はテスト環境を作るハンズオン形式な内容になっていたので、自分は1章と3章を中心に読みました。かなり読みやすい内容になっており、それでいて活かせそうな知見も多く得ることができてとても良い本でした。
+
+以降は読書メモです。
+
+## テストの目的と役割
+
+まず初めに、様々なテストの目的や役割についてです。
+受け入れテストというテストを初めて知ったり、リグレッションテストを手動でテストし続けるコストといったことを再認識できました。
+
+- 受け入れテストについて
+  - 出来上がったソフトウェアやが仕様や契約条件などの条件を満たしているかを確認するためのもの
+    - 例: 電子メールアドレスでパスワードとログインできること
+- テストを追加する時、まず最初に考えるのがリグレッションテスト
+  - 現在では動いているけど新しく何かを実装したことでそれまで正常に動作していたところが動かなくなるという「先祖返り（リグレッション）」を防ぐことが目的
+  - 性能上何かを変更するために実施する必要がある
+  - 影響の範囲が極めて限定的で、かつ特定できているようなケースでない限りは基本的に全てのケースで実施する必要がある
+  - q. これを手動テストで毎回実行していた場合どうなるか
+    - テストケースは増え続ける
+    - テストのスコープは常にシステム全体
+    - 会社/アプリが大きくなればなりシステムが複雑になればなるほどリグレッションテストの負荷は爆発的に高くなる
+  - 既存機能に対するテストが手動テストに依存してしまっていると、開発テストの労力は常に不均衡な状態になる
+    - 機能追加にかける労力×他の部分が壊れていないことを確認する労力
+    - この状態でテストを進めるとどこかで限界が来るので、本来テストをするだけでいいはずの人がマネジメントしたり日程の調整をしないといけなくなってしまう
+    - 全部テストをしているとテストが長くなるので、その間に他の機能もリリースしたいとなる。そうすると一回のリリースがでかくなってしまう。これをすることがバグが発生する確率は増える
+- **自動テストの目的とは、成長し続けるプロダクトを安全に、持続可能なコストにキープし続けること**
+- 自動テストは開発者の手助けになる
+  - 自動テストによってすぐにフィードバックを受けられる
+  - 同時に、コードがどのように動くのかも教えてくれる
+    - コードからだけでは得られないような、仕様に関わるような部分をテストから情報を得ることができる
+    - テストなので、**常にアップデートされ続けている**というのはかなり大きなメリット
+      - 三年前の仕様書をメンテするのは辛い
+- 自動テストは開発者の手助けになる。が、自動テストは一番頭の硬いテスター
+  - 書いた自動テスト以外のことはしてくれない
+  - 手動テストであれば、少し気になったところがあれば報告してくれたりする
+  - 曖昧になっている部分をどうやって手動テストで補うか
+
+## 開発を支える自動テスト
+
+ここでは先ほどの章で学んだ**受け入れテスト**使ったテスト手動である受け入れ駆動テストについて知りました。
+
+- 受け入れ駆動テスト（ATDD）
+  - 決められた要件があって、それを元にテストコードから先に書くという開発手法
+- 腐りやすいE2Eテスト
+  - メンテされない
+    - → メンテナンスが面倒だったらAutifyみたいなのに乗り換えた方がメンテ楽？
+  - E2Eの目的
+    - コンポーネントテストではカバーしきれないところをテストしたい
+      - → 例えばやっぱりユーザーの一連の動作フローとかになるのかな
+
+## 見つけたいバグを明確にする
+
+ここではどのテストがどのバグを発見したいか。ということを学びました。
+E2Eはそのテストレベル的にほぼ全てのテストが発見できるかもしれないですが、コストやフィードバックのスピード的にintegration（結合テスト）の方が良いかもしれないといった話です。
+
+- 何を見つけるのかを考える
+  - 達成したいこと
+    - 成功パターン
+  - 起こりそうなバグ
+    - 失敗パターン
+- どこで見つけるか
+  - 見つけるものをどのテストレベルでテストするかを考える
+  - e2eでもできるけどintegrationでもできるのであればその方が管理しやすいしフィードバックも早く得られるのでは？
+    - integrationで書いたテストをさらにe2e側で使用みたいなことをするとさらにコストも減らせるのでは
+  - 監視という手もある
+
+## E2Eテストとは何か
+
+次にそもそもE2Eとはなんなのかについてです。
+テストのベストプラクティスとして、ピラミッド型があると思います。（トロフィー型もあります。この場合はどちらでも良いですが、今回はピラミッド型で話を進めます。）
+
+逆にアンチパターンとして、アイスクリーム型があります。これは手動テストに一番負担がかかっている状態です。
+これを徐々にプラミッド型にしていく方法として、E2Eを書きつつ、E2Eではなくても補える部分をunit/integrationにまかせていって徐々にピラミッド型にしていくという話が出ており、とても勉強になりました。
+
+あと、規制がかかってE2Eが書いてしまっていないか、みたいなところも今の自分には刺さる内容でした。
+
+- ユーザーストーリーをテストしたい
+- テストのベストプラクティスとしては、ピラミッド型の方式がある
+- そしてそれの反対として、アイスクリーム型の方式もある。これは一番手動テストに依存した状態になっていること
+  - そしてこれを回避するためにまずe2eを書く必要があり、e2e以外でも担保できるものから徐々に移していくような方法を取る
+    - フォードバックの速さ/コストという点でe2eに依存しすぎるとかなり危ない
+- e2eでしかテストできないものと、なんらかの制約でe2eに縛られているものは区別したほうが良い
+  - 拡張機能のテストはブラウザで使うからブラウザでしか使えないように感じるが、別にそんなことはなく、jsdomを使えばできたりする。みたいな話
+- ユースケースとe2eの数が正比例していくことが理想
+
+## 自動テストを改善するテクニック
+
+ここまででテストの目的、導入方法などの話をしたので、最後に導入した結果を振り返る話です。
+
+- 成果を測定する
+  - Datadogなどのツールを使う
+- Four Keysなどのメトリクスと併用することで、品質や生産性などの直接的なメトリクスを見ながら、それらを向上させるための補助として、カバレッジを使用することができる
+- この本の筆者は、自動テストを導入して手動テストから自動テストにできたものの、やはりまた手動テストになってしまったという。
+  - これの反省としては周りを巻き込めなかったこととしても挙げられている
+  - 確かに強い人が1人でやってもいいが、それだと後に残らないと。なるほどすぎる