Testing is an essential part of software development. It needs to be approached in a systematic way mindful of the consequences of errors in the program or solution.
Modules tested as they are completed using valid, extreme and invalid data.
Complete programs tested as they are finished.
Test data should exploit every route through the program, causing each statement in program to be executed. Accuracy and effectiveness of processing tested against specifications laid down during analysis.
Skeleton system put together, stubs (eg prompts to say a task has occurred) replace incomplete modules or user interfaces.
Retested each time a new model is added.
Black-Box Testing (Functional)
Functional testing means preparing test data that covers the inputs, outputs and program functions. It is done independently of the code that has been developed.
White-Box Testing (Structural)
Structural testing is derived from the code that has been developed. It means preparing test data that ensures that every line of code and path of execution is covered. This will not, however, show what is missing from the code.
Selecting Test Data
Normal test data is data that should be handled by the program. It should not generate errors and any calculations that the program makes based on these values should be checked for accuracy. It is the obvious thing to do to check that the program works as it is expected to.
Boundary data is data which lies on the boundary between one response from the program and another. For example, you might have a program that calculates a discount for an order above say, £50. Test data should be prepared to ensure that values just above, just below and on the boundary are tested. The difference between above £50 and £50 or more is important. You should test that your program responds appropriately.
A good program caters for the kind of input errors that occur commonly. This could be the failure to enter a valid date, mistyping input and entering the wrong type of data, pressing enter without entering anything etc. A decent program validates input and prompts the user to correct their mistakes.
Test data should deal with all likely scenarios.
A test plan is best created as a table with the following headings,
Test Number | Test Data | Test Type | Expected Result | Actual Result | Comments |
---|---|---|---|---|---|
1 | 5 | Normal Data | 20 | 20 | |
2 | 25 | Normal Data | Error Message | 38 | Test failed: incorrect validation rule. |
In the examination and in later pieces of coursework, you would be expected to include samples of testing or evidence of having conducted a particular test. The numbers allow you to cross-reference any screenshot evidence of testing to the plan that you have made.