In my years of testing one of the most important things I have identified is Acceptance criteria. Unfortunately, I have seen too many projects focus on what they think is right, rather than what was agreed and defined in the Acceptance criteria.
What is Acceptance Criteria? Acceptance criteria is the agreed conditions that a software program should meet to be accepted by a customer or stakeholder. It defines what is acceptable by the program to insure quality.
Typically, this acceptance criteria is broken down into 3 areas, functional, non-functional and performance. If you have been around in testing for a while, or been looking for testing jobs, its likely you have heard of these terms before.
Quick Navigation
Shop Now
Functional Criteria
As the name suggests this breaks down the functional areas, such as “A User Login”. This is a specific function of the system that will have acceptance criteria, such as, once a valid password and user name is provided, the user will gain access.
Non-Functional Criteria
A good example of non-functional is the design and layout of a corporate website. This is different to a functional module I this sense. So, if we extend the example of the corporate website, you may want your site to follow your agreed brand colours. Therefore, a non-functional criteria item could be verifying this has been met.
Performance Criteria
Performance is different to functional. It focusses on certain agreed performance metrics for the software. For example,
“The system must load the contacts page within 10 milliseconds”.
Or
“The system must be able to support the load of 100 simultaneous users”.
These are just quick examples to make sure you understand what I a mean, they are not the perfect example of a well drafted user story.
What is the difference between an Acceptance test & Acceptance Criteria?
Acceptance criteria, done correctly, should not explicitly state how to technically do the solution. It should clearly state the intention. For example, it shouldn’t say to authorise the invoice, the supervisor must click the “A” key. It should be saying; a supervisor can authorise an invoice.
In other words, it should not be biased to any form of implementation. The design and execution of the test is different, this is more for an acceptance test.
Acceptance Tests, on the other hand are tests to prove that the acceptance test criteria has been met. In agile, they are typically derived from User stories. These tests are usually conducted by the actual user. Which is different to unit tests, for example. Because Unit tests are usually ran by developers.
These tests are also referred to as “black box tests”. Reason being, the user looks at the tests at a high-level functional level, without any need to understand the coding conditions and interaction between modules.
White box tests (Click here to see which white-box testing technique is best), such as unit testing on the other hand, focus on how each code module interacts together and focuses on the inputs and outputs of the modules.
How is Acceptance Criteria used for Agile User Stories?
Acceptance Criteria is closely tied to a User Story. The user story will prove if the Acceptance criteria has been met. This is why it is important that the criteria is clear with an obvious pass or fail. In other words, it should not be subjective or ambiguous.
Think of the Acceptance criteria as the foundation of your house. If they are not sturdy, the whole development project is doomed!
In Agile The user stories are created to prove that the criteria has been met. Following on from this, Acceptance tests are created to prove that the user stories have been implemented. This can be manual or automated tests, that choice is down to the team or business.
Test Estimation and Acceptance Criteria
Once the criteria is defined it is possible to group the user stories in to modular tasks. Once this is done then this will help to plan and estimate testing activities.
Who Actually Creates the Acceptance Criteria?
This task is usually done by the customer or stakeholder. However, the process involves close collaboration of the project team to review, agree and refine the requirements.
This review and collaboration is important because, whilst the customer knows what they like, they may find it hard to define this within a framework that can be used to code or test. For example,
Saying things like: “The system should load fast”
This statement is not a useful or useable Acceptance criteria. Because it doesn’t define what “fast” is. Believe it or not, fast can mean something completely different for each individual in a project team. If we use the house analogy again, if you asked your builder to create a “Big House”, you could be thinking a 6 bedroom detached, he could thing a 3 bed semi, with large double rooms, are you with me?
So, this is why they are reviewed and defined.
Related Questions:
What is an acceptance criteria format? One of the most common formats for acceptance criteria is the “Given when then” format. It makes it easier to define it. Like most things it’s easier to explain with an example:
Given [a certain pre-condition], When I do some type of Action, Then I expect this to happen
This is quite an easy format to follow for any given scenario you may have.
How can Acceptance Criteria Benefit the Project? It is very easy for a project to go over time and over budget. But with the use of a well-defined criteria it can help the development stay on track and focus on what needs to be delivered.
What is an example of an Acceptance story? If we use a banking application as an example. You may have the following acceptance criteria:
“The users bank statement cannot be displayed if an unknown bank user ID is provided”
This criterion may be accompanied by this User Story:
As a Bank User
I Can See My Bank Statement
So that I know how much funds I have
Dos and Don’ts for creating Acceptance Criteria? : To make life easier here are some do’s and don’ts to create your criterion:
- Do: Always create it before development. Don’t get fooled into thinking you can start development and then mould the criteria around what you have created. The idea is to the let the criteria guide you, not the other way around.
- Do: Always make sure that each item can be tested independently. In other words they must have a pass or fail scenario.
- Don’t make any item focus on the end solution. The acceptance criteria should be focussed on the “What”, not the “How”. Meaning you should be focussed on the end result that could be solved in many different ways using any software solution.
- Do include functional as well as non-functional criteria. As explained earlier, both of these are equally as important.
Conclusion
Hopefully this has helped you to understand What acceptance criteria is and more importantly how you can use it for your agile project in the near future.