How to Use Claude for Manual Testing

Use Claude for manual testing by giving it a specific requirement, asking for reviewable test cases, and running those cases yourself. Then give it your actual observations to help produce reproducible bug reports. Claude drafts the checks; a suggested test is never evidence that the product passed.

The useful output is a small test record: what you intended to check, what happened, and what still needs attention. fenbs can retain those outcomes, reusable prompts, and lessons so the next tester or assistant starts from the same evidence.

What should you give Claude before asking for tests?

1. Choose one user action, such as submitting a contact form, and provide the requirement or approved acceptance criteria.
2. Describe the environment: browser, device, build, account role, and whether the checks use a safe test system.
3. State what is outside the test, such as real payments, production emails, or changes to customer records.
4. Ask Claude to list missing requirements before it drafts cases. Resolve those questions with the person responsible for the behavior.

Say a small studio has a quote request form. The requirement says a name, email address, and message are required, and a successful submission shows confirmation. Give Claude those exact rules rather than asking it to infer them from a screenshot. A screenshot can show the layout but cannot establish what the server must accept.

Anthropic recommends explicit instructions and examples in its prompting guidance↗ (opens in a new tab). For testing, that means supplying an example of the case format you want and naming the constraints. Our introduction to Claude explains the assistant itself; here the focus is the manual testing workflow.

How do you turn requirements into useful test cases?

Request a compact table with a case ID, the requirement it checks, preconditions, steps, expected result, and a blank actual result. Ask for the normal path first, then invalid inputs and boundary conditions. Have Claude mark any expected behavior it cannot derive from the supplied requirement as a question.

Using only the requirements below, draft manual cases for the quote request form. Include normal submission, each required field missing, invalid email, repeated clicks, and returning after an error. Give each case an ID. Leave actual result and pass/fail blank. Mark unsupported expectations as questions. Do not claim to have executed anything.

Review the draft before touching the app. Remove duplicate cases and correct invented rules, such as a message length limit nobody specified. Make each expected result observable: the error appears beside the email field and the form remains available is clearer than the validation works.

For deciding which checks belong in this session, use the distinctions in types of software testing. A manual case set should be small enough that someone can execute it carefully and report where a case stopped.

How should you execute and record the checks?

Run the approved cases in the specified environment. Record the actual behavior immediately, including a failed setup or a blocked step. Use passed only when you observed the stated result. Use not run when you did not execute the case, even if a similar case passed earlier.

• Capture the build or release identifier and the time of the check so someone can find the same version.
• Write the exact input needed to reproduce the behavior, using synthetic data rather than customer details.
• Attach or link a relevant screenshot or recording, with sensitive information removed.
• Separate a product failure from a test that could not run because the environment was unavailable.

Return a few observations to Claude at a time and ask it to format them without changing their meaning. If you wrote confirmation never appeared, do not accept a summary that says the message was not delivered. The first is an observation; the second needs another check. A fenbs task can keep the test outcome and lesson together for the next session.

Where does exploratory testing fit?

After the planned cases, give yourself a short exploration goal. For the form, that might be recovering from a connection failure without losing the message. Ask Claude for variations to consider, then choose the ones relevant to the product and allowed in the test environment.

Keep a note of the path you actually took. Changing several variables at once may reveal a problem, but reproducing it requires narrowing the steps afterward. Try the smallest sequence that still produces the failure, and record whether it happens consistently or only sometimes.

Use the separate guide to Claude for QA testing for the broader quality process. This manual session should end with observed findings and remaining questions, rather than an unbounded list of things an assistant thinks might be worth testing.

How do you write a bug report Claude cannot overstate?

Give Claude the actual steps, expected behavior from the requirement, observed result, environment, and evidence. Ask it to write a short title describing the failure and to preserve uncertainty. A good report says double-clicking Submit creates two confirmations; it does not guess that a database transaction is broken.

Anthropic warns that Claude can produce incorrect or misleading responses↗ (opens in a new tab). Check its bug report against your notes, especially causal explanations, severity, and claims about affected users. Assign urgency from observed impact and the team’s priorities.

How to do this with fenbs

1. Create a free account, then add the project whose behavior you are testing.
2. Add tasks for the testing work and any confirmed bugs. Put the requirement and agreed test approach with the relevant task.
3. Record the test status and test notes: environment, cases executed, actual result, and checks still outstanding.
4. Save the useful case-generation prompt in Skills and prompts and the reusable correction in Lessons learned.
5. Ask your connected assistant to save Where we left off, including the next case to run and anything waiting on a person.

fenbs does not execute browser tests or prove the application works. If you need automated execution or a specialist test management system, use the appropriate tool and keep the work record connected to its evidence.

What should you check before calling the session finished?

Confirm every planned case has an honest outcome, each bug has reproducible steps, and the remaining checks have an owner or next step. Ask a colleague to follow one report without your help. If they cannot, improve the report before moving on.

End with one reusable improvement: a clearer requirement question, a better prompt, or a setup check that would have saved time. The AI at work collection covers other practical workflows; this one succeeds when another person can repeat the check and understand the result.