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?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this communityI 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?
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
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).