# A-level Computing/AQA/Problem Solving, Programming, Data Representation and Practical Exercise/Systems Development Life Cycle/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

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:
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
abcount
54
Answer:
abcount
540
1041
2042
4043
8044
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
zhigh
44
Answer:
zhigh
44
34
24
15
05 :

### 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 <letter><letter><number><number>:
* 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: 23
* 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 : 23rd, 16th
* Erroneous: 30th (you might also mention leap years here)
* Extreme: 1st, 28th or 29th (depending on leap years)