はじめに
長年運用しているプロダクトほど、「影響範囲のテストが誰かの頭の中にしかない」という課題を抱えていませんか？
私たちのチームもまさにその状態でした。
機能追加や修正のたびに、
「この変更って、あの画面にも影響するかも」
「ここを触ったら、こっちの挙動も確認しないと」
といった知見が、特定のメンバーの経験に依存していました
その結果、
- テスト範囲が属人化する
- 経験の浅いメンバーへ代替しづらい
- 知見の承継に時間がかかる
といった問題が発生していました
そこで今回、PlaywrightMCPを使い、“個人の頭の中にしかないリグレッションテスト” を 自然言語(Gherkin)形式で自動生成し、知見承継を加速させる仕組みを試しました。
この記事では、その取り組みを紹介します
背景と課題
私たちのサービスは数年前から継続的に開発しており、機能が複雑に絡み合っています
ドキュメントが全くないわけではないものの、「実際に使えるテスト観点」を網羅した資料は限られていました
特に問題だったのは、リグレッションテストの影響範囲が属人化していたことです
- 古参メンバーが仕様を深く理解しているが、他業務で多忙
- 参画してから日が浅いメンバーはテスト範囲を判断できず、確認漏れが発生
- 知見の承継が一朝一夕には進まない
つまり、「わかっているけど仕組み化されていない」状態です
この“頭の中の知見”をチームに展開することが、次の品質向上の鍵でした
取り組みの方向性
私たちが目指したのは、次のような流れです
- 知見のある社員が手動でリグレッションテストを実行
- PlaywrightMCPが操作内容を自動記録
- 自動記録したコードをGherkin記法のfeatureファイル に自動変換
- GitHubでソース管理し、チーム全体で再利用
これにより、「経験者が実施していたテスト内容」を「再利用可能な自動テスト資産」に変換できます
プロンプトの例
当記事では割愛します
実際に動かしてみた結果
以下のファイルが作成されました。
Feature: テストサイトでのユーザー操作
Scenario: ログインからログアウトまでの操作
Given "https://xxx/login" にアクセスする
And "メールアドレス" フィールドをクリックする
And "メールアドレス" に "xxx@xxx.co.jp" を入力する
And Tabキーを押す
And "パスワード" に "xxx" を入力する
And "ログイン" ボタンをクリックする
And ナビゲーションの最初の要素をクリックする
And "テスト用リンク" リンクをクリックする
And "テスト用ページ" が表示されることを確認する
And メニューボタン をクリックする
And "ログアウト" ボタンをクリックする
Then ログアウト完了メッセージが表示される
今後の展望
この仕組みはまだ実験段階ですが、方向性としては非常に有用です 今後は実際に運用し、属人化が解消できるよう取り組んでいきたいと思います
最終的には、「人が考えたテスト知識を自動で再現・再利用できるチーム文化」を作ることを目指していきたいと思います
