Most Agile frameworks express customer requirements using simple and lightweight methods, such as User Stories. These stories represent features that reflect customer needs and are small enough to allow developers to implement a set of them at each iteration (or Sprint). A story must be understandable to all members of the team, testable and valuable to the client. Testable in this context indicates that every story must include the acceptance criteria to ensure that the functionality has been implemented correctly and meets customer needs.
To achieve this goal, the client is responsible for writing Acceptance Tests for each story. Acceptance tests are created by the user because they know the business deeply and therefore know the what objectives are most important. Acceptance tests lightly describe and in the business language a set of concrete usage examples that serve to determine if functionality has been implemented correctly and meets customer’s explicit and implicit expectations.
Acceptance tests are built from system usage situations, establishing input, output, response time, and so on. The purpose of this type of test is to ensure that the system is able to perform the agreed functionality in the desired way and hence guarantee the quality of the product being developed.
Automating the execution of acceptance testing is possible. Many market tools are available for this. However, it will not be the scope of this article to describe any of these tools. In this way, the tests can be played automatically, without the need for a person to perform all the steps manually each time they have to retreat a feature. It is worth remembering that, automated or not, acceptance tests must support customer-designed test cases, because only the Product Owner can decide if the functionality is suitable for use.
Testing from the customer perspective
Importantly, the acceptance test described by the client is one of the criteria used to determine if the implementation is complete for the story (or requirement for traditional development approach). That is, the story is “ready” only when the acceptance tests run successfully. Kent Beck, creator, and disseminator of Extreme Programming (XP) categorically states:
Stories that can not be demonstrated through testing simply do not exist.
As far as the acceptance tests are run, there is no absolute consensus, but they can be executed by the developer, by another developer, by a tester, or even by the client. On the other hand, Agile methods advise that the tests be executed whenever possible by automatic means to enable short delivery cycles and continuous feedback, which is why developers often automated acceptance tests using specialized tools.
The client-side test complements the description of the story, providing additional definitions about the expected behavior of the feature. Also, when acceptance tests are automated, it acts as a quality guardian, alerting the team when software stability is violated due to side effects or defects.
The Acceptance Test involves a type of test called “Black box test,” where the importance of the test lies only in the result obtained. If the system presents the expected response for a particular input, that part of the software may be considered valid. It is important to emphasize that as important as testing the normal operation is also to test the situations in which the system should present an error or prevent a user action. If the product responds correctly to a valid entry, it does not mean that it will respond negatively to an incorrect value. It is up to the Product Owner to prioritize which operations are most important in the system and which input possibilities to test.
In Agile methods, we use this type of test for every portion of functioning software delivered to the client. This way, we can guarantee that all the produced features are according to the client’s request and the rework is avoided. Once development for a User Story is complete, it will be in full agreement with the customer needs.