Systematic approach to problem solving: Testing
Once we have created our solution we need to test that the whole system functions effectively. To do this should be easy, as all we need to do is compare the finished product next to the objectives that we set out in the Analysis. There are several ways of testing a system, you need to know them all and the types of data that might be used.
At an early stage in a project you should consider how the system will be tested to see if it works correctly. There are three main test methodologies that you need to be aware of, and able to choose between.
Black Box Testing
Consider the box to contain the program source code, you don't have access to it and you don't have to be aware of how it works. All you do is input data and test to see if the output is as expected. The internal workings are unknown, they are in a black box. Examples of Black Box testing would be if you were working as a games tester for a new console game. You wouldn't have been involved in the design or coding of the system, and all you will be asked to do is to input commands to see if the desired results are output.
White Box Testing
With white box testing you understand the coding structure that makes up the program. All the tests that you perform will exercise the different routes through the program, checking to see that the correct results are output.
Dry Run Testing
A dry run is a mental run of a computer program, where the computer programmer examines the source code one step at a time and determines what it will do when run. In theoretical computer science, a dry run is a mental run of an algorithm, sometimes expressed in pseudocode, where the computer scientist examines the algorithm's procedures one step at a time. In both uses, the dry run is frequently assisted by a trace table. And whilst we are here we might as well get some more practice in:
|Method||Availability of Source||Header text|
|White Box||Maybe (understanding required)||Example|
Black Box Testing as you don't have access to the internal workings of the program
Dry Run Testing as you have access to the source and this will allow you to find the offending line(s) of programming
Typical, Erroneous, Extreme
There are three types of test data we can use. What are they? The answer lies mostly in their name, let's take a look at this example where someone has created a secondary school registration system which lets students register themselves. We don't want people who are too young attending, and we don't want students who are too old. In fact we are looking for students 11–16 years old.
- A Typical Student will be 12,13,14 or 15
- An Erroneous (or wrong) aged student will be 45, 6 or any age outside those allowed.
- An Extreme (or boundary) aged student has just started or is just about to leave, they will be 11 or 16
If you are testing data that has Typical, Erroneous and Extreme data, show tests for all three. Some tests might only have typical and erroneous, for example entering a correct password might only have a typical and an erroneous value. Some things might only have typical testing, such as if a button to a next page works or not, or if a calculation is correct.
Imagine that the following objectives were set:
The maximum number of yellow cards a player can receive in a game is 2
There should be no more than 15 minutes extra time in a game
The name of a team should be no longer than 20 characters
Typical : 5,16,18
Erroneous: 21, -7
Typical : 28,56,32
Erroneous: 16, 86
Typical : GH24
Typical : 12/07/1987
Erroneous: 31/09/1987, 31/02/1987
Typical : brown, red, black
Typical : 28
Typical : 24, 500
Typical : 23th, 16th