はじめに

エムスリーテクノロジーズの永江 (@yukinagae)です。

2025年7月からエムスリーテクノロジーズに入社し、グループ会社への技術支援をしています。詳しい業務内容は、前回の記事でも紹介しました。

支援内容は、各グループ会社の状況や参画するエンジニアのスキルによって変わりますが、共通してCI/CDの強化から始めることが多いです。なかでも特に自動テストの強化は、最初に手がけるべき施策だと考えています。

その理由は、次の3つです。

導入ハードルが低い: 既存のコードに影響を与えずに導入できる
既存コードの理解が深まる: テストを書く過程で自然とコードの動きやドメイン知識が身につく
成功体験を積める: 自動テストは必要だとわかっていても後回しにされがち。テストを強化することで、チームに喜ばれ、小さな成功体験を積み重ねることができる

このように大きなメリットがある自動テストですが、個人的に特に意識しているのは、既存チームの技術や文化に合ったテストフレームワークを選択することです。

もし自分の担当プロダクトであれば、自分が慣れている、あるいは好みのフレームワークを選べます。しかし、グループ会社への技術支援という性質上、私たちが永続的に関わり続けるわけではありません。最終的にはチームにメンテナンスを移譲します。だからこそ、チームメンバーが今後も運用しやすい技術を選ぶことが重要だと考えています。

今回は、非エンジニアでも扱いやすい + 既存チームでメンテナンスしやすい テスト自動化のフレームワークを紹介します。

※注: ケース・バイ・ケースですが、もちろん既存チームの技術スタックと異なる、新しい技術を意図的に採用することもあります(´∀｀)

非エンジニアとエンジニアをつなぐテストフレームワーク

非エンジニアでも使いやすく、既存チームがメンテナンスしやすいe2eテストを構築するために、PlaywrightとGaugeを組み合わせた自動テストの方法を紹介します。

この手法は、次の2つの特徴により、多くのチームで抱える課題を解決できます。

Markdown形式で記述できる: 非エンジニアでも直感的にテストを作成・編集できる
幅広いプログラミング言語に対応: 既存チームの技術スタック（Java、Python、C#、JavaScript/TypeScriptなど）に合わせてスムーズに導入できる

Playwright はMicrosoftが開発したOSSのテストフレームワークです。Node.js / Python / Java / .NETなど幅広い言語に対応しており、ドキュメントも豊富で信頼性が高く、多くのプロジェクトで採用されています。

playwright.dev

一方、Gauge はPlaywrightほどメジャーではないかもしれませんが、私自身推しているOSSのテストフレームワークです。最大の特徴は、テストをMarkdown形式の自然言語で書けることです。これにより、非エンジニアでもテストシナリオを簡単に記述できます。TypeScript / Python / Java / C# と比較的多くのプログラミング言語に対応しています。

gauge.org

この2つのフレームワークを組み合わせることで、非エンジニアがテストを書いて、エンジニアとスムーズに協業できます。

具体的には、次のようなワークフローで進めます。

STEP 1. エンジニアがテストの「ステップ」を実装

エンジニアは、Playwrightを使ってブラウザ操作やアサーション（テストの検証）を行うコードを書きます。

@Step("アプリを開く")
public async openTodo() {
    await page.goto("https://todo.taiko.dev");
}

STEP 2. 非エンジニアがテストシナリオを記述

非エンジニアは、*.specファイルにMarkdown形式の自然言語でテストを記述します。TODOアプリを開く というステップ名を呼び出す形で書くため、コードを書く必要がありません。

* アプリを開く

最終的には次のようなテストシナリオをMarkdown形式で直感的に記述できます。

# TODOアプリのe2eテスト

このテストはTODOアプリの動作を確認するテストシナリオです。

* アプリを開く

## TODOアイテムを表示する
* "first task" を追加する
* "1 item left" が表示されていることを確認
* "second task" を追加する
* "2 item left" が表示されていることを確認

Visual Studio Codeの拡張機能を使えば、ステップ名の補完や構文エラーのチェックもできるため、さらに効率的に作業できます。

STEP 3. テストを実行

$ gauge run specs
Compatible version of plugin html-report not found. Installing plugin html-report...
........................
Successfully installed plugin 'html-report' version 4.3.3
Installing required plugins.
.......................
Successfully installed plugin 'screenshot' version 0.3.2
# Getting Started with Gauge
  ## Display number of items     ✔ ✔ ✔ ✔ ✔ ✔
  ## Must list only active tasks     ✔ ✔ ✔ ✔ ✔ ✔ ✔

Successfully generated html-report to => /Users/yuki.nagae/repos/gauge-playwright-sample/reports/html-report/index.html

Specifications: 1 executed  1 passed    0 failed    0 skipped
Scenarios:  2 executed  2 passed    0 failed    0 skipped

Total time taken: 5.87s

STEP 4. （オプション）レポートで結果を確認

テストの実行結果は、見やすいHTMLレポートで確認できます。

$ cd reports/html-report
$ open index.html

TypeScript + Playwright + Gauge サンプル

実際に手を動かしてみたい人向けに、サンプルプロジェクトを用意しました。

github.com

前提条件

Node.js v22以降がインストールされていること

$ node --version
v22.17.0

準備

サンプルのGitリポジトリのclone

$ git clone git@github.com:yukinagae/gauge-playwright-sample.git

依存関係をインストール

$ npm install

Gaugeのインストール

Macの場合

$ curl -Ssl https://downloads.gauge.org/stable | sh
# またはbrewの場合
$ brew install gauge

その他の環境は公式ドキュメントの Installing Gauge を参照してください。

Gaugeのセットアップ

$ gauge install ts
$ gauge --version
Gauge version: 1.6.20
Plugins
-------
ts (0.3.5)

Playwrightの依存ブラウザをインストール

$ npx playwright install

テスト実行

$ gauge run specs

おまけ

個人的にはGoを使うことが多いので、テストもGoで書きたいと考えています。残念ながらGaugeは公式でGoに対応していませんが、コミュニティ版の gauge-go が存在します。

まだ情報が少ないため、検証済みのサンプルも作成しておきました。Goで書きたい方は、ぜひ試してみてください。

github.com

まとめ

本記事では、既存チームや非エンジニアを巻き込んだテスト自動化の重要性と、それを実現するPlaywrightとGaugeの組み合わせについて紹介しました。

既存チームに合わせた技術選定が長期的な運用を成功させる鍵
PlaywrightとGaugeを組み合わせることで、エンジニアと非エンジニアが協業してテストする環境を構築できる

この記事が、あなたのチームにおけるテスト自動化のヒントになれば嬉しいです。

We are hiring !!

エムスリー/エムスリーテクノロジーズでは、グループ会社の技術支援を担うエンジニアを募集しています。テスト自動化のような技術課題から事業全体の課題まで、多種多様でチャレンジングな環境があります。

少しでも興味を持った方、ご応募お待ちしています！

https://jobs.m3.com/engineer/