CHAPTER

9
LEVELS OF TESTING

OBJECTIVES
This chapter details verification and validation activities associated with various stages of software
development life cycle starting from proposal. It also covers various ways of integration
testing

As seen in V testing' approach earlier, testing is a life-cycle activity which

starts at the time of proposal and ends when
9.1 INTRODUCTION acceptance testing is completed
and product is finally delivered to
customer. Testing begins with a proposal
the system is
forsoftware/system application development/maintenance, and ends when
formally accepted by user/customer. Different agencies/stakeholders are involved in
specialised testing required for the specific application. Definition of these conducting
on the type of stakeholders/agencies
testing involved and level of testing to be done in various stages of software depends
cycle. Table 9.1 shows in brief the level of testing performed by different development life
which may differ from customer to customer, agencies. It is an indicative list
product to product and organisation to organisation.

9.2 PROPOSALTESTING
A proposal is made to the customer on the basis of Request for Proposal (RFP) or
(RFI) or Request for Quotation (RFQ) by the customer. Request for Information
Before making
understand the purpose of such request, and devise the proposed solution any proposal, the supplier must
customer problem and the possible solution. Any proposal accordingly. One must understand
prepared in response to such request is
by an organisation before sending it to the customer. It 1s reviewed reviewed
by ditferent panels or
organisation such as technical group and cpmmercial group. The intention is to ensure that the groups in the
must be able to stand by its words, the proposal getS converted into
if a contract. The
organisation
the impact of proposal on the organisation as well as on the organisation must assess
prospect/customer.
TechnicalReview Technical review mainly involves
technical feasibility
h e availabilíty and requirement of skill sets, the
of the kind of system or application
cal is also reviewed on the basis of time hardware/software and other
required
for requirements of
developing such
required to make the proposal suceeest, The technical proposal is a
description of overailsystem, and efforts
approach, and not
 sOFTWARE TESTING: Levels of Testing 223
Principles, Techniques and Tools
Table9.1 Different agencies
involved at different may be specific, generic, present, future,
legal, operational and system requirements. Similarly, requirements these
levels of be unaware of many of requirements. The business analyst
Testing testing expressed, implied, etc. The customer may
and solution that the customer is
and system analyst must study the customer's line of business, problem
or intended requirement is a gray area
Proposal review
Customer, Business Agencies involved looking for before arriving at these requirements. Assumed, implied makes sure that requirements
and may be a reason for many defects in the final product. Requirement testing
CUstomer, Business Analyst, System Analyst Project Manager
Proposal testing criteria.
defined in requirement specifications meet the following
Requirement review Analyst, System Analyst,
CUstomer, Project
Leader Business Analyst, System Analyst, Project Manager
is from them. Requirements
Clarity Allrequirements must be very clear in their meaning and what expectedthe
Requirements testing Manager, Project Leader, Test clearly what the expected result of each transaction is, and who are actors taking part in the
must state very
Customer,
Leader BusinessAnalyst, System Analyst, Project Manager,
must be removed or clarified.
transactions. Anything which hampers the clarity of requirements
Design review Customer, Project Leader, Test
Design testing
Leader, TestBusiness Analyst, System Analyst,
Leader, Developer Architect, Project Manager, Project
CUstomer, Business
Leader, Test Leader, Analyst, System Analyst, Architect, Project
llustration 9.1

Code review Developer

Project Leader, Project Manager, Project Many requirement statements have words ike Application must be userfriendly or 'Application performance must be

Test artifact review Team, Customer fair Such requirements cannot be implemented as nobody knows the exact requirements
One may have to raise queries to understandthe meaning of user friendlyness or fair perfomance. If possible such
Project Leader, Project
Unit testing Team,
Project Leader, Project Team, CUstomer, Tester, Test Leader
statements must have some numeical figures to illustrate them.Tester will be able to wnte exact test case on the basis
of these numbers.
Module testing Project Leader, Project Custormer
Integration testing Project Leader, Project
Team, Tester, Customer
System testing Project Manager, Test
Team, Tester, Customer Complete Requirement statement must be complete and must talk about all business aspects of the
Acceptance testing Leader, Tester Customer application under development. It must consider all permutations and combinations possible when application
Project Manager, Tester,
User/Customer is used in production. Any assumption must be documented and approved by the customer.

the final
accepted approach solution/method and
with customer. undergo many iterations of
Requirement and estimations at themay
indicative. It works on stage of proposal are not very changes but per discussions
as
lustration 9.2
rough-cut methods, and estimations are specific rather, they are
Commercial Review A ball-park figures that prospect may expect.
proposal undergoes financial feasibility Sometimes requirement statement does not speciiy the transaction. li requirement statement says Enter valid Login and
With respect to the Password, then it is not a complete
business. Commercial review and other types of feasibilities involved to Password. It could be
requirement
as (it
not does speciy how one should enter valid Login and now to go
in terms of may stress on the gross margins of the by Tab' by clicking the mouse or it will automaticaly go to Password)
or
money going out and coming in the project and fund flow fany part of transaction requires an assumption, it indicates incomplete requirements. One has to go back to cus
into installations
depending upon development organisation. Generally, total tomer or business analyst/system analyst to get this clanfied
completion
of phases of
some payment is split
completed, money is realised at those
instances. development
activity. As different phases are
Several iterations of
tor
Quotation (RFQ) and
proposals and scope changes may happen before all the
proposal agree on some terms and conditions for parties involved in Request Measurable
project.
a doing Requirements must be measurable in numeric terms as far as possible. Such definition helps
Validation of Proposal to
understand whether the requirement has been met or not while testing the application. Qualitative tems like
to Aproposal sometimes involves development of
explain the proposed
customer problem in the
approach to the prototypes or
proof of concept
problem of the customer. One must define the approach
good, 'suficient', and 'high' must be avoided as different people may attach diferent
meanings to these words.
model or prototype. of handling
n case of product
decide about the new organisation,
the product development
group along with marketing and sales
release of a functions
product. llustration 9.3
9.3 REQUIREMENT TESTING
Sometimes, requirenment statement may states that-enter valid credential and click Login to
very clear how mucth time it will take to reach next go to next page. tisine
Requirement creation involves These can not be vernied under page
and validate gathering customer requirements and arranging
them in a form to
usability as performance testin9
them. The
requirements may be categorised into different types such as technical, verify
economical,
 ECnnques analools
Testable The Levels of Testing 225
requirement must help in creating use
application. Any requirement
be achieved which cases/scenario
by implementing these cannot be tested must be drilled downwhich can be used for testing the
requirements. further, to understand what is to 9.5 CODE REVIEW
Not
Conflicting The
between quality factors requirements must not conflict with each procedures, and
which needs to be Code reviews include reviewing code files, database schema, classes, object definitions,
problem in requirement collection agreed by the customer. other. There is possibility of trade-off
a
methods. Code review is applied to ensure that the design is implemented correctly by the developers, and
process. Conflicting requirements indicate possible followed Code must
correctly.have following
ldentifiable The guidelines and standards available for the purpose of coding are
way which can help in requirements must be distinctively identifiable. characteristics.
creating requirement They must have numbers some other
Validation of traceability matrix. Indexing or
requirement is very important.
Clarity Code must be written correctly as per coding standards and syntax, requirements torthe grven
statement. No Requirements
assumption is to be made Requirement testing involves writing use
platform. It must follow the standards and guidelines defined by the organisation/project/customer,as thecase
may be. It must declare variables, functions, and loops very clearly with proper comments. Code commenting
while using requirement
cases
cases can be
developed using the requirement writing use cases from requirement statement. must include which design part has been implemented, author, date, revision number, etc so that it can be

measurable, testable and not statement, requirements can be considered as If complete use traced to requirements and design.
statement. One has to ask the confilicting with each other. Each assumption indicates clear, complete,
customer whether the lacunae in Complete Code, class, procedure, and method must be complete in allrespect.It must suffice the purpose
the customer,
requirement statements must be updated. requirement
assumptions are correct or not. As per feedback for
given by for which it is created. One class doing multiple things, or multiple objects samecreated
a problem in design. Code must be readable and compilable. Proper indenting, and variable nitialisation
purpose ndicates
9.4 DESIGNTESTING must be followed as defined by coding standards.
Once the
requirement statement satisfies all characteristics defined Traceable Code must be traceable with design components. must It declare clearly about the
be considered
no traceability to design
etc. Code files as
system high-level architectural designing. The above, the system architect starts with requirements, design, author, date, having can

requirements. The system designer starts building designs made by system architects must
the low-level or detail
be traceable to redundant code which will never get executed even if design is correct.

design. Low-level design must be traceable to architectural design with the help of architectural Maintainable Code must be maintainable. Any developer with basic knowledge and training about
The design must also possess the characteristics design which in turn is traceable to
given
below. requirements. coding must be able to handle the code in future while maintaining or bug fixing it
Clarity A design must define all
functions, components, tables, stored procedures, and reusable
components very clearly. It must define any 9.6 UNIT TESTING
interdependence between different components and inputs/
outputs from each module. It must cover the information to and from the
application to other systems. Unit is the smallest part of a software system which is testable. It may include code files, classes and methods
Complete A design must be
complete in all respect. It must define the parameters to be which can be tested individually for correctness. Unit testing is a validation technique using black box
formats of data handled, etc. Once the
design is finalised, programmers must do their work of passed/received, methodology. Black box testing mainly concentrates on requirements of the system. In unit testing.units are
designs mechanically and system must be working implementing tested for the design in addition to requirements as low-level design defines the unit.
properly.
Traceable design must be traceable to requirements. The second column of
A
are tested to ensure that they work correctly as an individual as defined
matrix is design column. The project manager must check if there is any requirement
a requirement traceability Individual components and units
which does not have in design
corresponding design or vice versa. It indicates a defect if traceability cannot be established requires throwaway drivers and stubs as individual files may not be testable or executable
testing
completely. Unit
Implementable A design must be made in such a way that it can be implemented easily with selected without them
the
technology and system. It must guide the developers in coding and compiling the code. The design must include Unit testing may be performed in debugger mode how
to findvariable
the are
execution. But, it may not be termed 'black box testing' in such case as code is seen in
values changed during
interface requiremènts where different components are
communicating with each other and with other systems. Gray box testing is also considered as unit testing technique' sometimes as it cxamines the code m
debugging
Testable Testers make structural test cases on the basis of design. Thus, good design code and
in creating structural test cases.
a must help testers detail along with its functioning. Gray box testing may need some tools which can check the
functionality at the same time.
Validation of Design Design testing includes creation of data flow diagrams, activity diagrams, .Unit test cases must be derived from use cases/design component used at lowest levels of designs.
information fow diagram, and state transition diagram to show that information can flow through the system
Where the fow gets interrupted, it indicates that design is not complete. Flow of data and 9.6.1 DIFFERENCE BETWEEN DEBUGGING ANDTESTING
completely.
information in the system must complete the loop. It must consider the data definitions, attributes and input/ Many developers consider unit testing and debugging as the same thing. In reality there is no connection
output formats. Another way of testing design is creating prototypes from design. between the two. Difference between them can be illustrated as shown in Table 9.2
 SOFTWARETESTING: Principles,
Table 9.2 Techniques and Tools Levels ofTesting 227
Difference between
debugging and unit testing how the system is integrated. Different
Debugging There are various approaches of integration testing depending upon
It involves code checking have different benefits and limitations
to approaches
locate the causes Unit testing
Code may be updated during of defect
t checks the
The test cases are
debugging defect and not the causes of the
9.8.1 BOTTOM-UP TESTING
units and modules, and then goes
not defined for
debugging
t does not involve
any correction of code defect Bottom-up testing approach
focuses on testing the bottom part/individual The
Generally covers positive cases modules for system testing and intersystem testing.
to see Test cases dehned based on
are
upward by integrating tested and working units and
works whether unit bottom-up integration and testing.
Covers positive as well negativerequirements
correctly or not and design as mentioned below,. Figure 9.2 shows a
as process goes
cases
are designed for a special pur-
stubs/drivers. Stubs and drivers
9.7 MODULE TESTING Units at the lowest level are tested using
must be tested before using them
for unit testing.
pose. They combined to form modules.
Modules may
Once the units are tested and
found to be working, they are
Many units come tested and found to be working may
act as
its execution, if thetogether
and form a units which are already
module. The module need only drivers, as the low-level
module cannot be may work of its own or
needs stubs and compiled into an executable. If the module can
is tested by tester. If it may need stubs/drivers for stubs. WIite the stubs
one goes upward. Developers may
are designed for testing as
testing mainly concentrates on the drivers, developers must create the work lfrequired, drivers and stubs
structure of the same and independently, it the input/output parameters must be
known while designing.
system. perform testing. Module and drivers as
termed 'classical approach' as it may
indicate a normal wayof doing things.
Module testing is done Bottom-up approach is also to imnplement.
on related unit-tested but practically, it is very difficult
work together as a components to find whether Theoretically, it is an excellent approach next level is taken. This gives very
module or not. individually the hierarchy is tested first and then
Module test cases tested units can Each component which is lowest in
must be traceable to software. But, it is a time consuming approach.
low-level design. requirements/design. Generally, module test cases are derived from
defect-free
robust and

9.8 INTEGRATIONTESTING System

Integration testing involves integration of units to make a
integration of system with environmental variables if module/integration of modules to make a system/ Module3
Integration testing may start at module required to create a real-life application. Mod ule 1 Module 2
level, where different units and
a module, and go upto system level. If module is self components come
together to formm
needs stubs and executable, it may be taken for testing by testers. If it
drivers, it is tested by developers.
Though integration testing also tests the functionality of software under
review, the main stress of integration
Unit 1 Unit2 Unit 3
testing is on the interfaces between different modules/systems.
output protocols, and parameters passing between different units, Integration testing mainly focuses on input
modules and/or system. Focus of Fig.9.2 Bottom-up integration approach
is mainly on low-level integration
design, architecture, and construction of software. Integration testing is considered as
'structural testing'. Figure 9.1 shows a system
schematically suitable for the foilowing.
Bottom-up approach is

System objects
where designed and tested individually before using them
are in a system.
Object-oriented design are already tested
calls the same object, we know that they are working correctly (as they
When the system
and found to be working in unit testing). bottom
routines which are used across the application,
Low-level components are general-purpose utility
libraries.
This approach is used extensively in defining
Module 1 Module 2 Module3 up
recommended
testing is the approach.

Stubs/Drivers to test the units individually

Stubs/drivers are special-purpose arrangements, generally code, required
from the unit/module
Unit 1 Unit 2 Unit 3 which can act as an input to the unit/module and can take output
stub may take care
called function. In absence ofa called function,
Stub Stub is a piece of code emulating a
Fig.9.1 Integration testing view of that part for testing purpose.
 RE
TESTING:
Principles, Techniques and Tools
Driver Driver is a Too Levels of Testing
of code under piece of code 229
testing, driver tries toemulating
work
a
calling function. In absence of
as a
calling function. actual function
calling the piece
Stubs are
mainly created
integration testing like for integration testing like top-down System
Stubs/drivers must be verybottom-up approach. approach. Drivers are mainly created for
Most of the simple to
times, they are software develop and use. They must not
delivering code to customer/user. programs, but it is not rule. introduce any defect in the application. Module 1
Reusability of stub/driver can
a
Stubs/drivers must be taken away before Module 2 Module3
can be
big challenge.
a improve productivity, while
Estimation must consider time designing and coding
multipurpose stub/driver
a
required for creating stubs/drivers. Unit 1 Unit 2 Unit 3
Advantages of
Bottom-Up Approach
Each
component and unit is tested first for its correctness.
Fig.9-3 Top-down integration approach
goes for further If it found
I t makes a integration. to be working correctly, then only it
system more robust
since individual units are Advantages of Top-Down Approach
Incremental integration Feasibility ofan entire program can be determined easilyat a very early stage as the topmost layer, general-
testing is useful where individualtested and confirmed as working ly user interface, is made first. This approach is good if the application has user interface as a major part.
components can be tested in integration Top-down approach can detect majorflaws in system designing by taking inputs from the user. Prototyping
Disadvantages of
Bottom-Up Approach is
used extensively in agile application development where user requirements can be clarified by preparing
Top-evel components are the most amodel. Ifsoftware development is considered as an activity associated with user learning,
important but tested last, where the pressure
problem of not completing testing. There then prototyping
can be of delivery may cause gives an opportunity to the user to learn things.
system-level functioning may be a problem. major problems during integration or interface testing, or Many times top-down approach does not need drivers as the top layers are available first which can work
Objects
are combined one at a time, which as drivers for the layers below.
may need longer time and result into
required for complete testing may be very slow testing. Time
Designing and writing stubs and drivers forlong and thus, it may disrupt entire
delivery schedule. Disadvantages of Top-DownApproach
in
system testing is waste of work as
they do not form part of fina
Units and modules are rarely tested alone before their integration. There may befew
problems individual
units/modules which may get compensated/camouflaged in testing. The compensating defects cannot be
Stubs and drivers are to be
written and tested before found in such integration
to maintain the review and using them in integration testing. One needs
test records of stubs and driver to This approach can create a false software can be coded and tested before design is
beliefthat finished. One
ensure that they do not introduce
defect.
F o r initial
any must understand that prototypes are models and not the actual system. The customer may get a feelingthat
phases, one may need both stubs and drivers. As one the system is already ready and no time is required for delivering it for usage.
goes on
integrating units,
drivers may be required (which are to be thrownoriginal testing. Stubs mustbe simple
stubs may be used while large number of new Stubs are to be written and tested before they can be used in integration as
at the as possible, and must not introduce any defect in the software. Large number of stubs may be required
end).
which are to be thrown at the end.

9.8.2 TOP-DOWN TESTING 9.8.3 MODIFIED TOP-DOWN APPROACH

viz.
In top-down testing
approach, the top level of the application is tested first and then it goes downward till
Modified top-down approach tries to combine the better parts of both approaches, top-down approuch
and bottom-up approach. It gives advantages of top-down approach and bottom-up approach to some extent
it reaches the final component of the
system. All top-level components called by tested components are at a time, and tries to remove disadvantages of both approaches. Development must follow a similar approach
combined one by one and tested in the process. Here, integration goes downward. to incorporate modified top-down approach. The main challenge is to decide on individual module/unit
Top-down approach needs
design and implementation of stubs. Drivers may not be required as we go downward as earlier phase will act
testing for bottom-up testing as normal testing may start from top.
as
driver for latter phase while one may have to design stubs to take care of lower-level
are not available at that time.
which components Tracking and effecting changes is most important as development and testing startat two extremeendsa
a time. Any change found at one place may affect another end. Care must be taken that the two approaches
Top-level components are the user interfaces which are created first to elicit user requirements or creation must meet somewhere in between. Configuration management is very important for such an
of prototype. Agile approaches like prototyping, formal proof of concept, and test-driven development use Figure 9.4 shows a modified top-down integration and testing
approa
this approach for testing. Figure 9.3 shows a top down integration and testing.
 WARETESTING: Principles,
Techniques and Tools Levels of Testing 231

I f an organisation has optimised processes, this approach can be used as a validation of development
process and not a product validation. If all levels of testing are completed and all defects are found and
System 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.
.No stub/driver is required to be designed and coded in this approach. The cost involved is very less as it

Module 1 Module 2 Module3

does not involve much creatíon of test artifacts. Sometimes test plan is also not
.Big-bang approach is very fast. It may not give
adequate confidence to users as
created.
and
all permutations
combinations cannot be tested in this testing. Even test log may not be maintained. Only defects are
logged in defect-tracking tool.
Unit 1
Unit 2 Unit 3
Disadvantages of Big-Bang Approach
Problems found in this approach are hard to debug. Many times defects found in random testing cannot be
Fig. 9.4 Modified Top-down at that particular instance.
integration approach reproduced as one may not remember the steps followed in testing
I t is difficult to say that system interfaces are working correctly and will work in all cases. Big-bang
Advantages of Modified Top-Down approach executes the test cases without any understanding
of how the system is build
Important units tested
are Approach
individually, then combined to form the Location of defects may not be found easily. In big bang testing, even if we
can reproduce the defects, it

tested before system is made. Tnis is can be very difficult to locate the problematic
for
correcting
areas them.
The systems tested by done during unit modules, and finally, the modules are Interface faults may not be distinguishable from other defects.
modified approach are testing followed
used for critical better in terms of residual by integration testing. Testers conduct testing based on few test cases by heuristic approach and certify whether the system
components, and also better for defects as bottom-up
approach is
vis used in
general.
It also saves time as all
customer-requirement elicitation as top-down
approach
works/does not work.

critical for a system.

components are not tested individually. It is 9.10 SANDWICH TESTING
expected that all components are not
from both ends ie., top-down
Disadvantages of Modified Top-Down Approach
Stubs and drivers are
Sandwich testing defines testing into two parts, and follows both parts starting It combines the
or one after another. advantages of
required for testing individual approach and bottom-up approach either simultaneously
units
before they are integrated testing at a time. Figure 9.5 shows a sandwich testing approach.
units). Stubs are required for allparts as integration happens from top to bottom. (atleast for critical bottom-up testing and top-down
Definition of critical units is
very important. Criticality of the unit must be defined in
must be tested individually before any integration is done. design. Critical unit
System
This approach
actually means testing the system twice or atleast more than once. The first
starts from top to bottom as we are part of testing
integrating units downward, and the second part from bottom to top for Sub
selected components which are declared as 'critical
units'. This may need more resources in terms Sub Sub
and more time for test of people,
cycles than top-down approach but less time for test cycles than bottom-up approach. System 1 Lsystem 2 system 3
This approach is more
practical from usage point of view as all components may not be equally important.
9.9 BIG-BANG TESTING Unit 1 Unit 2 Unit 3
Big-bang approach is the most commonly seen approach at many places, where the system is tested completely Fig. 95 Sandwich testing approach
atter development is over. There is no testing of individual units/modules and integration sequence. System
tries
testing compensate for any other kind of testing, reviews, etc. Sometimes, it includes huge amount of
to
random testing which may not be 9.10.1 PROCESS OF SANDWICH
TESTING
repeatable. middle layer and goes upward to the top layer. Generally
for very big sys-
Bottom-up testing starts from
Advantages of Big-Bang Approach tems, bottom-up approach starts subsystem
at level and goes upwards.
for very big systems, top-down
I t gives a feeling that cost can be saved by limiting testing to last phase of development. Testing is done as middle layer and goes downward. Generally
Top-down testing starts from
a last-phase of the development lifecycle in form of system testing. Time for writing test cases and defin- level and goes downwards.
approach starts subsystem
at
ing test data at unit level, integration level, etc may be saved.
 232
SOFTWARE TESTING:
Principles, Techniques and Tools Levels ofTesting 33
Big-bang approach is followed
and
top-down approach goes for the middle layer. From this
downwards. layer, bottom-up approach defined in requirement statement. Once functions are tested, all defects related to functions must be fixed to
9.10.2 goes upwards
ADVANTAGES OF SANDwICH make the system correct.
Sandwich approach is useful TESTING Once the functionalities set correct, the next step is to set the user interface
lows a spiral model for very
large projects having several User Interface Testing are

and the module correct(if the system has a user interface). User interface testing may involve colors, navigations, spellings,
Both top-down and
bottom-up
itself is as
large as a system, thensubprojects. When development fol- and fonts. Sometimes, there can be a thin line between functional testing ánd user intertace testing,
and one

brought together to make a approaches start at a time as per

one can use
testing sandwich may take a decision depending upon the situation. There are few systems where
there is no or very minimal
I t needs is done development schedule. Units are
more resources and system. Integration
downwards. tested and user interface. In such cases, user interface testing may not be applicable.
big teams for
9.10.3 DISADVANTAGES
performing both methods of testing at time one a
Once the system is tested for functionalities and user interface, it is ready to go for other types of testing
after the other. or
security,
OF SANDWICH such as load, and compatibility. It depends upon the scope testing, of type of system under testing
It
representsvery high cost of
TESTING and which types of testing are involved as a part of system testing. If the scope does not include functionality

another part has testing as lot of

testing is done. One
testing, it is not required and one may directly go to user interface testing.
It cannot be usedbottom-up approach. part has top-down approach while
for smaller
systems with huge 9.14 TESTING STAGES
is as good as interdependence between different modules. It makes
sense when the individual
Different skill sets are subsystem complete system.
required for testers at different
levels as modules are
Generally an organisation performs unit testing as first part of testing. The inputs from unit testing are used
separate domains like ERP products with
modules separate systems
representing different functional areas. handling to identify downm. Once unít testing beis
and eliminate defects at unit level so that they will not go further

9.11 CRITICAL PATH FIRST

over and units are ready for integration, then integration or module
testing is done. Module testing may
done by development/test teams depending upon the requirements of stubs and drivers. After module testing,
Once the
In critical
the system goes for subsystem testing, which is also considered as 'integration testing'. system
path first, one must define critical completes all levels of integration, either it goes for system testing, or interface testing and then system testing
path which represents the main furction of a
a
represented by Pl requirements or Pl functionalities as the case may be. Interface testing addresses the issues associated with communication of a system with
systenm, generally
system which must be covered first. of an application. Testing defines the critical another system that already exists or is expected to exist in future.
of critical Development team concentrates on part of the
path of a system first. This is also termed 'skeleton design, implementation and testing Once the system is through with system testing, it is taken for acceptance testing to check whether it fulnis
critical path of a system is
important for system development testing. It is applied where
and the acceptance criteria or not. The stages of testing are graphically shown in Fig. 9.6.
One must understand the performance
and forbusiness from customer's
perspective.
criticality of system functions from user's
priority of testing. Critical path first is generallyperspective
and decide on the or from business
used where
perspective,
impossible and systems are so large that complete testing may not be complete system testing is Unit testing
economical.
9.12 SUBSYSTEM TESTING
Module
Subsystem testing involves collection of units, submodules, and modules which testing
have been
to form
subsystems. The subsystem can be independently designed and implemented, and also integrated can be a
separate executable. It is also called 'integration or interface
testing' when individual modules are as
independent systems. It mainly concentrates on detection of integration and interface errors where onegood
as
Subsystem
unit is testing
supposed to communicate with another module, and one system is supposed to talk with another
system.
9.13 SYSTEM TESTING System
testing
System testing represents the final testing done on a system before it is delivered to the customer. It is done
on integrated subsystems that make up the entire system, or the final system getting delivered to the customer.
System testing validates that the entire system meets its functional/nonfunctional requirements as defined by the
customer in software requirement specification. The criteria for system testing may involve an entire domain or Acceptanee
selected parts depending upon the scope of testing. Generally system testing goes through the testing
following stages.
Functional Testing Functional testing intends to find whether all the functions as per requirement Fig. 9.6 Software testing stages
definition are working or not. Generally, any software is intended for doing some functions which must be
 SOFTWARE TESTING: Principles,
234 Techniques and Tools

Tips for life-cycle testing

Tdantifv yarious stages of software development life

cycle, and verification and validation activities related
dhece stages. The ultimate aim of all activities is to reduce the defects
going
ldentify the integration approach designed for the application under testing.
to the customer.

Summary
This chapter details verification and validation activities
related to various stages of software
development phases. It gives advantages and disadvantages of the various
testing. approaches of integration

1)Describe proposal review process.

2)Describe requirement verification and
3) Describe design
validation process.
4) Describe code
verification and validation process
review and unit testing
process.
5) Describe difference between debugging and
6)
unit testing.
Differentiate between
2
integration testing and interface testing.
7) Describe bottom-up approach for integration.
8) Describe top-dowm approach for
9) Describe modified
integration
top-down approach for integration