LayerXのAutifyを利用したテスト自動化への取り組み
この記事は6月から始まっている #LXベッテク月間 25日目の記事です。 前日の記事はnumashiさんの「行動指針Bet Technologyが浸透してて嬉しいこと」でした！
こんにちは、hiroxyです！ブログ投稿は1年ぶりとなってしまいました。
そんな私ですが、今年の2月から株式会社LayerXバクラク事業部のQAチームにて業務委託として働いており、E2Eテストの自動化ツールであるAutifyの運用をメインで行っています。
これはなに
LayerXにおけるQAプロセスの課題に対して、Autifyをどのように活用しているかご紹介します。
Autifyを導入した背景については「LayerXのQAへの取り組み〜アイスクリームの誘惑に負けるな〜」に詳細が記載されているので、もしよろしければ見てみてください。
LayerXのQAチームが目指す姿
QAチームというと、プロダクトの画面を操作し意図しない挙動があれば不具合かどうか確認し、画面のスクリーンショットをテスト項目書に貼ることがメインの業務であるというイメージが私の中にありましたが、LayerXにおけるQAチームが目指す姿は大きく異なっていました。
QAチームとして最も大事にしているのは、顧客への価値提供を最大化することであり、それを実現するために社内の行動指針の1つであるBet Technologyのマインドで仕組み化を進めたり、そもそもプロダクトの仕様として既存仕様とバッティングしていないか検討できることが理想的です。
QAチームが目指す姿についてはmosa(@mosa_siru)さんの以下資料に詳細が記載されています。
資料の中でも特に「バグのなさ」それ自体を目的化しないという考え方がとても好きで、開発チームの全員がバグが起きた・起きないではなく「どれぐらい顧客影響があるか」をいつも意識されているなと強く感じます。
QAチームの一員として、いかに顧客影響の大きいクリティカルなバグを本番リリースの前に検知するかを常に意識するようになりました。
現状のQAプロセスと課題
上述した目指す姿が完璧に実現できているかというと、そんなことはなくまだまだ道半ばであるというのが現状です。
私が所属するバクラク事業部にはプロダクトとして
バクラク請求書
バクラク申請
バクラク経費精算
バクラク電子帳簿保存
の4つが存在し、基本的にはどのプロダクトも同じサイクルで開発が進んでいきます。
スプリントの初日が仮に月曜日の場合は、以下のような開発サイクルになります。
LayerXのプロダクトの開発速度は非常に速く、1スプリント内で出てくる成果物の量が非常に多いです。この開発速度が速いということについてもmosaさんの資料「開発速度が速い #とは（LayerX社内資料）」がわかりやすいので、よろしければ見てみてください。
この大量の成果物に対してのテストと、既存機能が壊れていないかのテストをQAチームが主導して3日間で行っているわけですが、この増え続けるテスト項目によるテスト実施工数の増大が顧客への価値提供の最大化を妨げる要因の1つとなっています。
増え続けるテスト工数にどう向き合うか
増え続けるテスト工数に対して、具体的に以下を行っています。
Autifyを利用したテスト項目の自動化
テスト実施の外部への委託
実施するテスト項目の再選定・優先順位付け
誰でもテストが実施できるように、テスト項目書の改善
ここからは私が主に取り組んだAutifyを利用したテスト項目の自動化について、具体的にやってみて良かったこと、やるべきだったことについてご紹介します。
テスト自動化は1人でやるべからず
そもそも私はテスト自動化の専任としてQAチームに参加し、専任は私1人だけなので、まずは私だけでテスト自動化を進めていき、他のメンバーは他のの業務に集中してもらうのがよいと考えていました。
しかし振り返ると、複数人がAutifyの運用に携わる体制をなるべく早く作るべきだったなと感じています。
1人でAutifyを運用していると、自分で作成した自動化したテストが、他の人から見て何を・どのような観点で自動化しているかの意図が伝わりやすいかどうかわかりません。
自分にしか解読できない自動化されたテストは、いずれ使われなくなります。
そのリスクを抱えたまま運用するのではなく、はじめから複数人で運用し、他の人から見てもわかりやすいかどうかチェックしながら運用ルールを整備していくのがよいと感じました。
複数人でAutifyを利用できる体制を整えるために、時間を抑えて一緒にテスト自動化してみるハンズオンを開催することも非常に効果的だと感じました。
特にAutifyは直感的にテスト自動化ができるので、文字や口頭で説明するだけじゃなく一緒にテスト自動化をしてみることで、他の人のAutify利用のハードルをぐっと下げることができると思います。
高頻度かつシンプルなテスト項目から自動化を
既存のテスト項目を自動化する場合は、どの項目から自動化をすべきか優先度をつける必要が出てくるかと思います。
優先度の観点としてはざっくり考えても以下のようなものが出てくるでしょう。
ユーザーが利用する頻度
バグのおきやすさ
テストを実施する際の操作の複雑さ
テストを実施する頻度
低頻度で実施されるテスト項目より、高頻度に実施するものを自動化した方がよいのは自明ですが、テスト実施の複雑さについてはシンプルなものからテスト自動化するのがよいと感じるようになりました。
理由はテストを自動化する際の難しさと、自動化したテストの壊れやすさにあります。
基本的に、人にとって操作が複雑なテストは自動化するのも難しいです。また、その難しさ故に、自動化されたテストも解読しづらくなる傾向があると感じています。
結果として、頑張って自動化したけれどよく壊れるし、さらには他の人とっては読みづらく結局使われないテストになってしまう可能性があります。
そのようなテスト項目はまず最初の段階では手動で実施し、シンプルなテスト項目から自動化していきテストカバレッジを増やしていくことをオススメしたいです！
実際にAutifyを運用してどう変わったのか
Autifyの運用を始めてから、自動化されたE2Eテストのカバレッジを約4割増やすことができ、テスト実施工数も削減することができました。
また、今までは1人でAutifyを運用していましたが今月からは他のチームメンバーと一緒に自動化に取り組み、自動化のスピードをより加速させ、テスト項目が増えても人手を増やさなくてよい組織構造にしていきます💪
そして自動化によって削減したテスト実施工数は
テスト項目書を改善し、更に自動化しやすいシナリオにブラッシュアップ
機能が追加・改修された際に、影響のあるテスト項目を自動判別
機能品質だけでなくそもそも良い仕様になっているかという、魅力的品質に目を向ける
E2Eテストの自動化以外にも目を向ける
というような今までやりたかったが、なかなか手を付けることができていなかった他のQA活動に充てることができます。
今後これらの活動にも取り組み、プロダクトの品質を担保する仕組みをより強固にしていきたいと考えています！
最後に
今回はLayerXのQAチームの目指す姿や、テスト自動化への取り組みの一部を紹介させていただきました。
QAチームやテスト自動化の話、QAに閉じず開発チームや開発プロセス全体に興味を持って頂いたかたは、以下のmeetyより是非カジュアルにお話しましょう！
👇QAチームメンバーtaikiさんのmeety👇
QA・開発に限らず、次の10年を作る最初の100人、積極採用中です！🫶