Cursor + Playwright MCPによる テスト実行のトライアル

ソフトウェアテスト自動化カンファレンス 2025 Cursor + Playwright MCPによる テスト実行のトライアル 12月6日(土) 株式会社ナレッジワーク QAエンジニア 綿貫朱里 / guncha

発表の概要 ● アウトライン 背景：AI活用によるプロダクト実装の高速化 事例：Cursor + Playwright MCPによる自然言語でのテスト実行トライアル ○ ○ ● 結論 ○ 「人間の初回の手動テストを代替させること」を目指さないほうが良い ■ ○ AI技術の隆盛で既存の自動テストのセオリーが大きく覆った訳ではない ■ ○ ● 偽陽性や偽陰性のリスク、人間が優れている部分 「テスト自動化の 8原則」『Lessons Learned in Software Testing』など 既存の自動テストのセオリーから学びつつ新たな技術の活用方法を模索しよう 聴いてほしい方 ○ ○ 既に同じような取り組みを始めている方 これからテスト実行にAI活用していきたい方 © Knowledge Work Inc. 2

自己紹介 綿貫朱里 / guncha 2022年9月 ナレッジワーク入社 職種：QAエンジニア 担当：全プロダクト → 社内共有領域 → プロダクト横断 → AI Agent Builder © Knowledge Work Inc. 3

Agenda 目次 • トライアル開始の背景 • トライアルの概要とデモ • 5つのトライアルの紹介 • トライアルを通しての学び © Knowledge Work Inc. 4

Agenda 目次 • トライアル開始の背景 • トライアルの概要とデモ • 5つのトライアルの紹介 • トライアルを通しての学び © Knowledge Work Inc. 5

トライアル開始の背景 ● AIコーディングツールの台頭 ○ ● テストの現状 ○ ○ ● プロダクトの実装は高速化されつつある E2E自動テストをリグレッションテストとして定期実行している（Playwright） 新規機能に対してフロントエンドもバックエンドもそれぞれUnitテストを書いてはいるが、 初回リリースに向けては手動実行するテストも一定存在する ボトルネック化の不安 ○ プロダクトの実装速度が上がると、リリースまでのボトルネックが 手動テストの実行になるのでは ■ © Knowledge Work Inc. 自分がやるよりも速く、自分と同じくらい良い感じにテスト実行してもらえないか 6

トライアル開始の背景 Cursor Playwright MCP ＋ AI機能を搭載したコードエディタ ブラウザ操作などもできる MCP(Model Context Protocol) Cursorのチャットから Playwright MCPでテストを実行できる 人間が手動でやろうとしていたテストを自然言語で実行させてみたい © Knowledge Work Inc. 7

Agenda 目次 • トライアル開始の背景 • トライアルの概要とデモ • 5つのトライアルの紹介 • トライアルを通しての学び © Knowledge Work Inc. 8

トライアルの概要とデモ ①テスト実行用 Cursor Command実行、②テストケース読み込み、 ③テスト実行＆スクリーンショット撮影、④スクリーンショット格納、⑤テスト実行結果の記録 © Knowledge Work Inc. 9

トライアルの概要とデモ ● ①テスト実行用Cursor Command ○ Playwright MCPを起動し、テストケースを読み込み、テストを実行し、スクリーンショット を撮影して指定のフォルダに格納し、テスト実行結果を記録するよう指示が書かれた Command © Knowledge Work Inc. 10

トライアルの概要とデモ ● ②テストケースについて ○ テスト分析、テスト設計の成果物はTestDesignDoc ■ ○ 詳細はブログ参照 https://note.com/knowledgework/n/n0203ecdc3da0 テストケースはスプレッドシートで作成することが多かった ■ © Knowledge Work Inc. このトライアルでは形式を変更し、マークダウンのチェックリスト形式にした 11

• https://note.com/knowledgework/n/n0203ecdc3da0

トライアルの概要とデモ ● テスト対象ついて ○ 実際に機能開発が進行中だったものを対象とした ■ パスワードログイン機能 ■ ■ 多要素認証機能 2025年12月時点で開発中の機能（リリース前につき詳細は割愛） © Knowledge Work Inc. 12

トライアルの概要とデモ トライアルのデモ 指定されたメールアドレスとパスワードで ログインに失敗するテストの実行 © Knowledge Work Inc. 13

トライアルの概要とデモ © Knowledge Work Inc. デモで利用した情報は削除済 14

Agenda 目次 • トライアル開始の背景 • トライアルの概要とデモ • 5つのトライアルの紹介 • トライアルを通しての学び © Knowledge Work Inc. 15

5つのトライアルの紹介 ①シンプルなテストケースの実行 ②シンプルなテストケースに誤りを埋めこんでおく ③スプレッドシートで作った表をベースにしたテスト ④人間が手動実行する予定のテストケースを全部任せる ⑤探索的テスト © Knowledge Work Inc. 16

トライアル①シンプルなテストケースの実行 ● テスト対象 ○ ● テスト内容 ○ ● パスワードを間違えた際のエラー文言の確認 テスト実行結果 ○ ○ ○ ● パスワードログイン機能のログインエラーのテスト うまくいった スクリーンショットも取れた Playwright MCPの起動から始めると2分52秒かかった その他 ○ デモで実施したものと同じ © Knowledge Work Inc. 17

トライアル②シンプルなテストケースに誤りを埋めこむ ● テスト対象 ○ ● テスト内容 ○ ● パスワードログイン機能のログインエラーのテスト 誤った期待結果を意図的に記載したテストケースの実行 テスト実行結果 ○ 実行結果と期待結果の差異に気づき、 スクリーンショットとテスト実行記録を残すことが出来た © Knowledge Work Inc. 18

トライアル③スプレッドシートで作った表をベースにしたテスト ● テスト対象 ○ ● テスト内容 ○ ○ ● 多要素認証の設定変更機能 設定の事前状態と事後状態が記載されている状態遷移表をもとにしたテスト スプレッドシートの表で記載されたテストをGenerateMarkdownTable という拡張機能を利用してマークダウン形式に変換し、テスト実行 テスト実行結果 ○ 読み方や操作ステップを例示してあげればうまくいった スクリプト↓ /execute-script-tests このファイル内にあるテストを実行して。例えば一つ目のテストの場 合、まずは多要素認証が無効であることをサービス設定 > セキュリティ管理の画面から確 認し、その後多要素認証を無効から「有効（必須）」認証方式は認証アプリのみにチェックし 保存、その後ログアウトして再度ログインを試みた際に TOTP登録ができることと TOTP登 録をした上でログインができることを確認して © Knowledge Work Inc. 19

• https://workspace.google.com/marketplace/app/generatemarkdowntable/23306117760

トライアル③スプレッドシートで作った表をベースにしたテスト © Knowledge Work Inc. 20

トライアル④人間が手動実行する予定のテストケースを全部任せる ● テスト対象 ○ ● テスト内容 ○ ● 多要素認証機能の色々なテスト 多要素認証機能に対し人間が手動実行する予定のテストケースのうち できるだけ多くのテスト実行を任せてみる テスト実行結果 ○ 226テストケースのうち ■ テスト実行操作を一通り任せられたケース →60 ■ 途中の一部のテスト実行操作を任せられたケース →65 ■ 設定等をすればテスト実行操作を一通り任せられる可能性のあるケース →35 ■ 設定等をすれば途中のテスト実行操作を任せられる可能性のあるケース →10 ■ テスト実行を任せることが難しそうなケース →56 © Knowledge Work Inc. 21

トライアル④人間が手動実行する予定のテストケースを全部任せる ● 一通り任せられたテストは存在するが、偽陰性が怖い ○ ○ ● スクリーンショットを撮ってもらっていたとしても、堂々と嘘をつく スクリーンショットの確認自体も大変 「期待結果と実行結果の差異」以外の不具合は拾ってくれない ○ ずっと見張ったり最終的に同じテストを人間がやったから拾えた不具合あり ● テスト実行操作の一部を任せたところで一部で人間の手が必要になるならば、結 果的に人間が実行した方が速い ● 設定すれば可能そうなものは、設定自体がセキュリティ制約的にしてはいけない ものも一定数あった ○ 別のツールで試しても同じ壁に当たる © Knowledge Work Inc. 22

トライアル⑤探索的テスト ● テスト対象 ○ ● テスト内容 ○ ● 入力欄と保存ボタンがある画面などの探索的テスト テスト方法 ○ ○ ● 2025年12月現在開発中の機能（リリース前につき詳細は割愛） 手動テストの実行結果のドキュメントをインプットに テストチャーターを作ってもらい、テストを実行してもらう 実行結果をもとにテストチャーターを更新してもらいテストを実行してもらう テスト実行結果 ○ 手動テスト実行結果に記載のない観点もテスト実行してくれた ■ ○ キーバインド操作、絵文字の入力 「5000文字より多く入力するとエラーメッセージが出る」のテストに失敗 ■ © Knowledge Work Inc. 文字数が多くなると正確に数えるのが難しくなる模様 23

トライアル⑤探索的テスト © Knowledge Work Inc. 24

Agenda 目次 • トライアル開始の背景 • トライアルの概要とデモ • 5つのトライアルの紹介 • トライアルを通しての学び © Knowledge Work Inc. 25

トライアルを通しての学び ● うまくいったこと ○ ○ ○ ● シンプルなテストケースに対するテスト実行に成功し、期待結果に意図的に埋め込んだ 誤りも検知できた 表形式のテストは拡張機能等を活用してマークダウン形式に変換すると良い 探索的テストを実行してもらうことができた うまくいかなかったこと ○ ○ ○ 実行できないテストケースがあった ■ セキュリティ上の制約 実行できたものの、偽陰性や偽陽性となるテストがあった ■ 特に偽陰性が怖い 実行結果と期待結果の確認が正しく実行できたものの、人間よりも時間がかかるテスト があった ■ © Knowledge Work Inc. ログインエラーのデモは 2分52秒かかっている 26

トライアルを通しての学び ● 気づき：実行してもらえるのは「実行結果と期待結果の違いを見つける」部分だけ （しかも不十分） ○ ● その違いを見つけようとしている道中での違和感を拾うことは、 現時点では訓練された人間のほうが得意 気づき：既存の自動テストのセオリーが今回のトライアルにも当てはまる ○ ○ ○ テスト自動化研究会「テスト自動化の8原則」より ■ 手動テストはなくならない ■ 自動テストは書いたことしかテストしない ■ テスト結果分析という新たなタスクが生まれる Cem Kaner, James Bach, Bret Pettichord『Lessons Learned in Software Testing』より ■ 105 Don’t mandate 100 percent automation. ■ 108 Don’t equate manual testing to automated testing. 末村拓也『テスト自動化実践ガイド』より ■ 「素朴なテスト自動化」 © Knowledge Work Inc. 27

トライアルを通しての学び 「人間の初回の手動テストを代替させること」を 目指さないほうが良い © Knowledge Work Inc. 28

トライアルを通しての学び 既存の自動テストのセオリーが AIの隆盛によって大きく覆ったわけではない © Knowledge Work Inc. 29

トライアルを通しての学び 既存の自動テストのセオリーから学びながら 新たな技術の活用方法を模索しよう © Knowledge Work Inc. 30

トライアルを通しての学び ● それらを踏まえての現時点での活用可能性→代替ではなく支援 ○ 大きな網の目のテストの実行 ■ 人間も同じテストをする前提で、先に大きな網の目のテストを実行してもらう ■ ○ バグとして検知された部分は注意しながら触る 一緒に探索的テスト ■ 人間が手動で実施したテスト結果もインプットにテストチャーターを作成してもらい、テスト ■ © Knowledge Work Inc. 実行しつつテストチャーターを更新してもらう 新鮮な観点を発見した場合は、今後のテスト設計時の観点として活用 31

お知らせ ● QAエンジニア積極採用中 ○ https://herp.careers/v1/kwork/cZQZNFAirOsU ■ ● カジュアル面談お待ちしています Encraft：ナレッジワーク主催のイベント 12/9(火)19:00 ○ https://knowledgework.connpass.com/event/372083/ ■ © Knowledge Work Inc. テーマ「QAキャリアこれから会議 ──AI時代をどう生きる？」 32

• https://herp.careers/v1/kwork/cZQZNFAirOsU
• https://knowledgework.connpass.com/event/372083/