Dry-Run
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 variables (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 if 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.
Walkthrough
Walkthrough Testing
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 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.
Example of what happens when you don’t do walk through testing…
WhiteBox
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.
BlackBox
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.
The user only knows the intent of the software, not the details of the implementation.
Integration
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.
Alpha
Alpha Testing
Alpha testing is a 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 itself) test the system by using the software in an attempt to find bugs or issues. This form of testing can include both white box and black box.
The advantage of using technically proficient in-house testers is that potential security issues are not revealed to external parties and the reputation of the software/brand is not jeopardized by exposing users to potentially incomplete or buggy software.
Another advantage of Alpha testing is that testers can use their technical knowledge to try to break the software using abnormal and boundary use cases that might not be testing during Beta testing.
Once Alpha testing is complete the program then moves onto the Beta testing phase.
Beta
Beta Testing
Beta testing is whole system testing that is performed after Alpha testing. It is usually performed by a wide number of users outside of the software development organisation.
The advantages of Beta testing include:
- 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.
Acceptance
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.
Stub
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.