What is Acceptance testing and how can it help with your Agile 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. Only what is known as the Minimum Viable Product is left. The Product description is then slowly broken down into User Stories. User Stories are the simplest expressions of a User’s Requirements at the most granular level.

Every User Story has a set of Acceptance Criteria which are defined by the Product Owner. These Acceptance Criteria are based on their experience and understanding of the Organization and how it runs. The Acceptance Criteria are described to the Scrum Development Team during the Sprint Planning Meeting. The Scrum Development Team are responsible for drawing up the Tests for Acceptance in accordance with these Criteria.

Acceptance Testing: Creating Test Cases

It is never too early to begin specifying Testing. The minute you have the Requirements and the Acceptance Criteria, you have everything you require to design your Tests. An excellent time to begin with the Test Cases is at the same time that you are writing a User Story. The Customer is thinking about his Requirement (as the User Story states: “I Want …”) and has clear expectations of what would produce an effective 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 Software Development Life Cycle Development as well as Agile.

Performing Testing of User Stories

The technique you will utilize to Test User Stories is partially dependent 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 enhances the Program logic and Tests Iteratively until all the Code is composed 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 that phrases the Testing in terms that make sense to the Customer/User, rather than just the Development Team. This works because the Customer base has a much better understanding of what is being Tested and whether it fits their expectations.

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

There are numerous Automated Toolsets that are appropriate for these types of BDD Frameworks.

Acceptance Testing and Test Frameworks

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. The fact that a portion of Code Worked in an earlier Test run does not mean it can be left out of the Testing – the most current changes to Code may impact earlier Code. This can happen even if the relationship between the two is not evident.

Apart from Testing a User Story, it is also essential to Test all the Stories finished to date within a Sprint, to ensure that mistakes have not crept in. If there are dependencies on Code written during previous Sprints or there are several Scrums, it is essential to perform 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 basic Principles of Agile, and particularly Scrum, do not differentiate between Scrum Team members’ (Agile Scrum Master, Scrum Product Owner, and Scrum Development Team) capabilities and skills. A Team member may be called upon to Code one User Story and Test Code for another Story. Another practice that is often used is “pairing”, where 2 Team members deal with a User Story, sharing the Coding and Testing Responsibilities, specifically when applying TDD. This tends to increase Velocity of a Sprint. This is due to the continuous Collaboration between the 2 Team members. Paired Testing is normally more efficient, since one person may get a possible point of failure which a Developer Working in isolation might miss out on. This could be because they composed the Code in the first place, and might have a blind spot with regard to their own Code problems.

Bringing the Customer in while performing Testing will also help. They will have the ability to quickly identify if the Code to be Delivered is not matching expectations. They might likewise find that the initial specification is not what they Required and can request Changes. Although Users are exposed to the latest Code during the Sprint Review, there is no harm in being proactive and including them prior to the Review.

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

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

Acceptance testing: Testing Disciplines

Acceptance Testing generally Tests the functions of a User Story from a Customers point of view. However non-functional Testing might likewise be part of the Acceptance Tests. Non-functional Testing looks at issues such as security, action time and performance. With the ever-growing rise in cybercrime, Security Testing needs to be done more often. Preferably security Features need to be embedded into the User Story Development and not added on later on.

Testing has always been the bad relative of Development in Traditional Projects. If the Project Manager required to find extra time, the first activities to be Cut would be Testing. Using Frameworks such as TDD guarantees that this can not happen in Agile projects. There is an agreed standard of how an Application should Work, as revealed by the Acceptance Criteria. The Delivery of Quality (i.e. defect-free Software Working according to requirements) is what Agile promises. This can be achieved with comprehensive Testing.