LEVELS OF TESTING

Software testing is generally carried out at different levels. There are four such levels
namely unit testing, integration testing, system testing and acceptance testing as
shown in figure. The first three levels of testing activities are done by the testers and
the last level of testing (acceptance) is done by the customer(s)/user(s). Each level
has specific testing objectives.

LEVELS OF TESTING

Unit Testing

We develop software in parts / units and every unit is expected to have a defined
functionality. We may call it a component, module, procedure, function, etc., which
will have a purpose and may be developed independently and simultaneously. At the
unit testing level, independent units are tested using functional and/or structural
testing techniques by developer.

There are also problems with unit testing. How can we run a unit independently? A
unit may not be completely independent. It may be calling a few units and also be
called by one or more units. We may have to write additional source code to execute
a unit called driver and stub module. The complete additional source code which is
written for the design of stub and driver is called scaffolding.

A unit X may call a unit Y and a unit Y may call a unit A and a unit B as shown in
Figure (a). To execute a unit Y independently, we may have to write additional
source code in a unit Y which may handle the activities of a unit X and the activities
of a unit A and a unit B. The additional source code to handle the activities of a unit
X is called ‘driver’ and the additional source code to handle the activities of a unit
A and a unit B is called ‘stub’.

UNIT UNDER TEST WITH STUBS AND DRIVER

Integration Testing
At the integration testing level, two or more units are combined and testing is carried
out to test the integration related issues of various units. A software program may
have many units. We test units independently during unit testing after writing the
required stubs and drivers. When we combine two units, we may like to test the
interfaces amongst these units. We combine two or more units because they share
some relationship. This relationship is represented by an interface and is known as
coupling.

COUPLING AMONGST UNITS

There are several integration strategies that really have little basis in a rational
methodology and are given in figure.

Top down integration starts from the main unit and keeps on adding all called units
of the next level. This portion should be tested thoroughly by focusing on interface
issues. After completion of integration testing at this level, add the next level of units
and so on till we reach the lowest level units (leaf units). There will not be any
requirement of drivers and only stubs will be designed.

In bottom-up integration, we start from the bottom, (i.e. from leaf units) and keep on
adding upper level units till we reach the top (i.e. root node). There will not be any
need of stubs.

A sandwich strategy runs from top and bottom concurrently, depending upon the
availability of units and may meet somewhere in the middle.

(a) Top down integration (focus starts from edges a, b, c and so on)
(b) Bottom up integration (focus starts from edges i, j and so on)

(c) Sandwich integration (focus starts from a, b, i, j and so on)

INTEGRATION APPROACHES
System Testing

At the system testing level, the system is tested as a whole and primarily functional
testing techniques are used to test the system. Non-functional requirements like
performance, reliability, usability, testability, etc. are also tested at this level.
Load/stress testing is also performed at this level. We perform system testing after
the completion of unit and integration testing.
We test complete software along with its expected environment. System testing
ensures that each system function works as expected and it also tests for non-
functional requirements like performance, security, reliability, stress, load, etc. This
is the only phase of testing which tests both functional and non-functional
requirements of the system. Progress of system testing also builds confidence in the
development team as this is the first phase in which the complete product is tested
with a specific focus on the customer’s expectations. After the completion of this
phase, customers are invited to test the software.

There are essentially three main kinds of system testing depending on who carries
out testing:
1. Alpha Testing: Alpha testing refers to the system testing carried out by the test
team within the developing organization.
2. Beta Testing: Beta testing is the system testing performed by a select group of
friendly customers.
3. Acceptance Testing: Acceptance testing is the system testing performed by the
customer to determine whether to accept the delivery of the system.

Acceptance Testing
The last level i.e. acceptance testing, is done by the customer(s)/user(s) for the
purpose of accepting the final product. This is the extension of system testing. When
the testing team feels that the product is ready for the customer(s), they invite the
customer(s) for demonstration. After demonstration of the product, customer(s) may
like to use the product to assess their satisfaction and confidence. This may range
from adhoc usage to systematic well-planned usage of the product. This type of
usage is essential before accepting the final product. The testing done for the
purpose of accepting a product is known as acceptance testing. This may be
carried out by the customer(s) or persons authorized by the customer(s).
 DEBUGGING
The process of identifying and correcting a software error is known as debugging.
In other words debugging is detecting and removing bugs from the programs.

DEBUGGING PROCESS
Debugging means detecting and removing bugs from the programs. Whenever a
program generates an unexpected behaviour, it is known as a failure of the program.
This failure may be mild, annoying, disturbing, serious, extreme, catastrophic or
infectious. Depending on the type of failure, actions are required to be taken. The
debugging process starts after receiving a failure report either from the testing team
or from users. The steps of the debugging process are replication of the bug,
understanding the bug, locating the bug, fixing the bug and retesting the program.
These steps are explained below -

(i) Replication of the bug:

The first step in fixing a bug is to replicate it. This means to recreate the undesired
behaviour under controlled conditions. The same set of input(s) should be given
under similar conditions to the program and the program after execution, should
produce a similar unexpected behaviour. If this happens, we are able to replicate a
bug. In many cases, this is simple and straight forward. In other cases, replication
may be very difficult. It may require many steps or in an interactive program such
as a game, it may require precise timing. In worst cases, replication may be nearly
impossible. Some of the reasons for non-replication of a bug are:

1. The user incorrectly reported the problem.

2. The program has failed due to hardware problems like memory overflow, poor
network connectivity, network congestion, non-availability of system buses,
deadlock conditions, etc.
3. The program has failed due to system software problems. The reason may be the
usage of a different type of operating system, compilers, device drivers, etc. There
may be any of the above-mentioned reasons for the failure of the program, although
there is no inherent bug in the program for this particular failure.

Our effort should be to replicate the bug. If we cannot do so, it is advisable to keep
the matter pending till we are able to replicate it. There is no point in playing with
the source code for a situation which is not reproducible.
(ii) Understanding the bug:

After replicating the bug, we may like to understand the bug. This means, we want
to find the reason(s) for this failure.

(iii) Locate the bug:

At this stage we find out the location of bug. There are two portions of the source
code which need to be considered for locating a bug. The first portion of the source
code is one which causes the visible incorrect behaviour and the second portion of
the source code is one which is actually incorrect. In most of the situations, both
portions may overlap and sometimes, both portions may be in different parts of the
program. We should first find the source code which causes the incorrect behaviour.
After knowing the incorrect behaviour and its related portion of the source code, we
may find the portion of the source code which is at fault.

(iv) Fix the bug and re-test the program:

After locating the bug, we may like to fix the bug. The fixing of a bug is a
programming exercise rather than a debugging activity. After making necessary
changes in the source code, we may have to re-test the source code in order to ensure
that the corrections have been rightly done at right place.
 TESTING TECHNIQUES AND THEIR APPLICABILITY
Testing techniques are methods and approaches used to identify defects in
software and ensure it meets specified requirements. These techniques can be
broadly categorized into two types: Black Box Testing and White Box Testing.
Black Box Testing Techniques:
These techniques focus on the functionality of the software without considering
its internal structure. The tester is only aware of the input and expected output.
a. Equivalence Partitioning (EP):
Description:
This technique divides input data into partitions or classes where all values in a
partition are expected to behave similarly. Only one value from each partition is
tested, reducing the total number of test cases.
Applicability:
Useful in functional testing.
Best applied when there is a large set of input values, such as form field
validations or numeric inputs.

b. Boundary Value Analysis (BVA):

Description:
This technique tests the values at the boundaries of equivalence partitions. Errors
are often found at the edges, so values just below, at, and just above the
boundaries are tested.
Applicability:
Ideal for scenarios where data ranges or limits are critical, such as validating
number ranges or date ranges.

c. Decision Table Testing:

Description:
This technique uses decision tables (a tabular representation of inputs and
outputs) to capture different possible combinations of inputs and their respective
outputs.
Applicability:
1. Applicable when a system's output depends on multiple conditions or business
rules.
2. Useful for testing complex decision-making logic, like loan approval systems
or insurance processing.

d. State Transition Testing:

Description:
This technique is used when the system can be in different states and its behavior
varies based on its current state and the triggered event.
Applicability:
1. Best for systems that have distinct states and transitions, such as banking
systems or vending machines.
2. Particularly useful for applications like workflows, devices with modes, or
game development.

e. Cause-Effect Graphing:
Description:
This technique identifies the relationships between different inputs (causes) and
the resulting outputs (effects), allowing for the testing of combinations of
inputs.
Applicability:
1. Works well for small programs with complex input-output relationships.
2. Not commonly used for large programs due to increased complexity.

White Box Testing Techniques:

White box testing focuses on the internal workings and structure of the software.
The tester has knowledge of the code and tests it from the inside.
a. Statement Coverage:
Description:
This technique ensures that every executable statement in the code is tested at
least once.
Applicability:
1. Best for identifying areas of code that are not executed, especially in unit
testing.
2. Applicable to any code, particularly where it is necessary to ensure complete
execution.

b. Branch Coverage:
Description:
Ensures that each branch (i.e., true and false outcomes of conditions) is tested.
Every decision point is evaluated for both outcomes.
Applicability:
1. Ideal for decision-heavy code, such as if statements or switch cases.
2. Helps ensure that all paths through the code are executed at least once.

c. Path Coverage:
Description:
Focuses on testing all possible paths through the code, including combinations
of branches.
Applicability:
1. Applicable when you need complete coverage of all code paths, especially in
critical systems like flight control or medical software.

d. Condition Coverage:
Description:
Tests all logical conditions independently to ensure that each part of a decision
is evaluated for both true and false.
Applicability:
1. Suitable for code with complex logical conditions.
2. Useful for areas of the code where multiple conditions are combined in
decisions (&&, ||).
Exploratory Testing:
Exploratory testing is a simultaneous learning, test design, and test execution
process where the tester actively explores the application to find defects without
predefined test cases.
Key Characteristics:
Unscripted Testing:
Unlike traditional testing, exploratory testing is unscripted. The tester does not
follow predefined steps but uses their intuition and experience to navigate the
software.
Simultaneous Learning:
The tester learns how the system behaves while testing it. This allows for
discovering unknown issues and unexpected behaviour.
Real-Time Test Design:
Tests are created and executed in real time, based on the tester’s understanding
of how the system should work.
Adaptability:
The tester can quickly adapt and adjust the test approach based on the findings or
system behaviour during the testing process.
Applicability of Exploratory Testing:
1. New or Unstable Systems:
o Especially useful when the system is incomplete, rapidly changing,
or when documentation is lacking.
o Helps find critical defects that formal testing might miss.
2. Short Deadlines:
o Ideal when there is limited time for testing, as it allows testers to
quickly identify major issues.
3. Areas of Uncertainty:
o Suitable for complex systems or areas where behaviour is uncertain
or undefined.
4. Supplementing Formal Testing:
o Can be used in conjunction with formal testing techniques to explore
areas that formal test cases might not cover.
Advantages of Exploratory Testing:
1. Early Defect Discovery:

By actively exploring the application, testers may discover defects earlier.

2. Flexibility:

The tester can follow their instincts and focus on areas they suspect might have
defects.
3. Requires Minimal Preparation:

It does not require extensive documentation or detailed test cases, making it

efficient when time is limited.

Limitations of Exploratory Testing:

1. Less Traceability:

Since it is unscripted, it can be difficult to reproduce defects or prove that specific

areas of the system were tested.
2. Tester Dependency:

The success of exploratory testing depends heavily on the skills and knowledge
of the tester.
 EXPLORATORY TESTING

Exploratory Testing is a type of software testing in which the tester is free

to select any possible methodology to test the software. It is an unscripted
approach to software testing. In exploratory testing, software developers use
their learning, knowledge, skills, and abilities to test the software developed by
themselves.
Exploratory testing checks the functionality and operations of the software as
well as identify the functional and technical faults in it. Exploratory testing aims
to optimize and improve the software in every possible way. The exploratory
testing technique combines the experience of testers with a structured approach
to testing. It is often performed as a black box testing technique.

Below are some of the reasons for using exploratory testing:

• Random and unstructured testing: Exploratory testing is unstructured
and thus can help to reveal bugs that would of undiscovered during
structured phases of testing.
• Testers can play around with user stories: With exploratory testing,
testers can annotate defects, add assertions, and voice memos and in this
way, the user story is converted to a test case.
• Facilitate agile workflow: Exploratory testing helps formalize the
findings and document them automatically. Everyone can participate in
exploratory testing with the help of visual feedback thus enabling the
team to adapt to changes quickly and facilitating agile workflow.
• Reinforce traditional testing process: Using tools for automated test
case documentation testers can convert exploratory testing sequences
into functional test scripts.
• Speeds up documentation: Exploratory testing speeds up
documentation and creates an instant feedback loop.
• Export documentation to test cases: Integration exploratory testing with
tools like Jira recorded documentation can be directly exported to test
cases.

Types of Exploratory Testing:

There are many types of exploratory testing. Few are as follows:

1. Freestyle: In freestyle exploratory testing, the application is tested in an

ad- hoc way, there is no maximum coverage, and there are no rules to
follow for testing. It is done in the following cases:
1. When there is a need to get friendly with the application.
2. To check other test engineers’ work.
3. To perform smoke tests quickly.
2. Strategy Based: Strategy-based testing can be performed with the help of
multiple testing techniques like decision-table testing, cause-effect
graphing, boundary value analysis, equivalence partitioning, and error
guessing. It is done by an experienced tester who has known the application
for the longest time.
3. Scenario Based: Scenario-based exploratory testing is done based on
scenarios with the help of multiple scenarios like end-to-end, test
scenarios. The scenarios can be provided by the user or can be prepared by
the test team.
4. Collaborative Exploratory Testing: During exploration, several testers
work together, exchanging observations and insights. Working together
improves the variety of viewpoints and raises the possibility of finding
various kinds of flaws.
5. Charter-Based Exploratory Testing: The charter, a written document that
describes the goals and scope of the investigation, is followed by testers.
The charter could list particular features to test, situations to consider or
goals to accomplish.
6. Timing-Boxed Exploratory Testing: There is a temporal limit on how
long exploration can last. The goal of testers is to find as many serious
flaws as they can in the allotted period.

Exploratory Testing Process:

The following 4 steps are involved in the exploratory testing process:

1. Learn: This is the first phase of exploratory testing in which the tester
learns about the faults or issues that occur in the software. The tester uses
his/her knowledge, skill, and experience to observe and find what kind of
problem the software is suffering from. This is the initial phase of
exploratory testing. It also involves different new learning for the tester.
2. Test Case Creation: When the fault is identified i.e. tester comes to know
what kind of problem the software is suffering from then the tester creates
test cases according to defects to test the software. Test cases are designed
by keeping in mind the problems end users can face.
3. Test Case Execution: After the creation of test cases according to end user
problems, the tester executes the test cases. Execution of test cases is a
prominent phase of any testing process. This includes the computational
and operational tasks performed by the software to get the desired output.
4. Analysis: After the execution of the test cases, the result is analyzed and
observed whether the software is working properly or not. If the defects
are found then they are fixed and the above three steps are performed
again. Hence this whole process goes on in a cycle and software testing is
performed.

Exploratory Testing vs Automated Testing:

Below are the differences between exploratory testing and automated testing:

Parameters Exploratory Testing Automated Testing

No need to Proper documentation

Documentation maintain is required.
documentation.
Test cases are Test cases are
determined determined in
Test cases during testing. advance.

Testing cannot be Testing can be

reproduced, only reproduced.
Is testing defects can be
reproducible reproduced.
 Parameters Exploratory Testing Automated Testing

There is no investment There is a significant

in preparing investment in
Investment in preparing
documentation.
documentation documentation and
test scripts.

This is spontaneous This is well-planned

and directed by and directed from
requirements and requirements.
Spontaneity exploring during
testing.

It usually requires less Higher initial costs for

tools and scripting, tools and script
which results in development are
cheaper initial involved. After that, it
expenses. Ongoing can result in cost
Cost manual testing reductions over time
initiatives, however, when using automated
can raise long- term testing.
expenses.
It depends on the Technical expertise is
tester’s abilities, needed for script
inventiveness, and development,
intuition. Ideal for preservation and
Skills situations when human troubleshooting.
discretion and
flexibility are essential.

Challenges of Exploratory Testing:

• Replication of failure: In exploratory testing replication of failure to

identify the cause is difficult.
• Difficult to determine the best test case: In exploratory testing,
determining the best test case to execute or to determine the best tool to use
can be challenging.
• Difficult to document all events: During exploratory testing
documentation of all events is difficult.
• Difficult reporting: Reporting test results is difficult in exploratory
testing as the report does not have well-planned test scripts to compare
with the outcome.

Advantages of Exploratory Testing:

• Less preparation required: It takes no preparation as it is an

unscripted testing technique.
• Finds critical defects: Exploratory testing involves an investigation
process that helps to find critical defects very quickly.
• Improves productivity: In exploratory testing, testers use their knowledge,
skills, and experience to test the software. It helps to expand the
imagination of the testers by executing more test cases, thus enhancing the
overall quality of the software.
• Generation of new ideas: Exploratory testing encourages creativity
and intuition thus the generation of new ideas during test execution.
• Catch defects missed in test cases: Exploratory testing helps to uncover
bugs that are normally ignored by other testing techniques.

Disadvantages of Exploratory Testing:

• Tests cannot be reviewed in advance: In exploratory testing, Testing

is performed randomly so once testing is performed it cannot be
reviewed.
• Dependent on the tester’s knowledge: In exploratory testing, the testing is
dependent on the tester’s knowledge, experience, and skill. Thus, it is
limited by the tester’s domain knowledge.
• Difficult to keep track of tests: In Exploratory testing, as testing is done
in an ad-hoc manner, keeping track of tests performed is difficult.
• Not possible to repeat test methodology: Due to the ad-hoc nature of
testing in exploratory testing, tests are done randomly and thus it is not
suitable for longer execution time, and it is not possible to repeat the
same test methodology.
 AUTOMATED TEST DATA GENERATION

Test data are the test cases only. They can be generated manually. Test data are
generated automatically by using automation tools. Automated test data generation
is an activity that generates test data automatically for the software under test.
Generating test data requires proper understanding of the SRS document, SDD
document and source code of the software. We may generate a large pool of test data
randomly or may use any specified technique. This data is used as input(s) for testing
the software. There are two ways to generate test data –

1. Static Test Data Generation

2. Dynamic Test Data Generation

The techniques which are based on static evaluation are called static test data
generation techniques. Static test data generation techniques do not require the
execution of the program. They generally use symbolic execution to identify
constraints on input variables for the particular test adequacy criterion. The program
is examined thoroughly and its paths are traversed without executing the program.
Static test data generation techniques may not be useful for programs containing a
large number of paths.

The techniques which are based on the actual execution of the program for the
generation of test data are called dynamic test data generation techniques.

APPROACHES TO TEST DATA GENERATION

The approaches to test data generation can be divided into two categories i.e. static
and dynamic test data generation. One needs execution of the program (dynamic)
and other does not need the execution of the program (static). We may automate any
functional testing techniques (boundary value, equivalence partitioning) or structural
testing techniques (path testing, data flow testing) for the generation of test data. The
program will execute automatically and test data will be generated on the basis of
the selected technique. The program execution will continue till the desired test
adequacy criterion is achieved.
APPROACHES TO TEST DATA GENERATION

The approaches to test data generation can be divided into two categories i.e. static and dynamic test data
generation. One needs execution of the program (dynamic) and other does not need the execution of the program
(static). We may automate any functional testing techniques (boundary value, equivalence partitioning) or
structural testing techniques (path testing, data flow testing) for the generation of test data. The program will
execute automatically and test data will be generated on the basis of the selected technique. The program
execution will continue till the desired test adequacy criterion is achieved.
 TEST DATA GENERATION TOOLS

A test data generator is a tool designed to automate the process of creating test
data for software testing purposes. It offers a range of functionalities that
enable testers to efficiently generate diverse and realistic data sets to simulate
various scenarios and conditions. Although some software industries have
been using their own tools for the generation of test data. The output of such
a tool is a set of test data, which include a sequence of inputs to the system
under test. Some tools are also available that accept manually created,
automatically generated, predefined test sequences and executes the
sequences without human intervention and supervision. A few examples of
such tools are Mercury’s WinRunner, LoadRunner, Rational Robot and
Teleogic Tau Tester. The purpose of these tools is to execute already
generated test cases and not to generate test data automatically. Some of the
popular test generation tools are given in Table –

The software industry is focusing more on the quality of a product instead of

increasing functionality. Testing is the most popular and useful way to
improve several quality aspects such as reliability, security, correctness, ease
of usage, maintainability, etc. If test data is generated automatically, it will
reduce the effort and time of testing. Although the process of automated test
data generation is still in the early stages, some reasonable success has been
achieved in the industry.
 SOFTWARE TESTING TOOLS

Software Testing tools are the tools that are used for the testing of software.
Software testing tools may be used to reduce the time of testing and to make testing
as easy and pleasant as possible. Automated testing may be carried out without
human involvement. This may help us in the areas where a similar dataset is to be
given as input to the program again and again. A tool may undertake repeated testing,
unattended (and without human intervention), during nights or on weekends. Many
non-functional requirements may be tested with the help of a tool. We want to test
the performance of a software under load, which may require many computers,
manpower and other resources. A tool may simulate multiple users on one computer
and also a situation when many users are accessing a database simultaneously. There
are three broad categories of software testing tools i.e. static, dynamic and process
management.
1. Static Software Testing Tools –
Static software testing tools are those that perform analysis of the programs without
executing them at all. These tools will find more bugs as compared to dynamic
testing tools (where we execute the program).

i. Complexity analysis tools

Complexity of a program plays a very important role while determining its quality.
Complexity may be cyclomatic complexity etc. These tools may take the program
as an input, process it and produce a complexity value as output. This value may be
an indicator of the quality of design and implementation.

ii. Syntax and semantic analysis tools

These tools find syntax and semantic errors.

iii. Flow graph generator tools

These tools are language dependent and take the program as an input and convert it
to its flow graph. The flow graph may be used for many purposes like complexity
calculation, paths identification, generation of definition use paths, program slicing,
etc. These tools assist us to understand the risky and poorly designed areas of the
source code.

iv. Code comprehension tools

These tools may help us to understand unfamiliar source code. They may also
identify dead source code, duplicate source code and areas that may require special
attention and should be reviewed seriously.

v. Code inspectors

Source code inspectors do the simple job of enforcing standards in a uniform way
for many programs. They inspect the programs and force us to implement the
guidelines of good programming practices. Although they are language dependent,
most of the guidelines of good programming practices are similar in many
languages. These tools are simple and may find many critical and weak areas of the
program. They may also suggest possible changes in the source code for
improvement.

2. Dynamic Software Testing Tools

Dynamic software testing tools select test cases and execute the program to get the
results. They also analyze the results and find reasons for failures (if any) of the
program. They will be used after the implementation of the program and may also
test non-functional requirements like efficiency, performance, reliability, etc.

i. Coverage analysis tools

These tools are used to find the level of coverage of the program after executing the
selected test cases. They give us an idea about the effectiveness of the selected test
cases. They highlight the unexecuted portion of the source code and force us to
design special test cases for that portion of the source code. There are many levels
of coverage like statement coverage, branch coverage, and condition coverage,
multiple condition coverage, path coverage, etc.

ii. Performance testing tools

We may like to test the performance of the software under stress / load. For example,
if we are testing a result management software, we may observe the performance
when 10 users are entering the data and also when 100 users are entering the data
simultaneously. Similarly, we may like to test a website with 10 users, 100 users,
1000 users, etc. working simultaneously.

Iii. Functional / Regression Testing Tools

These tools are used to test the software on the basis of its functionality without
considering the implementation details. They may also generate test cases
automatically and execute them without human intervention. Some of the popular
available tools are IBM Rational’s Robot, Mercury Interactive’s Win Runner,
Comuware’s QA Centre and Segue Software’s Silktest.

3. Process Management Tools

These tools help us to manage and improve the software testing process. We may
create a test plan, allocate resources and prepare a schedule for unattended testing
for tracking the status of a bug using such tools. They improve many aspects of
testing and make it a disciplined process. Some of the tools are IBM Rational Test
Manager, Mercury Interactive’s Test Director, Segue Software’s Silk Plan Pro and
Compuware’s QA Director. Selection of any tool is dependent upon the application,
expectations, quality requirements and available trained manpower in the
organization. Tools assist us to make testing effective, efficient and performance
oriented.
 SOFTWARE TEST PLAN

It is a document to specify the systematic approach to plan the testing activities of

the software. If we carry out testing as per a well-designed systematic test plan
document, the effectiveness of testing will improve and that may further help to
produce a good quality product. The test plan document may force us to maintain a
certain level of standards and disciplined approach to testing. Many software test
plan documents are available, but the most popular document is the IEEE standard
for Software Test Documentation (Std 829 – 1998). This document addresses the
scope, schedule, milestones and purpose of various testing activities. It also specifies
the items and features to be tested and features which are not to be tested. Pass/fail
criteria, roles and responsibilities of persons involved, associated risks and
constraints are also described in this document. Some changes may be made as per
requirement of the project. A test plan document is prepared after the completion of
the SRS document and may be modified along with the progress of the project. We
should clearly specify the test coverage criteria and testing techniques to achieve the
criteria. We should also describe who will perform testing, at what level and when.
Roles and responsibilities of testers must be clearly documented.

TEST PLAN OUTLINE (IEEE 829 FORMAT) -

1) Test Plan Identifier

2) References
3) Introduction
4) Test Items
5) Software Risk Issues
6) Features to be Tested
7) Features not to be Tested
8) Approach
9) Item Pass/Fail Criteria
10) Suspension Criteria and Resumption Requirements
11) Test Deliverables
12) Remaining Test Tasks
13) Environmental Needs
14) Staffing and Training Needs
15) Responsibilities
16) Schedule
17) Planning Risks and Contingencies
18) Approvals
19) Glossary