Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

新規プロダクトへAutifyを導入してメンテナンスコストを大幅に削減した話

はじめに

はじめまして、リンクアンドモチベーションでQAエンジニアをしている久原です。 今回は私が新卒入社約半年後、エンジニアとして圧倒的初心者のタイミングで任された、Autifyを使ったE2Eテスト自動化プロジェクトについて記事を執筆しようと思います。

本題に入る前に、Autifyとは、一言で言うとノーコードテスト自動化サービスです。

E2Eテストの自動化をノーコードで実現できるサービスになっており、コードをかけない・読めない方でもテストシナリオの作成やメンテナンスができるというメリットがあります。

なぜテスト自動化が必要だったのか?

当時のプロダクト開発のロードマップは以下のようになっており、機能2,3の開発の間に機能1は触れないものの、リポジトリを共有した状態で開発を進めているのでデグレリスクがあるという課題がありました。

しかし、約半年間繰り返し手動テストを行うのはあまりにも非効率であるため、自動化の需要が高まっていました。

そこで導入したのがAutifyです。 以下のように、既に実装を完了した機能についてはAutifyで毎日繰り返しテストを実施することでメンテナンスを行うことを考えました。

Autify導入の成果

じゃあ実際、どれくらいの成果があったのか? 結論から申しますと、半年間で約100hもの工数負担を削減することに成功しました。 上記が半年間手動でテストを行った場合とAutifyを導入した場合の工数の比較です。 表を見てわかる通り、自動化の導入コストを勘案してもAutifyを導入した場合の方が約100hもの工数削減につながっています。

更に、この工数の差分はプロダクトの拡大とともに2次関数的に広がります。 なぜかというと、手動テストの工数は定期的に発生することと、プロダクト拡大によって手動テスト1回あたりの実施工数も増大するためです。

プロダクトの拡大によってテスト実施が負債のように蓄積するという話を耳にすることがありますが、テスト自動化によってそれを回避することができるのです。

Autify導入のやり方

それでは実際にどうやったらAutifyを導入してテスト自動化ができるのか。 我々は以下のような構成でAutifyを実施しています。 image.png

テスト自動化をするために必要な3つの要素

上記構成図を見てわかる通り、必要な要素は3つです。

  1. テストシナリオ
  2. テスト環境
  3. テストデータ

テストシナリオ

これは自動化するテストケースの作成です。 AutifyはE2Eテストなので、細かなパターン網羅テストまでケースに入れ込むのは望ましくありません。(ケースメンテナンスが複雑になり、自動実施の時間も膨大になるため) プロダクトのユーザーが利用する主要な機能のシナリオをケースに落として実装するのが良いと思います。

テスト環境

テストを実施するための環境の作成です。 こちらについては特別なことをしたわけでなく、手動テストで利用するものと同じような環境を作成するだけです。基本的に本番環境以外はIP制限などによって外部公開をしていない場合がほとんどだと思いますが、Autify側の設定でAutify側からのアクセスを許可するIPアドレスを設定できるため、問題なく利用できます。

テストデータ

私が一番悩んだ部分はこの部分です。 自動で毎日テストが走るようにするためには、テスト開始時のデータ = テスト終了時のデータにならなければいけません。例えばブログサイトの自動化であれば、

記事投稿 → 記事編集 → 記事削除

上記のような流れでテストを作成すれば、開始時と終了時でデータの状態は同じはずです。 そのため、何度も上記のテストを回しても問題なくテスト実施できます。

しかし、例えば作成機能はあるが、削除機能を持たないプロダクトの場合そうはいきません。削除ができないため、1回目の実施時は記事は1つなのに2回目の実施時は記事は2つという差分が生まれてしまいます。

それを回避するために、私は以下の方法で回避をしました

記事投稿 → 記事編集 → データリセット → 初期データ作成

削除の代わりにデータリセットと初期データ作成を行うことで開始時と終了時で同じ条件にすることができました。 プロダクトやアーキテクチャによって最適な方法は変わってくると思いますが、テスト開始時とテスト終了時でデータの状態が同じであることは自動化をするためには必須の条件となります。

初期データ作成の実装

初期データ作成はrails runnerで実装しており、以下のような実装になっています。

class Tools::Data::Scenario < Tools::Base
  def set_data
    @hoge = hoge
  end

  def process
    ApplicationRecord.transaction do
      # ユーザーの作成
      create_users

上記をサーバーからbin/rails runner Tools::Data::Scenario.newというコマンドで呼び出してデータを作成するイメージです。

上記項目を自動で実行できるようにする

image.png

再度この図に戻ると、全体の流れがわかると思います。 では実際に上記をどのように自動化したのかについて軽く触れていこうと思います。

テストデータ

DBのデータをテスト開始前の状態に戻す手順については、現在CodeBuildで実装しています。 シェルスクリプト内で以下のコードを記述することでリセットとデータ作成を行なっています。

phases:
  build:
    commands:
      - bin/rails db:migrate:reset
      - bin/rails db:seed
      - bin/rails runner Tools::Data::Scenario.new

rails db:migrate:resetを行なって完全にリセットした後、seedデータと初期データを作成するという流れです。 上記のCodeBuildをEventBridgeで平日毎朝実行するようにスケジュールを設定しています。

テストシナリオ

Autify側の設定はとても簡単で、テストプランを作成することで、以下のように指定した曜日・時刻に定期実行することができます。

また、Slackへの通知設定もできるので、通知したいチャンネルに設定することで、毎朝定期実行の結果を通知してくれるようになっています。

上記のような設定によって、完全に手放しでも毎朝実行結果を確認できる状態を実現しています。

展望・課題

弊社ではE2Eテストを上記のように導入することができましたが、以下のような課題があると考えています。

  • E2Eテストと単体テストの間に落ちる結合観点でのテストをどう効率化できるか

弊社ではRSpec単体テストも自動化していますが、AutifyとRSpecだけですべての観点をテストできているわけではありません。複数機能同士の結合観点についてのパターンテストは手動テストによってカバーしている現状があります。それらをどう効率的に担保していくのか?について、開発フロー全体から考えていく必要があります。

繰り返しテストに悩まず、開発の品質とスピードの両方を高レベルに実現できる開発組織を目指し日々模索しています!