こんにちは。みぞぐちです。
アジャイル開発のQAとして日々業務を行っています。
11/2に開催されたJaSST’23 Kyushuにオンライン参加してきました。今回は「E2Eテストの自動化導入」や「継続的テスト」をテーマにした『 テスト自動化から、 開発を支える継続的テストへ』というセッションについて、要点と感じたことをレポートしたいと思います。
セミナー概要
今回のセッションは、ある開発チームがテスト自動化の導入を皮切りに、ソフトウェア開発サイクル全体に段階的にテストを導入していき「継続的テスト」を実現するまでの進化の道のりについてお話しされていました。
【登壇者】
末村 拓也（すえむら たくや）さん
オーティファイ株式会社
シニアテクニカルサポートエンジニア／テスト自動化スペシャリスト
ちなみに「笑わせないと生きていけないタイプの人間なんですよ」とご自身でおっしゃっていた通り、70分の講演は面白くてあっという間でした。
資料は公開されていますので、興味のある方は覗いてみてください。
継続的テストに進化するまでの道のり
これは末村さんが6年前にQAやソフトウェア開発に携わったときの話だそうです。 明日リリースするというリリース日程が差し迫っている状況のときに…
開発者：「QAテストしてください！」
QA：「はい！」
QA：「バグ見つかりました！」
開発者：「バグ直りました！」←リリース当日3時間前
QA：「（え？こっからテストするの～？）」
みたいなことがとてもストレスだったということで、開発者の実装とQAのテストの間に何か見えない壁があってウォーターフォールに近いものが残っていたそうです。この苦しみの源泉は何なのかいろいろ勉強していくうちにDevOpsというのを知りました。
DevOpsとは
DevOpsとは、Development（開発）とOperation（運用）を分けて仕事していたのを一緒にしよう、というシステム開発の流れを良くする意味で使われる造語で、それを下支えする技術や概念として継続的インテグレーションや継続的デリバリーという考え方が出てきたそうです。
では、今回の主役とも言える「継続的テスト」とは何なのか。
上記図のように、継続的テストはすべての場所でテストできると言われています。 開発とQAの間にあった壁が苦しみの源泉でしたが、確かにこの八の字なら壁を取っ払えそうです。ということで、「ある開発チームのテストが継続的テストに進化するまでの道のり」がスタートしました。
クライマックステスト
ある開発チームのお話です。1スプリント2週間で開発／テスト／リリースという流れで仕事をしていて「一度にリリースする量が多い」、「駆け込みマージが多い」、「手戻りが多い」という課題があり、QAの手動テストがボトルネックになっていました。手動テストを自動化したらリリース頻度を増やせるのではないか！ということで、まずはクライマックステストのソリューションとしてE2Eテストの自動化を導入しました。
（ちなみに「クライマックステスト」の名前はChatGPTに考えてもらったそうです。最後の方にどっかーーんとテストするの、何かいい名前ない？と聞いたら「クライマックスはどうでしょう」ということで名付け親になってもらったそうです。いい仕事しますね！）
テスト自動化
テスト自動化したらテスト実行速度は1/4～1/2まで短縮し、4時間だったテストは1～2時間になりました。
しかしここにも課題があり…
E2Eテストの自動テストコードが古かったり、新機能追加に対応できていなかったりと、実際に動かしてみて初めて問題に気が付きました。問題に気付くのが遅かったのです。テスト時間はテストコードのメンテナンス作業が追加発生してむしろ増えてしまいました。
実装の後にテスト工程が集中しているのが悪くて、これを開発中にE2Eテストを回したら、そのサイクルの中で問題にすぐに気付けるのではないか。
ということで次のチャレンジです！
シフトレフト
今まで開発の後に集中していたテストを開発の途中にもっていこう、というシフトレフトを取り入れました。
開発中に開発者によってテストコードの実装／メンテナンスがされるので、問題に気付くタイミングが早くなり、CIサイクルの中にE2Eテストを組み込めば自動的に実行されてリリース直前のQAの負荷軽減、コードフリーズ期間の短縮、リリースサイクルの短縮が可能となり、結果、「2週間スプリントを1週間に」、「2週に1回リリースを1週に1回に」改善していきました。
ただし、ここにも課題があり…
開発者たちにフラストレーションがありました。
「CIの実行時間が長くなった」
「UNITテストで充分なのにE2Eテストを書かないとダメなの？」
これはどのようなバグをどのように見つけるか、ということをチーム内で充分共有されていないのが原因ということがわかり、課題がわかったので次のチャレンジです。
テストリアーキテクティング
リアーキテクティングはリファクタリングと類義語で使われますが、リアーキテクティングは直訳すると再設計。テストリアーキテクティングは、今までE2Eテストに寄りすぎていたテストをもっといろんなテストレベルに寄せていこうというものになります。
左の図のアイスクリームコーンというアンチパターンから、右の図の実行時間が短く実行コストが少ない順に充実させたテストピラミッドのバランスにもっていこう、というのを開発チーム内で共有しまずは合意を取りました。
次にテストのバランスを考えてE2Eテストを減らし、同時にテストを削ってもカバレッジは保っていることを裏付けるためのカバレッジ計測を1週間に1回やって、このチームにとって一番最適なテストピラミッドのバランスを確立しました。
これによって、リリース頻度が週1回だったのをテストリアーキテクティングで週4回に増やすことができました。
ただここでも課題が…
品質について議論できていないのではないか…。
次のチャレンジです！
継続的テスト
「継続的テスト」は作る前からリリースの後までずっとテストし続けるということです。
「開発前」
仕様を理解し、仕様の抜け漏れを減らす。つまりは開発～デプロイまでの必要なテストをリファインメントで計画を立てて合意（QA承認済）するため、自動テストが通ったらQAの判断を待たずに（QAは開発者をブロックせずに）デプロイできるようになります。
「リリース前」
未知の不具合を探るために、探索的テストをします。
「リリース時（段階的ロールアウト）」
ユーザーの反応を見るために一度にリリースしないでちょっとずつリリースしていく、段階的ロールアウトをします。
「リリース後（GA（General Availability））」
全ユーザーに使ってもらい、GA（General Availability）＝ 監視を一つのテスト手段として使い、ユーザーがどんなふうに使っているかというのをテストします。
作る前からリリースの後までずっとテストし続ける「継続的テスト」をしたことにより、デプロイ頻度は週4回から毎日数回になりました！
さらにはチームの課題感も変わり、最初は開発プロセスの中の話ばかりしていたのが、どんなテストが必要か、自分たちがどういう価値をユーザーに提供できるかなど、気付けばチーム全体で品質について議論できるようになっていました。
最後に末村さんは、「この通りにやれというわけではありません。この話をたたき台にして自分たちのチームでも話してみてください。チームの状況に応じたアプローチが必要です。」とおっしゃっていました。
確かにおっしゃる通り、この「継続的テスト」の取り組みは一つの事例で、全ての開発チームにそのまま適応できるものではなく、開発チームごとの課題やそれぞれの議論の結果があって、解決していくためのプロセスやヒントについてをこの講演から学ぶととらえるのが良さそうだと思いました。
感想
今回のセッションを聴いて、『品質を伴う「継続的テスト」を続けること』が重要だと思いました。ただただ「継続的テスト」をするのではなく、PO／開発者／QAそれぞれが「品質」マインドを持ち続けることでその先のユーザーへの価値提供につなげられると解釈しました。さらに時代と共にユーザーの求める価値が変化し続ける今だからこそ『品質を伴う「継続的テスト」を続けること』がマッチしているのだと思います。（ちなみに、今携わっている自身の開発チームはまさにこれを体現しているので講演を聴いた後、にんまりと幸せを噛みしめていました。）
また、セッション内容とは別の観点で着目していたのは、今回一貫して段階的に体系立てて検証する進め方でした。末村さんがやっている「〇〇したことでXXが起こって、そこから出た課題、次のチャレンジ、成果をその都度丁寧に明らかにしていくサイクル」は本当に圧巻でした。これは日々の業務で意識している部分ではあるものの輪郭がぼやけてしまいがちなところでもあったので、自身の課題を見つめなおす講演にもなりました。さっそく明日からの仕事にこの学びを役立てていきたいと思います。
最後まで読んでいただき、ありがとうございました。
