見出し画像

テスト自動化の進展：DatadogからPlaywrightへの移行（前編）

Kenji Serizawa

はじめに

こんにちは。カラクリ株式会社QAチームリーダーの芹沢です。
業務多忙により、しばらくの間記事を書けていませんでした。

過去に「Datadogを活用したテスト自動化の取り組み」を紹介させていただきましたが、今回のタイトルをご覧になった方の中には、疑問を感じられた方もいるかもしれません。

前回のテスト自動化に関する記事を書いてから、早くも1年半という月日が経過しました。この期間中、日々の業務改善を進める中で、様々な課題に直面していました。その結果、現在はPlaywrightへのテスト移行を段階的に進めているところです。

本記事では、主にPlaywrightへの移行背景と、その導入に伴うテスト自動化プロセス全体の再設計と最適化を行ったQA活動について紹介いたします。内容が長くなるため、前編と後編の二部構成としております。

今回の前編では、Playwrightへの移行背景に焦点を当てています。

なお、本稿ではテスト自動化における課題と実践的な経験を率直に共有させていただきます。テスト自動化ツール・サービスを提供する方々にとっては、一部批判的に感じられる内容もあるかもしれません。この点についてもご理解いただければ幸いです。

また、これから紹介する内容はあくまで当社の経験に基づく事例であり、環境や状況によって、直面する課題や最適なアプローチは変わる点はご留意ください。

前編の記事から得られること

  • Datadogを用いたテスト自動化の成果事例

  • テスト自動化有償ツール利用時の課題と問題点

  • Playwrightへの移行背景

Datadog利用の振り返り

Good（導入の成果）

  1. テスト自動化の進展
    Datadogはとても使いやすいツールであり、その利便性によってテストの自動化を効率的に進めることができました。約1年という期間で、プロダクトのリグレッションテストのほとんどを自動化することに成功しました。

  2. CI/CDプロセスへの統合
    さらに、Datadog社が提供するGitHub Action（synthetics-ci-github-action）を活用することで、自動テストを継続的インテグレーション（CI）プロセスに組み込むことができました。具体的には、以下のようなYAMLファイルを作成し組み込むことでこれを実現しています。

name: CI (System Tests / Datadog)

on:
  workflow_dispatch:
    inputs:
      environment:
        description: リリースバージョン
        required: true
        type: choice
        options:
          - staging
        default: staging
      max-parallel:
          description: 並列実行数
          required: true
          type: number
          default: 1

concurrency:
  cancel-in-progress: true
  group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event.inputs.environment }}

jobs:
  prepare:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - id: prepare
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs')
            const environment = '${{ github.event.inputs.environment }}'
            const targets = fs.readFileSync(`.github/workflows/ci-st-datadog-${environment}.txt`, 'utf8')
              .split('\n')
              .map(line => line.replaceAll(/#.*/g, '').trim())
              .filter(Boolean)
            console.log(`${targets.length} targets found for ${environment}`)
            return targets
    outputs:
      result: ${{ steps.prepare.outputs.result }}

  test:
    needs: prepare
    strategy:
      fail-fast: false
      max-parallel: ${{ fromJson(github.event.inputs.max-parallel) }}
      matrix:
        id: ${{ fromJson(needs.prepare.outputs.result) }}
    name: test for ${{ github.event.inputs.environment }} (${{ matrix.id }})
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: DataDog/synthetics-ci-github-action@v0.24.0
        with:
          api_key: ${{ secrets.xxxxxx }}
          app_key: ${{ secrets.yyyyyy }}
          public_ids: ${{ matrix.id }}

YAMLファイルの構成について

  1. テストの直列実行
    テストの安定性を確保する目的で、直列での実行を採用しています。

  2. 実行するテストシナリオの指定を別ファイルで管理
    カレントディレクトリの「ci-st-datadog-${環境名}.txt」ファイルにDatadogで作成したテストシナリオを記述することで実行される仕組みを採用しています。これにより、本CI/CD設定ファイルに影響を与えることなく、柔軟にテストを追加・管理できます。

  3. テスト結果の可視化
    テスト結果をGitHub Actionsで取得し、開発チーム・QAチームが即時に確認できるようにしています。

この CI/CD 統合により、以下の利点が得られました。

  • 早期テストの実現（開発プロセスの効率化）
    開発ブランチのマージ時、テスト環境への反映時（リリース前QAのマニュアルテスト開始前） など、これらのタイミングで自動テストが実行可能となり、問題の早期発見に貢献しています。

  • 柔軟なリグレッションテスト（品質保証の強化）
    自動化により、必要に応じて何度でもリグレッションテストを実行できるようになりました。

  • テストプロセスの効率化
    これらの改善により、効果的なテストプロセスを確立し、品質保証の強化に大きく貢献しています。結果として、プロダクト品質の向上と開発効率の改善という高い成果を上げることができています。

なお、この事例はDatadogを用いた実装例ですが、同様の概念は他のツールでも適用可能だと思います。参考になれば幸いです。

Bad（直面した課題）

一方で、多くのリグレッションテストを自動化することで課題も見えてきました。主な課題は以下のとおりです。

  1. テストシナリオ間での変数共有ができない
    個別のテストシナリオで作成した変数を、他のシナリオで直接共有することができません。Subtest機能（親子関係のあるテストシナリオ間での継承機能）を使用すれば変数の共有は可能です。しかし、この機能の設定には複雑さがあり、迅速かつ柔軟な設定が困難なため、UI/UXに改善の余地があり、ツールの操作性に課題がある状態です。
    または代替手段として、グローバル変数を使用する方法があります。グローバル変数として登録すれば共通利用は可能になりますが、この方法にも以下のようなデメリットが存在します。

    • 変数のスコープが広すぎて管理が複雑化する

    • 変数数の増加に伴う管理の煩雑化が起こる

    • セキュリティリスクが増える

    • 全体的な管理構造が非効率化する

  2. 条件分岐の実装ができない
    まず条件分岐について、JSステップ機能を用いて一部の条件分岐処理は実装可能でしたが、機能の使用に制約があり、制約を考慮したテスト実装が必要で、柔軟な実装が困難なケースが多々ありました。これは重大な問題の１つです。主な問題点は以下のとおりです。

    • 条件分岐を活用したテスト対象の前提条件を揃えるステップが組めないことから、事前のテストデータや設定に依存し、プロダクトの不具合では無いのにテストが失敗するなど不安定なテストケースが増加する

    • 機能の制約により、テスト対象によっては実装が不可能な状況も発生し、目的のテストステップを完全に自動化できないことがある

  3. 反復処理の実装ができない
    単一シナリオ内で特定のステップ群を繰り返し実行する機能が存在しません。この反復処理機能の欠如は、メンテナンスを含めたテストシナリオの効率的な管理ができず、これも重大な問題となっています。主な問題点は以下のとおりです。

    • 同一ステップの複数回記録が必要となり、結果としてテストステップが増大しシナリオが複雑化する

    • テストステップの修正が必要な場合に、複数回記録した全てのステップの適切な修正が必要なため、メンテナンス性が著しく低下し管理が困難になる

  4. テスト自動化の拡大に伴い利用コストが増加した
    テスト自動化ケース数の増加に伴い、ツールの実行利用コストも比例して上昇し始めました。Datadogは他の自動化ツールと比較すると安価なツールではありますが、とはいえ、自動化されるテストケースの増加に伴いツールの利用コストが増大するという課題は残りました。

これらの制約の結果、テスト実装の効率性と有効性が低下しました。さらに、自動テストの規模が拡大するにつれて、これらの問題がより顕著になりました。

プロダクトの日常的なリグレッションテストは、数百から数千に及ぶテストケースがあり、当初はこれらを手動で実施していました。これらのテスト自動化を段階的に進め、効率化を図ってきました。しかしながら、上述に記載のような課題に直面しました。特に顕著だったのは、例えばプロダクトのUI/UX改善の改修に伴うテストケースの更新作業でした。自動化したテストケースが増加するにつれ、それらのメンテナンスと改修への追従に要する工数が増大し、テスト管理の効率が低下しました。常にコスト効率を考慮しなければならない我々にとって、この状況は脱却したい課題となりました。

また、ツールの使用に習熟し作業に馴染んでいくにつれ、多様なテストケースを自動化できるようになりました。しかし同時に、「より高度で効率的な自動テストを組みたい」という要求も高まっていきました。前述の問題点もこの要求の一部を反映しています。結果として、ツール利用に対するストレスレベルも上がっていきました。

そして、これらの課題に対応するため、新たなアプローチを検討し始めました。

Playwrightの導入

これらの課題を解決し、テスト自動化の効率を向上させるため、有償の自動化ツールからの脱却を検討し、新たなアプローチを模索し始めました。その過程で、解決策としてPlaywrightが浮上しました。開発チームからも「将来を見据えると、Playwrightへの移行が戦略的に有効ではないか」という提案があったことが大きなきっかけとなりました。これを受け、Playwrightの試験的導入と評価を行い、最終的にこのツールへの移行を決定しました。

この移行は、まさにテスト自動化管理のエンジニアリングの実践だと考えます。

前編のまとめ

今回は、Playwright導入に至るまでの背景に焦点を当てた内容を紹介させていただきました。Datadogを用いたテスト自動化の利点や、有償ツールの利用に伴う課題について、ご理解いただけたのではないでしょうか。

この共有が、QAテスト業務に従事する方々、テスト自動化に取り組むQAエンジニアの皆様のエンジニアリング活動の参考になれば幸いです。また、本記事を通じて、より効果的なテスト活動の創造、より洗練されたテストプロセスの普及に少しでも貢献できれば幸いです。

なお、Playwrightへの移行を進めているものの、Datadogの利用を完全に停止したわけではありません。適切な使用方法や範囲を考慮することで、むしろ継続利用が有益である側面も明らかになってきました。この点については、次回の記事で紹介予定です。

次回は、Playwright導入に伴うテスト自動化プロセス全体の再設計と最適化について詳しくお伝えする予定です。この改善活動を通じて得られた知見と、実践的なアプローチを紹介していきます。

前編をお読みいただき、ありがとうございました。
次回の記事もぜひご期待ください。

※続きはこちら


いいなと思ったら応援しよう！