Writing foolproof acceptance criteria as a Business Analyst

Ever wondered how to write foolproof acceptance criteria? Or even wondered what a business analyst can do to ensure that requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. A business analyst plays a key role in defining the tests around it. The acceptance tests can be at various levels of requirements detail. Starting from high-level requirements to detailed requirements. Let’s take a look at common challenges involved in this part of the world, along with a few ideas to overcome those.

This may sound like an oxymoron. In this classic situation, the business analyst puts all their efforts into writing requirements. But, validation of the solution somehow gets missed out. It’s either that or the onus of testing is on the testing/QA team. This leads to missing the business insight into the acceptance of the solution. A business analyst collaborates as a bridge between domain SMEs and implementation SMEs. It is important to think like a business user while writing an acceptance test. If this perspective is missing, it may lead to several bigger issues in later stages.

So, what’s the way out? Start by building business and end user-centric acceptance tests. Break the steps into smaller atomic parts. Think about the ‘minimum’ steps to test. Think about what exactly their outcome will look like. At first, if these practices are not being followed, it may sound like a mammoth task. As soon as you get into the habit of eliciting/writing the tests and the desired outcome, it will become second nature. Ensure you use a template for user stories with a section for ‘acceptance criteria’ in it.

In this situation, the acceptance tests are, well, data. But, there should be more emphasis on the process, and less emphasis on the data needed to execute that functionality. Since each function is unique, it does need the right kind of test data. In the absence of adequate test data, several issues may crop up as ‘real data’ comes in.

So, what’s the way out? Emphasize data preparation as part of your business analysis acceptance testing activities. Sometimes you may be able to prepare for the data on your own. Whereas sometimes you may need to seek help from other teams for your data preparation. Going back to the basics of testing, see if and how you can make the system break. Use the procedures in the test case to drive the data preparation. Also, consider if you can reuse this test data over the long term.

In this situation, you have started to find defects as you continue to test the system. There is no, or hardly any, traceability maintained amongst various requirements though. The outcome? As you start to log the defects, it is very difficult to trace their root and it is difficult to differentiate between a defect or an improvement. Furthermore, there is a chain effect too. The QA and dev teams need traceability to analyze the impact. In essence, the root cause is trace issues. It is cropping up as you start conducting your tests. And it is late in the game to build traceability at this stage.

So, what’s the way out? Business analysts need to pay adequate attention to building and maintaining traceability. This will bring control over the scope (and help manage scope creep). This will also bring clarity as they log defects or improvements.

There are many more aspects to it, but this is a glimpse into the challenges involved.

Thoughts?

Swati Pitre, CBAP®, is a Sr. Business Analyst with 20+ years of industry experience across various domains and geographies. Her specialties include Product Development, BPM, Process Improvement Consulting, Business Analysis/CBAP®/ CCBA®/ ECBA® Training.

Image Credit: pixabay.com

Related posts:

I discovered a neat trick that greatly reduced the time I normally spent to switch between my open apps. Additionally, it helped me organize everything so that finding a specific app is just a…