# 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.

## Test Plan

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

Black Box testing model

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

White Box testing model showing various routes through the code being put to test

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:

Exercise: Dry run testing

Complete the trace table for the following code:

```var a <- 5
var b <- 4
var count <- 0
while count < b
a <- a + a
count <- count + 1
end while
```
a b count
5 4

a b count
5 4 0
10 4 1
20 4 2
40 4 3
80 4 4

Complete the trace table for the following code:

```array nums() <- {4,2,5,2,1}
var z <- 4
var high <- nums(0)
while z > 0
if high < nums(z)
high <- nums(z)
end if
z <- z - 1
end while
```
z high
4 4

z high
4 4
3 4
2 4
1 5
0 5

### Summary

Method Availability of Source Header text
Black Box No Example
White Box Maybe (understanding required) Example
Dry Run Yes Example
 Exercise: Testing Methodology Name the suitable testing methods for each of the following scenarios: You don't have access to the source code and need to check that some input produces the desired output: Answer: Black Box Testing as you don't have access to the internal workings of the program There is a bug somewhere in the code producing the wrong output for a given input, you have access to the code Answer: Dry Run Testing as you have access to the source and this will allow you to find the offending line(s) of programming Dry run test the following algorithms:

## 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.

 Example: Electronic Crafts Test Data Imagine that the following objectives were set: The maximum number of yellow cards a player can receive in a game is 2 Typical : 0,1,2 (most likely to list 1) Erroneous: 3, -6 Extreme: 0,2 There should be no more than 15 minutes extra time in a game Typical : 0,1m45,9m23 Erroneous: -6, 15m01 Extreme: 0,15m00 The name of a team should be no longer than 20 characters Typical : Monster United Erroneous: Monster and Dagrington League of Gentlefolk Extreme: Moincicestier United (20 characters!)
 Exercise: Test Data List the typical, erroneous and extreme data for the following: The number of cigarettes currently in a 20 cigarette carton: Answer: Typical : 5,16,18 Erroneous: 21, -7 Extreme: 0 or 20 The age of a college teacher: Answer: Typical : 28,56,32 Erroneous: 16, 86 Extreme: 21, 68 The username for a system that must be of the form : Answer: Typical : GH24 Erroneous: G678 Extreme: AA00, ZZ99 The date for someone's birthday: Answer: Typical : 12/07/1987 Erroneous: 31/09/1987, 31/02/1987 Extreme: 31/12/1999, 01/01/2001 (this is harder to specify, it might depend on the age range you allow) Someone's hair colour: Answer: Typical : brown, red, black Erroneous: bicycle Extreme: n/a (we're not here to judge people!) Does the following calculation work: 14 * 2 Answer: Typical : 28 Erroneous: n/a Extreme: n/a Number of pages in a book Answer: Typical : 24, 500 Erroneous: -9 Extreme: 1 (notice no upper end, this is assuming that it wouldn't be a book without any pages!) Name a date in February: Answer: Typical : 23th, 16th Erroneous: 30th (you might also mention leap years here) Extreme: 1st, 28th or 29th (depending on leap years)