Enforce BDD Acceptance Tests for Critical Business Scenarios
Description
This rule mandates that critical business flows are validated using end-to-end acceptance tests written in Behavior-Driven Development (BDD) format. These tests must run as part of every release candidate CI pipeline, and all critical path scenarios must pass before deployment.
Purpose
To validate that high-value business behaviors function as expected in an integrated system. BDD-style tests ensure shared understanding between stakeholders and technical teams while guarding against regressions in core functionality.
Scope
- All product features considered part of the “critical path” (e.g., sign-up, donation, reporting)
- End-to-end test scenarios using tools like Cucumber, Cypress, Playwright, or similar
- Executed in CI for every release branch or tag
- Product owners, QA engineers, and release managers
SDLC Integration
- Planning: Acceptance criteria written in Given/When/Then format
- Analysis: Scenarios linked to work items and epics
- Design: System states and user flows captured via feature files
- Development: BDD scenarios automated as tests
- Testing: Tests executed on pre-release CI stage
- Deployment: Release blocked if scenario fails
- Maintenance: Test coverage and relevance reviewed per iteration
Standards
Acceptance Test Requirements
- BDD-style acceptance tests MUST be written for all critical business behaviors
- Tests MUST execute in CI before any release approval
- All critical path scenarios MUST pass with 100% reliability
- Acceptance tests SHOULD complete within SLA (< 5s per user-critical step)
- Flaky or non-deterministic tests MUST be resolved before release
Actionable Metrics
| Metric | Target Value | Measurement Method | Enforcement Level |
|---|---|---|---|
| Critical path test pass rate | 100 % | CI pipeline logs | MUST |
| Scenario execution per release | 100 % | Tag-triggered test report | MUST |
| Step execution time (SLA check) | < 5 seconds | Test framework performance log | SHOULD |
Implementation
Configuration Requirements
- Use
.featurefiles or annotated E2E tests with clear Given/When/Then structure - Integrate into CI stage gated by release candidate tags
- Fail CI if any critical path scenario fails
Example: Correct Implementation
Feature: Donation visibility
Scenario: Donation by new user appears in dashboard
Given a new user signs up
When they donate $10 to a project
Then the donation appears in the dashboard within 5 seconds