検証工数激減の立役者：ノーコードE2Eテストを導入してみた #e2e

6記事目は、エイチームコマーステックフロントエンドエンジニアの大沢（@kazzzzzz）が担当します！

今回は、ノーコードのE2Eテストを社内で導入してみたので、その経緯と所感をお伝えしたいと思います！

E2Eテストを導入したきっかけは、組織体制の見直しでエンジニアチームの人数が半減したことでした。限られたエンジニアリソースで開発を回していくために必要だと考え、本導入に向けて動き出しました。

使っているテストツールはMagicPodですが、ツール問わずに得られた知見をお伝えしたいと思っておりますので、MagicPod固有の話はあまり触れませんがご了承ください。

これまでの検証の課題

これまではスプレッドシートで検証リストをあらかじめ作成し、リリース前にエンジニアが手動で検証していました。役割的には、リグレッションテストに近い形で運用しておりました。

リリース頻度は大小合わせると 40~50回/月ほどあり、影響範囲が狭めだと考えられるリリースに関しては部分的に検証を行い、影響範囲が読めない or 広いリリースはすべての検証を行なっておりました。

これまでで説明した手動検証の課題は以下二点だと考えました

こちらは当然の話ではあるのですが、私たちのチームではdevelopなどの開発ブランチは設けておらず修正ごとにリリースを行う運用をしておりますので、より負担が大きい状態でした。

小さめの改修は数分で検証できますが、大きい改修はサイト全体の検証になるとエンドエンジニア二人がかりで半日かかるみたいなこともザラにありました。

大体、月40時間ほどは検証作業に工数を割いていたかなと思います。

冒頭でリグレッションテストに近い形で運用していると記載しましたが、この「近い」というのは、リグレッションテストとして不十分でした。理由は、実装したエンジニア自身が検証範囲を決めていたためです。

リリース回数が月40~50回と多いため、全部のリリースに対してサイト全体の検証を行なっていたら検証だけで人生が終わってしまいます。

なので開発者から見て、他のページや処理への影響値が読めない場合、もしくは全体に影響がある場合にのみ全体検証を行い、そうで無い場合は開発者の判断で検証範囲を決めていました。

この検証範囲を決める判断が、検証漏れにつながることが多かったように考えます。

その他の要因として、当然人間なので見落としやサボりが発生しますので、そういった機械ではないからこそのエラーも存在していました。

前提として、当時サービスはローンチから1年ちょっとしか経っておらず、ビジネス的にも作っては壊しがよく発生するフェーズでした。

そんな中でせっかく時間かけて質の高いテストコードを作成したところで、ページや機能自体がごっそりなくなったりすることもよくあります。そのため、いかにツール導入・テスト作成コストを下げるかがE2Eテストを効果的に運用するために重要だと考えました。

そのニーズが満たせるのが、ノーコードE2Eテストでした。

GUI上でポチポチとテストが作成できるようになりますし、コードベースのテストだと意識しなければならない部分もツールがいい感じにしてくれます。

例えば、

みたいな感じです。

テストってどうしても運用が続かない、いい加減になってしまう、みたいなことが起こりがちですが、導入して1年弱経ちますがそうはならずに運用を続けられています。

テストが通過しないとリリースできない運用にしているのも大きいですが、

その他にも、

などの理由があると考えています。

E2Eテストのメンテナンス工数を加味した上で、エンジニア全体の検証工数を 24時間/月削減することができました。元々が 40時間/月なので、検証工数6割減です。

また、リリース前の不具合も月に2~3回ほど検出できています。特に、副業のエンジニアの方に一任している実装タスクのテストに効果的に働いています。

次回カレンダーは、

エラー監視でシステムを安定化！緊急対応が減ってチームも安定化！

です！

もしご興味がありましたら次回記事もご購読いただければと思います！

よろしくお願い致します！