Claude Code memory QA workflows help teams stop repeating the same test review instructions in every prompt. If your QA standards are stable, put them where Claude Code can read them at the start of a session: a project CLAUDE.md file, a local memory file, or path-scoped rules for specific test folders.

This tutorial shows how QA engineers, SDETs, and automation testers can use Claude Code memory to keep test review rules consistent. The goal is not to let AI approve tests. The goal is to make AI-assisted review start from the same standards every time: selector quality, assertion depth, test data, screenshots, validation commands, and human final review.

What Claude Code Memory Means for QA

Anthropic’s Claude Code documentation describes memory as persistent context that Claude Code loads for a session. The main project memory file is commonly CLAUDE.md. The documentation also distinguishes memory from stronger controls: memory is context for the model, while hooks are the mechanism for blocking or enforcing actions regardless of model output.

That distinction matters for QA. A memory file can remind Claude Code to flag weak assertions. It can ask for screenshots and command evidence. It can tell Claude Code not to claim a test passed without output. But it should not be treated as a security boundary or a substitute for CI. Use memory to standardize review behavior, then use deterministic test execution to prove the result.

Practical Use Case: A Shared Test Review Checklist

Imagine a team where multiple testers ask Claude Code to review Playwright, Selenium, API, and unit test changes. Without shared memory, every prompt has to repeat the same review standards. Some prompts mention selectors. Others mention assertions. Some ask for validation evidence. Others forget it.

A repository CLAUDE.md gives the team a durable baseline. When a tester asks Claude Code to inspect a test change, the assistant already has the QA review rules in context. The tester can still add task-specific details, but the common standards stay close to the codebase.

Step 1: Start With a Small CLAUDE.md

Do not create a long policy document. Claude Code memory works best when it is concise, specific, and practical. Start with rules that affect real test review quality.

# QA test review rules

When reviewing test automation changes:
- Prefer stable user-facing locators such as role, label, accessible name, or test id.
- Flag selectors based on layout, generated classes, indexes, or fragile text fragments.
- Check whether assertions prove the business behavior, not only visibility or status.
- Look for removed coverage, missing negative cases, hidden retries, and broad mocks.
- Identify test data dependencies, cleanup needs, and environment assumptions.
- Ask for screenshots, traces, or browser evidence when UI behavior changed.
- Never say a test passed unless command output, CI output, or a verified artifact is available.

Expected review output:
- changed behavior under test
- selector risks
- assertion risks
- missing coverage or data concerns
- exact validation command to run
- final human decision points

This file tells Claude Code what a useful QA review should include. It also prevents a common AI testing failure: a confident summary with no proof that the test actually ran.

Step 2: Add Path-Scoped Rules for Test Folders

Project-wide memory should stay general. Folder-specific expectations belong closer to the files they affect. Claude Code documentation supports path-scoped rules through .claude/rules, which is useful when UI tests, API tests, and unit tests have different review standards.

For example, a UI automation folder may need screenshot and locator guidance, while an API test folder may need schema and business-rule assertions.

# UI automation rules

For tests under tests/e2e/**:
- Prefer role, label, accessible name, or test id locators.
- Avoid fixed waits and layout-dependent selectors.
- Include screenshot or trace evidence when reviewing visual behavior.
- Validate both the user-visible outcome and the underlying state change when possible.

# API automation rules

For tests under tests/api/**:
- Do not stop at HTTP status assertions.
- Check response schema, required fields, business rules, and important error messages.
- Include negative, boundary, and authorization cases where relevant.
- Keep test data setup and cleanup explicit.

These scoped rules reduce noise. Claude Code does not need every API rule when reviewing a browser locator, and it does not need every UI screenshot rule when reviewing a contract test.

Step 3: Use a Focused Review Prompt

Memory improves the baseline, but the active prompt still matters. After adding CLAUDE.md, give Claude Code a narrow task and ask it to separate risks from evidence.

Review the changed test automation files as a QA reviewer.
Use the repository QA rules from CLAUDE.md and any path-scoped rules that apply.
Do not edit files yet.

Return:
- what behavior changed
- selector or assertion risks
- missing negative or boundary coverage
- data, cleanup, or environment concerns
- screenshot or trace evidence I should capture
- exact command I should run before accepting the change

This keeps Claude Code in review mode first. Once you understand the risks, you can ask for a narrow patch. That usually produces a smaller and safer change than asking for review and edits in one broad prompt.

Step 4: Move Repeated Procedures Into Skills

Anthropic’s Claude Code skills documentation describes skills as packaged instructions or checklists that Claude can load when relevant. That makes skills a better home for longer multi-step workflows. Use CLAUDE.md for durable team standards. Use a skill when the procedure has many steps, examples, templates, or reusable assets.

A practical split looks like this:

  • CLAUDE.md: short QA review standards, validation expectations, and output format.
  • Path-scoped rules: folder-specific locator, assertion, API, mobile, or accessibility checks.
  • Skills: longer workflows such as flaky-test triage, release-risk review, accessibility evidence collection, or API assertion strengthening.
  • Hooks: deterministic guardrails that run commands or block actions independently of model reasoning.

This separation keeps memory readable. It also makes the workflow easier to maintain as the QA team adds new testing practices.

Step 5: Validate With Real Evidence

A memory-backed review is still an AI-assisted review. Before accepting a test change, run the targeted command, inspect the output, and save evidence when the workflow requires it. For UI tests, that may be a screenshot, trace, or video. For API tests, it may be command output plus a sample response or contract check. For unit tests, it may be a focused test run and mutation or coverage review when risk is high.

Ask Claude Code to list validation commands, but do not let a listed command become proof by itself. The proof is the result of running it in your environment or CI.

Screenshot Checklist

  • Screenshot of the repository CLAUDE.md QA review rules.
  • Screenshot of a path-scoped rule under .claude/rules for UI or API tests.
  • Screenshot of the review prompt asking Claude Code to use memory but not edit files yet.
  • Screenshot of Claude Code output showing selector risks, assertion risks, and validation commands.
  • Screenshot of terminal or CI output after the targeted test run.
  • Screenshot, trace, or browser evidence for the changed UI behavior when relevant.

Common Mistakes

Putting everything in memory. Long procedures become hard to scan. Keep CLAUDE.md short and move detailed repeatable workflows into skills.

Treating memory as enforcement. Memory is guidance for the model. Use hooks, CI, code review, and permissions for stronger control.

Forgetting path differences. UI tests, API tests, unit tests, and accessibility checks need different review standards. Use scoped rules when one global checklist becomes too broad.

Skipping evidence. A good AI review can point to likely risks, but it does not prove that the test is stable or correct. Run the test and capture the result.

Best Practices for Claude Code Memory QA

  • Keep the main CLAUDE.md under version control when the rules should apply to the whole team.
  • Use local memory only for personal preferences or machine-specific notes.
  • Write rules as observable checks, not vague preferences.
  • Ask Claude Code to report missing evidence instead of approving a change.
  • Review memory files after major framework, test data, or CI changes.
  • Keep secrets, credentials, production data, and private customer details out of memory.

Conclusion

Claude Code memory QA is a practical way to make AI-assisted test reviews more consistent. Put durable review standards in CLAUDE.md, use path-scoped rules for test folders, move longer repeatable workflows into skills, and rely on hooks or CI for deterministic guardrails. Claude Code can help surface risks faster, but QA engineers should still make the final decision from real test evidence.

FAQ

Should every QA rule go into CLAUDE.md?

No. Keep CLAUDE.md focused on durable team standards. Put long procedures into skills and folder-specific guidance into path-scoped rules.

Can Claude Code memory prove that a test passed?

No. Memory can tell Claude Code to request evidence, but the proof is command output, CI results, traces, screenshots, or other verified artifacts.

What is a good first QA memory rule?

A useful first rule is: never claim a test passed unless command output, CI output, or a verified artifact is available.

When should QA teams use hooks instead of memory?

Use hooks when you need deterministic behavior such as running checks or blocking risky actions. Use memory for guidance and review standards.

References