Acceptance testing
Acceptance testing evaluates whether a system or software satisfies specified user, business, or other stakeholder requirements and is acceptable for its intended purpose.
BDD in Action, Second Edition
An acceptance test verifies that software satisfies agreed behavioral and business requirements.
- How it is used
- Checks agreed business-facing behavior while guiding implementation and showing whether delivered features meet acceptance criteria.
- How deep it goes
- Develops a workflow from collaborative examples through scenarios and automation, then addresses reliability and maintenance rather than stopping at a definition.
- Examples
- Uses a refined commuter-train scenario, frequent-flyer points requirements, and high-level tests retrofitted to legacy applications.
- What you can do after
- Build it from scratch by turning business-readable scenarios into automated checks, then use their results as feedback on implemented behavior.
Read how BDD in Action, Second Edition explains acceptance testing →
Think Like a Software Engineering Manager
User acceptance testing is testing performed by end users or stakeholders to determine whether software satisfies their requirements and is ready for deployment.
- How it is used
- Positions UAT as a user-perspective check of requirements and deployment readiness.
- How deep it goes
- Defines who tests and what they assess, but provides no UAT procedure or acceptance checklist.
- Examples
- Uses an employee beta release as a related example of gathering feedback and fixing bugs before customers receive software.
- What you can do after
- Evaluate/understand whether user or stakeholder testing addresses requirements and readiness for deployment.
Read how Think Like a Software Engineering Manager explains acceptance testing →
Django in Action
An acceptance test verifies that software satisfies requirements from the perspective of an expected feature or user outcome.
- How it is used
- Verifies that features satisfy requirements through behavior that matches intended user outcomes.
- How deep it goes
- Defines feature-level behavior and its place in the testing pyramid, but does not detail implementation procedures.
- Examples
- Uses a shipping-cost page with varied addresses and shipping zones to illustrate the cost of higher-level testing.
- What you can do after
- Evaluate whether a defined feature works as designed from a requirements-oriented, often user-facing perspective.
Related concepts
- testkind of · A test is a procedure or check that evaluates behavior using specified inputs or evidence against expected results or criteria.
- requirementsuses · A requirement is a stated need, capability, quality, condition, or constraint that a system, product, solution, or project is expected to satisfy.
- Jestuses · Jest is a JavaScript testing framework for defining, running, and asserting automated tests.
- testing pyramidpart of · The testing pyramid is a software-testing model that favors many fast, focused lower-level tests and progressively fewer, broader, slower tests at higher levels.
- executable specificationproduced by · An executable specification is a machine-runnable description of expected system behavior that can automatically verify whether an implementation satisfies its requirements.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.