Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
bmad-code-org avatar

Bmad Qa Generate E2e Tests

  • 306 installs
  • 51.5k repo stars
  • Updated August 5, 2026
  • bmad-code-org/bmad-method

bmad-qa-generate-e2e-tests is a BMAD Method workflow skill that generates runnable API and end-to-end tests from implemented features for developers who need automated coverage without redesigning their test stack.

About

bmad-qa-generate-e2e-tests is a built-in QA Automate workflow in the BMAD Method BMM module that turns shipped features into executable test suites. The skill follows five ordered steps: detect the project's test framework from package.json and existing tests (Jest, Vitest, Playwright, Cypress, or a suggested runner), identify target features from prompts or codebase discovery, generate API tests covering status codes and response shape, generate E2E tests with semantic locators and visible-outcome assertions, then run and repair failing specs. Developers invoke it via the Developer agent QA command or the bmad-qa-generate-e2e-tests skill after stories in an epic are implemented and code-reviewed. It focuses on happy paths and one or two critical error cases rather than exhaustive coverage, and defers enterprise test-architecture strategy to the separate TEA module documented in BMAD testing references.

  • Story-to-E2E scenario mapping with priority ranking
  • Critical path and edge-case journey coverage
  • Executable test steps aligned to acceptance criteria
  • Regression-focused suites for high-risk integrations
  • QA artifacts ready for CI pipelines or manual runs

Bmad Qa Generate E2e Tests by the numbers

  • 306 all-time installs (skills.sh)
  • Ranked #700 of 2,153 Testing & QA skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/bmad-code-org/bmad-method --skill bmad-qa-generate-e2e-tests

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs306
repo stars51.5k
Last updatedAugust 5, 2026
Repositorybmad-code-org/bmad-method

How do you generate Playwright E2E tests from user stories?

Generate end-to-end test scenarios and executable test cases from stories and acceptance criteria to verify critical user journeys before release.

Who is it for?

Developers finishing a BMAD epic who already have Jest, Vitest, Playwright, or Cypress configured and need fast automated regression coverage.

Skip if: Projects still defining requirements or teams that need formal test-architecture strategy, traceability matrices, or pre-implementation TDD planning.

When should I use this skill?

An epic's stories are implemented and reviewed but API or E2E test files are missing or failing before release.

What you get

Runnable API and E2E test files, a passing local test run, and a coverage summary aligned to the detected framework.

  • API test files
  • E2E test files
  • Passing test run output

By the numbers

  • Follows a 5-step QA Automate workflow from framework detection through test execution
  • Targets Jest, Vitest, Playwright, and Cypress among detected runners

Files

SKILL.mdMarkdownGitHub ↗

QA Generate E2E Tests Workflow

Goal: Generate automated API and E2E tests for implemented code.

Your Role: You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the bmad-code-review skill for that).

Conventions

  • Bare paths (e.g. checklist.md) resolve from the skill root.
  • {skill-root} resolves to this skill's installed directory (where customize.toml lives).
  • {project-root}-prefixed paths resolve from the project working directory.
  • {skill-name} resolves to the skill directory's basename.

On Activation

Step 1: Resolve the Workflow Block

Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow

If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:

1. {skill-root}/customize.toml — defaults 2. {project-root}/_bmad/custom/{skill-name}.toml — team overrides 3. {project-root}/_bmad/custom/{skill-name}.user.toml — personal overrides

Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.

Step 2: Execute Prepend Steps

Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.

Step 3: Load Persistent Facts

Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.

Step 4: Load Config

Load config from {project-root}/_bmad/bmm/config.yaml and resolve:

  • project_name, user_name
  • communication_language, document_output_language
  • implementation_artifacts
  • date as system-generated current datetime
  • YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config {communication_language}

Step 5: Greet the User

Greet {user_name}, speaking in {communication_language}.

Step 6: Execute Append Steps

Execute each entry in {workflow.activation_steps_append} in order.

Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.

Paths

  • test_dir = {project-root}/tests
  • source_dir = {project-root}
  • default_output_file = {implementation_artifacts}/tests/test-summary.md

Execution

Step 0: Detect Test Framework

Check project for existing test framework:

  • Look for package.json dependencies (playwright, jest, vitest, cypress, etc.)
  • Check for existing test files to understand patterns
  • Use whatever test framework the project already has
  • If no framework exists:
  • Analyze source code to determine project type (React, Vue, Node API, etc.)
  • Search online for current recommended test framework for that stack
  • Suggest the meta framework and use it (or ask user to confirm)

Step 1: Identify Features

Ask user what to test:

  • Specific feature/component name
  • Directory to scan (e.g., src/components/)
  • Or auto-discover features in the codebase

Step 2: Generate API Tests (if applicable)

For API endpoints/services, generate tests that:

  • Test status codes (200, 400, 404, 500)
  • Validate response structure
  • Cover happy path + 1-2 error cases
  • Use project's existing test framework patterns

Step 3: Generate E2E Tests (if UI exists)

For UI features, generate tests that:

  • Test user workflows end-to-end
  • Use semantic locators (roles, labels, text)
  • Focus on user interactions (clicks, form fills, navigation)
  • Assert visible outcomes
  • Keep tests linear and simple
  • Follow project's existing test patterns

Step 4: Run Tests

Execute tests to verify they pass (use project's test command).

If failures occur, fix them immediately.

Step 5: Create Summary

Output markdown summary:

# Test Automation Summary

## Generated Tests

### API Tests
- [x] tests/api/endpoint.spec.ts - Endpoint validation

### E2E Tests
- [x] tests/e2e/feature.spec.ts - User workflow

## Coverage
- API endpoints: 5/10 covered
- UI features: 3/8 covered

## Next Steps
- Run tests in CI
- Add more edge cases as needed

Keep It Simple

Do:

  • Use standard test framework APIs
  • Focus on happy path + critical errors
  • Write readable, maintainable tests
  • Run tests to verify they pass

Avoid:

  • Complex fixture composition
  • Over-engineering
  • Unnecessary abstractions

For Advanced Features:

If the project needs:

  • Risk-based test strategy
  • Test design planning
  • Quality gates and NFR assessment
  • Comprehensive coverage analysis
  • Advanced testing patterns and utilities
Install Test Architect (TEA) module: <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/>

Output

Save summary to: {default_output_file}

Done! Tests generated and verified. Validate against ./checklist.md.

On Complete

Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete

If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.

Related skills

How it compares

Pick bmad-qa-generate-e2e-tests for fast post-implementation test generation inside BMAD; choose a dedicated test-architecture skill when you need enterprise strategy, gates, or planning-artifact traceability.

FAQ

When should bmad-qa-generate-e2e-tests run in BMAD?

bmad-qa-generate-e2e-tests should run in Phase 4 after all stories in an epic are implemented and code-reviewed. The QA Automate workflow generates API and E2E tests, executes them, and fixes failures before retrospective or release.

Which test frameworks does bmad-qa-generate-e2e-tests support?

bmad-qa-generate-e2e-tests scans package.json and existing test files for Jest, Vitest, Playwright, Cypress, or any standard runner. If none exists, the workflow analyzes the stack and suggests an appropriate framework before writing specs.

Testing & QAtestingfrontendbackend

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.