Software design:
You are developing a function for a website. Let it be a simple login form. Since you are an excellent developer, you decided to do some basic planning before you start designing. At the very least, you want to define some aspects of the function you are about to create.
Here’s what you need:
Input fields for usernames and passwords
Submit button
A way to inform the user if he entered his data incorrectly
Forgotten data recovery method
The method for registering an account if the user does not already have one.
Even simple functions can be tricky to develop. Already, you have listed five things you want to track. And, perhaps, this will not stop there. It’s reckless to rush into feature development without proper planning, but you know it and wrote the checklist above.
So is that enough?
What if you want to write something like a behavioral test? How do I translate what is written above into user steps? And is this short tagline approach enough to tell you how the user actually performs these actions? Have you ever thought about what’s going on after of how the user successfully logged in? Does this approach help to think in this way?
We know, what we need but as translate it into a well-designed function?
You can probably guess what the answer will be: these are the acceptance criteria.
What are Acceptance Criteria?
Acceptance Criteria is an unnecessarily vague name for a set of steps that describe how a user can interact with a particular feature. They are written in a format using the Given, When, and Then steps and are mapped to user actions. This makes it easy to convert them into behavioral tests. Designing a function this way is also a great way to identify other things that might be needed to make it work.
An example of acceptance criteria for your login form might look like this:
Given I have an account registered with <app>
And I am viewing the login form
When I enter correct login details
Then I should be logged in
And I should see the homepageGiven defines some kind of precondition for performing an action. When defines the action. Then defines the result of the action. We can also use And to complement any of the stages by adding additional conditions. This approach is logical, straightforward and simple. Each of these stages explains exactly what should happen in the script.
We can also easily write a behavioral test for this because we know exactly what attitudes, actions and results will be involved. There is a prerequisite for the test: the user must have an account. There is an action: the user clicks on the login button. The result is also known: the user is logged in and views the home page.
This AC also gave us some additional information. While writing it, I realized that I don’t know what will happen after the user successfully logs in. Formatting this requirement in this way got me thinking about it, which contributed to the development of the product design and user experience.
Finally, because of this formatting, AC encourages you to think more logically, and by using Then, it ensures that you think carefully about the results of user actions. It forces you to take care of how the user will experience the application, not just what wonderful things you would like to do.
How to write a good AC?
So you’ve decided to write this product, but how do you get it right? The above login function is very simple, but more complex concepts can lead to confusion in AC, so it is important to keep the following things in mind:
1. Write from the user’s point of view
This is rule number one. Acceptability criteria are not at all about how you, as a developer, might interact with something. And not about how you are want toto have someone interact with something. You need to imagine yourself as the most stupid and annoyed creature on the planet – user… Because he will be the one who will tinker with your “wonderful” login form.
2. Simplicity
AC should be easy to understand. Try to match each line to a specific user action or prerequisite, such as entering the correct user details or already being registered with the application. A long AC string that tries to accommodate several things can affect clarity and thereby negate many of the benefits mentioned above.
3. Understandable language
This point is related to point 2 and directly affects it. Write AC in plain language. One of the main advantages of this approach is that it can be understood by non-technical people. A tool capable of describing a feature to any person and managing implementation / testing at the same time is invaluable. A complicated language will hinder this.
4. Don’t focus on implementation details
AC should describe how the user interacts with the function; no need to explain what the function looks like or how it works from the inside. The way something is implemented can and will change much more often than the idea itself. Logging in is common, but the color of the submit button or which authentication provider is being used is rather vague in this case.
5. Don’t be techies
And again this point is related to the previous one. Don’t mention algorithms, machine learning, or the fact that mitochondria are the energy source of the cell. This is irrelevant.
Is AC enough as such?
No, this is just a starting point. It will guide your design, communicate your vision, and aid for testing, but that’s not all and not always. You should write subtasks to better define the technical aspects of your functions, create mockups, and write specific examples. All of these things are important and valuable and should be used, but nevertheless, well-written acceptance criteria are a solid starting point, and if done correctly, the result is always better software quality.
The translation of the material was prepared as part of the course “Systems Analyst. Basic “… If you are interested in learning more about the training format and the course program, we invite you to Open Day online.
