Engineering

QA as a strategy: user stories and the importance of acceptance criteria

What is acceptance criteria (AC)?

In software development, Acceptance Criteria (AC) are the conditions that a product must satisfy to be accepted by a user. These conditions include statements and rules that clearly indicate pass or fail results, and that specify both functional and non-functional requirements. At their core, AC is used to confirm whether a product is complete and whether it is working as expected.

Why use AC?

Simply put, to create products that end users will love using. AC allows us to define the right user features, and help with the following regarding those features to help:

  • our clients define what they require in a certain feature
  • clear up any vagueness about the requirements for the feature
  • the team gain a shared understanding of a feature
  • developers implement the required functionality of a feature
  • developers and testers test the feature correctly

When all the acceptance criteria are met, the feature will be fully implemented.

For example:

AC: In the “Ship Request” page, the user selects “Add More” and is taken to the “Ready to Send” tab to select more packages.

AC: When the user is taken to the “Ready to Send” tab, the existing packages they have selected will continue to be checked. User can select/deselect additional packages.

AC: Once the user returns back to the "Ship Request“ page, the default options will be populated. Any previous changes will not be saved.

Who should define AC and when? 

Questions always arise when AC is being defined about who should do it and when. Can we add more AC for additional features as we go? How do we know if they are correct and valid?

As far as the "who" is concerned, the first role that comes into mind is the product owner. A common responsibility that falls within the product owner role is, in fact, defining acceptance criteria for each user story. The product owner is the person that represents the customer defining all of the desired features of the end product. But is that the best way to do it? Should only the product owner be responsible for AC interpretation, formation, and fixation? Logic dictates that whoever ultimately sets AC has to have an understanding of what end-users need, and how this can be designed, implemented and tested. So, if you want to help your product owner, everyone needs to be on the same page on what has to be implemented, how it can be implemented, and how it will be tested. 

At Devbridge, we assemble a three-person team, consisting of either a product owner or business analyst, developer, and a quality control analyst. This team analyzes already written AC and add new criteria from their viewpoints. The success of the product depends on the whole team that is working on the product. We all have our responsibilities, but if we want to implement a successful product, we have to work as a real team, which has the same purpose and understanding. Treat AC as the responsibility of the entire team. Then, we end up avoiding many unnecessary questions throughout the process.

Now, onto the "when". AC must be written before the implementation is started. That way, the product will be implemented as it was described. Otherwise, the acceptance criteria will be formatted for already implemented functionality in order to verify that it works. However, it is really quite difficult to have a final list of correct AC from the beginning. As they say, "if you go deeper in the forest, you will find more trees". The same applies to software development. After the development process has started, more things become clear: developers have a better understanding of what they cannot implement as expected.

To fix this, we started to organize really productive pre-refinement meetings. Team members gathered and analyzed user story descriptions, attached designs, and examined written acceptance criteria. If something was not understandable for us or a resolution or implementation was unexplained, we made notes. In that way, we noted everything that was important for front-end developers, back-end developers, and testers. When we had refinement meetings with our PO, designers or clients, we asked these questions, analyzed how things could be implemented, and what way would be the best. After these meetings, our AC lists became more detailed and more accurate.

For example:

Front-end developer

AC: The header should stay fixed in more transitions.
AC: Once the user goes into profile view, the "Home" icon should morph into an arrow.

Back-end developer

AC: "Ready to Send“ is the default tab that is displayed when the user selects "My Suite" or gets redirected to this page.
AC: Tables are sortable by clicking links in the header (From and Date Received). One column at a time (cannot sort on multiple columns at a time).

Tester

AC: Required fields: First Name; Last Name; Account Type Name; Country; State (if a country with states is selected); Address; City.
AC: Length validation for:

First Name - max 35 characters. No numbers or special characters allowed.
Last Name - max 35 characters. No numbers or special characters allowed.
Account Type Name - max 25 characters, numerical and English alphabet. No special characters allowed.

Determine success

In order to create a successful product, the entire team has to work as one. Having the same understanding of what has to be implemented, how it has to be implemented, and how it has to be tested is the best way to justify the client's expectations. The AC list, which was defined in a user story, is the most useful way to reach that goal. How those criteria are formed, expanded upon or updated, depends on the team. Every team has to find its own way of working together. If you find that way–you're pretty much guaranteed success.