Trace tables track data/conditions/input/output through an algorithm.
They are useful for determining if an algorithm works as expected.
They can give clues to issues with code when problems arise.
With some practice, they are quite easy to create.
Jeff, Jill, Joe and Jack work for a software company.
They are currently working on a project for an accounting company.
They are designing a modular solution to the problem which means each of the can take responsibility for one or more modules.
Furthermore, each of them has different skills so they can contribute their expertise to the project.
Working as a team on a modular solution is different to working alone because:
Jack has designed one of the modules. It allows a user to input tax data and output the total tax entered, the average tax, the count of valid tax data items entered.
The program will terminate when the user enters -1.
Tax data must be in the range 50-1000 inclusive.
Jack has designed an algorithm to solve the problem in the form of a flowchart.
Jack prepared some and determined the output of the algorithm using that data.
Here is the test data:
| 150 | 50 | 7 | 15 | 1000 | 20 | -1 |
|---|
The expected result using this data is:
| count | total tax | average tax |
| 3 | 1200 | 400.00 |
Jeff takes the flowchart and codes it in Java.
However, when he runs the code with the same test data that Jack used, he gets a different result.
| count | total tax | average tax |
| 6 | 1240 | 206.67 |
He needs to figure out what is wrong... and quick! A deadline is looming!
To troubleshoot the problem, Jeff has decided to use a .
He can use it to trace the test data through an algorithm/program and determine the result.
If it is not the expected result, the trace table may give him some clues about what the problem is.
Here is the a simulation of the trace table activity that Jack completed using a pen and paper.
Click STEP to see how Jack filled the trace table in:
| 150 | 50 | 7 | 15 | 1000 | 20 | -1 |
|---|
int total = 0
int count = 0
System.out.println( "Enter a tax amount or -1 to quit: ");
taxAmount = kbin.nextInt();
while(taxAmount != -1){
total = total + taxAmount;
count = count + 1;
System.out.println( "Enter next tax amount or -1 to quit: ");
taxAmount = kbin.nextInt();
}
double avg = (double)total/count;
System.out.println("Total tax is "+total);
System.out.println("Average tax is " +avg);
System.out.println("Number of tax items entered"+count);
| total | count | taxAmount | avg | Output total | Output avg | Output count |
|---|---|---|---|---|---|---|
| 0 | 0 | 150 | ||||
| 150 | 1 | 50 | ||||
| 200 | 2 | 7 | ||||
| 207 | 3 | 15 | ||||
| 222 | 4 | 1000 | ||||
| 1222 | 5 | 20 | ||||
| 1240 | 6 | -1 | ||||
| 206.67 | 1240 | 206.67 | 6 |
Trace tables are used to test every path through an algorithm.
Because of this, test data needs to be thoughtfully selected. It should include:
Without thoroughly testing a module, it may cause problems later when integrated into the system.
This kind of testing is known as whitebox testing.
Whitebox Testing looks at the inner workings of a module - it traces data through the code.
Blackbox Testing tests the functionality of the program. For example, if you press the "p" key on your keyboard, do you see "p" on the monitor.
This is an example of blackbox testing - we don't care how the system produces the result, we just want to confirm that the system works as expected.
After all modules in a program have been designed, tested and integrated into the system, the entire system needs to be tested.
This is ALPHA testing and is done by the development company.
Once ALPHA testing is complete, some clients/end users are invited to use the system. This is BETA testing. The clients/end users are invited to give feedback on the new system.
Once BETA testing has been successfully completed, the new system will need to be installed at the client's site.
It will then need to be fully tested again to ensure that it works as expected. This is called USER ACCEPTANCE TESTING.
Fill the blanks and check. Do you get it?!
Programmers work in teams to complete project work.
Working in a team is useful because each member can contribute their own . Also, tasks can be completed , meaning the project may be completed faster than a programmer working alone.
When designing modules, testing is completed. This kind of testing does not involve the client.
A module should be tested using data that is expected. This is known as data.
It should also be tested using unexpected or unwanted data. This kind of data is known as .
If the module processes a range of data, the range should be tested using data, sometimes called extreme data.
As modules are designed and tested they are integrated into the final program.
When the designers are satisfied that the project is finished, some clients are invited to test the product. This is known as testing.
If this testing fails for any reason, the project team will need to continue developing the product.
When beta testing is successful, the product will need to be on the client's system.