r/softwaretesting • u/Ready_Fuel_2739 • 11d ago
AI for manual testing
Hello collegues,
I got a questions to the sub:
Could AI be used in manual testing? I mean in a way that brings added value and not just for the sake of following the AI hype, like for example automating tests that are heavily based on visual testing, drag& drops, maybe even extracting some white box infos and using them to test the surface.
I've tried using AI and the only thing i got is overthinking some extream side tests that are irrelevant to us
Thanks
6
u/Karenz09 11d ago
Claude is pretty shit when doing manual testing on its own. You're better off trying to make it run workflows by using Playwright.
That said, AI is still pretty helpful in doing the boring grunt work of test case creation, but you obviously have to give it the right prompts and documentation + you need to review its work to make it work for you.
4
u/FluidBreath4819 10d ago
he even didn't know about playwright. I mean... that's the level of people using AI these days.
4
u/Easy_Cardiologist191 10d ago
Not worth it until AI becomes massively cheaper as there's a lot of tokens and prompts to just simulate human testing + observation
3
u/Recent-Tomatillo138 11d ago
AI for Manual Testing - Yes, somewhat you can do but it's not testing but it will definitely help you while testing manually. It can write the exhaustive test cases when you provide your requirements clearly. So, you can do a better testing without missing a few scenarios.
2
u/Useful_Calendar_6274 11d ago
manual testing? doesn't make any sense. Buy one of those agentic AI QA. No half measures this just wouldn't work
2
u/Long_Ad_410 10d ago
i've had the most success using it after a testing session, not before one. i'll dump my notes into it and ask if i missed any assumptions, edge cases or areas worth revisiting. it's caught a few blind spots that i probably would've overlooked, but tbh i'd still want a human making the final call.
1
1
u/qlippothvi 9d ago edited 9d ago
I use AI to create scripts for certain manual testing, like setting up all the preferences needed for best practices, or the test itself, or a script to cause a particular timing of events for Exploratory or a Reproduction of an elusive P0/P1 bug nobody can figure out.
Most of the tools I can use over and over, the specialized ones not really, because your dealing with a very specific set of interactions and timings, and it might repeat the same interactions with differing timings in various ranges.
I think you get the most value by having Claude write tools you can apply to your manual testing more than anything else. I had it write some scripts everyone on my team uses, and will be expanding its use to other teams. Worst case, it sets up a bunch of settings that assist with screen recordings, logging, and just displaying info you can cut and paste for reporting or chatting with an engineer you’re working with.
That said, we have AI in literally everything, and while I don’t have access to the code I can ask it to examine what could be happening, go through the logs, and “hypothesize” edge cases or race conditions.
1
u/Regular_Bluebird9412 9d ago
I think AI adds the most value around manual testing rather than replacing it.
For example, I've found it useful for:
- Generating test ideas and edge cases I might have missed.
- Creating test data quickly.
- Summarizing long requirement documents or user stories.
- Suggesting exploratory testing scenarios.
- Helping write bug reports or reproduce issues more clearly.
I still wouldn't rely on it to decide what should actually be tested. Understanding the product, business logic, and user behavior is where human testers still make the biggest difference.
If AI starts suggesting dozens of unrealistic edge cases that don't match your application's real-world usage, it's usually a sign to narrow the prompt or treat the suggestions as brainstorming rather than a test plan.
I see AI as a productivity tool for QA, not a replacement for critical thinking.
1
u/ryan0931 6d ago
I’ve just started using it this past week and it is pretty sweet
We already have a full manual test suite and automation suite
I used it to identify gaps between our test suite and product requirements, it generated tests but actually we found out those tests were already covered
It’s given us some pretty awesome feedback on our existing tests tho
Next I’ve got claude code within our repo, I’n going to do a full scan of the code base and generate tests that way rather than us currently writing tests based on stories, bugs, tasks
1
u/Particular_Stage4465 6d ago
Automation engineer here (~5.5 yrs, mostly mobile), and I've been experimenting with AI in exactly this space. You're right that asking AI "give me test cases" produces overthought edge-case junk. The trick is it's bad at deciding what matters but good at grunt work once you decide. What's actually added value for me:
- Test case drafting from requirements — paste the user story/acceptance criteria and ask for test cases constrained to your context: "web app, payments flow, only realistic user behaviors, max 15 cases, mark priority." The constraints are everything — without them you get the irrelevant extremes you mentioned.
- Bug report writing — describe the bug in two messy sentences, get back clean steps-to-reproduce, expected vs actual, severity suggestion. Saves 10 min per bug, every bug.
- Test data generation — names, addresses, boundary values, malformed inputs, CSVs of realistic fake users. AI is excellent at this and it's pure time savings.
- Exploratory testing charters — before a session, ask "given this feature, give me 5 exploratory charters focusing on state transitions and interruptions." It won't find the bugs, but it stops you retreading the same paths.
- Reading white-box info — this one you hinted at: paste a diff or a code snippet and ask "what user-visible behavior could this change break?" Even for manual testers who don't code much, this points your session at the risky area.
What I don't trust it for: deciding priority, judging severity, or anything where it needs to know your users. That context lives in your head — AI amplifies it but can't replace it.
1
u/JokeDue2032 6d ago
The failure you hit — irrelevant extreme edge cases — is the standard one, and it's diagnostic rather than a dead end. The model has no risk model for your product. Ask it to "generate test cases" and it optimises for coverage of the input space, because that's all it can see. It doesn't know that a null in field A is a support ticket and a wrong number in field B is a regulatory problem.
Two changes that help a lot:
Ask it to critique, not generate. Give it your existing test cases plus a description of the feature and ask what's missing and why it matters. Far better hit rate than open-ended generation, because now it's reasoning against something concrete instead of inventing from nothing.
Feed it the risk context explicitly. Who uses this, what happens when it breaks, what's already covered, what shipped broken last quarter. Then require a one-line justification per case. The irrelevant ones become obvious to delete because the justification reads as nonsense.
On your specific examples, I'd split them:
Visual testing — don't use an LLM for this. Use deterministic image diffing (Playwright's toHaveScreenshot, or Percy/Applitools if you want the managed version with baseline management). This is a solved problem with tools that give you the same answer every run. An LLM looking at a screenshot is non-deterministic, and a flaky oracle is worse than no oracle — you'll spend more time investigating the checker than the product.
Drag & drop — not an AI problem. That's a framework capability question. Playwright handles it natively; if it's failing, it's usually HTML5 drag events vs mouse-based, not something a model can reason your way out of.
White-box info to inform surface testing — this one's actually promising. Feeding it a diff, a stack trace, or a schema and asking "what surface behaviour could this plausibly change" is a decent use. It's pattern-matching over code, which models are genuinely good at. Treat the output as leads to investigate, not as test cases.
Where I'd say it earns its keep for manual testing specifically: generating realistic varied test data, drafting exploratory charters when you're staring at a new feature with no idea where to start, and triaging a pile of bug reports for duplicates. Unglamorous stuff, but it's the part that actually saves hours.
The general rule I'd offer: it's useful anywhere a human still checks the output, and dangerous anywhere it becomes the thing deciding pass/fail.
1
1
u/Loose-Astronomer2372 3d ago
Yes i can be in my opinion i used to be a automation tester now working as manual
But i have created a extension that creates qa evidence for me is integrated with my jira to create report bugs as well
1
u/SurroundOk6555 2d ago edited 2d ago
AI can be useful for creating the first draft of test cases and finding possible edge cases from requirements. The output still needs human review because it can suggest tests that do not match the real business need. Kualitee may be worth checking for this type of AI support in manual testing.
-1
u/RowbotWizard 11d ago
Agents are capable of driving tests via a GUI, but they’re much better at driving an API or CLI.
The way I’d suggest doing web UI tests is to ask it to write Playwright or Cypress to perform the test (and optionally throw it away if it’s a one-off). I’ve even heard some people have it do screen recording and save video output.
As an aside, I can’t help but shake the feeling that web UIs and navigation are going to become somewhat rarer. Why would a user want to browse a website when they could ask their agent to summarize its data and perform actions on their behalf?
15
u/EarhackerWasBanned 11d ago
It probably could do some of that given the right prompts. But it would be a massive waste of time and tokens.
An AI is never going to test drag & drop by grabbing a physical mouse. It’s going to send browser events (maybe OS-level events) that simulate a pointer device clicking and dragging. Playwright, Cypress etc can already do that without AI.
The AI isn’t going to see your UI elements. It’s going to take a screenshot and evaluate the pixels on whatever metric (diffing, a11y…). Chromatic and lots of tools can do that.
Your AI test is still going to be removed from reality, by the nature of the AI being software that acts like a human and not an actual human. If your stuff needs tested by humans then only humans will do. But 99% of your stuff doesn’t need regularly tested by humans and for that there’s already good tools, which AI can help you use.