Claude Code for QA Engineers: Generate BDD Tests from Specs

Claude Code can draft Gherkin scenarios, step definitions and automation scripts from a written spec. QA engineers get the best results by writing testable acceptance criteria first, giving Claude Code the team's test conventions in CLAUDE.md, and reviewing every generated test for coverage, correctness and flakiness before it joins the suite.

Why start from a spec rather than the code?

Tests generated from existing code tend to confirm what the code already does, including its bugs. Tests generated from a spec check what the software is supposed to do. That is the point of spec-driven development for QA: the requirement, the scenario and the automated check stay connected, so a failing test points at a specific acceptance criterion.

What is the workflow?

1. Get a testable spec. Acceptance criteria in given-when-then form, with edge cases and open questions resolved.
2. Draft scenarios. Ask Claude Code for Gherkin feature files that cover each criterion, negative paths and boundaries.
3. Review the scenarios with the BA before any automation is written.
4. Generate step definitions and scripts in your framework (for example Cucumber, Playwright or Selenium), following your page-object conventions.
5. Run, fix and tighten. Execute the tests, investigate failures, and keep traceability from criterion to scenario to script.
6. Select regression by risk, using the spec and recent changes to choose what to run.

What does it look like in practice?

A spec states: "After 5 failed sign-in attempts the account locks for 15 minutes." The scenarios Claude Code drafts should include the happy path, the boundary and the recovery:

Feature: Account lockout
  Scenario: Account locks after 5 failed attempts
    Given a registered user with a valid account
    When the user enters a wrong password 5 times
    Then the account is locked for 15 minutes
    And the user sees a lockout message

  Scenario: Fourth failed attempt does not lock the account
    Given a registered user with a valid account
    When the user enters a wrong password 4 times
    Then the account is not locked

  Scenario: Account unlocks after the lockout period
    Given a locked account whose lockout period has elapsed
    When the user signs in with the correct password
    Then the user is signed in

Your review then asks the useful questions: does a successful sign-in reset the counter, and is the lockout per account or per device? Those belong back in the spec.

How do you teach Claude Code your test conventions?

Put your rules in CLAUDE.md, which Claude Code reads at the start of each session. For a QA repo that usually means: the framework and folder layout, the page-object pattern, naming rules for scenarios, how test data is created and masked, and what the agent must never touch (production configuration, shared fixtures). Skills and hooks can then package the repeatable parts, such as a test-generation skill or a hook that runs the linter after edits. With MCP, Claude Code can connect to tools such as Jira, or a browser through a Playwright server for exploratory checks.

What should you check in generated tests?

• Coverage: every acceptance criterion has at least one scenario, including negative and boundary cases.
• Correctness: assertions check outcomes the spec states, not incidental UI details.
• Independence: no hidden order dependence or shared state.
• Flakiness: explicit waits rather than fixed sleeps, stable selectors.
• Data safety: no real customer data or secrets in prompts, fixtures or logs.
• Redundancy: no near-duplicate scenarios inflating run time.

What should you not delegate?

Decide what "correct" means yourself. Judging whether a spec reflects business intent, signing off coverage, and deciding release risk stay with people. Claude Code speeds up drafting and mechanical work; accountability stays with the team.

Frequently asked questions

Can Claude Code write Cucumber step definitions?

Yes, it can draft feature files and matching step definitions for common frameworks. Treat the output as a draft that a tester reviews and runs.

Do testers need to code to use Claude Code?

Basic familiarity with your automation framework and a terminal helps. The skill that matters most is writing testable criteria and reviewing output critically.

Is it safe to put test data into prompts?

Only if your policy allows it. Mask or synthesise data, avoid PII and secrets, and agree access controls and log retention with your security team first.

Sources: Claude Code overview, CLAUDE.md and memory, Hooks, MCP in Claude Code.

Keep reading: What is spec-driven development? · Spec-driven development vs vibe coding