Testing Approaches

 

In a large software project it is impossible to integrate all the modules in one shot and start testing the software as a whole. The system has to be built in stages and the product has to built incrementally carrying out testing on each incremented software. The testing approaches discussed in this article help in achieving the objective.

Static Testing Vs. Dynamic Testing:

Once the code is written, there are two ways of testing - Static Testing & Dynamic Testing.

In static testing the code is checked without executing it through Reviews/Inspections/Walk-through, hence it is also known as desk checking. This can be done either formally in a meeting or informally by two or more development/QA engineers. This testing is mainly performed to test the documents related to software, QA/QC team go through the source code/document or use certain debugging tools to find out the syntax errors. In dynamic testing the code is executed and the actual results are compared with the expected results. It is always suggested to carry out both the types of testing because each testing reveals specific bugs. For instance, if the development team forgot to implement a particular user requirement, this can be only revealed in static testing as the code is checked for completeness. But dynamic testing does not reveal such errors.

Positive Testing Vs. Negative Testing:

The software has to do what it is intended to do and nothing more or less. We need to test the software to check whether it is doing what it is intended to do. But that is not enough. We also need to check whether it is doing anything, which is not intended to do. This is differentiated  by Positive testing & Negative testing. 

Positive testing is testing the software to ensure that it does what it is intended to do. Negative testing is testing the software to ensure that it does not do anything, it is not intended to do.

Top-down Testing Vs. Bottom-up Testing:

In top-down approach testing is done from the top of hierarchy. Dummy routines called stubs are introduced that simulate a module.

In bottom-up approach, testing is done from the bottom of hierarchy. Dummy routines called drivers are introduced that invoke a module.

At system level, carrying out top-down testing is difficult, it is better to do the testing using bottom-up approach - test the sub-modules, the sub-systems and the total system.

Generally, the top-down approach is followed for design and bottom-up approach for testing.

Functional Testing Vs. Structural Testing:

In functional testing we test what the software does. Here the functionality of the module is tested and structure is not considered. Test cases are based on specifications and internals of modules are  also not considered. In functional testing we try to find discrepancies between how the program performs and its specification. The test data are derived exclusively from the specification because we do not have access to the program code and you do not have knowledge of the internal structure of the program. This type of testing is also known as "Black-Box testing".

Structural is a "White Box" testing based on the algorithm or code. The structure of a program differs at different levels. At component level, the structure is the code. At integration level, the structure is the tree diagram that shows the interconnecting modules. At system level, the structure is the menu structure or web page structure or business process depending on the application.

Structural testing is also called clear-box testing and glass box testing. 

Structural testing at component level is used to test the implementation of the program. The source code is looked into for testing the software. Structural testing involves:

1. statement coverage/decision coverage
2. condition coverage/branch coverage
3. path coverage/function coverage

Re-testing Vs. Regression Testing:

Re-testing is done to make sure that bug is fixed and failed functionality is working fine or not, this is kind of verification method followed in testing field for the fixed bugs. Re-testing is used only for failed test cases. Re-testing cannot be automated. It is also known as planned testing.

Regression testing is a type of software testing, which is used to verify that modifications in the software or the environment have not caused any unintended adverse side effect. Passed test cases can be executed and this can be automated or done manually. Regression testing is known as a generic testing.