Chapter-02

Types and Levels of

Testing

Software Testing-Chapter 2 1
Q. Explain unit testing

• Unit testing involves individually testing unit of code

separately to make sure that it works on its own,
independent of the other units.
• Unit testing is a software development process in which
the smallest testable parts of an application, called units,
are individually and independently exercised for proper
operation.
• Without affecting the functioning of other units or the
program as a whole
• Unit testing is an action used to validate that separate
units of source code.
Software Testing-Chapter 2 2
• It is also called as module test.
• It focuses on functionality.
• It is done before system integration.
• Main goal is to isolate the smallest unit to check
whether behave as expected.
• It is executed by the Developer.
• Before integration each unit is tested separately.
• Example: - A function, method, Loop or statement
in program is working fine.

Software Testing-Chapter 2 3
• Concentrates on the internal processing logic and
data structures
• Allows errors to be more easily predicted
• Concentrates on critical modules and those with high
cyclomatic complexity.
• Unit testing can be time-consuming and tedious.
• It helps to produce high quality code

Software Testing-Chapter 2 4
 A B C
Stub
Driver Test

Software Testing-Chapter 2 5
 Driver
• Drivers are testing tool used to control and operate the
software being used.
• For Testing modules, it may require some inputs are to
be received from another module, the module which
passes inputs to the module to be tested is not ready and
under development.
• Suppose you are testing the software that requires large
amount of data to enter for execution.
• you could replace the keyboard and mouse of system
being tested with additional computer acts as a test
driver.

Software Testing-Chapter 2 6
• ‘Driver’ is a piece of software that drives the Unit
being tested. I.e. A piece of code that passes test
cases to another piece of code
• A driver creates necessary ‘Inputs’ required for
the Unit and then invokes the Unit
• Driver is called component
• They control or operate the software being tested
• Used in the Bottom –Up Test strategy

Software Testing-Chapter 2 7
 stub
• Stubs are opposite of driver.
• They don’t control or operate the software being
tested.
• They instead receive or respond to data that the
software sends.
• Suppose you are testing software that sends data to
a printer. To test we can enter data , print it and
look at resulting paper but it is inefficient method.

Software Testing-Chapter 2 8
• But if you replace printer with another computer
that running stub software that could read and
interpret the data.
• It is much more feasible and quick to test
software.
• stubs are programs that simulate the behaviors of
software components (or modules) that a module
undergoing tests depends on.

Software Testing-Chapter 2 9
• ‘Stub’ is a piece of software that works similar to a
unit which is referenced by the Unit being tested,
but it is much simpler that the actual unit
• dummy modules required to simulate for testing,
instead of actual modules. These are called stubs.
i.e. A piece of code that simulates the activity of
missing components

Software Testing-Chapter 2 10
• A Stub works as a ‘Stand-in’ for the subordinate
unit and provides the minimum required behavior
for that unit
• Stub is calling Component
• Used in the Top – Down Testing Strategy

Software Testing-Chapter 2 11
• Stubs and drivers are used to replace the missing
software and simulate the interface between the
software components in a simple manner.
• For testing module independently we require
stub and driver.
• Both are temporary program written for testing
purpose.

Software Testing-Chapter 2 12
Software Testing-Chapter 2 13
 Integration Testing
• It is logical extension of unit testing.
• Two units already have been tested are combined
and test.
• Integrate more than one unit up to whole system.
• Idea is to test small pieces and eventually expand
the process to test your module with other group.
• Integration testing identifies the problem that
occur when units are combined.

Software Testing-Chapter 2 14
• There are three types
1.Decomposition based
2.Call Graph
3.Path Based

Software Testing-Chapter 2 15
 Decomposition based Testing

There are following strategies

• Top Down Integration
• Bottom Up Integration
• Bi-Directional Integration
• Incremental Integration
• Non- Incremental Integration

Software Testing-Chapter 2 16
 Top-down Testing
• The top down testing requires highest level
module to test and integrated first.
• Modules are integrated from the main module
to subordinate module.
• In Top-down Testing, higher level modules are
tested. If lower modules required to make up
the system are not yet available then, stubs
are used to simulate their activity.

Software Testing-Chapter 2 17
Software Testing-Chapter 2 18
 Bottom-up testing
• The bottom- up testing requires the lowest
level units to be tested and integrated first.
• Lowest level sub-module are integrated and
test then successively upper level components
are added and tested.
• In Bottom-up testing, lower level modules are
tested. If the higher level modules required to
make up the system are not yet available then,
drivers are used to simulate their activity.
Software Testing-Chapter 2 19
Software Testing-Chapter 2 20
 Bi-directional Testing
• It is combination of Top down and Bottom up
integration testing.
• Known as sandwich testing.

Software Testing-Chapter 2 21
Software Testing-Chapter 2 22
 Incremental Integration

• The program is constructed and tested in

small increments by adding a minimum
number of components at each interval.
• Therefore errors are easier to isolate and
correct.
• Interfaces are tested completely

Software Testing-Chapter 2 23
 Non-incremental
• All the software units are assembled into the entire
program.
• This assembly is then tested as a whole from the
beginning.
• Cause of defects are not easily isolated and
corrected.
• The non incremental approach is also known as
“Big-Bang” testing. This approach is very
unfashionable due to the level of risk that one takes
in hoping that the system will perform as expected.
Software Testing-Chapter 2 24
 System Testing
• System Testing (ST) is a black
box testing technique performed to evaluate the
complete system against specified requirements.
• In System testing, the functionalities of the
system are tested.
• It concentrates on testing the complete system.
• Against objectives of the system.
• In many different environment with various
versions and operating systems.
• System testing test all components of the system.
Software Testing-Chapter 2 25
• Testing the interaction with other parts of the
system to validate and verify functional
specifications.
• Usability testing, Functionality testing,
Performance testing, Load Testing, Stress Testing,
Security testing, regression testing are used .
• System testing should investigate both functional
and non-functional requirements of the testing.

Software Testing-Chapter 2 26
 Recovery Testing
• In software testing, recovery testing is the activity
of testing how well an application is able to recover from
crashes, hardware failures and other similar problems.
• It is a type of non-functional testing.
• It is done to check how fast and better the application can
recover against any type of crash.
• Recovery testing is an extension to Error handling testing.
• It is also known as reliability testing where test engineer
can test whether application can recover from abnormal
situation
• Ex. During power failure, network disconnect, server
down, database disconnect
Software Testing-Chapter 2 27
• Recovery testing is the forced failure of the software in
a variety of ways to verify that recovery is properly
performed.
• For example, when an application is receiving data from
a network, unplug the connecting cable. After some
time, plug the cable back in and analyze the
application’s ability to continue receiving data from the
point at which the network connection was broken.
Restart the system while a browser has a definite
number of sessions and check whether the browser is
able to recover all of them or not.
Software Testing-Chapter 2 28
 Security testing
• It is a type of non-functional testing.
• Security testing is basically a type of software testing
that’s done to check whether the application or the
product is secured or not.
• It checks to see if the application is vulnerable to
attacks, if anyone hack the system or login to the
application without any authorization.
• It is a process to determine that an information system
protects data and maintains functionality as intended.

Software Testing-Chapter 2 29
 Security testing
• The security testing is performed to check whether
there is any information leakage in the sense by
encrypting the application or using wide range of
software’s and hardware’s and firewall etc.
• Software security is about making software behave in
the presence of a malicious attack.
• The six basic security concepts that need to be covered
by security testing are: confidentiality, integrity,
authentication, availability, authorization and non-
repudiation.

Software Testing-Chapter 2 30
 Performance testing
• It is a type of non-functional testing.
• Performance testing is testing that is performed, to determine
how fast some aspect of a system performs under a particular
workload.
• It can serve different purposes like it can demonstrate that the
system meets performance criteria.
• It can compare two systems to find which performs better. Or it
can measure what part of the system or workload causes the
system to perform badly.
• This process can involve quantitative tests done in a lab, such as
measuring the response time or the number of MIPS (millions
of instructions per second) at which a system functions.

Software Testing-Chapter 2 31
 Performance testing
• Why to do performance testing:
• Improve user experience on sites and web apps
• Increase revenue generated from websites
• Gather metrics useful for tuning the system
• Identify bottlenecks such as database configuration
• Determine if a new release is ready for production
• Provide reporting to business stakeholders
regarding performance against expectations

Software Testing-Chapter 2 32
 Load testing

• Load testing is a type of non-functional testing.

• A load test is type of software testing which is
conducted to understand the behavior of the
application under a specific expected load.
• Load testing is performed to determine a system’s
behavior under both normal and at peak conditions.
• It helps to identify the maximum operating capacity of
an application as well as any bottlenecks and
determine which element is causing degradation

Software Testing-Chapter 2 33
 Load testing

• E.g. If the number of users are increased then how

much CPU, memory will be consumed, what is the
network and bandwidth response time.
• Load testing can be done under controlled lab
conditions to compare the capabilities of different
systems or to accurately measure the capabilities of a
single system.
• Load testing involves simulating real-life user load for
the target application. It helps you determine how your
application behaves when multiple users hits it
simultaneously.

Software Testing-Chapter 2 34
 Load testing

• Load testing differs from stress testing, which evaluates

the extent to which a system keeps working when
subjected to extreme work loads or when some of its
hardware or software has been compromised.
• The primary goal of load testing is to define the
maximum amount of work a system can handle
without significant performance degradation.

Software Testing-Chapter 2 35
 Load testing

• Examples of load testing include:

– Downloading a series of large files from the
internet.
– Running multiple applications on a computer or
server simultaneously.
– Assigning many jobs to a printer in a queue.
– Subjecting a server to a large amount of traffic.
– Writing and reading data to and from a hard disk
continuously.

Software Testing-Chapter 2 36
 compatibility testing
• Software compatibility testing means checking that
your software interacts with and shares
information correctly with other software.
Compatibility Testing means checking whether software
interacts and shares information correctly with different
operating systems, hardware and software
configurations available.
• This interaction could occur between two programs
• simultaneously running on the same computer or
even on different computers connected

Software Testing-Chapter 2 37
• Examples of compatible software are
• Cutting text from a Web page and pasting it into a
document opened in your word
• processor
• Saving accounting data from one spreadsheet
program and then loading it into a completely
different spreadsheet program
• Having photograph touchup software work correctly
on different versions of the same operating system
Software Testing-Chapter 2 38
Software Testing-Chapter 2 39
• There are two types of compatibility:
• 1. Backward compatibility testing: it will work
with previous versions of the software.
• 2. Forward compatibility testing: it will work
with Future invented versions of the software.

Software Testing-Chapter 2 40
Software Testing-Chapter 2 41
 Data Sharing Compatibility

1. File save and file load

2. File export and file import
3. Cut, copy, and paste

Software Testing-Chapter 2 42
 Usability Testing

The means that you use to interact with a software program is

called its user interface

⮚ It really doesn't matter whether the software is embedded in

a microwave oven, a telephone switching station, or an Internet
stock trading website. Eventually the bits and bytes bubble up to
where a live person will interact with it.

⮚ Usability is how Appropriate, Functional, and Effective that

interaction is.

Software Testing-Chapter 2 43
 Usability Testing

Usability is the degree to which a user can easily learn and use
a product to achieve a goal.
Usability testing is the system testing which attempts to find any
human-factor problems.
It is testing the software from a users’ point of view.
Essentially it means testing software to prove/ensure that it is
user-friendly, as distinct from testing the functionality of the
software.

Software Testing-Chapter 2 44
 Usability Testing

The idea behind usability testing is to have actual users perform

the tasks for which the product was designed.

If they can't do the tasks or if they have difficulty performing

the tasks, the UI is not adequate and should be redesigned.

It should be remembered that usability testing is just one of the

many techniques that serve as a basis for evaluating the UI in a
user-centered approach.

Software Testing-Chapter 2 45
 Usability Testing:

seven important traits common to a good UI.

• Follows standards and guidelines
your software follows existing standards and guidelines
• Intuitive
Is the user interface clean, unobtrusive, not busy?
Is the UI organized
Is there excessive functionality?
• Consistent

Software Testing-Chapter 2 46
 Usability Testing:

Shortcut keys and menu selections.

Terminology and naming
• Flexible
Flexible software provides more options and more ways to
accomplish
the same task
• Comfortable
Software should look and feel proper
A program should warn users before a critical operation

Software Testing-Chapter 2 47
• Correct
WYSIWYG (what you see is what you get).
• Useful
whether it’s useful

• This testing is related to a system’s presentation rather than its

functionality. It helps to find human factors or usability
problems on the system. To adapt according to the actual
work styles rather than forcing the user to adapt according to
the software
• Usability testing identifies discrepancies between the user
interfaces of a product and the human engineering
requirements of its potential users.
• It tests how easy software easy to us/learn and convenient to
the end use.
Software Testing-Chapter 2 48
 Stress testing
• Stress testing a Non-Functional testing
technique that is performed as part of
performance testing.
• During stress testing, the system is monitored
after subjecting the system to overload to
ensure that the system can sustain the stress.
• The recovery of the system from such phase
(after stress) is very critical as it is highly likely
to happen in production environment.
Software Testing-Chapter 2 49
 Stress testing
• Stress testing is the process of determining
the ability of a computer, network, program or
device to maintain a certain level of
effectiveness under unfavorable conditions.
• The process can involve quantitative tests
done in a lab, such as measuring the
frequency of errors or system crashes.

Software Testing-Chapter 2 50
 Stress testing
• It allows the test team to monitor system
performance during failures.
• To verify if the system has saved the data
before crashing or NOT.
• To verify if the system prints meaning error
messages while crashing or did it print some
random exceptions.
• To verify if unexpected failures do not cause
security issues.
Software Testing-Chapter 2 51
 Volume testing
• It is a type of non-functional testing.
• Volume testing refers to testing a software application
or the product with a certain amount of data. E.g., if
we want to volume test our application with a specific
database size, we need to expand our database to that
size and then test the application’s performance on it.
• “Volume testing” is a term given and described in
Glenford Myers’ The Art of Software Testing, 1979.

Software Testing-Chapter 2 52
 Volume testing
• Here’s his definition: “Subjecting the program to heavy
volumes of data. The purpose of volume testing is to
show that the program cannot handle the volume of
data specified in its objectives” – p. 113.
• The purpose of volume testing is to determine system
performance with increasing volumes of data in the
database.
• Volume Testing = Large amounts of data
Load Testing = Large amount of users
Stress Testing = Too many users, too much data, too
little time and too little room
Software Testing-Chapter 2 53
 Acceptance testing
• Acceptance testing is a test conducted to
determine if the requirements of a specification or
contract are met.
• The goal of acceptance testing is to establish
confidence in the system.
• Acceptance testing is most often focused on a
validation type testing.
• enable the user, customers or other authorized
entity to determine whether or not to accept the
system.
Software Testing-Chapter 2 54
Software Testing-Chapter 2 57
 Alpha testing
• Alpha testing, the software is tested by in-house
developers during which the goal is to catch bugs
quickly.
• In the second phase of alpha testing, the software
is given to the software QA team for additional
testing.
• Alpha testing is a form of internal acceptance
testing, before the beta testing is performed.

Software Testing-Chapter 2 58
• performed to identify all possible issues/bugs
before releasing the product to everyday users
or public
• The focus of this testing is to simulate real
users by using blackbox and whitebox
techniques.

Software Testing-Chapter 2 59
 Beta Testing
• Beta Testing of a product is performed by "real
users" of the software application in a "real
environment" and can be considered as a form of
external user acceptance testing.
• Beta version of the software is released to a
limited number of end-users of the product to
obtain feedback on the product quality. Beta
testing reduces product failure risks and provides
increased quality of the product through
customer validation.
Software Testing-Chapter 2 60
• It is the final test before shipping a product to
the customers.
• Direct feedback from customers is a major
advantage of Beta Testing.
• This testing helps to tests the product in real
time environment.

Software Testing-Chapter 2 61
 Alpha Testing Beta Testing
Alpha testing performed by Testers who Beta testing is performed by Clients or
are usually internal employees of the End Users who are not employees of
organization the organization.
Alpha Testing performed at developer's Beta testing is performed at client
site location or end user of the product

Reliability and security testing are not Reliability, Security, Robustness are
performed in-depth Alpha Testing checked during Beta Testing

Alpha testing involves both the white Beta Testing typically uses black box
box and black box techniques testing

Alpha testing requires lab Beta testing doesn't require any lab
environment or testing environment environment or testing environment.
Software is made available to the
public and is said to be real time
environment

Software Testing-Chapter 2 62
 Alpha Testing Beta Testing
Long execution cycle may be Only few weeks of execution are
required for Alpha testing required for Beta testing

Critical issues or fixes can be Most of the issues or feedback is

addressed by developers collected from Beta testing will be
immediately in Alpha testing implemented in future versions of
the product
Alpha testing is to ensure the Beta testing also concentrates on
quality of the product before moving quality of the product, but gathers
to Beta testing users input on the product and
ensures that the product is ready for
real time users.

Software Testing-Chapter 2 63
Smoke Testing

• Smoke Testing is performed after software build to ascertain that

the critical functionalities of the program is working fine.
• It is executed "before" any detailed functional or regression tests
are executed on the software build.
• The purpose is to reject a badly broken application, so that the QA
team does not waste time installing and testing the software
application.
• In Smoke Testing, the test cases chosen cover the most important
functionality or component of the system. The objective is not to
perform exhaustive testing, but to verify that the critical
functionalities of the system is working fine.
For Example a typical smoke test would be - Verify that the
application launches successfully, Check that the GUI is
responsive ... etc.
Software Testing-Chapter 2 65
• Smoke testing consists of :
• Identifying the basic functionality that a product
must satisfy.
• Design test cases to ensure that these basic
functionality work and packaging them into
suite.
• If this suite fails, changes or rollback of changes
to the state where the smoke test suite
succeeds.

Software Testing-Chapter 2 66
Sanity Testing
After receiving a software build, with minor changes in code,
or functionality, Sanity testing is performed to ascertain that
the bugs have been fixed and no further issues are
introduced due to these changes.
The goal is to determine that the proposed functionality works
roughly as expected. If sanity test fails, the build is rejected to
save the time and costs involved in a more rigorous testing.
The objective is "not" to verify thoroughly the new
functionality, but to determine that the developer has applied
some rationality (sanity) while producing the software.
For instance, if your scientific calculator gives the result of 2 +
2 =5! Then, there is no point testing the advanced
functionalities like sin 30 + cos 50.

Software Testing-Chapter 2 67
Sanity Testing

• This testing is performed to test the major functionality or

behavior of the software application.
• This testing is done after through regression testing is over. It
ensures that the defects fixes or changes after regression
testing does not break the core functionality of the product.
• It follows deep and narrow approach with detailed testing of
some limited features (particular component).
• It is dene with intent to verify that end user requirements are
met or not.
• It is non-scripted.
• It finds uncovered testing issues.
• It increases level of confidence of testers. It is set of
acceptance test.
Software Testing-Chapter 2 68
Software Testing-Chapter 2 69
 Regression testing
• What is Regression testing in software?
• Regression testing: During confirmation testing the
defect got fixed and that part of the application started
working as intended.
• But there might be a possibility that the fix may have
introduced or uncovered a different defect elsewhere
in the software.
• The way to detect these ‘unexpected side-effects’ of
fixes is to do regression testing.

Software Testing-Chapter 2 70
 Regression testing
• It is selective testing of a system or component to
verify that modifications have not caused unintended
effect and the system or component still complies
with its specified requirements.
• It is used to ensure that bug-fixes and new
functionalities introduced in new version of software
do not adversely affect the correct functionality from
previous version.
• It is the software maintenance task performed on a
modified program to instill confidence that changes
are correct and have not adversely affected the
unchanged portion of the program.
Software Testing-Chapter 2 71
 Regression testing
• Objectives of Regression Testing:
• It finds other related bugs
• It tests to check the effect on other parts of the
program.
• Regression testing produces Quality software.
• Validate the parts of software where changes occur.
• It validates parts of software which may be affected
by some changes but otherwise unrelated.
• It ensures proper functioning of the software, as it
was before changes occurred.
• It enhances quality of software, as it reduces the high
risk bugs. Software Testing-Chapter 2 72
 Regression testing
• The purpose of a regression testing is to verify that
modifications in the software or the environment have
not caused any unintended adverse side effects and
that the system still meets its requirements.
• Regression testing are mostly automated because in
order to fix the defect the same test is carried out
again and again
• it will be very tedious to do it manually.
• Regression tests are executed whenever the software
changes, either as a result of fixes or new or changed
functionality.
Software Testing-Chapter 2 73
Regression testing

Software Testing-Chapter 2 74
 Graphics User Interface (GUI) Testing
• Graphics User Interface Testing (GUI) Testing is important phase of testing
where important part of application along with functionality are tested as
effects on usability.
It includes following:
• All colors used for background, control colors, and font color have a major
impact on users.
• User must able to identify entities on the screen correctly and efficiently.
Like wrong color combinations and bright colors may increase fatigue of
users.
• All words, Fonts, Alignments, scrolling pages up and down, navigations for
different hyperlinks and pages, scrolling reduce usability.
• Error messages and information given to users must be usable to the user.
• Reports and outputs produced, readability issue, paper size on printer.
Screen layouts, types of controls on single page are important.
• No. of images on page or moving parts on screen may affect performance.
Software Testing-Chapter 2 75
 Graphical User Interface (GUI) Testing
Advantages of GUI Testing:
• Good GUI improves feel and look of the application; it psychologically
accepts the application by the user.
• GUI represents a presentation layer of an application due to better
experience of the users.
• Consistency of the screen layouts and designs improves usability of an
application.
Disadvantages of GUI Testing:
• When no. of pages is large and number of controls in a single page is huge.
• Special application testing like those made for blind people or kids below
age of five may need special training from testers.

Software Testing-Chapter 2 76
 Object Oriented Testing
• Objects at several instances giving benefits of optimization,
reusability and flexibility.
• Made major change in development methodologies.
• Improves productivity with good maintainability of an application.
• many effective approaches to test object oriented software.
• Here the cost of finding and correcting bugs is always higher.
• Testing activities can begin and proceed in parallel with concept
definition , object oriented architecture and designs.
• Currently switching to object oriented paradigm the importance of
object oriented software is increasing.

Software Testing-Chapter 2 77
Object Oriented Testing

Software Testing-Chapter 2 78
 Object Oriented Testing
• These three methods of Object oriented application testing :
1. State based Testing: used where the methods of class are interacting
properly with each other. Testing seeks to exercise, State transaction
diagrams are useful for performing this testing

2. Fault-based testing: used to determine a set of possible faults. It starts

by examining the analysis and design models of object oriented software as
these models may provide an idea of problems in the implementation of
software.

3. Scenario-based testing: used to detect errors that are caused due to

incorrect specifications and improper interactions among various segments
of the software, which lead to incorrect outputs that can cause
malfunctioning of some segments of the software.
Software Testing-Chapter 2 79
 Client server Testing:
• Client server Testing:
• The client server is improvement in standalone application, where
there are several clients communicating with the server. There are
many advantages of client server over stand-alone applications. It
can be assessed by no. of users to work with software at a time.
• There are two (three) parts, client – server system, client, server
(and network).
• Multiple users can access the system at a time and they can
communicate with the server.
• Configuration of client is known to the server with certainty.
• Client and server are connected by real connection.

Software Testing-Chapter 2 80
 Testing approach of client-server system:

• Component Testing: one need to define the approach and test plan
for testing client and server individually. When server is tested there
is need of a client simulator, whereas testing client a server
simulator, and to test network both simulators are used at a time.
• Integration testing: After successful testing of server, client and
network, they are brought together to form network testing.
• Performance testing: System performance is tested when no. of
clients are communicating with server at a time. Volume testing and
stress testing may be used for testing, to test under maximum load
as well as normal load expected. Various interactions may not be
used for stress testing.
• Concurrent Testing: It is very important testing for client-server
architecture. It may be possible that multiple users may be
accessing same record at a time, and concurrency testing is
required to understand the behavior of a system.
Software Testing-Chapter 2 81
 Testing approach of client-server system:
• Disaster Recovery/ Business continuity testing: When the client
server application are communicating with each other , there exit a
possibility of breaking of the communication due to various reasons
or failure of either client or server or link connecting them. The
requirement specifications must describe the possible expectations
in case of any failure.
• Testing for extended periods: In case of client server applications
generally server is never shutdown unless there is some agreed
Service Level Agreement (SLA) where server may be shut down for
maintenance. It may be expected that server is running 24X7.
• Compatibility Testing: Client server may be put in different
environments when the users are using them in production. Servers
may be in different hardware, software, or operating system
environment than the recommended. Other testing such as security
testing and compliance testing may be involved if needed, as per
testing and type of system.
Software Testing-Chapter 2 82
 Web based testing
• Web application is further improvement in client-server applications
where the clients can communicate with servers through virtual
connectivity. Multiple server networks can be accessed at a time from the
same client. It improves communication between people at different
places significantly.
• Component Testing: Here client, server as well as network testing is also
Required
• Integration testing: After successful testing of server, client and network,
they are brought together to form network testing.
• In addition to this there are several special testing involved in web
application. Following are some types.
• Performance testing: System performance is tested when no. of clients
are communicating with server simultaneously.

Software Testing-Chapter 2 83
 Web based testing
• Concurrency Testing: It may be possible that multiple users may be
accessing same records at a time and requires understanding behavior of
the system as no. of users is very large.
• Disaster Recovery/ Business continuity testing: Requirement
specifications must describe the possible expectations of the system
behavior in each case of any failure. MTTR (Mean Time To Repair).and
MTTB (Mean Time Between Failures) are very important tests for web
applications.

Software Testing-Chapter 2 84