In Agile, developers, testers, and business analysts build a working product through a series of short iterations. At the end of each iteration, the product owner accepts the software as working or not, and the team moves forward to the next iteration. This kind of acceptance is not the same as the User Acceptance Testing (UAT) traditionally done at the end of the development effort. Unfortunately, traditional UAT does not fit neatly into Agile. This often represents a missing link that causes significant pain for those implementing Agile. In this blog, we discuss how to solve this problem.
The Need for User Acceptance Testing (UAT) in Agile
The Agile Manifesto contains no mention of user acceptance testing (UAT) or testing of any kind. However, the overarching objective of ‘working software’ implies testing of some sort, but what kind of testing and by whom?
When businesses define their requirements, it is assumed that developers and QA will design and implement software to meet all defined business requirements. In implementing Agile, however, the aspect of quick iterations often limits the level of detail provided leading to some business requirements being misunderstood.
Figure 1 below illustrates how “uncertainty” can rise through the software development cycle. In the beginning, if End Users are not clearly defining their needs, some clarity can be achieved through early pre-kickoff communication. However, as the development progresses and more people become involved in the communication cycle, the connection between “business needs” and the software’s capabilities becomes less clear. Each “filter” role introduces some uncertainty in the communication of thoughts, definitions, and outputs. The accumulation of “uncertainty” manifests in defects. For Agile, the question is where should UAT take place? And how can it be inserted or fit into the process without an extra dedicated iteration?
Modifying UAT for Agile
In an Agile environment, iterations move quickly forward until the final software release. Unless there is a sprint or iteration planned as UAT, it just won’t happen. To tackle this issue, we’ve developed an approach for implementing UAT through methods that can be modified to each organization’s flavor of Agile.
Let’s start by examining UAT objectives in order to better understand and define what UAT is. UAT should identify gaps between how an application works (as coded) versus how it was and is expected to perform by users in a business environment when executing their required tasks. From a user’s perspective, the needs, requirements, and associated business workflows within the software have been successfully implemented.
The common thread of UAT is satisfying requirements with minimal defects. With Agile, requirements are now part of each iteration and are expressed in the form of user stories and acceptance criteria.
To successfully achieve the goals of UAT, User Acceptance Testing must be emphasized such that requirements become User Stories. User Stories in turn, should be coupled with acceptance criteria and acceptance tests that are then integrated within each sprint or iteration as shown in Figure 2.
User Stories in Agile – The Basis of UAT
While there are many formats and examples of what User Stories should or should not be, their purpose is to add certainty to what software can and cannot do. As a general guideline, User Stories address the following:
- Describe an objective that a user should be able to achieve or a feature that a user should be able to utilize when using a software application.
- In simple language such that a customer or end-user would know without ambiguity what the expected outcome is.
- May reference other User Stories or design documents to provide details, but should not repeat.
User Stories must be accompanied by Acceptance Criteria. Acceptance Criteria should:
- State intent, but not a solution, and should be independent of the implementation and platform.
- Be comprised of a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of the project.
- Represent “conditions of satisfaction” with no partial acceptance: Yes or No, Met or Not Met, True or False.
- Define the boundaries and parameters of a User Story (i.e., feature) and determine when a story is completed and working as expected.
- Be easily translated into one or more test cases.
Acceptance Criteria need to be accompanied by Acceptance Tests. These tests are specifically tied to the criteria and if the criteria are written unambiguously with clear pass/fail results, the acceptance tests are merely an implementation of the criteria particular to the related story. Acceptance Tests should be reusable and automated whenever possible.
Implementing UAT in Agile
In Agile, traditional UAT that occurs at the end of development when the product is about to be delivered has been swept aside. However, that doesn’t mean that we ignore it or can’t accomplish the objectives of UAT within Agile. Rather, we need to consciously and purposely emphasize the many aspects of User Stories as we’ve described here in this article, namely:
Discipline: User Stories must be groomed on a regular basis. This means revisiting them and adding detail at the right time. Therefore, User Stories should be done for the current and next sprint, but not much farther out in advance. As new knowledge is gained with each iteration, expect that existing User Stories may need further modification.
User participation: User Stories should get user participation and input where the product owner or business analyst, developer, and tester meet to discuss each user story and whether or not there are sufficient detail and clarity.
Communication: User Stories need to be communicated up, down and across the Team with a well-defined communications plan.
The Agile Manifesto contains no mention of user acceptance testing (UAT) or testing of any kind. However, the overarching objective of ‘working software’ implies testing of some sort, because iterations move quickly forward in an Agile environment, unless there is a sprint or iteration planned as UAT, it just won’t happen. The challenge, as such, is that traditional UAT does not fit neatly into Agile. The common thread of UAT is satisfying requirements with minimal defects. With Agile, requirements are now part of each iteration and are expressed in the form of user stories and acceptance criteria. To successfully achieve the goals of UAT, User Acceptance Testing must be emphasized such that requirements become User Stories. User Stories in turn, should be coupled with acceptance criteria and acceptance tests that are then integrated within each sprint or iteration. User Stories can form the basis of UAT that is baked into Agile without having a separate UAT phase. It requires proper attention to User Story detail, at the right time, by the right people and making sure that the entire team is cognizant of their meaning and intention.
Leave A Comment