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