Zenn
🍖

mabl コア機能を体系的に理解する

2022/12/13に公開
mabl
tech

イントロダクション

ご挨拶

こんにちは。sumirenといいます。
CIerでテックリードをやったり、スタートアップでフリーランスエンジニアをやっています。

CIerにおけるテックリード業務で開発プロセスのモダナイゼーションを担当しており、先進的な品質エンジニアリングへの取り組みとしてmablを利用しています。

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

背景

mablは最先端のローコード品質エンジニアリングプラットフォームです。
最も主要な機能は、WebのUIテストです。

mablにはTest、Plan、Application、Environmentなど、様々な概念があります。
デベロッパーやQAエンジニアは、これらの概念を使いこなすことで、組織やプロダクトにとって最適なテスト戦略を直感的に実現できます。

一方で、これからmablを始める人にとっては、こうした概念体系は複雑で取っつきづらく感じる部分もあるかと思います。
「ブラウザを操作しながらテストが作れる」「Visual Regressionが検知できる」といった華やかなフィーチャーに比べ、こうした裏方の機能を体系的に理解するためには、ドキュメントの通読や検証が必要となり手間がかかります。

そこで、この記事では、そうしたmablのコア機能について、全体像を体系的に解説します。
渋いテーマで恐縮ですが、組織のテスト戦略を実現するうえで避けては通れない内容ですので、是非お付き合いください！

この記事のゴール

  • 読者の方が、mablのコア機能について全体像をサクッと押さえられること
  • （裏の狙いとして）筆者が、今後もう少しニッチなmablの記事を書くときに、全体的な話はこの記事にデリゲートできること

記事の流れ

mablのコア機能を、以下の2つの観点から順番に解説します。

  • テストをどう構成するか
    • 例えば、あるテストはクロスブラウザ向けだが、あるテストは1ブラウザのみ、など
  • 構成したテストをいつ・どこで実行するか
    • 例えば、PRマージ前にCI環境内で実行し、Stgデプロイ後にはmablのクラウド上で実行する、など

対象読者

mablやテスト自動化に興味がある方。
まだmablを使ったことがない方でもお読みいただけるよう努めています。

1. mablのテスト構成

この章では、mablでテストを構成する方法について、全体像を解説します。

mablのテスト構成は、主に4つの概念から実現されます。
これらの概念を理解することで、mablでテストを構成できるようになります。

図解を見てイメージを膨らませたうえで、後続の説明を読んでいただけると幸いです。

1-1. Application

mablでは、アプリケーション単位でテストを構成します。
例えば、ポータルサイトや管理画面、Eコマースサイトなどのアプリを、それぞれApplicationとして登録します。

1-2. Environment

mablにはアプリケーションの環境を登録できます。ApplicationのEnvironmentごとにURLや認証情報、その他のパラメータ（環境変数）を持つことができます。
例えば、StgとDevの2種類を、mablに2つのEnvironmentとして登録します。EコマースApplicationの、Stg / DevEnvironmentに、それぞれの環境のURLや認証情報を登録できます。これにより、Testで動的にEnvironmentから環境変数を取得することができ、環境ごとにテストを作り直す必要がなくなります。

1-3. Test

Applicationに紐づけてTestを作成することができます。TestにはAPI testやBrowser testがありますが、主にはBrowser testです。Browser testは、ブラウザを操作したりアサーションを宣言することで作成します。

例えば、EコマースのApplicationに紐づけて、顧客が商品を購入する、顧客がサインアップするといったTestを作成できます。
Testは、対象とするApplicationと手順しか情報を保持しないシンプルな概念で、「いつ実行されるか」「どの環境で実行されるか」などの情報は持ちません。

1-4. Plan

上記のとおり、Testは対象とするApplicationと手順のみを保持しています。

このTestをどう実行するか構成するのがPlanで、以下のような情報を保持します。

  • 対象とするアプリケーションと環境
  • テストを実行する際のブラウザの種類や画面幅
  • 定期実行、CIによるトリガなどの実行タイミング

例えば、EコマースサイトApplicationに紐付ける形で、振る舞いの検証とクロスブラウザので2つのPlanを作成します。その際、以下のようにPlanごとに柔軟に実行方針を定められます。

  • 振る舞いの検証Planは全Testをやる。落ちやすいためDevやStgなど全てのEnvironmentで実行する。Shift-Left促進のため、CIで即実行する。費用効率のため、ブラウザはChromeのみに限定する
  • クロスブラウザPlanは、関わるTestが少ないため一部のTestに絞る。また、まり落ちないためStgEnvironmentでのみ、定期で実行する。

Testは単体ではステップを保持しているだけであり、このTestとApplication/Environmentを紐付け、実行方針を定めることがPlanの責務です。
mablのテスト構成においては、Planが最も重要な機能です。品質エンジニアリング上の工夫や洞察のほとんどが、Planの構成と設定に現れると思われます。

2. mablのテスト実行

前の章では、mablのテストを構成する方法について説明しました。
この章では、こうして構成したテストを、mablで柔軟に実行する方法について、全体像を説明します。

mablには、2つの実行環境と、3つの実行方法があります。
以下の表を見ながら、後続の説明を読んでいただければと思います。

2-1. 実行環境

mablには、mabl Cloudとローカルという、2つの実行環境があります。

2-1-1. mabl Cloud

mabl Cloudとは、テストをクラウドで実行する際の環境のことです。
基本的には、このmabl Cloudでのテスト実行が中心となるべきです。
以下のようなmablの強力な機能の大部分は、mabl Cloudに支えられているからです。

  • 自動修復やVisual Changesなど、AIやデータの活用
  • Chrome以外のブラウザパターンや、並列実行と順序制御など

また、上記2点目は、Planはローカル実行できないということを意味しています。

2-1-2. mabl Cloud

一方のローカルとは、私たちが普段操作しているWindowsやMacなどのPCを指します。
mablはローカルでテストを設定しながら実行したり、任意のTestを選んでローカルで動かすことが可能です。
ローカルではmabl Cloudの強力な機能は利用できませんが、テストの作成中や機能の開発中に、特定のテストの結果を素早く確認することに向いています。

また、mablではCI環境内でもmablを実行することが可能です。
CI環境内からmabl Cloudに対してテスト実行をリクエストするだけでなく、CI環境内に閉じたテストも可能です。
この記事ではCI環境内でのテストも、動作が同じなので便宜上ローカルとします。結局ローカルPCでテストを実行する場合と動作は同じだからです。

2-2. 3つのテスト実行方法

mablのテストは、3つの実行方法があります。
全体像は以下のとおりです。

2-2-1. Ad hoc test runs

mablでは、GUIやCLIから、任意のTestやPlanを選んで実行でき、このことを便宜上「アドホック実行」と呼びます。

ユースケースは大きく2つと考えられます。

  • 動作確認のために、ローカルやmabl Cloudで特定のTestやPlanを実行する（Planはmabl Cloudのみ）
  • CI環境内（デプロイ前）で、一連のTestを実行する

重要なこととして、Ad hoc test runsは、mabl Cloud上でも実行できるものの、あくまで動作確認という位置づけです。
そのため、mabl Cloudの持つ自動修復やインサイト生成といった機能の結果は記録されません。

例えば、テスト実行ロジックとして自動修復などは動作するものの、mabl Cloud上でテストの修復は永続化されません。
つまり、Ad hoc test runsしか実行しないような開発プロセスをデザインした場合、毎回自動修復が走って効率が悪くなったり、仕様が段々変わっていく中で、あるときベースラインとのギャップが大きすぎて自動修復が効かなくなるといった懸念があります。

2-2-2. Deployment

mablにはDeploymentという概念があります。
例えばEコマースApplicationのDevEnvironmentに対して、Deploymentを1つ生成することができます。
このときDeploymentは、そのApplicationのEnvironmentに紐づく全てのPlanを実行します。

つまり、ApplicationのEnvironmentに実際にデプロイが行われ、アプリケーションのバージョンが更新されるたびに、mabl上で、GUIやCLIを用いてDeploymentを生成するという考え方です。
これは、とても直感的で分かりやすいかと思います。

また、Deploymentは正式なテストのため、自動修復やインサイト生成はmabl上に記録されます。
DeploymentがPlanを実行することや、正式なテストであることからも分かるとおり、Deploymentによるテスト実行では、テストはmabl Cloud上でしか走りません。

2-2-3. Timer/Schedule

mablではPlanごとに「何時間ごと」や「何曜日の何時」といった実行設定が可能です。
これは、Planに対するTriggerという設定値によって設定します。

このとき、Timer triggerでは「何時間ごと」という設定が可能で、Schedule triggerでは「何曜日の何時」という設定が可能です。
位置づけはDeployment同様に正式なテストであり、実行環境はmabl Cloud上のみです。

2-3. 開発プロセス設計上の考慮事項

実際の開発プロセスでは、これらの実行環境や実行方法を適材適所で組み合わせることになります。

例えば、

  • 開発中はローカルでのAd-hoc test run(s)で、Test1件1件を適宜動かしながら開発
  • PR作成時、CI環境上でAd-hoc test run(s)で、機能に関するTest全件を実行
  • developブランチへのマージ後、デプロイされたDev環境に対してmabl CloudのDeploymentイベントにより関連するPlan全件を実行。ここで自動修復やインサイトなどがmabl Cloud上でも取得されるようになる。
  • Stg環境では、さらに多くのテストがmabl Cloud上で定期実行される。
  • etc...

品質戦略上、仮にローカルとCI上でのAd hoc test runsで品質担保が間に合っていたとしても、デプロイ後にDeploymentかTimer/Scheduleのどちらかでテストを実行するとよりよいと考えます。
これらを開発プロセスに入れ込むことで、mabl Cloud上でAIが学習して実行最適化や自動修復が適用されたり、インサイトを取得することができるようになり、より幅広い品質エンジニアリングの可能性が見えてくるためです。

また、デプロイ後の正式なテストについて、筆者はDeploymentを利用することを推奨します。
環境にアプリケーションがデプロイされたら関係するテストが全て実行されるという考え方は、とても分かりやすく合理的だからです。

まとめ

mablではApplication、Environment、Test、Planといったコア機能があります。
Testは単体ではステップを保持しているだけであり、このTestとApplication/Environmentを紐付けることがPlanの責務です。

品質エンジニアリング上の工夫や洞察のほとんどが、Planの構成と設定に現れます。

mablには、2つの実行環境と、3つの実行方法があります。
3つの実行環境のうち、DeploymentとTimer/Scheduleは正式なテストであり、mabl Cloud実行環境上での実行され、自動修復やインサイト生成がmabl上に記録されます。
動作確認という位置づけであるアドホック実行は、ローカルとmabl Cloudのどちらでも実行でき、自動修復なども動作はしますが、mabl上には記録されません。

品質戦略上、仮にローカルとCI上でのAd hoc test runsで品質担保が間に合っていたとしても、デプロイ後に正式なテストをすべきです。
mabl Cloud上でAIが学習して実行最適化や自動修復が適用されたり、インサイトを取得することができるようになり、より幅広い品質エンジニアリングの可能性が見えてくるためです。

この記事を読んで、mablのコア機能について全体像が押さえられましたでしょうか。
よければTwitterもフォローお願いします！
@sumiren_t

Discussion