はじめに
こんにちは。コドモンでテスト自動化周りや、テスト基盤周りを色々やりまくっているQAエンジニアの水落です。こしあん派です。
コドモンでは、一人目QA(私)がJOINしてから、テストの自動化(特にUIベースのE2E的なテスト)に取り組んできました。試行錯誤して5年ほど経過し、経験して理解したこと・まだ見えていないことなど、多くのことがわかってきました。この記事では、コドモンの開発体制と自動テストの推移をふりかえりつつ、本当に必要だったテストとは何だったのか？ということをお伝えします。
なお、先日機会をいただいてお話しした内容と一部重なります。
5年間の振り返り
自動テストとその周辺
5年前('20)の時点では、体系的な自動リグレッションテストを用意することが急務でした。数ヶ月でそれなりのものができましたが……頓挫しました。メンテナンスと実行のコストが大きすぎたためです。
テストを諦めるわけにはいきませんので、外部テストツールのAutifyを用いてテストを行うことにしました。「とりあえずAutifyを回しておく」ということができるようになったのは心強かったです。
また、副次的効果ですが、Autifyを用いる前提でリリースパイプラインの構築・運用ができるようになりました。
その後2年ほど('21-23)かけてシナリオ数は増加し、150シナリオ程度が定常的に実行されていました。「Autifyで守る」ということがかなり定着していました。
しかしその後('24)、Autifyのシナリオ数が頭打ちとなりました。これはAutifyでのテストがリリース集約時に行われることで、FAILしたときの手戻りが大きく、担当者に負担が大きいためだと推測しています。
ここまでにも社内では何度か内製自動テスト基盤作成をリトライしていました。結果として、Gauge(テストランナー)とPlaywright(E2Eテストツール)により概ね実現できました。ビジネスサイドでもテスト(= 動作仕様)の読み書きができるよう、Gaugeを用いています。
このテスト基盤を用いて、テックリードとSREにより、Kubernetesを用いたCIが実現できるようになりました。
このCIの実現がきっかけとなり、Autifyから内製自動テスト環境に載せ替えることを決断しました。概ね半年程度で移行が完了しました。
現時点('25/04)ではすでにAutifyでのテストは停止し、内製自動テスト環境で定期実行を行なっています。今後はテスト自体の最適化を行い、trunkベースで開発・リリースができるよう進めています。
開発組織・体制の変化
5年前('20)は開発部全体で20〜30名程度で、機能別チームが発足し始めたころであり、まだアジャイル開発は組織内に浸透していない状態でした。一部開発でスクラム開発を取り入れるなど、少しずつアジャイル開発に取り組もうとし始めたのもそのころでした。
その後('21)、アジャイル開発手法としてエクストリーム・プログラミング(XP)を取り入れはじめました。
XPのプラクティスの中にテスト駆動開発(TDD)があることから、このころから「開発エンジニア自身がテストを作る・実施する」ということが広まってきていたように思います。
数年を経て現時点('25/04)では、開発組織は100名規模に拡大し、XPが社内に普及しました。5〜10名ほどの機能別チームがそれぞれXPに則ったアジャイル開発を行い、その中でTDDや受け入れテスト駆動開発(ATDD)に取り組んでいます。
変化に合わせた自動テスト方法の選択
5年を経てわかってきたのが、プロダクトの状況と開発体制により適した自動テストの方法・ツールを選択する必要があるということです。
体制が固まっておらずプロダクトもテスタブルでない時点では、外部テストツールを用いることは実質必須だったと考えています。外部ツールを利用開始することにより、プロダクト自体もテストが動かせるように若干自動化・最適化が進みます。自動テストが次の高次な自動テストにつながっていきます。
その後、コドモンではXPを導入し、「テストファーストで開発する」「テストが実行され続けている」ということが重要になってきました。QAエンジニアだけでテストをするのではなく、開発エンジニアを含むエンジニア全員が品質について考え、全員でテストをしながら開発する、という考え方です。そうなってくると、テストをプロダクトコードと同等に扱う必要があり、またテストがオンデマンドで実行できることが必要になりました。それが進むにつれ、外部ツールと折り合わない部分が出てきます。
このときには自動テスト実行基盤・実行環境の内製化が重要になるように思います。テストも各チームの持ち物として扱うことで、ようやくXPないしアジャイル開発手法と整合が取れるようになります。
自動テストを開発体制に合わせていく、というのはこのことです。
その上で、行うべき自動テストのスコープとレベルを整理して、「ちょうどいい」テスト方法を選択するのも重要であると考えています。
ユーザー受け入れテストを厚めにする必要があれば外部テストツールを用いた方が、より原義的なシステムレベルのE2Eテストができますし、ストーリー受け入れテストを増やしたければ内製しているテストで対応できるようにするのがよいはずです。リソースや「何を守りたいか」など総合的に判断する必要があります。
事前にテスト計画で振り分けができれば嬉しいですが、後々変更できるよう可塑性を持たせておく必要もあると思います。
まとめ
この5年ほどで開発体制が変化してきて、それに伴い最適な自動テストの形があることがわかってきました。ある意味、コンウェイの法則なのかもしれません。
テストの7原則*1にも「テストはコンテキスト次第」とあり、その"コンテキスト"に開発体制も含まれているのだろうと思います。
本文内ではあまり触れていませんが、これらの知見はコドモンでQAエンジニアもストリームアラインドチームでXPを体現しながら、日々業務にあたって得られたところが大きいです。QA活動と開発が離れていると、お互いの目線でしか理解できません。QAエンジニアが開発エンジニアと深く関わっていくのはもちろん、開発エンジニアがQAエンジニアを受け入れてくれていることで、よりよい方法を模索できています。
ここ5年だけでも、技術面もそうでない面でも著しく変化してきたように思います。チームで変化を乗り切るためにも、「自動テストも変化するもの」と考えてみてはいかがでしょうか？
