AI in test automation: what works (and what doesn't yet) โ
Notes from two real experiences applying AI to QA: a PoC with the Playwright agents, and using coding assistants during a massive test migration. No hype: with numbers and verdicts.
PoC: the Playwright agents โ
Playwright offers three AI agents. We evaluated them on a real E2E suite:
๐ฉน Healer โ fixes failing tests โ
- Reliable when the failure is in the automation repo itself: badly specified locators or test implementation errors. In the PoC we introduced a typo in a method argument and it identified and fixed it quickly.
- Fails when many tests break at once due to selector changes in the application: it can't detect the mismatch between the frontend code and the automation's selectors.
Verdict: useful as a detector of test implementation errors; not for failures caused by changes in the application.
๐ Planner โ generates test plans โ
You give it context about the app and how many scenarios you want; it produces an .md with numbered scenarios and steps with nested expect: items. What surprised me most: the coverage includes responsiveness, accessibility (keyboard, screen reader, ARIA), and performance with large datasets โ dimensions a manual plan often forgets.
Verdict: valuable as a scenario checklist generator that a human curates and implements.
๐ค Generator โ generates the tests โ
It takes the Planner's plan + context about the team's approach (POM, locators) and generates the test class. The numbers from our PoC:
- Generating a test for a cross-domain scenario: 13โ15 minutes.
- Most generated tests don't work and come with a significant number of errors.
- Fixing a single cross-domain test: more than 15 minutes.
Verdict: for complex E2E, today it doesn't beat writing it yourself with the existing POM.
PoC conclusion โ
The agent solution doesn't (yet) fit into the daily flow of creating and maintaining complex E2E tests. What's worth keeping: Healer for one-off implementation failures and Planner as scenario brainstorming.
What did work: AI as a migration accelerator โ
During the TestCafe โ Playwright migration we used Copilot/ChatGPT with a simple technique that multiplies the quality of the result: the reference file (few-shot). Instead of asking "migrate this to Playwright" cold:
> Use 'editor.ts' as a reference example to migrate selectors
> from 'Feature/UI/Feature.js'The full flow: a style corpus (tests already migrated by hand by humans) + AI for the mechanical translation work + human review, always. AI performs far better imitating your pattern than inventing its own.
My rules for using AI in QA โ
- AI proposes, the human curates. Drafts of acceptance criteria, test plans, mechanical migrations: yes. Final output without review: no.
- Give it examples, not descriptions. One reference file is worth more than three paragraphs of instructions.
- Never share sensitive data (business, internal security, personal data) with external AI tools.
- Measure before adopting. Our PoC cost little and saved us from adopting a flow that doesn't pay off today. Verdicts expire: what doesn't work today may work two versions from now โ re-evaluate.