I'm using ALM to create test cases to cover different customer creation workflows.

The challenge is that when you look up a customer, there are at least 20 ways to do so (through name search, CVR, birth date, etc.).

Question: I would like to minimize the number of test cases I need to create in ALM, while still covering all the options to look up a customer. Is there a way to do so? Can I create one test case, and test multiple lookup options within the same case?

2 Answers 2


Since throughly testing would be unfeasible, have two options:

  • Do a risk analysis and perform only a subset of the possible tests, trying to cover all ways in a limited number of ways.

  • Do random testing. You would have to model the creation flow, so you could generate a random state and check if the output matches the model.

In both cases, you should sync with the developers to perform more throughly testing in the unit/integration level, given your E2E testing is limited.

  • Why is thoroughly testing infeasible? Commented Jun 4, 2017 at 21:00
  • There is the "combinatorial explosion of test cases" problem. Consider you have a system with n test cases, running on Windows. If you come to support Linux, you'll have 2 * n test cases. If you come to support m number of OS`s, you'll have m * n test cases. If you support t number of browsers, you'll have t * m * n test cases. Any non-trivial system has combinatorial tests cases. James Bach wrote about a popular technique to deal with it called "pairwise testing". testingeducation.org/wtst5/PairwisePNSQC2004.pdf. There are approaches with AI as well nowadays. Commented Jun 6, 2017 at 16:01
  • I understand. But in a limited domain (like the one posed by the OP), thoroughly testing is certainly feasible. And in this case, it may even be necessary. Commented Jun 6, 2017 at 16:44
  • "The challenge is that when you look up a customer, there are at least 20 ways to do so (through name search, CVR, birth date, etc.).". At least 20! teste cases. If you consider the a name input could be of many types (empty, ASCII, unicode, big, too big, "God, that's big") you will have even more tests. Test case explosion happens in any non-trivial system. The one described is not trivial (nor complex). Commented Jun 6, 2017 at 21:26
  • 20 test cases doesn't seem infeasible to me. And throwing varied data at it is rather trivial for automation. It's something many of us do every day. Commented Jun 6, 2017 at 21:42

What you want for this, assuming you have intelligent testers who aren't expected to follow a "click this button" script, is to define one test case for customer lookup, and in that test case, list the ways to search for a customer.

Depending on how your system works, you should be able to define the search methods as test parameters that can be used in customer search - especially if you keep your description at a high level.

For example:

"Given that Customer X has a %PARAMETER% stored in the system, when I search for customers by %PARAMETER%, I should see the Customer X in the list of matching customers."

Parameters could be:

  • Full name
  • Contact name
  • Zip code
  • Birth date
  • date of last purchase

Pretty much any of the fields that you could search on.

Note that you should also include test cases for customers who have nothing stored in the field e.g. customers with no birth date stored should never be returned when searching by date of birth; and for customers who have a different value than the search value e.g a customer who does not have zip code 12345 should not appear in the search results for zip code 12345.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.