How QA Should Work with Claude: a Workflow, Not a Toy

Most testers open Claude, type something like “write test cases for login”, copy the answer, and walk away disappointed: too shallow. The problem isn’t the model — it’s the approach. Claude is not a search engine or a text generator. It’s a junior teammate who knows a lot and works fast, but knows nothing about your product until you tell it.

Here’s how to fit it into a real QA process.

What Claude actually closes

Its strengths are wherever you need to reshape a lot of text and structure quickly:

Generating test cases and checklists from requirements, a feature description, or a screenshot.
Parsing logs and stacktraces — spot the anomaly, group similar errors, explain an unfamiliar exception.
Reviewing a test plan or requirements — find gaps, contradictions, invalid assumptions.
Draft bug reports from raw notes — turn “broke when paying by card” into a structured ticket with steps.
Test data — boundary values, invalid inputs, edge cases for dates, money, unicode.
Automation — a Page Object skeleton, a manual case turned into Playwright/Selenium, explaining someone else’s code.
Routine writing — release notes, a message to stakeholders, translating a checklist.

What it does poorly

Your system’s real behavior. It doesn’t know the “Pay” button disables after 3 seconds. It guesses.
Fresh facts — SDK versions, APIs, store limits change; verify them.
Counts without data — don’t ask “how many cases do I need”, ask “which scenarios did I miss”.
Accountability. The final call on quality is yours, not the model’s.

Context is everything

The difference between garbage and value is context. Compare:

Bad: “Write test cases for the sign-up form.”

Good: “Mobile banking app, sign-up form: phone + SMS code + password. Biometrics on step two. Password 8+ chars, one digit. Regions: RU and KZ. Give test cases grouped by: field validation, security, localization, network/offline. Format — a table: steps / expected result.”

The second answer is far sharper because the model knows the domain, the constraints, and the format you want. Rule of thumb: if a new intern couldn’t do the task from your text, neither can Claude.

A workflow, not “ask-and-copy”

A single prompt rarely gives the final result. What works is an iterative loop:

Give context — product, feature, constraints, what’s already tested.
Scope the task narrowly — not “test payments”, but “give negative cases for card payment on a poor network”.
Ask for questions back — “before answering, ask me 3 clarifying questions”. This sharply raises quality.
Critique the answer — “cases 4 and 7 duplicate, add an expired-card scenario”.
Pin the format — table, JSON, Gherkin. The model holds structure well.

Where not to trust it

Anything about facts and numbers — double-check (versions, limits, links).
Generated code — run it, don’t commit blindly. Especially selectors and asserts.
The confident tone — it sounds convincing even when wrong. Confidence ≠ correctness.
Private data — never paste real credentials, tokens, or user PII.

Bottom line

Claude doesn’t replace the tester — it removes the busywork so you can spend your head on what actually needs it: risks, priorities, non-obvious scenarios. Treat it like a fast junior teammate: give context, scope the task, verify the result. Then it saves hours instead of faking progress.

Concrete prompt templates are in the separate QA prompt cheatsheet.