Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

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

share|improve this answer
    
+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. –  Laura Hensley Jun 16 '11 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 '11 at 18:58

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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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