Levels of Testing
Levels of Testing
As we learned in the earlier section of the software testing tutorial that testing
any application or software, the test engineer needs to follow multiple testing
techniques.
1|Page
INTRODUCTION
Testing levels are the procedure for finding the missing areas and avoiding
overlapping and repetition between the development life cycle stages. We
have already seen the various phases such as Requirement collection,
designing, coding testing, deployment, and maintenance of SDLC (Software
Development Life Cycle)
In order to test any application, we need to go through all the above phases of
SDLC. Like SDLC, we have multiple levels of testing, which help us maintain the
quality of the software.
2|Page
Different Levels of Testing
The levels of software testing involve the different methodologies, which can
be used while we are performing the software testing.
In software testing
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
As we can see in the above image that all of these testing levels have a specific
objective which specifies the value to the software development lifecycle.
3|Page
Unit Testing
The goal of unit testing is to isolate each part of the program and show that
individual parts are correct in terms of requirements and functionality.
There is a limit to the number of scenarios and test data that a developer can
use to verify a source code. After having exhausted all the options, there is no
choice but to stop unit testing and merge the code segment with other units.
4|Page
Integration Testing
Sandwich Testing
Sandwich Testing is a strategy in which top level modules are tested with lower
level modules at the same time lower modules are integrated with top
modules and tested as a system. It is a combination of Top-down and Bottom-
up approaches therefore it is called Hybrid Integration Testing. It makes use of
both stubs as well as drivers.
5|Page
S.No. TOP DOWN INTEGRATION BOTTOM UP INTEGRATION
TESTING TESTING
01. Top Down Integration testing is one of Bottom Up Integration testing
the approach of Integration testing in is one of the approach of
which integration testing takes place Integration testing in which
from top to bottom means system integration testing takes place
integration begins with top level from bottom to top means
modules. system integration begins with
lowest level modules.
02. In this testing the higher level modules In this testing the lower level
are tested first then the lower level modules are tested first then
modules are tested and then the the higher level modules are
modules are integrated accordingly. tested and then the modules
are integrated accordingly.
03. In this testing stubs are used for In this testing drivers are used
simulate the submodule if the invoked for simulate the main module
submodule is not developed means if the main module is not
Stub works as a momentary developed means Driver
replacement. works as a momentary
replacement.
04. Top Down Integration testing Bottom Up Integration testing
approach is beneficial if the significant approach is beneficial if the
defect occurs toward the top of the crucial flaws encounters
program. towards the bottom of the
program.
05. In Top Down Integration testing In Bottom Up Integration
approach the main module is testing approach different
designed at first then the modules are created first then
submodules/subroutines are called these modules are integrated
from it. with the main function.
06. It is implemented on It is implemented on Object-
Structure/procedure-oriented oriented programming
programming languages. languages
6|Page
SYSTEM TESTING
The third level of software testing is system testing, which is used to test the
software's functional and non-functional requirements.
7|Page
Acceptance Testing
Similar to a unit test, an acceptance test generally has a binary result, pass or
fail. A failure suggests, though does not prove, the presence of a defect in the
product.
Teams mature in their practice of agile use acceptance tests as the main form
of functional specification and the only formal expression of business
requirements. Other teams use acceptance tests as a complement to
specification documents containing uses cases or more narrative text.
8|Page
Conclusion
9|Page