Test Plans

Objective #1: Create and use a test plan.

• Test plans are used to test computer programs during and after development. They consist of a set of possible inputs along with their associated expected outputs.
  
  Here is an example:
  
  Program Specification - Write a program that allows the user to input three bowling scores between or including 0 and 300. The program must display the average of the inputted scores rounded to the nearest whole integer.
  
  Test Plan -
  
  
  
  
• A test plan should contain at least 10 sets of possible inputs for programmers in an introductory programming course. However, it 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 titled "Possible Inputs" and "Expected Outputs". In the Possible Inputs column, there must be subheadings and columns for all of the individual items that are inputted by the user or read from an external file in the exact order that they are inputted. Number your test cases as well. Under the Expected Outputs column of the test plan, you must include subheadings and columns that identify the exact output that prints or displays across from their corresponding entries in the Possible Inputs column. Also, include a column labelled "Reasons" that explains why each test case was included in the test plan and whether it is an upper or lower boundary case or another kind of special case.
  
  
• 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".
  
  
• 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. All programs must be thoroughly tested before they are sold or submitted for a grade. Do not rush the development of a program and 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.

Objective #2: Select proper values when testing an algorithm.

• When you are testing code that involves user input, passing parameters to method, and/or if statements it is important to select proper values. In the following code segment:
  
  int average = <an integer value in the range of 0 to 100 inclusive>
  
  if (average >= 90)
     System.out.println("Your grade is A");
  else if (average >= 80)
     System.out.println("Your grade is B");
  else if (average >= 70)
     System.out.println("Your grade is C");
  else
     System.out.println("Your grade is F");
  
  you should test the values 0 and 100 because they are the lower and upper boundaries. You should also test the values 90, 80, and 70 because they are values used in the control expressions. Finally, you should test values in the middle of the ranges of each if else clause including 95, 85, 75, and 65.
  
  
• If you are testing a method such as
  
  coming soon
  
  
• If you are testing code that involves user input, you should specifically test out-of-range inputs
  
  coming soon