E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと / Preconceptions and What Happened with E2E Testing

Scrum Fest Niigata 2022
https://www.scrumfestniigata.org/

Transcript

1. E2E自動テスト導入・運用を めぐる先入観と実際に起きたこと 2022-05-21 Scrum Fest Niigata 2022 Day 2 サイボウズ株式会社 小山晃久（@akihisa1210）
2. 自己紹介 小山晃久（@akihisa1210） サイボウズ株式会社 開発本部 Garoon 開発チーム 兼 生産性向上チーム 品質、テスト、CI/CD、アジャイル 趣味は読書
3. コンテクストの共有
5. プロダクト 中規模・大企業向けグループウェア 複数のアプリケーションを含む（スケジュール、掲示板、……） クラウド版は1～3ヵ月ごとにリリース、オンプレ版は年に1度リリース 今年で20年目（クラウド版は約10年目）
6. 開発体制（1/2） 日本とベトナムで開発（80人くらい） PdMチーム、デザイナーチーム、ドキュメントチーム、データ分析 チーム、改善・メンテナンスチーム、サポートエンジニアチーム、QA チーム、新機能開発チーム（複数）、E2E 自動テスト基盤チームなど
7. 開発体制（2/2） 新機能開発チームには QA エンジニアも所属 独立した QA チームもある 1スプリントは1週間
8. 発表者がこれまでにやってきたこと（1/2） 問い合わせに対する技術調査（2016～2017） 不具合の調査、不具合改修のテスト 新機能開発チーム（2017～2019） スクラムの中での QA 自動テストにも関わり始める
9. 発表者がこれまでにやってきたこと（2/2） E2E 自動テスト基盤のプロダクトオーナー（2018～） 基盤の改善、何をいつ自動テストに追加するのかの方針決め CI、リリース周りの改善（2019～） 生産性向上チーム（プロダクト横断の支援チーム）を兼務し、一緒にプロダク トの改善にあたったり知見を共有したり
10. イントロダクション
11. この発表のゴール 自動テスト（特に E2E）の導入や運用をやり始めた方、またはやりたい と思っている方に、 自動テストに関する判断の参考になった、と言ってもらう
12. この発表で扱うもの テスト自動化の導入・運用を実際にやってみて起きたこと テスト自動化に対して自分がもっていた先入観 そこから学んだこと
13. 先入観の図式（1/3） 理想とする状態と現状にギャップがある 現状 理想とする状態
14. 先入観の図式（2/3） 理想とする状態に到達するために施策を行うが、理想とする状態と実 際の状態の間にズレがある 施策 実際の状態 現状 理想とする状態
15. 先入観の図式（3/3） ズレが生じる要因の1つに、施策を実施する判断に影響を与えていた 先入観がある 施策 実際の状態 現状 理想とする状態 先入観
16. 事例1
17. 事例1-状況 プロダクトの連携性を強化するため、新しく REST API 群を作成する 発表者が当時属していた開発チーム（ともう1チーム）が担当すること に 開発チーム（の一部）で『実践アジャイルテスト』を輪講するなど、テ ストへの関心が高まっている リグレッションテストの自動化プロジェクトが別チームで動いている
18. 事例1-やりたいこと 初めから自動テストも考慮して開発を進めよう REST API をテストする仕組みを作る PBI を作る 一般に、インテグレーションテストは E2E テストよりも楽とされている ので、テスト自動化の経験がそこまで深くないチームがまず取り組む にはちょうどよさそう
19. 事例1-起こったこと テストを実行する仕組みを作り、テストを書き、CI に組み込んだ サービスが動いている環境に対して、画面操作相当のリクエストを送 信して事前準備を行い、テスト対象の REST API を実行し、レスポン スを期待結果と比較している REST API のテストの一部が自動化されたこと自体はよかったが、既 存の E2E テストの仕組みと似ているがちょっと違う仕組みを開発、し ばらくの間両者を維持することになった
20. 事例1-先入観（1/2） 「API のテストなら E2E テストやユニットテストではなくインテグレー ションテスト相当のものになるだろう」という思い込み しかし、今回実装された REST API は、内部のコンポーネントやサー ビス間をつなぐものではなく、システムを他のサービスと連携させる もの 内部 API 外部 API
21. 事例1-先入観（2/2） 結果として、テストが依存している要素が多く、容易に特定コンポー ネントのみを取り出してテストするのが困難だった → E2E 相当のテ ストを行わざるを得なかった
22. 事例1-ふりかえり 課題の設定自体はよかった。新しい領域に手を出し始めるときに、あ らかじめテスト自動化も考慮しておくのはよい。 しかし、何を自動化すべきか、という点を具体的にイメージできてお らず、これからやるのは「インテグレーションテスト」だろうとしてし まったため、施策がずれてしまった 「何をテストするのか」を特定するための、テスト分析が不足していた
23. 事例1-学んだこと 自動テストを行う場合も、テスト分析を通じて何をテストするか理解 する活動は必要 既存のプラクティスを活用するのは良いが、作るものの性質を理解 し、それのどこに何を適用できるのか具体的に考えてみるとよい
24. 事例2
25. 事例2-状況 E2E テストの自動化を進めるプロジェクトに関わり始める 当面の目標は、リリース前に手動で実行されているリグレッションテ ストの自動化
26. 事例2-やりたいこと 自動化されているテストが少ないので、増やしたい
27. 事例2-起こったこと 自動化されたリグレッションテストのケースは増えたが、そもそも CI のセットアップの手間が大きいことがわかってきた 具体的には、新しいバージョンの開発が始まるたびに、CI ジョブの設 定を新バージョン用にコピーし、テスト環境を構築して参照させる作 業がある これをジョブの数だけやる必要がある 1チームが1スプリント（またはそれ以上）の時間を費やしていた
28. 事例2-先入観（1/2） テスト自動化とは、テストスクリプトを書くことだと考えていた テストスクリプト
29. 事例2-先入観（2/2） そうではなく、テストが実行され、結果がレポートされるまでの全体が スコープ テスト実行環境 テストランナー テスト環境 テストスクリプト CI ジョブなど テスト結果
30. 事例2-ふりかえり リグレッションテストを自動化したい、という狙い自体は適切 リグレッションテストを自動化する = テストスクリプトをたくさん書く （だけ）だと思ってしまったのがよくなかった
31. 事例2-学んだこと テスト自動化を考えるときは、それがどのように実行されて価値を提 供するか、というところにまで目を向ける テストスクリプト → 環境構築自動化 → CI への組み込み、のように順 番に完了させていくと辛い（テストスクリプトがそろっているのに実行 が困難、など） 価値を提供できる状態に早く到達し、そこから各要素を充実させてい くのがよさそう
32. 事例3
33. 事例3-状況 引き続き、 E2E テストの自動化を進める リグレッションテストの実装ができるチームも増えてきた
34. 事例3-やりたいこと リグレッションテストの自動化を進めて、コストを削減していきたい
35. 事例3-起こったこと テストのメンテナンス テストスクリプトの修正だけでなく、テストランナーのライブラリ更新 や、新しい CI システムへの移行なども発生 役割を終えたら解散する予定の E2E テストプロジェクトチームが残 り続けている
36. 事例3-先入観（1/2） テスト自動化をするとその分のコストが減ると思っていた しかし、事例2で紹介したように、自動テストは複数の構成要素からな るシステムであり、個々の要素や全体のメンテナンスが必要になる
37. 事例3-先入観（2/2） それでも自動化するのはなぜ？ 待ちを減らしてスムーズにタスクを流すためには自動テストは必須 （手動テストだと最後にまとめて、となりがち） そこに私たちは価値を感じて投資している、ということ
38. 事例3-ふりかえり 自動テストの仕組み全体のメンテナンスコストが新たに発生すること を考慮できていなかったため、期待値がズレてしまった（コストが純粋 に減る、メンテ不要、といった幻想） メンテナンスを考慮していなかったので、自動テストの継続的なメン テナンスを誰が担当するのか、という問題が存在することに気付けて いなかった（テストのメンテナンスが発生するのは例外的な事態だ と思い込んでいた）
39. 事例3-学んだこと テスト自動化は複雑なシステムを開発することであり、メンテナンス を避けて通ることはできない それでもなぜやるのか、説明できるようにしておくべき 比較的独立性の高いドメインであるため、専門のチームを割り当てる のも理にかなっている（ 『チームトポロジー』でいうところの「プラット フォームチーム」に相当）
40. 事例4
41. 事例4-状況 事例2で問題があることが明らかになった、CI 周りの改善を進めたい チーム外の有識者に相談し、改善に協力してもらう 分かれているジョブを CI パイプラインに組み込み、コミット時やマー ジ時に一連のビルド、テストが流れるようにする
42. 事例4-やりたいこと 日次で実行されている E2E テストのジョブを、メインブランチへの マージごとに流すようにしたい 様々な課題がありそう（例えば、環境構築・破棄の自動化はできる？ 複数バージョンの CI ジョブを並列実行できる？）
43. 事例4-起こったこと 内心、「これはできないのではないか」と考えていたが、支援を受けつ つやってみたらできた 簡単ではなかったが、不可能でもなかった
44. 事例4-先入観 自分が詳しいと思っている分野、手動で行いがちな分野、こだわりが ある分野こそ、自動化が難しいと考えてしまう
45. 事例4-ふりかえり 気づいていなくても、防御的になっていた 他チームの有識者と一緒に作業をすることで、それに気づくことがで きた
46. 事例4-学んだこと ブロッカーは自分かもしれない 長く触れているものには自分のアイデンティティが移ってしまってい るかも 自分で限界を設定しなくてもよい
47. 最後に
48. 先入観まとめ 事例1 「API のテストならインテグレーションテストだろう」 → テスト対象の性質次第 事例2 「テスト自動化 = テストスクリプトを書く」 → テストが価値を提供するための全体が含まれる 事例3 「テストを自動化すればコストが削減できる」 → メンテナンスは必要なので、それでもやる理由を説明 事例4 「それは自動化できないのでは」 → 自分の見方が防御的になっていないか疑う
49. 先入観にどう気づくか 短期間のふりかえりでは気づけないことも 理想と現実のズレが大きくなったときに気づける 他者や外部を利用して距離を取る 「なんかうまくいかない」というような直観も大事に
50. 先入観はなくせるか？ 新しいことを始めるときは、やる前に何かを想定することは不可欠（先 入観をなくすことはできない） 自分や他者の経験に基づいて、判断を better なものに近づけていく
51. Meety やってます！ https://meety.net/matches/HZhQlsWrtFHA