はじめに
イノベーション開発チームの大野です！ITトレンドで開発業務をしています。
今回は、リリース後の不具合早期発見のために、手動実施していたテストをE2Eとして実装しました。
品質保証やSREの観点で、どのように考えて具体化したかを残すべく記事にしました。
前提
ITトレンドは、基本的に週1回リリースしています。
リリース後に毎回、主要ページのアクセスができるか、CV機能が壊れていないかのテストを手動で実施していました。
しかし手動でのテストには下記のような問題点があります。
- リリースのたびに時間がかかる
- 担当者の仕様理解度によってテスト精度のバラつきがある
- シンプルに面倒
課題解消にあたって、いかに楽をするか・どうすれば誰でも同じクオリティの成果を出せるかを考えて、自動化が必要だと思い至りました。
今回は本番環境のE2Eテスト作成というアプローチで実現させました。
環境
miyakenが構築してくれていたPlaywright環境を使用しました。
効果
テスト観点は三点です。
- 主要ページが表示できること
- CV完了までの導線が正常に動作すること
- CV後のメール送信が行われること
時間・品質・メンタルの面でメリットがありました！
時間面
-
1回の定常テスト
- Before：5分
- After：1分
- 4分削減
-
1年（48回リリース）
- Before：240分
- After：48分
- 192分削減
品質面
- 誰がやっても同じ検証内容を担保できる
- 確認漏れを防げる
メンタル面（これ大事）
- リリース業務に伴う「毎回テストやらなきゃ...」というメンタルダメージが0に！！！
実装
環境構築してローカルでの実行と、GitHub Actionsからの実行どちらもできるようにしています。
ローカル実行編
テスト実行は下記手順です。
- 実行者がメールアドレスを選択
- E2Eが起動
- メールが届いていることを確認（実際の受信確認）
- 出力されるレポートで実行結果を確認
CV後にメールが届くかの確認のため、最初にメンバーのメールアドレスを選択するようにしました。
今はリリース権限を持つリーダー以上とSREチームが選択できるようにしています。
export interface UserProfile {
email: string;
first_name: string;
last_name: string;
}
export const USER_PROFILES: Record<string, UserProfile> = {
'user1@example.com': {
email: 'user1@example.com',
first_name: 'A',
last_name: '担当者',
},
'user2@example.com': {
email: 'user2@example.com',
first_name: 'B',
last_name: '担当者',
},
'user3@example.com': {
email: 'user3@example.com',
first_name: 'C',
last_name: '担当者',
},
};
async function selectUserEmail() {
console.log('📧 テストユーザーのメールアドレスを選択\n');
const userEmails = getAllUserEmails();
const choices = [
...userEmails.map((email) => ({
name: email,
value: email,
short: email,
})),
{
name: '❌ キャンセル（テストを実行しない）',
value: 'cancel',
short: 'キャンセル',
},
];
// コマンドラインで選択された変数を使ってテストケースを実行
GitHub Actions編
せっかくなら環境構築も不要にしたくて、GitHub Actionsで実行できるようにしました。
普段E2Eのリポジトリを触らない人でも、実行できるようにしました。
name: E2E Tests After Release
on:
workflow_dispatch: # 手動実行のみ
inputs:
user_email:
description: 'テスト用ユーザーメールアドレス'
required: true
type: choice
options:
- user1@example.com
- user2@example.com
- user3@example.com
jobs:
test-after-release:
runs-on: ubuntu-latest
steps:
# 入力値のバリデーション
- name: Validate user_email
run: |
if [ -z "${{ github.event.inputs.user_email }}" ]; then
echo "❌ エラー: user_email は必須です"
exit 1
fi
# リポジトリのチェックアウト
- name: Checkout repository
uses: actions/checkout@v4
# Node.jsのセットアップ
- name: Use Node.js
# --- 省略 ---
# 依存関係のインストール
- name: Install dependencies
# --- 省略 ---
# E2Eテストの実行
- name: Run E2E tests
env:
TEST_USER_EMAIL: ${{ github.event.inputs.user_email }}
TEST_ENV: production # stg環境にもテストがあるので、環境を指定している
run: npx playwright test tests/production
# Playwrightレポートのアップロード（テスト失敗時も実行）
- name: Upload Playwright report
# --- 省略 ---
# トレース・スクリーンショット・動画のアップロード（テスト失敗時も実行）
- name: Upload traces / screenshots / videos
# --- 省略 ---
GitHubの Actions > After Release Tests から、Run workflow で実行できます。
実際に、インフラアップデートをしたので動作確認したいが、普段アプリを見ていないので何をもって正常とすれば良いかわからない、というケースがあります。
こういったケースでも、環境構築不要でクリティカルなバグが起きていないことの検証ができるようになりました。
やらなかったこと
デプロイ完了時の自動実行は組み込んでいません。
場合によって、デプロイ完了後にバッチサーバに対してコマンド実行が必要だったり、マーケチームによるオペレーションが必要になります。
これら全てが完了して都合の良いタイミングでE2Eを実行したい、というのが理由です。
今後
チームパフォーマンスの可視化・向上のため、Fourkeysの指標の一つ「デプロイの頻度」の向上に繋げたいです。
また、今回の実装はほぼ生成AI（Cursor, ChatGPT）製です。普段はバックエンドがメインなのでTSは慣れてないのですが、それほど苦労せずとも実装でき、やりたいことが素早く実現できました。
楽できる構成・アーキテクチャを考える力が重要で、そのためにも技術の引き出しを増やし続ける必要があると感じました。
業界最大級の法人向けIT製品比較サービス「ITトレンド」の運営会社、イノベーション開発チームの公式Tech Blogです！ 各記事の内容は個人の意見であり、企業を代表するものではございません。 note にも投稿しています！ note.com/inno_tech/m/me0da0dc94db9
Discussion