How does Acceptance Criteria help with the testing of User Stories? One of the main reasons for the growing popularity of Agile Project Management is the ability to meet Customer expectations. This is done firstly by stripping the proposed Product down to its essentials, leaving only what is known as the Minimum Viable Product. The Product description is then gradually broken down into User Stories, which are the simplest expressions of a User’s Requirements at the most granular level. This is Done either by the Product Owner or under his care by members of the Agile Team. In order to match the Customer’s expectations, every User Story has a set of Acceptance Criteria. The Acceptance Criteria are defined by the Product Owner.. The Product Owner explains the Acceptance Criteria to the rest the Scrum Team (Scrum Master and Development Team).

The Right Time for Creating Test Cases

It is never too early to begin defining Tests. The minute you have the Requirements and the Acceptance Criteria, you have what you need to design your Tests. A good time to start creating the Tests is at the same time that you are writing a User Story. The Customer is thinking about his Requirements (as the User Story states: “I Want …”) and has clear expectations of what would produce a successful result in his eyes. Those expectations translate into the Acceptance Criteria and how you will Demonstrate that you have satisfied those Criteria. To start specifying Test cases after Development is far too late. This applies to Traditional SDLC Development as well as Agile.

Testing of User Stories With Acceptance Criteria

The technique you will utilize to Test User Stories is reliant on the Test Framework your Company or Project uses. For instance, if you are applying Test-Driven Development (TDD), the Test logic is Coded before the Program logic. The first Test in a TDD cycle is expected to fail, because it is run without any data or Code. The Developer then augments the Program logic and Tests Iteratively. They will do this until all the Code is written and runs through the Test Framework successfully. TDD tends to be quite Technical and Code-related, which is why some Companies prefer BDD.

Business-Driven Development (BDD) is a Testing Framework. This Framework phrases the Testing in terms that make sense to the Customer/User, instead of the Development Team. This is useful because the Customer base has a much better understanding of what is being Tested and whether it fits their expectations.

There is likewise ATDD – which is Acceptance Test-Driven Development. This is a mix of TDD and BDD, and is focussed on meeting the Acceptance Criteria. The Test cases are more technically-oriented than BDD, but still are transparent enough for Customers to understand and assess.

Acceptance Criteria & Automated Toolsets

There are quite a few Automated Toolsets that are appropriate for these types BDD Framework.

Whichever Framework is selected, the next question is how many Tests should be run and how frequently? The answer is as many as it takes. This is why an Automated Testing option, or at least a Test Script is necessary, because the Testing is Iterative and Regressive.

A portion of Code Worked in an earlier Test run does not mean it can be left out of the Testing. The latest changes to Code may affect earlier Code. This can occur even if the relationship between the two is not obvious. Apart from Testing a User Story, it is also essential to Test all the Stories finished to date within a Sprint. This ensures that no new mistakes have not crept in. If there are dependencies on Code written during previous Sprints or there are numerous Scrum Teams, it is required to conduct Regression Testing for all completed Code. This is why Automated Testing is Required in order to reduce the Testing overhead where Manual Testing is Done.

Duty for Testing

The general Principles of Agile, and especially Scrum, do not differentiate between Development Team members’ abilities and skills. A Team member might be called upon to Code one User Story and Test Code for another Story. Another practice that is frequently utilized is “pairing”. This is where two Team members work on a User Story. Thy share the Coding and Testing Responsibilities, and is often used in conjunction with TDD. This tends to increase Velocity of a Sprint, thanks to the Collaboration between the 2 Team members.

Paired Testing is usually more effective. This is due to the fact that one partner of a set may select a potential point of failure which a Developer Working in isolation might miss out on. This is because the developer that composed the Code might have a blind spot with regard to his own Code defects. Bringing the Customer in while carrying out Testing can also assist. They will be able to get feedback quickly if the Code to be Delivered is not matching expectations. They might likewise discover that the original specification is not what they Required and may ask for Changes.

We found these books great for finding out more information on Agile Scrum:

Users are exposed to the product developed to date throughout the Sprint Review. There is no harm however in being proactive and including the users prior to the Review. This is a choice for the Scrum Team.

While we have actually been focusing primarily on Acceptance Testing and Functional Testing here, we also wish to look briefly at other Testing disciplines that may be Required to Deliver the Product as defined.

Acceptance Criteria & Testing Disciplines

Acceptance Testing typically Tests the functions of a User Story from a Customer point of view. However non-functional Testing could likewise belong to the Acceptance Tests. Non-functional Testing takes a look at concerns such as security, action time and performance. With the ever-growing increase in cyber-crime, Security Testing should form part of Acceptance Testing. This enables the team to examine whether vulnerabilities have actually sneaked in as new Code is Developed. Performance is likewise crucial. The most perfectly defined and Developed Application will stop being used if it is too sluggish or can not handle the required number of concurrent Users.

From a Quality perspective, Load and Performance Testing must be performed a minimum of once per Sprint, if reaction time or a large User base belongs to the Requirement. Security Testing should be done more regularly – ideally security Features must be embedded into the User Story Development and not added later on. If your Company is considering relocating to a DevOps culture this is especially essential – security is Fundamental to DevOps, and is in some cases referred to as DevSecOps.

Testing has always been the poor relative of Development in Traditional Projects – if the is Project Manager required to discover additional time, the very first activities to be Cut would be Testing. Using Frameworks such as TDD ensures that this can not occur in Agile, and that there is an agreed standard of how an Application need to Work, as expressed through the Acceptance Criteria. The Delivery of Quality (i.e. defect-free Software Working according to specification) is what Agile promises, and this can just be attained with comprehensive Testing.