QaseとPlaywright Reporter試してみた

2024/07/03に公開

はじめに

テスト管理ツールのQasePlaywrightのReporterを提供しています。
どんなことができるのか、テストの運用方法がどうなりそうか使ってみながら考えてみました。
(普段は1フロントエンドエンジニアなので、「どう開発しながら自動テスト運用できそうか」という視点が中心です。)

  • 前提
    • playwright-qase-reporter: v2.0.4
    • Next.js: v14.2.3
      • create-next-appでプロジェクト作成後1ページだけリンク先として用意しただけ
    • @playwright/test: v1.44.1

Qaseについての補足説明

Qaseはテストケース、テスト計画、実行記録、検知した不具合などを管理できるSaaSです。
主要な機能の使い方は以下のドキュメントから確認ができます。

Playwright Reporterを試してみた

本題のPlaywright Reporterですが、管理画面からのアプリ設定とPlaywright側の設定が必要です。

ここではいくつか試したことを記載しておきます。

管理画面で作成したテストケースとの紐づけとテスト結果の送信

  • Qaseでテストケースを作成すると、 {プロジェクトコード}-{連番} 形式でIDが設定される
  • テストコード内で qase.id(1); のようにQaseで作成したテストケースのIDの連番を指定するとテストコードとQaseのテストケースを紐づけられる
  • 上の状態でテスト実行すると実行結果にも紐づけたテストケースの結果として表示がされる
  • 環境変数 QASE_TESTOPS_RUN_ID を設定して自動テストを実行することでQaseで作成したTest Runに結果を同期できる
    • 反対に指定がない場合は自動テスト実行結果のみが新規Test Runとして登録される
  • Playwrightのテストコード側で test.skip したものはTest RunでもSkippedと登録される

テストケースの自動作成

  • QASE_MODE=testops の環境変数(もしくはPlaywrightのレポーター設定)とともにテストを実行する
  • 実行結果の送信とともに qase.id() を呼び出していないテストケースが新規テストケースとして自動登録される
  • ただし、テスト内容が変わってもテストケースが削除されることはなさそう
  • グルーピングしたりタイトルを書き換えたりすると新規ケースとして登録される(編集内容が同期されるというわけではなさそう)
    • あとから qase.id() で紐づけてテストコードのタイトルを変えてもQaseには反映されない
    • qase.title() もあるが、qase.idと併用してもQase側でタイトル更新されない

(削除や同期は、自分がやり方を知らないだけの可能性があります...)

テストの運用方法を考える

ここからは、PlaywrightのReporterを試したうえで日々開発しながらのテスト運用がどうなりそうか考えてみました。

まずはテストケース自動作成モードのおさらいですが、自分が試して確認できたところでは以下のような挙動でした。

  • ID設定がないものについて結果レポートの送信とともにQase上で新規テストケースとして追加される
  • qase.id() を呼び出してQaseで作成済みのテストケースとテストコードを紐づけられる
  • IDを設定したものをタイトル編集してもQaseには反映されない
  • テストケースが自動削除されることはなさそう

これらのことから、試行錯誤したときやコードレビューによってテストのタイトルやシナリオが変更された場合に追従できず、テストケースが余計に増えてしまいそうなことが予想できます。

個人的には、テストケース自動作成を積極的に使うよりは手動・自動ともにテストケースを一元的に管理するほうが効率よさそうかなと思いました。
具体的な運用方法として考えたのは以下の通りです。

  1. (スクラムであれば)プランニング中にQase上でテストケースとテスト計画まで作成する
    • エンジニア以外でもGherkin記法を共通言語としてコミュニケーションとれるのが便利そう
    • テスト計画を作ることで開発規模に合わせて新規テスト中心なのか既存テストケースを利用したデグレチェックが中心なのかも選択可能
  2. Qaseを見ながら自動テストを整備する
    • Qaseのテストケースを主データとして観点やシナリオの追加・変更が発生した場合はそちらを修正する
    • テストケースのタイトルだけ test.skip('テストタイトル', () => { }) というように転記してあとからシナリオ記載するとよさそう
      • 自動テスト実装の進捗状況を自動で共有できるようになる
    • (Qaseとテストコードでタイトルなど重複管理しているのは否めません...)
  3. Qase上でTest Runを作成し自動テストの結果と手動テスト結果を記録していく
    • 自動・手動組み合わせたテスト全体の進捗が把握できるようになる
    • 自動テストの結果はPlaywright Reporterに送信してもらう(以下で補足あり)
  4. コードレビューとともにTest Runの結果も確認してもらう

ステップ3でQaseの画面でTest Runを作成し、そのIDをCI実行時に紐づける必要がありますが、
プルリクエスト作成時や追加のコミット時に自動実行される場合は都度Test Run IDの紐づけができません。
自分は回避策としてGithub Actionsのワークフロー設定で実行条件を分けることにしました。
開発中はTest Runの自動新規作成を気にせずどんどん自動実行し、
コードレビュー前など実行した(手動含む)テスト結果を確認してもらうときにワークフローを手動実行する想定です。

Github Actionsのワークフロー設定ファイル例
name: Playwright Tests
on:
  push:
    branches: [main, master]
  pull_request:
    branches: [main, master]
  # 手動実行可能とし、Test Run IDを指定できるようにした
  workflow_dispatch:
    inputs:
      testRunId:
        description: "Qase Test Run ID"
        required: false
        type: number
        default: 0
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    environment: prod
    env:
      QASE_TESTOPS_API_TOKEN: ${{ secrets.QASE_TESTOPS_API_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      # 自動実行された場合はTest Run IDなしで実行し、新規のTest Run結果としてレポートしてもらう
      - name: Run Playwright tests
        run: npm test
        if: ${{ inputs.testRunId == 0 }}
      # 手動実行された場合はinputで指定されたTest Run IDにテスト結果を紐づけてもらう
      - name: Run Playwright tests with Run ID
        run: QASE_TESTOPS_RUN_ID=${{ inputs.testRunId }} npm test
        if: ${{ inputs.testRunId != 0 }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

テストタイトルなどの重複管理は引き続き改善アイデアを考えていきたいところです...

まとめ

この記事ではQaseが提供しているPlaywright Reporterを試したうえで
開発しながらのテスト運用をどう効率的に進めていけそうかを考えていきました。
テストコードをどんどん拡充するだけでテストケース管理ができるようになるわけではないですが、
手動で実施するテストケースと自動テストのケース・テスト実行結果を一元管理できるのは全体感を把握しやすいですし、
チーム(もしくはQAの方とコラボしながら)でテストケースを運用していけるイメージは具体化できました。

引き続き、開発しながら自動テストも整備しつつ動作確認もQAとして実施できるような
(一人で頑張る、というよりはチームメンバーで連携するイメージ)工夫を考えていきたいと思います。

Discussion