Working as a QA engineer, I try to optimize my time the best way possible. Even though sometimes it’s hard to handle multitasking, there are certain ways to get things done within a planned time limit that can help tremendously. In the Mews tech world, we use Agile, so we live by the rule of sprint.
Apart from planning, one of the tricks that help with time management is writing acceptance criteria (further AC) – conditions that verify that the to be developed feature completely satisfies the user story, or in other words, that the feature is exactly what the user wants. In the end, it’s all about the customer and how happy he is with the product.
If you are still thinking that acceptance criteria are a nice thing to have, here are six problems that arise and why I think writing AC is actually a great solution to use.
Problem 1. “I feel this one won’t take much time.” In practice, it does.
Solution: AC that define scope of the work to be done for the user story.
While a user story can be a one-liner or extensively determined in Gherkin syntax (more about it here), acceptance criteria outline the boundaries and make the expected amount of development more feasible. It is a common practice to discuss a feature that entails a bunch of questions, and that is where AC come into play, bringing in certainty to how much work is required.
Problem 2. “I thought it needs to do the opposite, no?” Not really.
Solution: AC that reduce ambiguity and clarify what needs to be done.
Apart from defining the scope, AC are meant to clarify the structure and help the team find common ground on how the features need to be designed and developed. Basically, the team working on the functionality has to fully understand what is required and how it needs to be done. It allows you to solve as many questions as possible before coding is started
Problem 3. “1, 2, 3…No, actually it is 1, 3, 2. Or is it 3, 1, 2?”
Solution: AC that help prioritization.
Going hand in hand with the Agile philosophy, it’s an absolute must to prioritize the backlog and, most importantly, to look through it regularly, which can be tricky. The team needs to make sure the prioritization remains up to date. In this case, AC serves as the means to determine priority, clearing out the scope and complexity of the issue.
Problem 4. ‘We have this issue in sprint, but does this help to achieve the sprint goal?”
Solution: AC that can defend against sprint creep.
Scope creep, also known as sprint creep in Agile, is the uncontrollable expansion of the project scope, which eventually leads to overdue/broken deadlines. As the result lowers the quality of the product, this is something that can break the heart of any QA. Not all unplanned issues are scope creeps, but it’s essential to understand the capacity you have for any unplanned issues. Coming back to the first point, the better you define the scope of the planned work, the better you understand how many more ‘extras’ you can accommodate within the sprint. And for this, AC is exactly what you need.
Problem 5. “Where do I derive tests from for this feature?”
Solution: AC that are the best source for writing acceptance tests.
The dedicated person (in Mews – the QA) writes AC and based on them, creates acceptance tests – not a draft, but a full list of tests to be sure that everything is checked and good to go for the release. Acceptance tests are not just a list of test cases – they are a result of the detailed decomposition of a task. The ideal scenario is when, after writing these down, you have a complete sense that there’s nothing else to discuss.
Problem 6. “Do I have enough time for this? I would have known better if…”
Solution: AC that save you precious amounts of time.
Last but definitely not least, AC save you a lot of time. Instead of having a superficial impression or ‘feeling’ of how much time or effort a feature is going to take, it is best to have a predefined set of AC that explicitly show what needs to be done.
Conclusion
Acceptance criteria can be valuable to save you time, and they are also valuable to elaborate user stories. Nothing can compare, however, to a good discussion involving different parties. So, it doesn’t mean that AC should serve as a substitute for another catch-up meeting, nor does it mean that AC should look like documentation specifying each little detail. AC are primarily used to point out the key bullet points that make the team closer to attaining the desired result much faster and easier.
I like looking at the acceptance criteria as small goals that need to be achieved. If you feel the same way or have any questions about how acceptance criteria make a QA life easier, don’t hesitate to contact me. I’ll be happy to chat.
