KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

【mabl】SaaSでテスト自動化！少人数のチームでリリース工数を半減させるまでの道のり

QA 開発プロセス

こんにちは、カケハシでMusubi Insightのバックエンドエンジニアをしている末松です。

こちらの記事はカケハシ Advent Calendar 2021の 14 日目の記事になります。

半年ほど前の話にはなりますが、Musubi Insight チームにおいてローコードテスト自動化の SaaS であるmablを導入することで、リリースにかかっていた工数を半減させることに成功しました。

今回は、その mabl を導入した背景や実運用に至るまでの工程、そして学びを紹介したいと思います。
mabl の向き不向きなテストやつまづきポイントなども記載してますので、最後まで読んでいただけると嬉しいです。

mabl とは

早速ですがまずは mabl について軽く。

mabl はローコードでテストを自動化できる SaaS で、E2E(End to End)テストだけでなく API テストの自動化も可能なサービスとなっています。

mabl のデスクトップアプリから立ち上げることができるmabl Trainer上でブラウザアプリを操作するだけで、その操作を実行するテストを作成可能です。

1 mabl_trainer

操作の記録だけでなく、以下のようなテストや処理を作成することもできます。

  • html 要素のテキストや選択状態の評価
  • 条件分岐や繰り返し処理
  • 特定の要素が表示されるまで待機

その他複数ブラウザでのテスト実行やAI によるテストの自動修正などが特徴的です。
詳細はリンクを参照ください。

チームの課題感

Musubi Insight チームではリリースサイクルを 1 週間と定めており、毎週検証作業を行った上でリリースを行なっています。

検証作業では、Musubi Insight における全ての機能の検証手順が記載されたチェックリストを元にチームメンバーで分担して確認作業を行なっていましたが、Musubi Insight の機能増加に伴い検証作業量とそれに要する時間も増加していきました。

また増えた検証作業を時間内に終わらせようとするあまり、1 つ 1 つの検証の質が落ちていることも課題でした。

検証項目の肥大化

mabl 導入を検討していた 2021/04 時点で Musubi Insight は開発開始から 1 年半ほど経過しており、約 20 ページもの機能を有していました。

合計すると 700 近くにも及ぶ検証項目を、当時は 4 名（エンジニア 3 名・スクラムマスター 1 名）で毎週検証作業を行なっていました。

E2E テスト作成の属人化

検証項目の肥大化を受け、E2E テストを実装することで検証作業の削減を目指す方針にチームは舵を切りました。

Musubi Insight は Angular フレームワークで実装されていたため、Angular のテストフレームワークであるProtractorを採用。

しかしチームのエンジニア構成がフロントエンド 1 名・バックエンド 2 名ということもあり、Angular の成熟度に少なからず差が。

3 名でのモブプロを定期的に開催して E2E テストの作成やメンテナンスを行うなどしてその差を埋めようと試みましたが、自然とフロントエンド担当の 1 名に E2E テストの作成とメンテナンスが偏っていってしまいました...

チームの課題にどう mabl がフィットしたか

ここまでのチームの課題感はこちら。

  • 機能増加による検証項目の肥大化
  • 特定の技術領域への依存による属人化

このような状況下でカケハシ全社として mabl の導入検討が始まり、Musubi Insight チームでも mabl のテスト導入を進めていくことに。

そのテスト導入の中で、チームの課題に対して mabl がフィットすることがわかってきました。

1. 特定の技術領域に依存せずローコードでテストが作成できるため、誰でもテストを作成することができる

シンプルなテストであればコードを書くことなくテストを作成することができるため、アプリケーションやその技術に精通していないメンバーでもテスト作成を任せることができます。

エンジニア以外のメンバー（スクラムマスターやプロダクトマネージャー）でもテスト作成は可能です。

2. 直感的にテストを作成することができる

Protractor などのテストフレームワークで E2E テストを作成する場合、テストしたい要素を開発者ツールなどから探し出す必要がありました。

mabl ではテストしたい要素をクリックするだけで特定することができるため、直感的にテストを作成することができます。
（CSS セレクタによる要素の特定も可能）

2 要素選択

mabl を導入して運用を回すまで

テスト導入を経て本格的に mabl の導入を進めることになりました。
この章では、どのような工程で実際に運用を回すまでに至ったのか紹介したいと思います。

フローを活用して共通部分を使い回し

mabl ではFlowを作ることで複数のTestで使いまわすことが可能です。

Musubi Insight においても各ページのテストで共通の要素がありました。

  1. ログイン

    mabl のTestはそれぞれログイン画面に遷移するところから始まるため、毎回ログインが必要です。

  2. 薬局・薬剤師選択

    どの薬局・どの薬剤師にフォーカスして各種指標を確認するかを検索・選択することができます。

    3 mi_薬局選択

  3. 表示期間の選択

    どの粒度でグラフを表示するのか選択することができます。

    4 mi_期間選択

ページによって若干仕様が異なる場合でも、以下のように対応することができました。

  • FlowのパラメータをTestごとにオーバーライドする（下画像）

  • Testの中でパラメータを参照してロジックを分岐する

    5 flow_parameter

このように共通のテストをFlowで作成して使いまわすことで、効率的にTestを作成していきました。

Plan を作成してテストを列挙

次に複数のTestをまとめるPlanを作成していきます。

Planを実行することで、複数のTestを並列で処理させることができるため効率的です。
（参考: 1Testの所要時間は大体 5~15 分くらいなので直列で実行すると数時間かかる）

また、後述の CI/CD インテグレーションで使用するためラベルを付与します。

6 plan

GitHub・Slack との連携

運用を回すためには、CI/CD に乗せることが大事です。

mabl も CI/CD インテグレーションには力を入れており、様々なツールと連携が可能です。

CI/CD インテグレーションの概要

Musubi Insight チームでは、GitHub Actions と連携して mabl のPlanを実行させるように組み込みました。

  • リリース前に mabl テストを動かしたいため、プロダクションブランチであるmainブランチへの PR 作成をトリガーにする
  • PlanにつけたラベルMusubiInsightPlansを指定

その他の設定項目に関してはこちらを参照ください。

name: mabl E2E Test

on:
  pull_request:
    types: [opened, reopened]
    branches:
      - main

jobs:
  test:
    name: Mabl Tests
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:
      - uses: actions/checkout@v2

      - name: Run mabl Flow
        id: mabl-test
        uses: mablhq/github-run-tests-action@v1
        env:
          MABL_API_KEY: ${{ secrets.MABL_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          environment-id: <environment-id>
          plan-labels: |
            MusubiInsightPlans

GitHub から実行されたPlanの結果は、Slack に通知されるように設定しています。

詳細な設定手順は省きますが、mabl 側で設定するだけでその設定内容に基づいて自動で通知されます。設定手順

7 slack_notifier

運用開始

毎週の検証の準備段階でプロダクションブランチへの PR を作成しておくだけで、mabl によって自動でテストが実行されるようになりました。

膨大な検証手順書から mabl によって自動化できた項目を除外し、残りの項目をチームで分担して検証していきます。

そして mabl のテスト作成を恒常化させるため、新規機能を開発する際の簡単なルールを設定しました。

  1. リリースする前には必ず検証手順書を作成すること
  2. その手順書を元に、可能な範囲で mabl によるテストを作成すること（ただしリリースには間に合わなくても OK）

mabl の運用を開始してから約半年が経過しましたが、結果的にその間に追加された 9 つの機能全てにおいて mabl テストが作成されており、カバレッジを維持することに成功しています。

mabl を導入した結果・学び

mabl を導入したことで、700 あったテスト項目のうち約 300 を mabl によって自動化させることができました。

カバレッジは約 40%と高くありませんが、Protractor で実装した際は 10%にも満たなかったことを考えるとチームにとっては大きな進歩でした。

mabl の向き不向き

カバレッジの残り 60%の中には、

  • mabl による自動化の余地があるテスト
  • mabl では自動化が難しいテスト

の 2 種類が存在します。

どんなテストだと mabl で自動化しやすくてどんなテストだと難しいのか、mabl を半年間触ってきて分かったことの一部を紹介します。

自動化しやすいテスト ① 単純で工程が多いテスト

クリックやテキスト入力を行った上で、要素がどうなったのかを検証するテストは mabl で自動化しやすいです。

Musubi Insight で例えると、薬局名での絞り込みが該当します。

こういったテストは様々な操作を経て状態を検証するため、工程が長くなりがちで人が検証するには単純作業でつらいものがあります。

8 絞り込み

上画像は Musubi Insight における薬局名での絞り込みをしている様子。

絞り込みをするとどうなるのか、絞り込みを解除するとどうなるのか、存在しない薬局名を入力するとどうなるのか、など工程が長くなりがちです。

自動化しやすいテスト ② 日付表示の正しさを検証するテスト

例えば、アプリケーション上で先週の月曜の日付が表示されていることを検証したいケースなどが該当します。

人がそれを検証する場合、カレンダーを開いて先週の月曜がいつか確認したり頭の中で計算したりと面倒で、これまたつらいものがあります。

mabl では javascript を動かすことができ、その結果を mabl 上で利用することができる変数として扱うことができます。

9 js_snipet

Musubi Insight では表示期間の絞り込みにおいて「昨日」「先週」「先月」といった選択肢があり、その選択によって画面に表示される期間が動的に変化します。

この表示期間が正しいことを人の目で確認するのは非常に大変だったため、自動化されたことでその作業から解放されることができました。

10 組織集計の期間指定

自動化が難しいテスト ① canvas 要素内のテスト

Musubi Insight は薬局経営のための所謂 BI ツールであるため、グラフが多く表示されます。

グラフは canvas 要素内に配置・表示されているのですが、canvas 要素の中の情報を mabl で取得することは難しいようでした。

そのためグラフ内の表示内容や色分けなどを自動化することはできておらず、現在も手作業で確認をしています。

自動化が難しいテスト ② テーブル内の数値のテスト

Musubi Insight ではグラフ以外にも、テーブル上に数値が列挙されているページが存在します。

そのテーブル内での数値の整合性をテストしたい場合、

  • テーブルのデータをまるまる変数として取得する
  • テーブルの列と行を指定して 1 つの数値を変数として取得する

などの方法が考えられますが、これらの方法はまだ mabl では対応していなさそうでした。

少し補足をすると、

1 つの数値を変数として取得する

これは mabl で実現できるのですが、列と行の指定をすることができないためテストの度に違う数値を取得する可能性があり安定性に欠く印象です。

11 組織集計

（例えば「薬歴当日完了率」=「薬歴当日完了数」/「処方箋受付回数」x 100であることを検証したい）

mabl のつまづきポイント

mabl を導入する中でつまづいたポイントも紹介します。

mabl のつまづきポイント ① local 実行はうまくいくのに cloud 実行をすると失敗する

mabl には local 実行と cloud 実行がありますが、cloud 実行ではマルチブラウザでのテストや AI によるテストの自動修正などの他、個人の環境に左右されないなどのメリットがあります。

mabl の実行方法と実行環境の違いはなんですか？

そのためチームでは mabl のテストを全て cloud 実行するようにしているのですが、cloud 実行が成功するまでにいくつかの壁がありました。

  • cloud 実行は海外のサーバー上で動作するため、地理的制限をかけているとログインすらできない
    • mabl のサーバーは 3 種類の固定 IP アドレスが使われているため、それらを許可することで回避
  • cloud 実行がされるサーバーの時刻は UTC(協定世界時)に設定されているため、JST(日本標準時)を前提にしているとテストが失敗する
  • 地理的に遠いからか処理が若干重くなり、画面表示が全て終了する前に次のテスト項目に進んでしまい失敗する
    • とりあえず Wait 処理を入れることで対応

mabl のつまづきポイント ② なかなかチームに mabl が浸透せず、テスト作成が進まない

mabl は今までにあまりない SaaS であるため、自分含めてチームが慣れるまでに時間がかかった印象があります。

エンジニアメンバー全員で一緒に mabl を触る機会を何度か作り、その後分担して各自テストを作ってみることでようやくスタート地点に立つことができた気がします。

一度テストが作れるようになると mabl に興味が湧くようになり、他にはどんな機能があってそれはどのように活かすことができるかを各自が考えるようになってからはスムーズでした。

また社内で mabl に関して情報共有をする slack チャンネルが作られたり、チームで作った mabl テストを見せ合うデモ会が開催されていたのも成功への大きな要因だったかもしれません。

今後の展望

mabl によるテストカバレッジを向上させることはもちろん、
頻繁にアップデートされる mabl の機能をキャッチアップしてメンテナンス性の向上などに努めていきたいと思っています。

今興味がある機能・アップデートはこの 2 つです。

mabl では API のテストも作成できるようなので、そちらにもチャレンジしていきたいですね。

最後に

ここまで記事をご覧いただき、ありがとうございます。

カケハシではアプリケーションエンジニア、フロントエンドエンジニア、デザイナーをはじめ、多くの業種で採用を強化しています。

  • 運用改善や開発環境の改善にも積極的に取り組んでいきたい

そんなエンジニアの方と一緒に仕事できると嬉しいです！