Acceptance criteria are a pre-agreed list of conditions that functionality must meet to be considered successfully implemented and accepted. Their formulation started with Agile development methods for transparency in the verification process.
Without clear acceptance criteria, there is a risk of subjective assessment of the result, discrepancies between the tester, developer, and client. This leads to conflicts, delays, and repeated iterations of verification.
Formulate criteria collaboratively with the team, describing not only "what should work," but also "how exactly," anticipating edge cases, errors, and user scenarios. Before testing begins, all project participants familiarize themselves with the criteria.
Key Features:
Who formulates acceptance criteria: only testers or project managers?
It is important to formulate the criteria together: testers, managers, analysts, sometimes — the client.
Can a feature be accepted if it works "generally well," but one of the acceptance criteria is not met?
No. Non-fulfillment of at least one criterion is a reason for rejection of acceptance.
Should the criteria include only positive scenarios?
No. They should account for negative and edge cases to exclude unexpected bugs.
Acceptance criteria were defined verbally and not documented. As a result, one of the important business functions does not work due to hidden client requirements.
Pros:
Cons:
Acceptance criteria were formalized in a list and agreed upon with the product team and client, with examples of data at edge values added.
Pros:
Cons: