Software Testing

[This material copied from Prof. Troy's CS 211 course material. The particular content below is modified from Lab 12, Fall 2015.]

Knowledge in software testing is one of the skills many employers ask for from graduating students. What does this mean in practical terms?

Testing is when we determine whether a program executes correctly, validating that it performs as described in the program specification. In contrast debugging is finding the causes of failed tests and correcting the issues in the code. In this activity we will focus on testing. Consider the following Specification for a tax calculation web form, and 3 different implementations that you must evaluate:

Program Specification for a Simple Tax Calculation:

Create a web form that will allow the user to calculate the amount of taxes owed to the government. The user should enter the income amount in an input field, then press/click a button and the amount of taxes owed is to be displayed. If the user enters a non-numeric income amount or a negative income amount, display an error message telling the user that a positive numeric value must be entered. The amount of taxes owed is determined by:

This web form used for testing looks like the following:

Three different companies have implemented versions:

Which one is best? For this activity, create, run and document multiple test cases to answer this question.

Each test case should specify a specific input value, the expected result, whether the test case is testing an Equivalence Class or a Boundary Case, and the result (pass or fail) for each of the three attempts. A table is provided below for you to fill in. The first few have been started for you. These test cases MUST thoroughly test the entire specification, so you will need multiple test cases. (Hint: you will need more than 8 test cases to properly do this.)

What are Test Cases and What Kinds of Testing Cases Exist?

Test cases describe the actions/inputs to be given and the expected results. Multiple test cases are needed for each action/input. These test cases should include inputs which result in all possible error messages generated by the program. For this lab, we will only concern ourselves with two different kinds of Test Cases: Equivalence Class Cases and Boundary Cases.

Test cases should include inputs from all possible ranges of inputs (including error inputs). Each of these possible ranges of input is often called an Equivalence Class. For the above specification, one Equivalence Class is the values greater than $5,000 up to and including $50,000. Another Equivalence Class is the non-numeric values. For each Equivalence Class, a test case using a value from the “middle” of the range of inputs is to be created.

Test cases should also include inputs that verify the proper functioning of the program for values at the boundary between two Equivalence Classes. These are often called Boundary Cases. Each boundary should generate multiple test cases: a test for the boundary value, and a test for each value on either side of the boundary value. For the above specification, one boundary case is the value of $5,000. So we should have a test case that uses the value of $5,000, another with the value of $4,999 and one more with the value of $5,001.

Test form (and see Microsoft Word version attached below) For your convenience, here again is the specification table: