Here is the full workflow that turns Playwright CLI + an AI coding agent into a system that can write UI tests for you. It works with Cursor, Claude Code, Codex, or any agent you have. ──────────────────────────────────────── 🟢 𝐓𝐡𝐞 𝐔𝐧𝐢𝐯𝐞𝐫𝐬𝐚𝐥 𝐖𝐨𝐫𝐤𝐟𝐥𝐨𝐰 ➤ Step 1. Explore the test case with Playwright CLI You give the agent a real test case with the steps and validations: ∙ What user flow to cover ∙ What URL to start from ∙ What success looks like ∙ What data or credentials to use (or where to find them in the repo) The agent uses Playwright CLI to walk through that flow in the browser: ∙ `open` the starting page ∙ `snapshot` to read what is on screen ∙ `click`, `fill`, and navigate step by step ∙ `snapshot` again after each meaningful action The Agent is exploring the app the same way a human tester would, but faster, and with structured output, a.k.a it generates a file with it's findings. ➤ Step 2. You review. When exploration finishes, the Agent should produce a short exploration document. Something you can read and review. It should include: ∙ Pages visited and the order of steps ∙ Locators or element refs that worked ∙ Form fields, buttons, and links involved ∙ Assertions the Agent observed (visible text, URL changes, success messages) ∙ Anything ambiguous or blocked (login wall, captcha, missing test data) 𝐘𝐨𝐮 𝐫𝐞𝐯𝐢𝐞𝐰 𝐭𝐡𝐢𝐬 𝐛𝐞𝐟𝐨𝐫𝐞 𝐚𝐧𝐲 𝐭𝐞𝐬𝐭 𝐜𝐨𝐝𝐞 𝐢𝐬 𝐰𝐫𝐢𝐭𝐭𝐞𝐧. ➤ Step 3. The Agent generates UI tests Now the agent writes code. It uses two inputs: 1. The exploration document from Step 2 2. Your existing test framework. Folder structure, page objects, fixtures, naming conventions, helper methods Playwright CLI does not replace your framework. It feeds facts into it. Same workflow whether you use Playwright Test, Selenium, Cypress, or something else. The exploration layer is shared. The test code layer is yours. ➤ Step 4. The Agent runs the tests. The agent runs the new test (or the relevant suite). If it passes —> done. If it fails —> the agent goes back to Playwright CLI:

──────────────────────────────────────── 🟢 𝐖𝐡𝐚𝐭 𝐑𝐮𝐧𝐬 𝐖𝐡𝐞𝐧 𝐘𝐨𝐮 𝐨𝐫 𝐚𝐧 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭 𝐓𝐲𝐩𝐞 𝐚 𝐂𝐨𝐦𝐦𝐚𝐧𝐝 1. You or your AI agent type a command in the terminal. 2. Playwright CLI reads it and opens the browser. It can run in headed mode (you see the window) or headless (no UI). 3. After the browser opens and the page loads, Playwright CLI takes a snapshot of the page. The snapshot is a small `.md` file with page details, including locators. 4. You or the AI agent read the snapshot and decide what to do next. If it shows a Login button, you see its accessibility ID (often something like `e10` or `e12`). Then you run a command such as `playwright-cli click e10` to click it. That is the workflow in a nutshell: Step 1 — load the web page Step 2 — get a snapshot of it Step 3 — act on the snapshot information Playwright CLI does not replace Playwright, Selenium, or Cypress. It is a different tool that sits on top of them. ──────────────────────────────────────── 👁 𝐇𝐞𝐚𝐝𝐞𝐝 𝐯𝐬 𝐇𝐞𝐚𝐝𝐥𝐞𝐬𝐬 Playwright CLI can open browsers in two modes: headed and headless. Headed mode shows the browser on your screen. Use it when you set up the tool or when you need to see what happened. Headless mode runs without a window. It is faster for repeat runs, but harder to watch. Some failures only show up in one mode. If a command fails in headless, try headed once before you change the test. ──────────────────────────────────────── 📌 Want hands-on practice with the AI workflows for test automation? Join the AI AutoTest Live Workshop — live theory, practice, and real agent workflows for test automation. 👉 Click here to read more: https://www.skool.com/qa-automation-career-hub/welcome-to-qa-automation-roadmap-lab-start-here

🧠 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝘁𝗼𝗼𝗹𝘀 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗯𝗲 𝗯𝘂𝗶𝗹𝘁 𝗳𝗼𝗿 𝗵𝘂𝗺𝗮𝗻𝘀. 1. A QA engineer wrote the code. 2. Read the errors. 3. Decided what to try next. That was the normal workflow for years. But now everything has changed. Starting in early 2026, AI Coding Agents can handle all of those steps, while QA engineers act as managers and agentic leads. ──────────────────────────────────────── 🟠 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐌𝐂𝐏 It was the first serious tool for this new AI QA workflow. It let an AI Agent look at the page, click buttons, take page snapshots, and do basic browser tasks. Main use cases for the Playwright MCP in Test Automation: - Gathering locators for the UI tests - Debugging flaky or failed tests - Read console and network logs How it works: 1. User asks an AI agent that has access to Playwright MCP to do a task. 2. The AI coding agent controls the Playwright MCP to interact with a browser. For a while, that seemed like a great option, but soon enough it was discovered that it has a few fatal issues... ──────────────────────────────────────── 🔴 𝗣𝗹𝗮𝘆𝘄𝗿𝗶𝗴𝗵𝘁 𝗠𝗖𝗣 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗼𝗽𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝘁𝗲𝘀𝘁 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 Here is how Playwright MCP works: 1. It loads a full page snapshot (HTML + CSS) into the AI agent’s context after each page interaction. 2. It also loads large MCP metadata that tells the agent how to use the tool. That means Playwright MCP can eat 20–30% of that memory in a single use. And once context crosses 50–60%, agents start making mistakes and losing track of earlier instructions. So technically it works, but the context overhead and cost are not great. Quick recap: the AI agent’s context is its working memory. It holds the current conversation, instructions, code, and everything else the agent needs to stay on track. ──────────────────────────────────────── 🟢 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐂𝐋𝐈 Playwright CLI was built to solve those problems. It gives AI agents a simple command-line utility they can call like any other terminal command: - The agent runs small commands and gets back short results. - It reads the full HTML page only when needed, not on every interaction like Playwright MCP does.

You open Cursor, Copilot or whatever AI tool you like ... You type: "write a login test" The agent responds. It looks like a test. Imports are there. Structure looks familiar. But you look closer. - Hardcoded credentials. - Wrong file location. - No page objects. - Naming convention are ignored. - And on top of all that, you run it... it fails. ──────────────────────────────────────── 🧠 𝐖𝐡𝐲 𝐭𝐡𝐞 𝐀𝐠𝐞𝐧𝐭 𝐆𝐮𝐞𝐬𝐬𝐞𝐬 𝐖𝐫𝐨𝐧𝐠 Most people at this point blame the model. - "Claude is bad at tests." - "GPT doesn't understand Playwright." - "I need a better model." But the reality is... the model did not fail you. You gave it nothing useful to work with. Think of the agent like a new hire. Smart. Fast. Capable. But they have never seen your project before. ➤ They do not know where your fixtures live. ➤ They do not know how you name test files. ➤ They do not know what credential pattern you use. ➤ They do not know whether you run tests after every change. You told them: "write a login test." So they try to find all that information and make a lot of assumptions. Every assumption is a guess. Every guess is a risk of being wrong. That is an onboarding problem and a lack of proper documentation. ──────────────────────────────────────── 📝 𝐖𝐡𝐚𝐭 𝐚 𝐑𝐞𝐚𝐥 𝐓𝐚𝐬𝐤 𝐒𝐩𝐞𝐜 𝐋𝐨𝐨𝐤𝐬 𝐋𝐢𝐤𝐞 In the AI coding agents world, that documentation is often called "Task Spec." A task spec is not a longer prompt. It is a precise set of constraints that leaves the agent very little room to guess. Here is the difference. 𝗪𝗲𝗮𝗸 𝗽𝗿𝗼𝗺𝗽𝘁: ``` write a login test ``` 𝗚𝗼𝗼𝗱 𝗧𝗮𝘀𝗸 𝗦𝗽𝗲𝗰: `` Write a login test. Before making any changes, inspect the existing tests in /tests/auth/ and follow the existing suite structure, naming, and conventions. Task: - Add a test for successful login using the existing credentials fixture. - Place it in the appropriate existing auth test suite. - Do not hardcode credentials or duplicate fixture data. - Do not create new files unless no existing test file is appropriate.

Hey QA fam! 👋 Ever been asked in an interview about the difference between smoke and sanity testing? It’s a classic question! They sound similar, but they’re actually different. Here’s the quick breakdown: Smoke Testing 🔥 Think: “Does this thing even turn on?” It’s a broad but shallow check to see if your app’s critical functions work at all. When to run it: • Right after a new build drops • Before starting detailed testing What you’re checking: • Can users log in? • Does the homepage load? • Do critical workflows start? Example: New build deployed → Quick smoke test checks login, navigation, basic functionality → If it fails, reject the build immediately. Sanity Testing 🧠 Think: “Did that bug fix actually work?” It’s a narrow but deeper check on specific functionality after a bug fix or small change. When to run it: • After a bug fix • After a minor code change What you’re checking: • Did the bug get fixed? • Do related features still work? Example: Dev fixed the “Forgot Password” link → Sanity test verifies the fix works and didn’t break related login features. Quick Comparison 📊 Smoke Testing: • Broad and shallow • Tests build stability • After new build • Accept/reject build Sanity Testing: • Narrow and deep • Tests specific functionality • After bug fix • Accept/reject fix The Easy Way to Remember 🏠 Smoke Test: Walking through a house checking if lights work, doors open, water runs. Basic stuff! Sanity Test: Going back to check if that leaky faucet the seller “fixed” actually works now. Bottom Line 🎯 • Smoke testing = “Is this build stable enough to test?” • Sanity testing = “Did that fix actually work?” Use both strategically and you’ll save tons of time! Happy Testing! 🚀 Your turn: Which one do you use most in your projects? Drop a comment! 💬