QAエンジニアへPlaywrightを布教して自動化を推進してみた

この記事は カオナビ Advent Calendar 2024 (シリーズ1) 19日目です。

はじめに

QAエンジニアのfenecrg1218です。
昨年のアドカレで少しだけ触れた Playwright でのテスト自動化を推進中です。

今年は、推進活動で実際に取り組んだことをまとめてみます！
（具体的なテストコードの話は殆どございません。）

忙しい人向けの要約

• サンプルを用意して、業務で関わった人たちへの草の根活動を実施
• QAエンジニアで興味のある少数精鋭を集めて、ハンズオンを複数回実施
• エンジニア側で取り組み中のテスト自動化を噛み砕き、QAエンジニア向けに整えて共有
• 各チームの課題を解決するにはどのテストが有効なのか、QAエンジニアが集まって話し合える土壌作り

といった記事になります。

経緯や背景、実現したいこと

以前、弊社にはテスト自動化専任のチームが存在しました。度重なる組織変更などで一度解体となり、その後はE2Eテストが存在しない状態でした。今年の上期で担当していた大きな案件が落ち着き、ようやく着手できるチャンスとなったので、覚悟を決めて手を挙げて取り組んでみました！

やってやるぜッ！！ と意気込んだのも束の間、QAエンジニアのスキルや知見が異なるため、何をどこから始めたらよいものかと悩みまくり、まずは私個人として実現したいことを整理してみました。

（※他社での失敗事例を多数見聞きしたため、慎重に進めていく必要があります。がくぶるです。）

E2Eテストで実現したいこと

①バグを未然に防ぐ、または早期に検知したい

• 「検知できる状態」をいち早く提供するためには、画面操作でテストコードを生成、そこに少し手を加える程度が理想だと考えます。

②QAエンジニアがE2Eテストの運用に何らかのカタチで携わってほしい

• 他社ではQAエンジニアが直接E2Eテストに携わる事例が多いです。私自身も過去に携わっていました。テストシナリオは常に更新していく必要があるため、各チームの QAエンジニア自身がテストシナリオをメンテしていくべき と考えます。

• 各チームのQAエンジニアでのメンテを考慮すると、エンジニアが考える理想の状態、コード難易度だと理解できないため、 利用ツールは最低限に留める、実装難易度を下げる必要がある と考えます。

③QAエンジニア間の交流を促進したい

• QA-SETが解体以降は各グループ配下にあるチーム毎の所属となり、他グループのQAエンジニアと接触する機会が減ってしまったので、知見や技術交換をしたいと考えます。

④QAエンジニアのスキルを底上げしたい

• 所属チームでE2Eテストを導入する際、（もし可能であれば）QAエンジニア自身がテストコードを作成、更新して運用できるようになってほしい と考えます。
• または、E2Eテストのテストコードを何となくは読むことができて、レビューできるようになってほしいと考えます。

---

上記①～④を実現するにはどうすればよいか、関係各位に相談しつつ各施策を実施していきました。

サンプルを用意して、業務で関わった人たちへの草の根活動を実施

突然E2Eテストやろうぜ！ と言ったところで「何言ってんだこいつ」と否定または無視されておしまいなので、数年前～今年上半期まで業務の傍らで少しずつ布教を進めていきました。

• アサインされたチームにて、新規作成、編集、削除など最低限の動作テストを「ミニマムテスト」と呼称して、実行時のサンプル動画を撮影して共有
• 1on1や評価時期にて、こんな感じでE2Eできますよ、上手に使えば工数削減できて便利ですよ！ と言い続ける
• slackの個人分報チャンネルにて、日々のリリースに対してインシデント再発防止のE2Eテストを実施
  • 上記施策で興味を持った方々に対して、画面操作をするだけでテストコードが生成できる、こんなに簡単なんですよ！ とアピールを繰り返す

こいつに任せたら出来るんじゃないか、任せてみようかな？ と思われるように信頼を積み重ねていきました。（今回の件に限らずですが、普段の勤務態度や業務実績、人脈なども重要です。）

QAエンジニアで興味のある少数精鋭を集めて、ハンズオンを複数回実施

上長からゴーサインが出て、工数を確保。まずは実際に体験していただくことから始めました。

• 資料を用意して共有のみだと、環境構築で躓き、体験できずに挫折する可能性が高い
  • ハンズオン形式 にして、環境構築から手厚くフォロー
• 言語はPythonを採用
  • 過去にSeleniumやAppiumでの経験あり、Pythonであれば直ぐに教えることが可能
  • 直ぐやる、早さを最優先とする
• ハンズオンの場でやること、やってほしいこと、やらないことを明文化

• この場でやること、やってほしいこと
  • エンジニア側には寄せず、初学者向けで簡易な内容に留める
  • Playwrightを実際に体験していただく
    • コード自動生成を活用してテストシナリオを生成、テストを実行する
  • 些細なことでも分からなければ遠慮なく質問
  • 怒るような人はいないし、恥ずかしいなどは一切思わなくてよいですー！
    　
• この場でやらないこと
  • プログラミングの勉強
  • 議論
  • 利用ツールは必要最低限に留める
    • GitやDocker、Laravelなど余計なものは一旦削ぎ落とす

ハンズオン第1～3回の主な内容

ハンズオンを実際にやってみて

対象者が非エンジニアなので当然ではありますが、PowerShellまたはターミナルなどコマンドラインでの操作、プログラミング言語自体の導入やライブラリ管理、vscodeの使い方を厚めにフォローする必要がありました。また、利用するPCがWindowsとMacで統一されておらず、同一OSであってもシェル実行で異なる挙動をする場合があり、個別で対応する場合が何度もありました。ハンズオン中に実際に起きた事例も含めて、OS毎に導入手順を資料に残すことで私自身も大変勉強になりました。

ハンズオン参加者は過去に何らかのE2Eテストを経験済みではないため、画面操作でのテストコード生成では対応できない画面要素への指定方法を別途説明する必要がありました。

getByRole()などでは指定できないときの具体例

// 属性内容
<label class="固定文言_固定文言-固定文言-以降はランダム文字列">

// 属性を指定
page.locator("label[class^='固定文言_固定文言-固定文言']").first().click();

エンジニア側で取り組み中のテスト自動化を噛み砕き、QAエンジニア向けに整えて共有

エンジニア側では、有志または一部チームにてTypeScriptでPlaywrightのE2Eテスト実装をお試しで進めていました。各チームでも利用できる便利なフォーマットを用意いただいたので、QAエンジニア側もTypeScriptへ移行できるように下記を実施していきました。

• TypeScript、TypeScriptでのPlaywrightそれぞれを勉強
• 用意いただいたフォーマットを非エンジニアでも扱えるように噛み砕き、資料を整える
  • エンジニアの皆様にご協力いただき疑問点を1つずつ解消していく
  • GitLabを扱う場合、GitLabでの追跡は無しでとりあえず試してみたい人向けそれぞれの手順を整備
  • 用意いただいたフォーマット未使用でシンプルな書き方、フォーマットを用いた書き方それぞれの具体的な手順を整備
• GitLabでの開発作業～コードレビューを終えてマージ完了までの具体的な手順を整備
  • 何をどこでどのように実行するのか、具体的なコマンドや画像多めで解説
• 質問相談あればハンズオンで随時フォロー
  • 気兼ねなく聞ける雰囲気を作り、分からなければ何度でも教える

私自身も未だにそうですが、初学者だと何が分からないのか分からないので困ってしまう画面が頻発するため、私の方から率先してお声がけすることを心掛けました。

【補足】便利なフォーマット　＝　ページオブジェクトモデルを用いたテストコード一式を指しています。

初学者がいきなりページオブジェクトモデルを理解できるわけがないので、順序立てて説明していきました。

シンプルな書き方　具体例

  // カオナビへ遷移してログイン
  await page.goto('URL');
  await page.getByLabel('ID（メールアドレス）').click();
  await page.getByLabel('ID（メールアドレス）').fill('メールアドレス');
  await page.getByLabel('ID（メールアドレス）').press('Tab');
  await page.getByLabel('パスワード').fill('パスワード');
  await page.getByRole('button', { name: 'ログイン' }).click();

  // TOP画面からボイスノートへ遷移
  await page.getByRole('link', { name: 'ボイスノート アンケートを作成・集計' }).click();

  // ボイスノートでイベントを新規作成
  await page.getByRole('link', { name: '新しいイベントを追加' }).click();

ページオブジェクトモデルでの書き方　具体例

  test.beforeEach(async ({ admin }) => {
    // TOP画面からボイスノートへ遷移
    const 管理者でログイン = new TopPage(admin.page);
    await 管理者でログイン.遷移(トップページのURL);
    await 管理者でログイン.ボイスノートへ遷移();
  });

  test("新規作成の動作確認", async ({ admin }) => {
    // ボイスノートでイベントを新規作成
    const 管理者でログイン = new EventsPage(admin.page);
    await expect(管理者でログイン.イベント一覧.新規作成ボタン).toBeVisible();
    await 管理者でログイン.イベント一覧.新規作成ボタン.click();

初学者にオススメの参考書

各チームの課題を解決するにはどのテストが有効なのか、QAエンジニアが集まって話し合える土壌作り

組織横断でQAエンジニアの有志が集まり、月次でテスト自動化の共有会を開催しています。最初のうちはハンズオンを実施してただ学ぶだけだったのですが、最近だと各チームの報告を受けて意見交換が活発になりました。

• XXXチームでは正常系は最低限、エラー系のテストを厚めにしている
• この機能の場合だと、E2Eテストではなく、インテグレーションの方がよさそう
  • エンジニアさんに教わりながらインテグレーションテストやってみた！
    • うちのチームもやってみたいので今度詳しく聞かせてください！
• TDDをやっていますが初学者だと難しいので、最初は既存機能かつ実データでのE2Eテスト実装で経験を積むとよさそう！
• Gitさっぱり分からんので教えてほしい！
• ハンズオンでせっかく覚えたので、Pythonで担当機能の回帰テストを自動化してみた！
  • （日々のお昼休憩中に実行、自分自身の工数削減に活用した事例）
  • 一旦はこのまま量産を優先、TypeScriptへの意向は別途検討

自動化を推進した結果

• 簡単なテストコードのレビューにQAエンジニアが参加
• 簡単なテストコードの実装をQAエンジニアが担当
• うちのチームも皆でやろうぜ！　といったチームが増えてきた

工数を大幅に削減できたなど具体的な成果はまだこれからです。誰か一人が無理して頑張ってもいつかは破綻してしまうので、この調子でテスト自動化の文化を浸透させていければと思います。

おわりに

私一人では到底実現できませんでした。相談に乗ってくださった皆様、嫌な顔をせずにご協力いただいた皆様、面白そうだからやってみるわ！ と手を挙げてくださった皆様、裏で色々と調整いただいた皆様、本当に有難うございました！！！

E2Eテストを布教させたい誰かの役に立ったら幸いですｗ

お読みいただきありがとうございました！
明日のカオナビ Advent Calendarもお楽しみにです！！