1 of 11

Methods of testing

2 of 11

Starter - discuss with a partner

Why do we need to test our programs?

What types of errors are there?

Which are the hardest to find?

3 of 11

Dry Run Testing

This is where the programmer walks through the code, either on paper or on screen, to see if they can spot any errors. Usually this involves tracing the value of values (either mentally or using a trace table) to see if they can find a particular bug. The process might also happen as a check before running the code, especially is the code is writing data to an external file or database.

Dry run testing is performed throughout the software development process, as and when required, and is usually not specified within the testing plan.

4 of 11

Walkthrough

Walkthrough testing is a form of peer review in software within software engineering where the programmer guides others (e.g. managers, users, customers) through the documentation specifying the software being designed, so that any errors, changes or improvements can be spotted and changes can be implemented.

It is mainly done within the design phase of the software development process, before any code has been written, and usually involves any high level documentation, such as structure charts or state transition diagrams.

5 of 11

White Box Testing

White Box Testing is any software testing where the tester has access to the source code of the software under review. This type of testing is completed throughout the development process, especially the development and testing phases.

Access to the source code allows the program to be inspected directly through the use of dry run testing and the use of trace tables.

6 of 11

Black Box Testing

This type of testing is where the person performing the test only has access the the compiled code, such as a beta version of the software, and they can only perform tests by running the code and analysing the results of the code, not the code itself. Beta testing involves black box testing.

7 of 11

Integration Testing

Integration testing is the process of testing how software components that have been developed independently work together. This can be done by combining individual components slowly together one at a time, or through the use of big bang testing.

Often when software components are developed independently by large teams the success of their interaction when part of a larger system cannot be guaranteed, especially when different practices and standards are used.

8 of 11

Alpha Testing

Alpha testing is formal method of testing which is usually performed during the testing phase of the software cycle. It is a whole system test where users outside the development team, but usually inside the development organisation test the system by using the system, modelling expected behavior in an attempt to find bugs or issues. This form of testing can include both white box and black box testing.

One Alpha testing is complete the program then tends to move onto the Beta testing phase.

9 of 11

Beta Testing

Beta testing is whole system testing that is performed after Alpha testing. It is usually perform by a wide number of users outside of the software development organisation.

  • The system is used/tested by non specialists and therefore more errors may be found.
  • The system is tested on a wider range of hardware and therefore hardware related issues can be highlighted.
  • The system can be analysed for load/stress testing in a manner that is closer to real world than in Alpha testing.

10 of 11

Acceptance Testing

Once a system has completed Beta testing, at the point of handover, then acceptance testing is performed. The aim is to ensure that both parties are happy that the system conforms to all the requirements listed in the specification.

Once acceptance testing is complete handover/cut-over can occur.

11 of 11

Stub Testing

This testing technique involves the use of empty / incomplete functions that return dummy values in the range of values expected from the final product.

This allows the system to be developed in a modular manner even when certain components have yet to be implemented.

As modules are completed the stub code is replace with working versions of the code.