Many organizations today are clearly focusing on having often software releases to the client. Even though the software is with reduced functionality, it is still available early in the development lifecycle and has a time-to-market advantage. Usually, organizations are following the agile way using SCRUM for delivering software where every functionality is captured by writing user stories in a collaborative way between the members of the team.
For the user story to be fully developed, tested, and integrated with the system a set of requirements and rules also known as acceptance criteria in agile projects need to be created. This is not the single activity for the agile team to perform during requirement review, design, implementation, and execution. Other, many essential activities need to be performed in agile teams, especially testing-related activities which can contribute to the team and to the overall product quality.
Interested to learn more about how to measure the performance of your project? Check out this amazing course: Performance Testing Using JMeter By Edureka which covers broad topics about website performance and performance testing.
What is Acceptance Criteria in Agile projects?
Acceptance criteria in agile projects are a form of requirements that must be satisfied in order for one user story to be considered as done. Writing acceptance criteria is a collaborative approach between developers, testers, and other members of the team including, business analysts and product owners. Often called ‘Definition of Done’ since they determine what the development team needs to do in order to finish with the story. If the acceptance criteria are not satisfied, then the story is not completely finished and needs to be re-evaluated (tested again, requirements re-review, developing new code, or change the existing one).
Why do you need Acceptance Criteria?
Acceptance criteria in agile projects are needed because once established, the developers and testers know exactly what their activities would be. When the criteria are defined, the team can gain the needed understanding of how the system should behave in terms of a single functionality and will gain confidence about the overall product quality. Having good and clear acceptance criteria allows other members of the team, including stakeholders to know the expected outcome of the feature as well as to reduce any potential bottlenecks being discovered late in the development lifecycle.
Once the user story is picked up for refinement, the acceptance criteria should be written and all potential risks, dependencies, and preconditions need to be considered as well.
What should Acceptance Criteria include?
The content of the acceptance should be concise, sufficient, and understandable. In general, the following topics needs to be covered within AC:
- Functional behavior – How the software behaves in terms of the specified input from the user
- Non-functional aspect – How the system behaves under certain non-functional actions
- Scenarios/Test Cases – Written steps to be performed by the technical person to verify the product
- Third-party systems – Dependencies that can affect the flow
- Data – Needed as a setup in order to perform the tests
- Constraints – Potential constraints that can affect the development team
How Acceptance Criteria format should look like?
There are no specific order or way to write acceptance criteria in an agile project. Most organizations are using the Behaviour-Driven-Development format of AC:
As an end-user
I want to subscribe to the newsletter
So that I can receive regular news and updates
Scenario: User successfully subscribed to the newsletter
GIVEN that the subscribe field is visible
WHEN I write my email in the field
AND I click on the ‘subscribe’ button
THEN I have successfully subscribed to the newsletter
From the example above, you can clearly understand what the end-user wants to achieve. That’s the whole purpose of writing the AC. Making sure that every member of the team understands the system flow and what it needs to be achieved in order to complete the work.
From the example above, the end-user wants to subscribe to the newsletter so that it can receive news through email. It’s a pretty straightforward goal to be fulfilled. Now, the first happy flow scenario as an acceptance criterion would be that, given that we have the form already and we enter our email and click on the button, we are successfully subscribed. The developers must ensure that the fields are working correctly. Back-end developers must work on the core functionality that will be executed in the background.
UX designers must ensure that the form would look like that one specified in the requirements by the customer. And the testers, of course, need to ensure that they cover as many scenarios as possible, positive and negative ones to gain confidence about the functionality as well as to determine if the user story can be close. Acceptance criteria can be written for functional testing (including positive and negative tests), as well as non-functional testing such as performance, load, reliability, etc.
Acceptance Criteria (Definition of Done) in test levels
Every test level has its own AC or DoD. In the table below, we can sum the most important criteria each test level should have.
- Unit Tests
- 100% full unit coverage
- All test automated
- Static code analysis performed
- No major defect or technical debt
- Quality characteristic like performance considered
- Integration Tests
- All positive and negative tests covered
- No unresolved major defect
- All test automated and part of the regression suite
- Defects reported and fixed
- Communication between all the units covered
- System Tests
- All e2e scenarios covered
- All quality risks are considered
- Regression tests are automated
- Testing performed on a staging environment
- No major defect left to be fixed
- All most important non-functional aspects of the system tested
Conclusion
Having a clear and defined set of requirements, e.g. Acceptance Criteria in agile projects allows every member of the team to clearly comprehend how the system should function, and testers having the knowledge to perform the needed tests against the system. The BDD format, being the most popular one for writing AC, clearly captures the behavior of the system from a functional and non-functional aspect. Either way, its content should be clear enough to be understandable by anyone.
Share This Post
Latest Posts
- Test Analyst’s Responsibilities in Risk-Based Testing
- Crucial Aspects Of Superior Test Code Quality
- Streamline Your Cucumber BDD Tests with Gherkin Lint: A Comprehensive Guide
- How to Test Authentication and Authorization with Confidence + Best Tips
- Exploring the Three Scrum Artifacts: Grasping Their Essence and Effective Utilization
