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