開発者がe2eテストを書くことによって、テスト可能なコードの記述、迅速なフィードバックの提供、バグの回避が可能になる。Wixでは、同社のプロジェクトマネージャ、開発者、QAエンジニアを対象に、QAのみによるテストから開発者によるe2eテストに移行することによって、QAの左シフト(上流への移行)とデリバリ速度の向上を実現した。
WixでQAギルドリーダを務めるYevheniia Hlovatska氏は、2021 Spring OnlineTestConfで、開発者が書いた優れたe2eテストをQAエンジニアが実行する、という変革を自身のチームが実践するための支援をした経験を語った。
Hlovatska氏はまず、開発者がエンドツーエンドテストを作ることに前向きでない理由について説明した。
最大の理由は、開発者はそれが好きではない、ということです。テストを書くことの重要性はもちろん分かっています。ですが、数百万というユーザのために機能を実装することと比べると、どうなのでしょうか？不安定なテストで苦労した経験があれば、なおさらです。
このような理由で、e2eテストを書きたくないという開発者がたくさんいる、とHlovatska氏は言う。それでもテストを書かせれば — 出来栄えの悪いテストがベロシティを向上するどころか、逆に低下させることになりかねない。
Wixは、QAのみがJavaで記述するテストから、開発者がJSで記述するe2eテストへの移行に取り組んでいる。最初に行ったのは、さまざまな役割の人たちに、このアプローチについて説明することだった。
開発者には、e2eテストを書くことの承諾と、そのための時間が必要です。私たちはプロダクトマネージャに会って、開発者にe2eテストを書いてほしいと話しました。そのような場合のマネージャの返答は、予想がつくのではないでしょうか？"機能を書く時間がなくなる。"ここでは、テストの欠如が技術的負債に等しく、最終的にはデリバリの遅延と提供する機能の減少につながる、ということの説明が非常に重要です。優れたテストはベロシティの向上につながるのです。
2番目に行ったのは、開発者たちへの説明です。彼らがそれを"ok"してくれたことで、この取り組みが始まりました。しばらくして私たちは、開発者が必ずしもe2eテストのエキスパートではない、ということに気付きました。知識不足と過去にe2eテストを使った苦い経験とが相まって、テストが不安定であったり、e2eテストに対する悪い評判を耳にするケースがいくつもあったのです。そこで私たちは、ベストプラクティスの構築と、改善のための教育から始めることにしました。
私たちが次に話をしたのは、QAエンジニアたちでした。これまでのe2eテストは、完全に彼らのものでした。テストの記述、テストシナリオの設計、その他テスト自動化に関するすべてのアクティビティにおいて、彼らは経験豊富でした。ですから、正直なところ、私たちが"今後は開発者にe2eテストを書かせたい"といった時、彼らの中にはかなりの不満がありました。一部のQAエンジニアにはこれを、"これからは手作業によるQAエンジニアになるので、自動化を行う必要はない"、と言われたように受け止めたのです。そこで私たちは、彼らがテストを記述する開発者チームとともに、専門家として新たなアプローチを推進する立場にあること、それが次の成長へのステップになり得ること、などを説明しました。
開発者がテストを書くことによる最初のメリットは、テスト可能なコードだ。機能開発中にe2eフローについて考えることは、将来的なユーザとその行動について考えることになる、とHlovatska氏は言う。テスト可能なコードはバグを少なくし、QAエンジニアが適切なテストを行うための余地を大きくする。
Hlovatska氏が挙げた第2のメリットは、開発者が機能実装中にe2eテストを書くことで、コードの品質に関するフィードバックループの速度を上げることが可能になる、という点だ。バグの所在を知るために、テストを依頼して、その完了を待つ必要がなくなる。
開発者がe2eテストを書くことで、ボトルネックが解消し、QAの左"シフト"が可能になるのだ。QAを左シフトすることで、バグを見つけるのではなく防止することが可能になり、待ち時間が少なくなり、最終的には少ないバグで早く提供することができる。
従ってこのアプローチは、開発者のみならず、チーム全体にとってメリットがあるのだ、とHlovatska氏は結論付けている。
開発者がエンドツーエンドテストを行うことについて、Yevheniia Hlovatska氏に話を聞いた。
InfoQ: 開発者がエンドツーエンドテストを行おうという時に、それを実現ないしサポートするための秘訣は何かありますか？
Yevheniia Hlovatska: 私の秘訣はこれです。
- 設計カバレッジ
優れたテストシナリオ設計は、オートメーション成功の50パーセントです。
- テストは短く、焦点を絞ったものにする。テストが数多くのステップでいくつもの機能に触れるようなものならば、間違いなくそのテストは不安定なものになって、開発者のデバッグ時間を増やすことになるでしょう。
- テストでは常に"状況"を念頭に置く。私たちの場合、数千のテストを並行して実施しているので、それに見合った設計が必要になります。
- カバレッジを分析し、時間を掛けて改善する。テスト結果やバグ、最新の運用インシデント、その他テストを改善するデータを定常的に分析することが重要です。
- 教える。
記述されたテストすべてをコントロールするのは非常に困難ですから、規模を拡大するには、よいe2eテストを行う方法を開発者に教育する必要があります。
- 最初にテストをレビューする。コードレビューは、テストとそれに関わるプロセスの両方を改善するための情報を、数多く提供してくれます。
- ベストプラクティスを作る。テストプロジェクトの構造、命名規約、よいウェイター、その他さまざまなことについて。
- 自分のプロセスを作る。例えば、バグが原因でテストがフェールした場合にどうするか。
- 考え方を変える。
開発者がe2eテストで苦い経験をしていると、e2eテストに関する考え方を変えさせるのはかなり難しいかも知れません。
- よいテストひとつから始める。不安定なテストがたくさんあるならば、それらはすべて飛ばして、ひとつをリファクタして安定させましょう。テストがなければ、よいテストをひとつ作りましょう。
- 習慣にする。テストはもはや自分たちの文化である、ということを生き生きとした記憶にしましょう。テストを書くことに同意していても、先を急ぐ時には忘れてしまいがちなのです。
- 数値を示す。メトリクスをいくつか選んで、早い段階でそれを"投資への見返り"として示しましょう。
InfoQ: テスタはエンドツーエンドテストについて、どのように考えているのでしょうか？自分たちに代わって開発者がテストを行うようになることに、どのような懸念を持っているのでしょう？
Hlovatska: たいていのQAエンジニアは、一歩後退したように感じます。ですが実際には、QAプロセスやQAエンジニアのための革命になる可能性もあるのです。
Wixでは、開発のペースが非常に早く、開発者とQAエンジニアの比は、通常は10:1です。ですから、QAがひとりでe2eテストを受け持つと、デリバリ上のボトルネックになるか、テストの数が少なく、それをサポートする時間も不十分なものになります。
テストの記述とメンテナンスを開発者に移行したことで、当社では、新たなタスクのためのスペースが生まれました。QAは自身のオートメーションスキルを向上して、開発者を教育し、既存のテストを改善することができます。オートメーション戦略に関する開発に着手して、それを改善することも可能です。
より詳細なテストを実施したり、プロダクトを調べたり、見逃していたバグを見つけるようなこともできるでしょう。
そしてもちろん、QAエンジニアが望むならば、テストを書き続けることも可能です。
InfoQ: どのような教訓がありましたか？
Hlovatska: 開発者に対して単にe2eテストを書くように頼むだけでは、このアプローチは成功しない、ということが分かりました。必要なのは、
- テストを書く時間を提供すること。
- 開発者用にテストシナリオの設計と改善を行うこと。
- 教育すること。
- テストに関する優れたプロセスを構築すること。
そして、彼らが本当にやりたいと思っていること — コーディングをさせることです :)