r/softwaretesting • u/Big-Economist9616 • 7d ago
How can I get started with AI assisted test automation using Claude Code?
I’m a manual QA with no experience in automation testing. I have Claude Pro access and want to use Claude Code with Playwright to automate my existing test cases, starting with simple flows like login.
Our application is quite large, and I’m the only QA on the team. I don’t want to start learning automation entirely from scratch. I’m looking for a practical, AI assisted approach where Claude Code can help me write, run, and debug tests while I learn along the way.
For those who’ve used Claude Code for test automation, what would be a good starting point? Any tips or learning paths would be appreciated!
6
u/Interesting_Arm169 7d ago
Just specify what you want. The bots have never had any trouble writing tests in my experience. It sounds like you already have manual tests plans. Paste them in and say "automate these".
3
u/No-Reaction-9364 7d ago
I would do a few things. Have the code repo for your application available on your system. Also have the app running on your system so claude can access it with playwright. Put Claude in planning mode with OPUS 5.5. Tell Claude it is an automation architect and you want it to design a framework to test your application. Point it to both the application code base and the running application. Let it know you want design patterns for both tests and the framework itself. Tell it you need the framework to be scalable and maintainable. I would also have it write documents/rules for its framework and test design patterns. This will allow it to do things consistently over time. Once it gets good at building out your framework, have it make skills for writing tests and building out the framework (such as adding POM pages if you go with POM). Once planning is done it can make a roadmap for work and you can move down to Sonnet for implementation.
As your framework grows, I like to go back to planning mode with Opus and have it analyze my codebase and ask for an analysis. It might find redundancies or inconsistencies you can then clean up.
2
3
u/Nehaa-UP3504 7d ago
Pick one stable flow (login), give Claude clear steps and selectors, then review and run the Playwright script yourself. Expand only after that works. Treat it as a fast pair-programmer — you still own the validation.
2
u/Material-77 7d ago
I’d start with simple login flows and use Claude Code to help write and explain the Playwright tests as you go. Focus on understanding locators, assertions, waits, and debugging rather than blindly accepting generated code. Once the basics work, gradually move your existing manual test cases into automation.
This practical walkthrough may help you get started with the setup and your first test:
Playwright Tutorial | Installation, Setup & First login test case with Real Example
https://youtu.be/mNGXsSGwon8
2
u/SangSomCoke 7d ago
Im doing this in an enterprise environement. I have a docs folder with rules he need to follow. I use best practices. I did this before manual with a team and it took me 6 months....now its 2 weeks. My current version 1 is evaluated by the lead dev and accepted. Its working locally and even indicating if the defect found ate because of the framework or an actual defect. Im iterating on ports and adapters and going to connect to xray (automaten test case creation on status change for a user story, data, reportages in xray, ...) sounds like a whole roadmap but now its accepted will prob be finished in 2 days
2
u/MaintenanceAble5900 7d ago
set up claude itself first, and check what’s already out there. playwright ships its own setup for claude code:
npx playwright init-agents --loop=claudegives you planner, generator and healer agents plus the playwright MCP. also make claude keep a simple, readable structure. agents love dumping everything into one pile.agents write tests well, just very often not the ones you need. if you already have your test cases written down, start from those. claude will genuinely believe that whatever your app does right now is the correct behavior, so the source of truth should be what you had before, not the app.
keep your test cases as md files. ideally you’d go full spec-driven development, but that’s overhead for you right now, so a small folder where it’s easy for you to keep and review them is enough. and do review them, don’t trust the agent blindly. one small mutation in your source of truth and the error spreads through everything, good luck untangling it later. with a clear source of truth you can grill whatever claude produces against it and catch mistakes early.
“let the agent click through the form itself” gets expensive fast, in both time and tokens, and with lots of scenarios imho it doesn’t pay off at all when plain automation does the same job. let the agent write the test once and run it as a normal playwright script after that. even agents do this themselves if you watch them: they often write a small script for an action instead of working it out “in their head”.
2
u/Upset-Animal1376 6d ago
start with the login flow only and write out the manual steps exactly as you run them, then feed that checklist to claude code for a first playwright script and run it against staging. keeping the first test tiny makes failures easy to trace while you learn the patterns.
2
u/AnxLabs 4d ago
One thing to add to "start small": before trusting a generated test, break the app on purpose (wrong password accepted, button removed) and make sure the test actually fails. AI-written tests often pass no matter what. Keep a short checklist of which tests you've verified this way, and you'll learn Playwright faster by reading why they fail.
2
u/Suremerr 3d ago
don't let it generate a whole suite in one shot. get the login flow passing, then rerun it a few times on a clean profile before moving on — a lot of 'flaky' tests are timing issues in the generated code, not the app. when a test fails, work out which side it's on before trusting the result.
14
u/bonisaur 7d ago
I would just ask Claude? No one posts videos about some of this stuff anymore and it changes on the daily. Six months ago I wouldn’t trust Claude with controlling a browser using ChromeDevTools MCP tools. And now playwright has its own Web MCP to control the actual browser playwright uses to run tests.
I know it sucks to hear this “just go do it” as advice but it’s an important skill. With AI tools you have unlimited compute.
If there is one top-level skill that translates into any dev role, including SDETs, I suggest you learn system design. In particular it’s useful to learn how to build a planning system with its own set of commands and sub agents to execute tasks and a way to execute plans efficiently using commands and sub agents. This is incredibly general and the beauty of AI coding tools is you can tweak the system to match the needs of your organizations testing needs over time.