Back

Quality Assurance

Developers may not always fully test features, so QA technicians put the software through the wringer. For QA, acceptance criteria are the golden standard of how a software should behave. If there are any deviations between what should happen and what does happen, that acceptance criteria cannot be checked off. However, there is also the problem of “what” versus “how.” QA must be able to ignore the how, and strictly focus on whether the current version of software meets what the stakeholders have stated that it should do. This includes obvious use cases, as well as edge cases that many other members of the Scrum team might overlook.

Effects of Acceptance Criteria on Agile Process

In addition to individual roles of a Scrum team, acceptance criteria change how certain parts of the Agile process are handled. Knowing what counts as fulfilling stakeholder requests plays a part of every stage of Agile software development

User Stories

As an example of what a typical user might do, user stories use acceptance criteria as building blocks. These building blocks can then be seen as a sort of checkpoint. Acceptance criteria are usually very specific. This is great for deciding whether one particular requirement is actually finished. However, the average user is typically going to do much more than that one specific thing. Even if the user is attempting to do what seems like a single thing, it may take multiple tasks and steps. Therefore, user stories may comprise several acceptance criteria. This helps break down where things might not yet be finished. It allows QA to say, “I can do parts X and Y of user story A, but criteria Z is broken.” Then, the developers know exactly where the problem begins.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course:

Translate »