UNIT 2

Approaches to
Testing- I

2.1. White Box Testing

2.2. Black Box Testing
2.3. Gray Box Testing
2.4. Levels of Testing
 Introduction

The computer industry is changing at a very rapid pace. In order to keep pace with a
rapidly changing computer industry, software test must develop methods to verify and
validate software for all aspects of the product lifecycle.

Software testing is a set of activities conducted with the intent of finding errors. It also
ensures that the system is working according to the specification.

Various test techniques to achieve more effective testing by software completeness is

provided and conditions of testing which get the greatest probability of finding errors are
chosen.

So, testers do not guess which test cases to chose and test techniques enable them to
design testing conditions in a systematic way.

Also, if one combines all sorts of existing test techniques, one will obtain better results
rather if one uses just one test technique.
2.1 White Box Testing
Every software product is realised by means of a program code. White box testing is a way of
testing the external functionality of the code by examining and testing the program code
that realises the external functionality. White-box testing is also known by other names, such
as glass-box testing, structural testing, clear-box testing, open-box testing, logic-driven
testing, and path-oriented testing.

Design Specification

Input Output

Events, Standards
2.1 White Box Testing
A) Techniques of White Box Testing:
The following are the different techniques of white box testing:

Control
Structure
Loop Testing
Testing

Basis
Path
Testing
2.1 White Box Testing
A) Techniques of White Box Testing:

1) Basis Path Testing:

Basis path is a white box testing techniques which is first proposed by Tom McCabe and it
allows the test case designer to produce a logical complexity measure of procedural
design and use this measure as an approach for outlining a basic set of execution path
(basic set is the set of all the execution of a procedure).
2) Loop Testing:
Loop testing is another type of white box testing which exclusively focuses on the validity
of loop construct. Loops are simple to test unless dependencies exist between the Loops
or among the loop and the code it contain.
a) Simple Loop.
b) Nested Loop.
c) Concatenated Loop.
d) Unstructured Loop.
3) Control Structure Testing:
The other synonym of control structure testing are conditional testing or decision testing
or branch testing and comes under box testing technique; it makes sure that each
possible outcome from the condition is tested at least once. Branch testing however, has
the objective to test every option .
2.1 White Box Testing
B) Types of White Box Testing:
The following are the different types of white Box testing:

Types of White Box Testing

Static Testing Structural Testing

Unit/Code Code Coverage Code Complexity

Desk Checking
Functional Testing Testing Testing

Statement Cyclomatic
Code Walkthrough Complexity
Coverage

Path
Code Inspection
Coverage

Combining Various Condition

Methods Coverage

Function
Coverage
2.1 White Box Testing
B) Types of White Box Testing:
a) Static Testing:
Static testing is a type of testing which requires only the source code of the product, not
the binaries or executables. Static testing does not involve executing the programs on
computers but involves select people going through the code to find out whether. There
are multiple methods to achieve static testing by humans. They are (in the increasing
order of formalism) as follows.

1) Desk Checking:
Normally done manually by the author of the code, desk checking is a method to verify
the portions of the code for correctness. Such verification is done by comparing the
code with the design or specifications to make sure that the code does what it is
supposed to do and effectively.

2) Code Walkthrough:
This method and formal inspection (described in the next section) are group-oriented
methods. Walkthroughs are less formal than inspections. The line drawn in formalism
between walkthroughs and inspections is very thin and varies from organisation to
organisation. The advantage that walkthrough has over desk checking is that it brings
multiple perspectives.
2.1 White Box Testing
B) Types of White Box Testing:
a) Static Testing:
3) Code Inspection:
Code inspection also called Fagan Inspection (named after the original formulator) is a
method, normally with a high degree of formalism. This method increases the number
of defects detected by demanding thorough preparation before an inspection/review.
4) Combining Various Methods:
The methods discussed above are not mutually exclusive. They need to be used in a
judicious combination to be effective in achieving the goal of finding defects early.
Formal inspections have been found very effective in catching defects early.
b) Structural Testing:
Structural testing takes into account the code, code structure, internal design, and how
they are coded. The fundamental difference between structural testing and static testing
is that in structural testing tests are actually run by the computer on the built product,
whereas in static testing, the product is tested by humans using just the source code and
not the executables or binaries.
1) Unit/Code Functional Testing:
This initial part of structural testing corresponds to some quick checks that a
developer performs before subjecting the code to more extensive code coverage
testing or code complexity testing.
2.1 White Box Testing
B) Types of White Box Testing:
b) Structural Testing:
2) Code Coverage Testing:
Since a product is realised in terms of program code, if run test cases to exercise the
different parts of the code, then that part of the product realised by the code gets
tested. Code coverage testing involves designing and executing test cases and finding
out the percentage of code that is covered by testing. Code coverage testing is made
up of the following types of coverage.
i) Statement Coverage
ii) Path Coverage
iii) Condition Coverage
iv) Function Coverage

3) Code Complexity Testing:

In previous sections, we saw the different types of coverage that can be provided to
test a program. Two questions that come to mind while using this coverage are:
i) Which of the paths are independent? If two paths are not independent, then we
may be able to minimize the number of tests.
ii) There is an upper bound on the number of tests that must be run to ensure that all
the statements have been executed at least once.
2.1 White Box Testing
C) Advantages of White Box Testing:
The following are the advantages of white box testing:

• Verification
• Followed Processes
• Early Warnings
• Software Work Product

Advantages • Increased Effectiveness

• Full Code Pathway Capable
of White • Early Defect Identification
• Reveal Hidden Code Flaws
Box Testing • No Waiting
2.1 White Box Testing
C) Advantages of White Box Testing:

1) Verification:
White box testing is a primary method of verification.
2) Followed Processes:
Only white box testing can ensure that defined processes, procedures and methods of
development have really been followed during software testing. It can check whether the
coding standards, commenting and reuse have been followed or not.
3) Early Warnings:
White box testing or verification can give early warnings, if something is not done
properly. It is the most cost effective way of finding defects as it helps in reducing stage
contamination.
4) Software Work Product:
Some characteristics of software work product can be verified only. There is no chance of
validating them.
For example: code complexity, commenting styles and reuse.
5) Increased Effectiveness:
Crosschecking design decisions and assumptions against source code may outline a
robust design, but the implementation may not align with the design intent.
2.1 White Box Testing
C) Advantages of White Box Testing:

6) Full Code Pathway Capable:

All the possible code pathways can be tested including error handling, resource
dependencies and additional internal code logic/flow.

7) Early Defect Identification:

Analyzing source code and developing tests based on the implementation details enables
testers to find programming errors quickly.

8) Reveal Hidden Code Flaws:

Access to source code improves understanding and uncovering unintended hidden
behavior of program modules.

9) No Waiting:
Testing can be commenced at an earlier stage. One need not wait for the GUI to be
available.
2.1 White Box Testing
D) Disadvantages of White Box Testing:
White box testing being a verification technique has few shortcomings:

User Requirements

Set of Requirements

Dominated

Difficult to Scale

Difficult to Maintain

Cultural Stress

Highly Intrusive

Tools Not Readily Available:

Mechanic Work
2.1 White Box Testing
D) Disadvantages of White Box Testing:
1) User Requirements:
It does not ensure that user requirements are met correctly. There is no execution of
code, and one does not know whether it will really work or not.

2) Set of Requirements:
It does not establish whether decisions, conditions, paths, and statements covered
during reviews are sufficient or not for the given set of requirements.

3) Dominated:
Sometimes, white box testing is dominated by the usage of checklists. Some defects in
checklists may reflect directly in the work product One must do a thorough analysis of all
defects.

4) Difficult to Scale:
Requires intimate knowledge of target system, testing tools and coding languages, and
modeling. It suffers for scalability of skilled and expert testers.

5) Difficult to Maintain:
It requires specialized tools such as source code analyzers, debuggers, and fault injectors.
2.1 White Box Testing
D) Disadvantages of White Box Testing:

6) Cultural Stress:
The demarcation between developer and testers starts to blur which may become a
cultural stress.

7) Highly Intrusive:
Requires code modification has been done using interactive debuggers, or by actually
changing the source code. This may be adequate for small programs; however, it does
not scale well to larger applications. Not useful for networked or distributed systems.

8) Tools Not Readily Available:

Since this method of testing it closely tied with the application being testing, tools to
cater to every kind of implementation/platform may not be readily available.

9) Mechanic Work:
White Box Testing is like the work of a mechanic who examines the engine to see why
the car is not moving.
2.1 White Box Testing
E) Challenges in White Box Testing:
White box testing requires a sound knowledge of the program code and the programming
language. The following are the challenges of white box testing:

Human tendency of a developer being unable

to End the defects in his or her code

Fully tested code may not correspond to

realistic scenarios

1) Human tendency of a developer being unable to End the defects in his or her code:
As it saw earlier, most of us have blind spots in detecting errors in our own products.
Since white box testing involves programmers who write the code, it is quite possible
that they may not be most effective in detecting defects in their own work products. An
independent perspective could certainly help.
2) Fully tested code may not correspond to realistic scenarios:
Programmers generally do not have a full appreciation of the external (customer)
perspective or the domain knowledge to visualize how a product will be deployed in
realistic scenarios. This may mean that even after extensive testing, some of the common
user scenarios may get left out and defects may creep in.
2.2 Black Box Testing
Black box testing is an attesting methodology where product is tested as per software
specifications or requirement statement defined by business analysts/system
analysts/customer. Black box testing mainly talks about the requirement specification given
by customer or intended requirements as perceived by testers. It deals with testing of an
executable and is independent of platform, database, etc.

Requirement Specification

Input Output

Events
2.2 Black Box Testing
A) Black Box Testing Techniques:
Following are some techniques that can be used for designing black box tests:

Boundary
Equivalence Cause Eject Comparison Model-based
Value Fuzz Testing
Partitioning Graphing Testing Testing
Analysis

1) Equivalence Partitioning:
Equivalence Partitioning is a software test design technique that involves dividing input
values into valid and invalid partitions and selecting representative values from each
partition as test data.

2) Boundary Value Analysis:

Boundary Value Analysis is a software test design technique that involves determination
of boundaries for input values and selecting values that are at the boundaries and just
inside /outside of the boundaries as test data.
2.2 Black Box Testing
A) Black Box Testing Techniques:

3) Cause Eject Graphing:

Cause Effect Graphing is a software test design technique that involves identifying the
cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph
and generating test cases accordingly.
4) Comparison Testing:
Different independent versions of same software are used to compare to each other for
testing in this method.
5) Fuzz Testing:
Fuzz testing is often employed as a black box software testing technique, which is used for
finding implementation bugs using malformed / semi- malformed data injection in an
automated or semi-automated fashion. Fuzzing is also used to test for security problems
in software.
6) Model-based Testing:
Model-based testing is automatic generation of efficient test procedures/vectors using
models of system requirements and specified functionality. In this method, test cases are
derived in Whole or in part from a model that describes some aspects of the system
under test. These test cases are known as the abstract test suite and for their selection
different techniques have been used.
2.2 Black Box Testing
B) Types of Black Box Testing:
Black-box testing is a method of software testing that examines the functionality of an
application without peering into its internal structures or workings. The following are the
types of black box testing:

Functional System Integration

Testing Testing Testing

Incremental
Sanity End-to-end
integration
Testing Testing
Testing

Regression Stress
Testing Testing
2.2 Black Box Testing
B) Types of Black Box Testing:

1) Functional Testing:
Black-box type testing geared to functional requirements of an application; this type of
testing should be done by testers. This does not mean that the programmers should not
check that their code works before releasing it (which of course applies to any stage of
testing.)
2) System Testing:
Testing is based on overall requirements specifications; covers all combined parts of a
system.
3) Integration Testing:
Testing combined parts of an application to determine if they function together correctly.
The 'parts' can be code modules, individual applications, client and sewer applications on
a network, etc. This type of testing is especially mainly to client /server and distributed
systems.
4) Incremental Integration Testing:
Continuous testing of an application as new functionality is added; requires that various
aspects of an application's functionality be independent enough to work separately
before all parts of the program are completed, or that test drivers be developed as
needed; done by programmers or by testers.
2.2 Black Box Testing
B) Types of Black Box Testing:

5) End-to-end Testing:
Similar to system testing; the 'macro' end of the test scale; involves testing of a complete
application environment in a situation that mimics real-world use, such as interacting
with a database, using network communications, or interacting with other hardware,
applications or systems if appropriate.
6) Sanity Testing:
Typically an initial testing effort to determine if a new software version is performing well
enough to accept it for a major testing effort.
7) Regression Testing:
Re-testing after fixes or modifications of the software or its environment. It can be
difficult to determine how much re-testing is needed, especially near the end of the
development cycle. Automated testing tools can be especially useful for this type of
testing.
8) Stress Testing:
Term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy leads, heavy
repetition of certain actions or inputs, input of large numerical values, large complex
queries to a database system, etc.
2.2 Black Box Testing
C) Advantages of Black Box Testing:
The following are the advantages of Black Box Testing:

No Coding
Easy to
Skill
Execute
Required

Non Intrusive Ease of Use

Quicker Test
Unbiased
Case
Testing
Development

Advantages
Efficient
Testing of Black Box Simplicity
Testing
2.2 Black Box Testing
C) Advantages of Black Box Testing:

1) Efficient Testing:
Well suited and efficient for large code segments or units.

2) Unbiased Testing:
Clearly separates user’s perspective from developer’s perspective through separation of
QA and Development responsibilities.

3) Non Intrusive:
Code access not required.

4) Easy to Execute:
It can be scaled to large number of moderately skilled testers with no knowledge of
implementation, programming language, operating systems or networks.

5) No Coding Skill Required:

Tester need not know programming languages or how the software has been
implemented.
2.2 Black Box Testing
C) Advantages of Black Box Testing:

6) Ease of Use:
Because testers do not have to concern themselves with the inner workings of an
application, it is easier to create test cases by simply working through the application, as
would an end user.

7) Quicker Test Case Development:

Because testers only concern themselves with the GUI, they do not need to spend time
identifying all of the internal paths that may be involved in a specific process, they need
only concern themselves with the various paths through the GUI that a user may take.

8) Simplicity:
Where large, highly complex applications or systems exist black-box testing offers a
means of simplifying the testing process by focusing on valid and invalid inputs and
ensuring the correct outputs are received.
2.2 Black Box Testing
D) Disadvantages of Black Box Testing:
The following are the disadvantages of black box testing:

Lack of Localized
Introspection Testing

Inefficient
Script
Test
Maintenance
Authoring

Blind
Redundant
Coverage
2.2 Black Box https://www.guru99.com/black-box-testing.h

Testing
ml

D) Disadvantages of Black Box Testing:

1) Localized Testing:
Limited code path coverage since only a limited number of test inputs are actually tested.
2) Inefficient Test Authoring:
Without implementation information, exhaustive input coverage has unknown additional
benefits to the actual code paths exercised and can require tremendous resources.
3) Blind Coverage:
The testing cannot control targeting code segments or paths which may be more error
prone than others
4) Redundant:
Tests can be redundant if the software designer/ developer has already run a test case.
5) Script Maintenance:
While an image-based approach to testing is useful, if the user interface is constantly
changing the input may also be changing. This makes script maintenance very difficult
because black-box tools are reliant on the method of input being known.
6) Lack of Introspection:
Ironically, one of the greatest criticisms of black-box testing is that it is not more like
white-box testing; that it does not know how to look inside an application and therefore
can never fully test an application or system.
2.2 Black Box Testing
E) Differences between White Box and Black Box Testing:
Basis White Box Testing Black Box Testing
Purpose It is concerned only with the testing of software It is concerned only with testing specifications and does
and does not guarantee the complete not guarantee that all the components of the software
implementation of all the specifications that are implemented are tested.
mentioned in user requirements.

Stage It is performed in the early stages of testing. It is performed in the later stages of testing.

Requirement Knowledge of the internal structure of a program No knowledge of the internal structure of a program is
is required for generating test cases. required to generate test cases.

Test Case Here test cases are generated based on the Here the internal structure of modules or programs is
actual code of the module to be tested. not considered for selecting test cases.

Example The inner software present inside the calculator In this testing, it is checked whether the calculator is
(which is known by the developer only) is working properly or not by giving inputs by pressing the
checked by giving inputs to the code. buttons in the calculator.
2.3 Gray Box Testing
Gray box testing is done on the basis of internal structures of software as defined by
requirements, designs, coding standards, and guidelines as well as the functional and
non-functional requirement specifications. Gray box testing combines verification techniques
with validation techniques where one can ensure that software is build correctly, and also
works. Figure shows a gray box testing schematically.

Requirement and Design Specification

Input Output

Events, Standards
2.3 Gray Box https://www.guru99.com/white-box-testing

Testing
ml

A) Gray Box Testing Techniques:

The following are the techniques of gray box testing:

Matrix
Testing

Orthogonal Regression
Array Testing Testing

Pattern
Testing
2.3 Gray Box Testing
A) Gray Box Testing Techniques:

1) Matrix Testing:
It starts with developers defining all the variables that exist in their programs. Each
variable will have an inherent technical risk, business risk and can be used with different
frequency during it’s’ life cycle.
2) Regression Testing:
This testing is performed after making a functional improvement or repair to the
program. Its purpose is to determine if the change has regressed other aspects of the
program.
3) Pattern Testing:
It is best accomplished when historical data of previous system defects are analyzed.
Analysis will include specific reasons for the defect, which will require system analysis.
Unlike black box testing where the tracking the type of failures that are occurring, gray
box testing digs within the code and determines why the failure happened.
4) Orthogonal Array Testing:
Orthogonal Array Testing is a statistical testing technique implemented by Taguchi. This
method is extremely valuable for testing complex applications and e-comm products. The
e-comm world presents interesting challenges for test case design and testing coverage.
2.3 Gray Box Testing
B) Advantages of Gray-Box Testing:
The following are the advantages of gray box testing:

Offers
Combined
Benefits

Unbiased
Non Intrusive
Testing

Intelligent Test
Authoring
2.3 Gray Box Testing
B) Advantages of Gray-Box Testing:

1) Offers Combined Benefits:

Leverage the strengths of both Black Box and White Box testing, wherever possible.

2) Non Intrusive:
Gray Box does not rely on the access to source code or binaries. Instead, is based on
interface definitions, functional Specifications and application architecture.

3) Intelligent Test Authoring:

Based on the limited information available, a Gray Box tester can author intelligent test
scenarios, especially around data type handling, communication protocols, and exception
handling.

4) Unbiased Testing:
The demarcation between testers and developers is still maintained. The handoff is only
around interface definitions and documentation, without access to source code or
binaries.
2.3 Gray Box Testing
C) Disadvantages of Gray-Box Testing:
The following are the disadvantages of gray-box testing:

Partial Code
Coverage Defect
Identification

1) Partial Code Coverage:

Since the source code or binaries are not available, the ability to traverse code paths is
still limited by the tests deduced through available information. The coverage depends
on the tester authoring skills.

2) Defect Identification:
Inherent to distributed applications is the difficulty associated in defect identification.
Gray box testing is still at the mercy of how well systems throw exceptions, and how well
are these exceptions propagated with a distributed Web Services environment.
 2.3 Gray Box Testing

tween the White Box, Black

Basis BoxTesting
White Box and Gray Box Testing:
Black Box Testing Gray Box Testing
Internal Working The Internal Workings of an application Somewhat knowledge of the internal Tester has full knowledge of the Internal
are not required to be known workings are known workings of the application

Known As Also known as closed box testing, data Another term for grey box testing is Also known as clear box testing,
driven testing and functional testing translucent testing as the tester has structural testing or code based testing
limited knowledge of the insides of the
application

Performed By Performed by end users and also by Performed by end users and also by Normally done by testers and developers
testers and developers testers and developers

Based -Testing is based on external expectations Testing is done on the basis of high Internal workings are fully known and the
-Internal behavior of the application is level database diagrams and data flow tester can design test data accordingly
unknown diagrams

Time This is the least time consuming and Partly time consuming and exhaustive The most exhaustive and time
exhaustive consuming type of testing
Algorithm Not suited to algorithm testing Not suited to algorithm testing Suited for algorithm testing
testing
Testing Method This can only be done by trial and error Data domains and Internal boundaries Data domains and Internal boundaries
method can be tested, if known can be better tested
2.4 Levels of Testing
Testing is usually relied upon to detect these faults, in addition to the faults introduced
during the coding phase itself. For this, different levels of testing are used, which perform
different tasks and aim to test different aspects of the system. The various levels of testing
are unit testing, integration testing, system testing, and acceptance testing. Unit testing
checks the modular design (independent units) of software.

A) Unit Testing:
This type of testing is performed by the developers before the setup is handed over to the
testing team to formally execute the test cases. Unit testing is performed by the
respective developers on the individual units of source code assigned areas. The
developers use test data that is separate from the test data of the quality assurance team.
a) Types of Unit Test:
The following are the types of unit test :

Error
Module Boundary Independent
Handling
Interface Conditions Paths
Paths
2.4 Levels of Testing
A) Unit Testing:
a) Types of Unit Test:

1) Module Interface:
These are tested to ensure that information flows in a proper manner into and out of
the ‘unit’ under test. Note that test of data-flow (across a module interface) is
required before any other test is initiated. O Local data structure: These are tested to
ensure that the temporarily stored data maintains its integrity while an algorithm is
being executed.

2) Boundary Conditions:
These are tested to ensure that the module operates as desired within the specified
boundaries.

3) Independent Paths:
These are tested to ensure that all statements in a module have been executed at
least once. Note that in this testing; the entire control structure should be exercised.

4) Error Handling Paths:

After successful completion of the various tests, error-handling paths are tested.
2.4 Levels of Testing
A) Unit Testing:
b) Reasons for Unit Testing:
There are many reasons why unit testing should be adopted these reasons are as follows:

Faster Debugging

Better Design and Documentation

Better Feedback Mechanism

Good Regression Tool

Reduce Future Cost

2.4 Levels of Testing
A) Unit Testing:
b) Reasons for Unit Testing:
1) Faster Debugging:
Without unit testing, the time it takes to debug or resolve a functional test that may have
failed takes a long time to track down.
2) Better Design and Documentation:
Writing unit tests forces developers into thinking how their code is going to be used and
has generally resulted in better design and even better documentation.
3) Better Feedback Mechanism:
When all unit tests for a system are run as a whole, the state of the system as a whole
can be measured. Unit tests also provide other developers with an instant mechanism of
evaluating whether other parts of the code base are meeting their requirements or are
still under development.
4) Good Regression Tool:
A comprehensive unit test suite enables major re-factorings and restructuring of the code
base to be completed with greater confidence.
5) Reduce Future Cost:
Many studies have proved that it costs significantly more money to fix a bug found later in
its release than earlier in its development.
2.4 Levels of Testing
A) Unit Testing:
c) Disadvantages of Unit Test:
The following are disadvantages of unit test:

Benefits not
Fully
Recognised or
Evaluated

Poor No Time Was

Development Allocated For
Attitude Unit Testing

Difficult to Difficult to
Manage Write
2.4 Levels of Testing
A) Unit Testing:
c) Disadvantages of Unit Test:
1) Benefits not Fully Recognised or Evaluated:
The benefits mentioned in the previous section may not have been identified and valued
by members of the software engineering team. As a result, their software project misses
out on the value-added proposition that unit testing offers.
2) No Time Was Allocated For Unit Testing:
Writing unit tests takes time for a developer to write. Thus it can be difficult to meet
deadlines if time is not budgeted to include the time it takes to write unit tests as well as
the code that meets the requirements.
3) Difficult to Write:
There was no easy way for unit tests to be written in a manner that was easy, giving
developers less of an incentive to write unit tests.
4) Difficult to Manage:
The ad-hoc nature of which the unit tests had to be written prior to Unit meant that
projects had to develop their own standard for writing and managing their unit tests.
5) Poor Development Attitude:
Some developers assume that their code will operate exactly the way they think the first
time around. As a result, there is no guarantee that when changes are made to that code
in the future that the intended behaviour does not change.
2.4 Levels of Testing
B) Integration Testing:
Integration testing involves integration of units to make a module/integration of modules
to make a system integration of system with environmental variables if required to create
a real-life application. Integration testing may start at module level, where different units
and components come together to form a module and go up to system level. Integration
testing is considered as ‘structural testing’. Figure shows a system schematically.

System

Module 1 Module 2 Module 3

Unit 1 Unit 2 Unit 3

2.4 Levels of Testing
B) Integration Testing:
a) Bottom-Up Testing:
Bottom-up testing approach focuses on testing the bottom part/individual units and
modules, and then goes upward by integrating tested and working units and modules for
system testing and intersystem testing. The process goes as mentioned below. Figure
shows a bottom-up integration and testing.

System

Module 1 Module 2 Module 3

Unit 1 Unit 2 Unit 3

2.4 Levels of Testing
B) Integration Testing:
b) Top-Down Testing:
In top-down testing approach, the top level of the application is tested first and then it
goes downward till it reaches the final component of the system. All top-level
components called by tested components are combined one by one and tested in the
process. Here, integration goes downward. Top-down approach needs design and
implementation of stubs.

System

Module 1 Module 2 Module 3

Unit 1 Unit 2 Unit 3

2.4 Levels of Testing
B) Integration Testing:
c) Modified Top-Down Approach:
Modified top-down approach tries to combine the better parts of approaches, viz.
top-down approach and bottom-up approach. It gives advantages of top-down approach
and bottom-up approach to some extent at a time, and tries to remove disadvantages of
both approaches. Development must follow a similar approach to incorporate modified
top-down approach.

System

Module 1 Module 2 Module 3

Unit 1 Unit 2 Unit 3

2.4 Levels of Testing
C) Big-Bang Testing:
Big-bang approach is the most commonly seen approach at many places, where the
system is tested completely after development is over. There is no testing of individual
units/modules and integration sequence. System testing tries to compensate for any
other kind of testing, reviews etc. Sometimes, it includes huge amount of random testing
which may not be repeatable.
a) Advantages of Big-Bang Testing:
The following are the advantages of Big-bang testing:

Validation of
Limiting
Development
Testing
Process

No
Stub/Driver Very Fast
is Required
2.4 Levels of Testing
C) Big-Bang Testing:
a) Advantages of Big-Bang Testing:

1) Limiting Testing:
It gives a feeling that cost can be saved by limiting testing to last phase of development.
Testing is done as a last-phase of the development life cycle in form of system testing.
Time for writing test cases and defining test data at unit level, integration level etc may
be saved.
2) Validation of Development Process:
If all levels of testing are completed and all defects are found and closed then system
testing may act as certification testing to see if there are any major issues still left in the
system before delivering it to the customer.
3) No Stub/Driver is Required:
No stub/driver is required to be designed and coded in this approach. The cost involved is
very less as it does not involve much creation of test artifacts. Sometimes test plan is also
not created.
4) Very Fast:
Big-bang approach is very fast. It may not give adequate confidence to users as all
permutations and combinations cannot be tested in this testing. Even test log may not be
maintained. Only defects are logged in defect tracking tool.
2.4 Levels of Testing
C) Big-Bang Testing:
b) Disadvantages of Big-Bang Testing:
The following are the disadvantages of big-bang testing

Hard to
Debug

Syst em
emW Syst aces
ork rf
Inte

lt
O i cu
De ther ff
Di to te
fec
t ca
Lo
2.4 Levels of Testing
C) Big-Bang Testing:

b) Disadvantages of Big-Bang Testing:

1) Hard to Debug:
Problems found in this approach are hard to debug. Many times defects found in random
testing cannot be reproduced as one may not remember the steps followed in testing at
that particular instance.
2) System Interfaces:
It is difficult to say that system interfaces are working correctly and will work in all cases.
Big-bang approach executes the test cases without any understanding of how the system
is build.
3) Difficult to Locate:
Location of defects may not be found easily. In big bang testing, even if it can reproduce
the defects, it can be very difficult to locate the problematic areas for correcting them.
4) Other Defects
Interface faults may not be distinguishable from other defects.
5) System Work:
Testers conduct testing based on few test cases by heuristic approach and certify
whether the system works/does not work.
2.4 Levels of Testing
D) Sandwich Testing:
Sandwich testing defines testing into two parts, and follows both parts starting from both
ends i.e., top-down approach and bottom-up approach either simultaneously or one after
another. It combines the advantages of bottom-up testing and top-down testing at a time. A
typical approach to sandwich testing is to test the user interface in isolation, using
stubs(अडचण), and also to test the very lowest level functions, using drivers.

System

Sub Sub Sub

System 1 System 2 System 3

Unit 1 Unit 2 Unit 3

2.4 Levels of Testing
D) Sandwich Testing:
a) Process of Sandwich Testing:
The following are the process of sandwich testing:

Upward Downward Middle Layer

1) Upward:
Bottom-up testing starts from middle layer and go upward to the top layer. Generally for
very big systems, bottom-up approach starts at subsystem level and goes upwards.

2) Downward:
Top-down testing starts from middle layer and goes downward. Generally for very big
systems, top-down approach starts at subsystem level and goes downwards.

3) Middle Layer:
Big-bang approach is followed for the middle layer. From this layer, bottom-up approach
goes upwards and top-down approach goes downwards.
2.4 Levels of Testing
D) Sandwich Testing:
b) Advantages of Sandwich Testing
The following are the advantages of sandwich testing:

Useful for
Development More
Very Large
Schedule Resources
Project

1) Useful for Very Large Projects:

Sandwich approach is useful for very large projects having several sub-projects. When
development follows a spiral model and the module itself is as large as a system, then one
can use sandwich testing.

2) Development Schedule:
Both top-down and bottom-up approaches start at a time as per development schedule.
Units are tested and brought together to make a system. Integration is done downwards.

3) More Resources:
It needs more resources and big teams for performing both methods of testing at a time
or one after the other.
2.4 Levels of Testing
D) Sandwich Testing:
c) Disadvantages of Sandwich Testing
The following are the disadvantages of sandwich testing:

Cannot be Used
High Cost of Different Skill
for Smaller
Testing Sets
Systems

1) High Cost of Testing

It represents very high cost of testing as lot of testing is done. One part has top-down
approach while another part has bottom-up approach.

2) Cannot be Used for Smaller Systems:

It cannot be used for smaller systems with huge interdependence between different
modules. It makes sense when the individual subsystem is as good as complete system.

3) Different Skill Sets:

Different skill sets are required for testers at different levels as modules are separate
systems handling separate domains like ERP products with modules representing different
functional areas.