From 1a81e91228a85b1bc6fe6af47ea51852d404e065 Mon Sep 17 00:00:00 2001 From: yossydev Date: Fri, 9 Aug 2024 20:06:14 +0900 Subject: [PATCH 1/5] add --- app/routes/posts/auto-test-guide-book-memo.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 app/routes/posts/auto-test-guide-book-memo.mdx diff --git a/app/routes/posts/auto-test-guide-book-memo.mdx b/app/routes/posts/auto-test-guide-book-memo.mdx new file mode 100644 index 0000000..46be5ba --- /dev/null +++ b/app/routes/posts/auto-test-guide-book-memo.mdx @@ -0,0 +1,8 @@ +--- +title: "a" +description: "a" +date: "2024/08/13" +published: true +--- + +ここに本文を書く From f7899d70b88042d91aa14b3c29e05be337a9098a Mon Sep 17 00:00:00 2001 From: yossydev Date: Sun, 11 Aug 2024 12:02:10 +0900 Subject: [PATCH 2/5] update --- .../posts/auto-test-guide-book-memo.mdx | 100 +++++++++++++++++- 1 file changed, 97 insertions(+), 3 deletions(-) diff --git a/app/routes/posts/auto-test-guide-book-memo.mdx b/app/routes/posts/auto-test-guide-book-memo.mdx index 46be5ba..7539b38 100644 --- a/app/routes/posts/auto-test-guide-book-memo.mdx +++ b/app/routes/posts/auto-test-guide-book-memo.mdx @@ -1,8 +1,102 @@ --- -title: "a" -description: "a" +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)という本を読みました。 +今の業務でテスト環境の改善を考えており、何か参考になるような情報があるかもと買ってみて読んだんですが、新しい発見もありつつ、ふんわりとした理解だった部分がうまく言語化できるようになった気がしていててとてもいい本でした。今のプロダクトでテスト環境に課題を持っている方は読んでみると色々と発見があると思います。 + +移行は読書メモです。 + +## テストの目的と役割 + +まず初めに、様々なテストの目的や役割についてです。 +受け入れテストというテストを初めて知ったり、リグレッションテストを手動でテストし続けるコストといったことを再認識できました。 + +- 受け入れテストについて + - 出来上がったソフトウェアやが仕様や契約条件などの条件を満たしているかを確認するためのもの + - 例: 電子メールアドレスでパスワードとログインできること +- テストを追加する時、まず最初に考えるのがリグレッションテスト + - 現在では動いているけど新しく何かを実装したことでそれまで正常に動作していたところが動かなくなるという「先祖返り(リグレッション)」を防ぐことが目的 + - 性能上何かを変更するために実施する必要がある + - 影響の範囲が極めて限定的で、かつ特定できているようなケースでない限りは基本的に全てのケースで実施する必要がある + - q. これを手動テストで毎回実行していた場合どうなるか + - テストケースは増え続ける + - テストのスコープは常にシステム全体 + - 会社/アプリが大きくなればなりシステムが複雑になればなるほどリグレッションテストの負荷は爆発的に高くなる + - 既存機能に対するテストが手動テストに依存してしまっていると、開発テストの労力は常に不均衡な状態になる + - 機能追加にかける労力×他の部分が壊れていないことを確認する労力 + - この状態でテストを進めるとどこかで限界が来るので、本来テストをするだけでいいはずの人がマネジメントしたり日程の調整をしないといけなくなってしまう + - 全部テストをしているとテストが長くなるので、その間に他の機能もリリースしたいとなる。そうすると一回のリリースがでかくなってしまう。これをすることがバグが発生する確率は増える +- **自動テストの目的とは、成長し続けるプロダクトを安全に、持続可能なコストにキープし続けること** +- 自動テストは開発者の手助けになる + - 自動テストによってすぐにフィードバックを受けられる + - 同時に、コードがどのように動くのかも教えてくれる + - コードからだけでは得られないような、仕様に関わるような部分をテストから情報を得ることができる + - テストなので、**常にアップデートされ続けている**というのはかなり大きなメリット + - 三年前の仕様書をメンテするのは辛い +- 自動テストは開発者の手助けになる。が、自動テストは一番頭の硬いテスター + - 書いた自動テスト以外のことはしてくれない + - 手動テストであれば、少し気になったところがあれば報告してくれたりする + - 曖昧になっている部分をどうやって手動テストで補うか + +## 開発を支える自動テスト + +ここでは先ほどの章で学んだ**受け入れテスト**使ったテスト手動である受け入れ駆動テストについて知りました。他のテスト手法としてはテスト駆動開発(TDD)があります。 + +- 受け入れ駆動テスト(ATDD) + - 決められた要件があって、それを元にテストコードから先に書くという開発手法 +- 腐りやすいE2Eテスト + - メンテされない + - → メンテナンスが面倒だったらAutifyみたいなのに乗り換えた方がメンテ楽? + - E2Eの目的 + - コンポーネントテストではカバーしきれないところをテストしたい + - → 例えばやっぱりユーザーの一連の動作フローとかになるのかな + +## 見つけたいバグを明確にする + +ここではどのテストがどのバグを発見したいか。ということを学びました。 +E2Eはそのテストレベル的にほぼ全てのテストが発見できるかもしれないですが、コストやフィードバックのスピード的にintegration(結合テスト)の方が良いかもしれないといった話です。 + +- 何を見つけるのかを考える + - 達成したいこと + - 成功パターン + - 起こりそうなバグ + - 失敗パターン +- どこで見つけるか + - 見つけるものをどのテストレベルでテストするかを考える + - e2eでもできるけどintegrationでもできるのであればその方が管理しやすいしフィードバックも早く得られるのでは? + - integrationで書いたテストをさらにe2e側で使用みたいなことをするとさらにコストも減らせるのでは + - 監視という手もある + +## E2Eテストとは何か + +次にそもそもE2Eとはなんなのかについてです。 +テストのいい状態として、ピラミッド型があると思います。(トロフィー型もあります。この場合はどちらでも良いですが、今回はピラミッド型で話を進めます。) + +逆にアンチパターンとして、アイスクリーム型があります。これは手動テストに一番負担がかかっている状態です。 +これを徐々にプラミッド型にしていく方法として、E2Eを書きつつ、E2Eではなくても補える部分をunit/integrationにまかせていって徐々にピラミッド型にしていくという話が出ており、とても勉強になりました。 + +- ユーザーストーリーをテストしたい +- テストのベストプラクティスとしては、ピラミッド型の方式がある +- そしてそれの反対として、アイスクリーム型の方式もある。これは一番手動テストに依存した状態になっていること + - そしてこれを回避するためにまずe2eを書く必要があり、e2e以外でも担保できるものから徐々に移していくような方法を取る + - フォードバックの速さ/コストという点でe2eに依存しすぎるとかなり危ない +- e2eでしかテストできないものと、なんらかの制約でe2eに縛られているものは区別したほうが良い + - 拡張機能のテストはブラウザで使うからブラウザでしか使えないように感じるが、別にそんなことはなく、jsdomを使えばできたりする。みたいな話 +- ユースケースとe2eの数が正比例していくことが理想 + +## 自動テストを改善するテクニック + +ここまででテストの目的、導入方法などの話をしたので、最後に導入した結果を振り返る話です。 + +- 成果を測定する + - Datadogなどのツールを使う +- Four Keysなどのメトリクスと併用することで、品質や生産性などの直接的なメトリクスを見ながら、それらを向上させるための補助として、カバレッジを使用することができる +- この本の筆者は、自動テストを導入して手動テストから自動テストにできたものの、やはりまた手動テストになってしまったという。 + - これの反省としては周りを巻き込めなかったこととしても挙げられている + - 確かに強い人が1人でやってもいいが、それだと後に残らないと。なるほどすぎる From edae12172159e1092e665295d95c9c475a22e489 Mon Sep 17 00:00:00 2001 From: yossydev Date: Sun, 11 Aug 2024 16:09:44 +0900 Subject: [PATCH 3/5] update --- app/routes/posts/auto-test-guide-book-memo.mdx | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/app/routes/posts/auto-test-guide-book-memo.mdx b/app/routes/posts/auto-test-guide-book-memo.mdx index 7539b38..59a794b 100644 --- a/app/routes/posts/auto-test-guide-book-memo.mdx +++ b/app/routes/posts/auto-test-guide-book-memo.mdx @@ -8,9 +8,8 @@ published: true ## Intro [テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法](https://www.amazon.co.jp/dp/4339027081?psc=1&ref=ppx_yo2ov_dt_b_product_details)という本を読みました。 -今の業務でテスト環境の改善を考えており、何か参考になるような情報があるかもと買ってみて読んだんですが、新しい発見もありつつ、ふんわりとした理解だった部分がうまく言語化できるようになった気がしていててとてもいい本でした。今のプロダクトでテスト環境に課題を持っている方は読んでみると色々と発見があると思います。 -移行は読書メモです。 +以降は読書メモです。 ## テストの目的と役割 @@ -76,11 +75,13 @@ E2Eはそのテストレベル的にほぼ全てのテストが発見できる ## E2Eテストとは何か 次にそもそもE2Eとはなんなのかについてです。 -テストのいい状態として、ピラミッド型があると思います。(トロフィー型もあります。この場合はどちらでも良いですが、今回はピラミッド型で話を進めます。) +テストのベストプラクティスとして、ピラミッド型があると思います。(トロフィー型もあります。この場合はどちらでも良いですが、今回はピラミッド型で話を進めます。) 逆にアンチパターンとして、アイスクリーム型があります。これは手動テストに一番負担がかかっている状態です。 これを徐々にプラミッド型にしていく方法として、E2Eを書きつつ、E2Eではなくても補える部分をunit/integrationにまかせていって徐々にピラミッド型にしていくという話が出ており、とても勉強になりました。 +あと、規制がかかってE2Eが書いてしまっていないか、みたいなところも今の自分には刺さる内容でした。 + - ユーザーストーリーをテストしたい - テストのベストプラクティスとしては、ピラミッド型の方式がある - そしてそれの反対として、アイスクリーム型の方式もある。これは一番手動テストに依存した状態になっていること @@ -100,3 +101,8 @@ E2Eはそのテストレベル的にほぼ全てのテストが発見できる - この本の筆者は、自動テストを導入して手動テストから自動テストにできたものの、やはりまた手動テストになってしまったという。 - これの反省としては周りを巻き込めなかったこととしても挙げられている - 確かに強い人が1人でやってもいいが、それだと後に残らないと。なるほどすぎる + +## まとめ + +本書はテストに課題を抱えている方や、テストは十分に動いているがなんでこの構成でうまく行っているのかわかってないみたいな方にとてもおすすめできます。 +ぜひ読んでてみください。 From 42a910debf0ddcba34d4e03ea8420d9136949cbb Mon Sep 17 00:00:00 2001 From: yossydev Date: Sun, 11 Aug 2024 16:12:22 +0900 Subject: [PATCH 4/5] update --- app/routes/posts/auto-test-guide-book-memo.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/app/routes/posts/auto-test-guide-book-memo.mdx b/app/routes/posts/auto-test-guide-book-memo.mdx index 59a794b..f978818 100644 --- a/app/routes/posts/auto-test-guide-book-memo.mdx +++ b/app/routes/posts/auto-test-guide-book-memo.mdx @@ -8,6 +8,7 @@ published: true ## Intro [テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法](https://www.amazon.co.jp/dp/4339027081?psc=1&ref=ppx_yo2ov_dt_b_product_details)という本を読みました。 +今の関わっているプロダクトでテストについての課題があり、 以降は読書メモです。 @@ -45,7 +46,7 @@ published: true ## 開発を支える自動テスト -ここでは先ほどの章で学んだ**受け入れテスト**使ったテスト手動である受け入れ駆動テストについて知りました。他のテスト手法としてはテスト駆動開発(TDD)があります。 +ここでは先ほどの章で学んだ**受け入れテスト**使ったテスト手動である受け入れ駆動テストについて知りました。 - 受け入れ駆動テスト(ATDD) - 決められた要件があって、それを元にテストコードから先に書くという開発手法 From 0a632e01fcb88743e78b731ade2e60a6af5090ae Mon Sep 17 00:00:00 2001 From: yossydev Date: Sun, 11 Aug 2024 16:18:40 +0900 Subject: [PATCH 5/5] update --- app/routes/posts/auto-test-guide-book-memo.mdx | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/app/routes/posts/auto-test-guide-book-memo.mdx b/app/routes/posts/auto-test-guide-book-memo.mdx index f978818..9a98d45 100644 --- a/app/routes/posts/auto-test-guide-book-memo.mdx +++ b/app/routes/posts/auto-test-guide-book-memo.mdx @@ -8,7 +8,9 @@ published: true ## Intro [テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法](https://www.amazon.co.jp/dp/4339027081?psc=1&ref=ppx_yo2ov_dt_b_product_details)という本を読みました。 -今の関わっているプロダクトでテストについての課題があり、 +社内の方におすすめいただき、今のプロダクトのテスト環境で何か活かせるものもありそうだと思い購入し読みました。 + +大きく3章あり、2章はテスト環境を作るハンズオン形式な内容になっていたので、自分は1章と3章を中心に読みました。かなり読みやすい内容になっており、それでいて活かせそうな知見も多く得ることができてとても良い本でした。 以降は読書メモです。 @@ -102,8 +104,3 @@ E2Eはそのテストレベル的にほぼ全てのテストが発見できる - この本の筆者は、自動テストを導入して手動テストから自動テストにできたものの、やはりまた手動テストになってしまったという。 - これの反省としては周りを巻き込めなかったこととしても挙げられている - 確かに強い人が1人でやってもいいが、それだと後に残らないと。なるほどすぎる - -## まとめ - -本書はテストに課題を抱えている方や、テストは十分に動いているがなんでこの構成でうまく行っているのかわかってないみたいな方にとてもおすすめできます。 -ぜひ読んでてみください。