How do I create a test case based on requirements documents for user acceptance testing?

Creating user acceptance tests out of basic software requirements documents can be a daunting task. Expert Mike Kelly points out logical approaches testers could try in this tip.

I've been tasked with creating user acceptance tests and I need some advice about the best way to do this. Can...

you give a simple example of how to create a test case from a requirement?

While your question is a good one, there's not really an answer for it. There's no magic formula for creating a test case from a requirement. The tests you'll want to run depend on the risks involved, how much coverage you'd like, what other testing you've done, how much time you have, and other project factors. This might be best illustrated with a couple of examples.

Let's look at an insurance requirement. I've worked for a couple of insurance companies in the past, and the following isn't an uncommon requirement in that context:

If the policy is written in the state of Indiana, and the policy effective date is between January, 2010, and January, 2012, and the amount of coverage is less than $2,000,000 but greater than $500,000, then make optional coverage X required.

For this single requirement, we're dealing with state, effective date, and coverage amount as test variables. We're monitoring if the optional coverage in question is required or not. A simple requirement like this could yield a number of test cases. For example:

  1. State is not Indiana
  2. State is Indiana, and policy effective date is less than Jan 2010
  3. State is Indiana, and policy effective date is greater than Jan 2012
  4. State is Indiana, and policy effective date is between Jan 2010 and Jan 2012, and the coverage amount is greater than $2,000,000
  5. State is Indiana, and policy effective date is between Jan 2010 and Jan 2012, and the coverage amount is less than $500,000

For all five of those test cases, we would not expect the optional coverage to be included. And that doesn't include testing the specific boundaries identified in the requirement. Those are just generic values. Realistically there are at least 18 meaningful combinations of tests -- 2x3x3 -- based on a simplified view of the three variables we're working with.

But even that simple analysis leaves out test cases for null or missing values. It leaves out stress test cases like really large or really small numbers for dollar amounts. It leaves out test cases for different date and dollar amount formats and special formatting characters, or even state abbreviations. It leaves out other system variables, like the state of the system, other transactions occurring at the same time, and load. In reality, a simple requirement like this could yield hundreds of tests if you wanted it to.

Contrast that analysis with the analysis of the following simple requirement for an IVR system:

The caller can respond with 'Yes', 'No', or should be allowed to select the appropriate DTMF response.
For this requirement I immediately notice that while there are only two stated options -- yes and no -- there are also two input methods, spoken and DMTF ( Distributed Management Task Force). Because I've done some IVR) testing, I'm also aware that there are also some implicit requirements here -- the unstated options like silence, noise, and DTMF that's not really DTMF -- some people's voices will trigger DTMF when they talk. For this requirement I have a number of simple tests:
  1. Say 'yes'
  2. Say 'no'
  3. DTMF yes
  4. DTMF no
  5. Do nothing
  6. Provide a very noisy response where a determinate answer can't be made

For any of the spoken responses, what languages should we support? Even if it's only English, what accents should we test with? Is the prompt leading up to this utterance bargable? Because if it is, does that result in partial yes/no utterances?

With both requirements, to adequately and effectively test, I'll need to know more than just the requirement. I need to understand the industry I'm testing for, the context of the specific project, and what other testing I've done up to this point or have planned.

Finally, your question specifically calls out user acceptance testing as your focus. If that's the case, then all of this analysis happens through the prism of trying to determine if the software built solves your business problem. Often, while this testing doesn't go as deep as some of the analysis I've provided above, it can focus on aspects that I haven't even touched on – like business processes, data or transaction lifecycles, and changes over time.

Next Steps

How to write test cases for both manual and automated tests

Dig Deeper on Topics Archive