株式会社Hacobu（以下、Hacobu）でQAエンジニアをやっている、かわせです。
Hacobuでは、E2Eテスト自動化にノーコードツールである、MagicPodの導入をしました。
「テスト自動化」と聞くと、品質向上・生産性向上といったポジティブなワードが並ぶかと思います。
しかし、ノーコードツールによる自動テストの導入と運用には、想像以上の落とし穴があるのも事実です。
今回の記事では、MagicPod導入初期に私たちが直面した課題と、それをどう乗り越え、継続的に運用できるテスト基盤を設計したかについて紹介します。
同じようにノーコード自動化を検討しているチームにとって、アンチパターンに陥らないためのヒントになれば幸いです。
なぜMagicPodだったのか？
E2Eテスト自動化にあたり、多くのかたがツールの比較検討をされたかと思います。
Hacobuでも同様に比較検討を行いました。レコーディング形式のツールやMagicPodのようにステップを実装していく形式のもの、同じノーコードツールの位置づけでも多様なスタイルがあると思います。
その中でも、運用後のテスト管理のしやすさに着眼してMagicPodの導入を決めました。
- 構造的に実装していくのでレコーディング形式に比べてメンテナンスのしやすさがある
- 共有ステップの活用でメンテナンス性が高くなる
- データパターンの活用でデータ駆動なテストができる
このあたりが、継続して運用していくために必要なものと捉えました。
最初に取り組んだこと
MagicPod導入後に何も決めずに実装を始めると運用後に破綻しやすくなる、メンテナンスコスト爆増によって陳腐化するというお話を耳にしました。
- 何をしているかわからず誰も直せない
- 直せるけど改修する対象やステップが多くコストがかさむ
- 結果、失敗したテストが放置され通知が来てもスルーする
- そして、テスト自動化なんてなかったことにされる
特に改修するコストがかさんだ結果、運用ができなくなるのはノーコードツールならではの苦しみと思います。そのため、私たちのチームでは実装を始める前にガイドラインや各種規約を整備しました。
MagicPodプロジェクトの構成設計
まず最初に運用後のメンテナンスのしやすさ、実装のしやすさを考慮して構成の設計を行いました。構成設計を行うことでMagicPodの機能の役割が明確になったと思います。
ガイドライン・規約の設計
次にテストケース実装のためのガイドラインと命名規約などの規約を設計しました。これによって安全なデータ駆動テストが実装できるようになったかと思います。（画像は変数の命名規約の一部）
運用設計
構成の設計やガイドライン・規約の設計を行っただけでは運用されない可能性がありますので、テストケースの実装フローやレビューフロー、テスト失敗時の調査から修正に至るまでのフローを作成しました。
活用の手引きの準備
導入した直後は手探りでテストケースの実装を進めていたため、実装時の気付きや知見をためるためのページを用意しました。これにより実装時に感じた良い方法やアンチパターンが共有することができます。
4. 学習コストは高かったが、レールは引けた
私としてはE2Eテスト自動化を本格的に取り組むのは初めてだったので、導入直後に設計から入れたのは良かったと思いました。「ノーコード≠ノーデザイン」ではなく、設計から始めることで初期コストや新規メンバーの学習コストは高くなる一方で、属人性の低減と継続運用が見えてきたと思います。
Discussion