Test Plans
What is a test plan?
Test plans are used to test computer programs during and after development. A test plan is a set of possible inputs along with their associated expected outputs. A test plan should contain at least 5 sets of possible inputs for programmers in first and second-year programming courses. However, a test plan must contain enough sets of possible inputs to thoroughly test the program and its algorithm. The test plan consists of a table which is broken up into main columns, possible inputs and expected outputs. Within the possible inputs column, there must be subheadings and columns for all of the individual items that are inputted by the user or an external file in the order that they are inputted. Within the expected outputs part of the test plan, you must identify the exact output that prints or displays across from their corresponding entries in the possible inputs column.
When you determine the possible inputs that a user (or a file) may enter, you must think about all of the possible "boundary" cases. Each boundary case should have an entry in the possible inputs column. For example, if the user is expected to enter a Celsius temperature, you should include the lowest legal centrigrade temperature which is -276 degrees. While there is no upper limit to possible Celsius temperatures, you should include the boiling point of water (100 degrees) and maybe another entry higher than that. You should also include "special" cases such as the freezing point of water (0 degrees.) A test plan must also include a few "normal" input cases. If you program includes error-checking (which prevents the user from inputting bad data), you should include a test plan item that simulates bad entry. For example, if the user is supposed to enter an integer, you should include the possible inputs of 4.3 and "zero".
Why are test plans necessary?
All programs must be thoroughly tested before they are sold or submitted for a grade. Do not rush the development of a program and sell it or hand it in before you have tested it. You still have a chance to debug your program if you learn that you have an error from administering the test plan.
How do I write a test plan?
BEFORE you begin to write pseudocode and long before you write any code for the program, you must complete a fully-developed test plan. This is absolutely necessary. If you create the test plan later, coding problems or language issues may prejudice your open-mindedness. That is, you may not find all of the boundary cases or "tricky" inputs if you subconsciously put them out of your mind. It is always necessary to make the test plan by closely examining the program's specifications.
Note that you must include a column in your test plan that explains why each test plan item was included. You must also number the test plan items. It is fine and even advisable to list more than one example of each kind of test plan item (i.e. boundary, normal, error-checking, etc.)
Example:
Original Program Specification:
Write a program that computes the area of a rectangle when the user to input two integer numbers between or including 0 and 20. It will print out the area of the rectangle along with an appropriate message.
Test Case
Expected Output
Reason
width
length
1. 3 12 "The area is 36" normal case 2. 0 0 "The area is 0" lower boundary case 3. 1 4 "The area is 4" normal case with least possible nonzero width 4. 0 20 "The area is 0" mixed boundary case 5. 20 0 "The area is 0" mixed boundary case 6. -2 5 "Please input another width. " error-checking
Follow this format when typing test plans with Excel: