3

I have constructed a large decision table based on the possible inputs I can have.

My question is, how do I determine what test cases to write?

1
  • @BharatMane Why have you turned part of question into a quote? Is this to mark that OP is quoting himself or herself?
    – dzieciou
    Dec 23, 2016 at 14:01

2 Answers 2

4

Once you have the table, you should be able to generate the paths through those options. It's the path I find most important as then it can be related to the real world or the deliverable.

The 'User Journey' is a thing you can prioritise. Eg. It is more important that a customer can place an order, than the customer viewing their order history.

Once the paths are prioritised, you'll then know which test cases to develop first.

Hope that helps

2
  • +1 for customer (high profile or showstopper) test cases first. I would add to go through the defect (bug) listing and note the areas that are prone to break. Those should also be higher priority. Jun 16, 2011 at 15:12
  • Hi Laura, I agree high priority test cases should be developed first. But for a new feature yet to be implemented it is hard to determine which areas could be defect prone. Test cases that are steel threads (happy paths that must be implemented to complete the feature) need to be automated first.
    – Aruna
    Jun 16, 2011 at 18:58
4

If you have defined user stories or customer requirements, those test cases have to be your first ones to work with.

If you don't have this information, the fallback is to think what you as a user would do when faced with this application for the first time, and use that as your initial pass test cases.

Any test cases that generate data your happy path/steel thread tests require are your next target to write - and need a note to indicate that they have to be executed first.

After that, I'd start looking at the most likely things the users are going to be doing, where the highest load is likely to be (this is always a judgment call) and aiming at those cases as your next round to work with.

At this point, you can start looking at potential breakage points: your boundary cases, invalid inputs, and the like.

The overall goal should be first that the application does what it's supposed to do (as defined by the customer user stories or requirements documentation), then that doesn't do what it's not supposed to do (i.e. you can't enter invalid data), and finally that it handles anything it wasn't designed to do or not do with a certain amount of grace (i.e. you get an error message and can continue your work, rather than the entire application crashing).

Your Answer

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

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