A) Well, Rover12, what you have there is a start. It also seems to imply that you already know what can be valid data and invalid data; and it implies, too, that you know what “all valid scenarios” are.
Both implications are not trivial at all - I would double check these assumptions, chances are you'll discover there's still a lot you don't know about the product.
The test cases you mention are overly simplistic, and chances are there is more to the data inputs and to the scenarios (and to the behaviors, and users) than what these tests and the testing approach take into account.
B) For example, here are suggestions for some expansions to these cases:
- What else can happen when filling invalid data? Crashing is a very drastic result. What about these invalid inputs being in fact accepted? Or causing data corruption? Or causing lags, delays, cryptic error messages, no error messages at all, different error messages?
- How clear are instructions to fill the form between levels? Who gets reports of progress? Is the application fast and responsive?
- How does this app function in 64b systems? How does it look at different screen resolutions and colors? What load of users does the system support and keep stable? How can one hack the internal process memory and break a flow in the system, gain elevation of privileges, cause DoS? How fast does the app print reports? Is it compatible with all needed printers? How does it save configuration files? Can these be moved between computers? Can a user customize the view? Why yes, is it needed?
C) If that looks a long list, be aware that all my examples from "B)" are overly simplistic too. Those are trivial, because I am not acquanted with the 'livecycle' app, don't know the users and don't know what kind of information you are in a quest to uncover.
So, off the top of my head, I can suggest some expansions to the testing approach itself too:
- Why don't you experiment with the application first, in order to understand what are the interesting features, what parts are important to the user? Then, if you need to fill test-cases, they will better suit your needs.
- Trying to base the test cases in the inputs may not be the best approach, especially if the application is big in features and flows -- you may miss a lot if you focus on simple good/bad input tests.
- Trying to base the tests in test cases may not be the best approach too... you can to define areas to experiment, and analyze, as you experiment them, what could cause an execution flaw, or what would make your users happy or sad.
- As you go, you'll be able to identify areas that need more testing. Areas where you need to learn more technical stuff or get special tools.
- Why don't you speak with the rest of the team or company? What are your company and/or manager trying to discover with the tests?
Rover12, good luck and please come back to let us know what you learnt in the process!
