Acceptance criteria in software testing are so important – what happens when they are not there or are incomplete?
QA testers may have experienced this at one time or another: a user story, feature or bug fix with a one to five word description and no details, expected results, results expected, acceptance criteria, or any sort of useful data to figure out how to fix it, let alone create a valid test case for it.
If you’ve been in QA long enough, you’ve had your share of it. Void or insufficient detail is independent of the methodology and can occur whenever such slippage in the protocol is allowed, i.e. whenever it is not part of a governmental or regulatory change. . In other words, these issues arise when there is no significant trade penalty for failing to change. How many hundreds of defects have escaped due to missing acceptance criteria in software testing?
I would estimate that at least 50% of defects delivered to customers are the direct result of inadequate or completely missing descriptions and acceptance criteria. Many groups use Agile as an excuse for sloppy documentation of software changes, claiming it’s meant to be flexible. I would say that The flexibility of Agile lies in its ability to modify a non-working design on the fly and not have to completely recreate new functionality from scratch because the description and acceptance criteria in software testing were missing or invalid.
As a QA tester, how do you fill in the gaps? You need valid test cases. My first suggestion is to meet the developer responsible for coding the change. Find out what they think the requirements are, as well as the desired outcome. Build your base test cases around the developer’s understanding of the change, because that’s how it will be coded.
Then take a step back and imagine how the change will fit into the existing software. List other areas that may be affected, where mail connections may fail, and where database backups occur. All of these are potential points of failure. It is critical for customers that QA uncovers all possible points of failure in the developer’s coding.
Finally, meet the product manager. Find out the business intent and see if there are any disconnects. To be even more effective, invite the developer and make him speak. If the developer or QA can demonstrate the change as coded so far, or demonstrate a prototype, you’ll likely get new or undocumented requirements from the product manager.
Why? This is the nature of human communication. We all interpret things to suit our needs, and those needs create different understandings. The QA team member should note the discrepancies and lead the conversation to ensure that what is coded is what the customer expects.
Closing the understanding gap and meeting acceptance criteria in software testing are essential goals to ensure quality software is released with fewer bugs. They also make customers much happier.