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 the requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. 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.

Not Paying Adequate Attention to Building Acceptance Criteria

This may sound an oxymoron. In this classic situation, the business analyst puts all efforts into writing requirements. But, validation of the solution is somehow gets missed out. Or, the onus of testing is on the testing/QA team. This leads to missing the business insight into the acceptance of the solution. 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.

Way out? Build 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 a mammoth task. As soon as you get into the habit of eliciting/writing the tests and the desired outcome, it will be second nature. Ensure you use a template for user stories with a section for 'acceptance criteria' in it.

Not Giving Enough Thought on Test Data

In this situation, the acceptance tests are well data. But, there is more emphasis is on the procedures. Less emphasis on the data needed to execute that functionality. Since each functionality 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.

Way out? Emphasize on 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.

Inadequate Traceability While Logging Defects

In this situation, you have started to find out the defects as continue to test the system. There is no or hardly any traceability maintained amongst various requirements though. Outcome? As you start to log the defects, it is very difficult to trace those their root. It is difficult to differentiate between a defect or an improvement. Further, there is a chain effect too. QA team and dev team needs 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 to build traceability at this stage.

Way out? Business analysts need to pay adequate attention to building and maintaining traceability. This will bring control over the scope (as well as scope creep). This will bring clarity as they log defects or improvements.

Well, there are many more aspects to it, I am sure this is a glimpse into the challenges involved.

Thoughts?