UNIT – I

 Testing consumes at least half of the time and work required to produce a
functional program
 History reveals that even well written programs still have 1-3 bugs per
hundred statements

Productivity and Quality in Software

Goals for Testing
Test Design

Productivity and Quality in Software:

 In production of consumer goods and other products, every

manufacturing stage is subjected to quality control and testing from
component to final stage
 If flaws are discovered at any stage, the product is either discarded or
cycled back for rework and correction

 Productivity is measured by the sum of the costs of the material, the rework and the
discarded components and the cost of quality assurance and testing
  There is a trade-off between quality assurance costs and manufacturing
costs
 If sufficient time is not spent in quality assurance, the reject rare is high
and so is the net cost
 If inspection is good and all errors are caught as they occur, inspection
costs dominates and again the net cost suffers
 Testing and Quality assurance costs for manufactured items can be as low
as 2% in consumer products or as high as 80% in products such as
spaceships, nuclear reactiors and aircrafts, where failures threaten life.
Where as the amnufacturing cost of a software is trivial
 The biggest part of software cost is the cost of bugs, the cost of detecting
them, the cost of correcting them, the cost of desinging tests that discover
them and the cost of running those tests
 For software, quality and productivity are indistinguishable, because the
cost of a software copy is trivial

Goals for Testing:

 Testing and test design are parts of quality assurance that should also
focus on bug prevention
 A prevented bug is better than a detected and corrected bug

Phases in testers mental life can be categorized into the following 5 phases:

Phase 0: Until 1956: (Debugging Oriented)

Phase 1: 1957-1978: (Demonstration Oriented)
Phase 2: 1979-1982: (Destruction Oriented)
Phase 3: 1983-1987: (Evaluation Oriented)
Phase 4: 1988-2000: (Prevention Oriented)

Phase 0: Until 1956: (Debugging Oriented)

 There is no difference between testing and debugging

 Phase 0 thinking was the norm in early days of software development till
testing emerged as a discipline

Phase 1: 1957-1978: (Demonstration Oriented)

 The purpose of testing here is to show that software works

 Highlighted during the late 1970's
 This failed because the probability of showing that software work
'decreases' as testing increases. i.e. the more the test, the more likely a
bug is found
Phase 2: 1979-1982: (Destruction Oriented)

 The purpose of testing is to show that software doesn't work

 This phase also failed because the software is never released, as we find
one bug or the other. Also a bug corrected may also lead to another bug

Phase 3: 1983-1987: (Evaluation Oriented)

 The purpose of testing is not to prove anything but to reduce the

perceived risk of not working to an acceptable value (Statistical Quality
Control)
 Notion is that testing does improve the product, to the extent that testing
catches bugs, and to the extent that those bugs are fixed
 The product is released when the confidence on that product is high
enough ( Note: This is applied to large software products with millions of
code years of use)

Phase 4: 1988-2000: (Prevention Oriented)

 Testability is the factor considered here, Once reason is to reduce the

labour of testing
 Other reason is to check the testable and non-testable code
 Testable code has fewer bugs than the code that's hard to test
 Identifying the testing techniques to test the code is the main key here

Test Design

 Software design is the process of implementing software solutions to one

or more set of problems, One of the important parts of software design is
the Software Requirements Analysis(SRA)
 We know that the software code must be designed and tested, but many
appear to be unaware that tests themselves must be designed and tested
 Tests should be properly designed and tested before applying it to the
actual code
 Testing is not everything. There are approaches other than testing to
create better software
 Methods other than testing include:

Inspection Methods: Methods like walk throughs, desk checking, formal

inspections and code reading appear to be as effective as testing, but the bugs
caught do not completely overlap

Design Style: While designing the software itself, adopting stylistic objectives
such as testability, openness and clarity can do much, to prevent bugs
Static Analysis Methods: It includes formal analysis of source code during
compilation, In earlier days, this is a routine job of the programmer, Now, the
compilers have taken over this job

Languages: The source language can help reduce certain kinds of bugs.
Programmers find new bugs while using new languages

Development Methodologies and Development Environment: The

development process and the environment in which that methodology is
embedded, can prevent many kinds of bugs

Dichotomies:

Testing vs Debugging
Function vs Structure
Designer vs Tester
Modularity vs Efficiecy
Small vs Large
Builder vs Buyer
Testing vs Debugging

 Many people consider both as same, but

 Testing start with known conditions, uses predefined procedures and has
predictable outcomes
 Debugging starts from possibly unknown initial conditions and the end
can not be predicted(except statically)
 The purpose of testing is to find the error or misconception that led to the
programs failure, and to design and implement the program changes that
correct the error
 Testing is performed to find the location of a defect, and debugging is
performed to fix these defects
 Testing is performed by the testing team and debugging is performed by
the development team
 Intention behind testing is to find as many defects as possible in the
defined environment, but the intention behind debugging is to fix as
many defects as possible keeping the requirements in view.
  Debugging usually follows testing, but they differ as to goals, methods
and most importantly, psychology. The below table shows few important
differences testing and debugging.

Testing Debugging

Testing starts with known conditions, uses Debugging starts from possibly unknown
predefined procedures and has predictable initial conditions and the end can not be
outcomes predicted except statistically

Testing can and should be planned, designed Procedure and duration of debugging cannot
and scheduled be so constrained

Testing is a demonstration of error or Debugging is deductive process

apparent correctness

Testing proves a programmers failure Debugging is the programmers

vindication(Justification)

Testing, as executes, should strive to be Debugging demands intuitive leaps,

predictable, dull, constrained, rigid and experimentation and freedom
inhuman

Much testing can be done without design Debugging is impossible without detailed
knowledge design knowledge

Testing can often be done by an outsider Debugging must be done by an insider

Much of test execution and design can be Automated debugging is still a dream.
automated
 Function vs Structure

Function Structure

It takes the user point of view-bother about It looks at the implementation details
functionality and features and not the
programs implementation

In functional testing, the program or Things such as programming style, control

system is treated as a black box method, source language, database design,
and coding details dominate structural testing
It is subjected to inputs and its outputs are
verified for conformance to specified
behaviour

 Both structural and functional tests are useful, both have limitations, and
both target different kinds of bugs
 Functional tests can detect all bugs but would take massive time to do so
 Structural tests are inherently finite, but cannot detect all errors, even if
completely executed

Designer vs Tester

 Test designer is the person who designs the test, whereas the tester is the
one who actually tests the code
 During functional testing, the designer and tester are probably different
persons. During unit testing, the tester and the programmer merge into
one person
 Tests that are designed and executed by software designers are more
likely inclined to structural considerations
 Structural testing restricts these tests to convey its meaning correctly in a
simple lucid (easy) manner
Modularity vs Efficiency

 A module is a discrete, well-defined, small component of a system

 If modules are small, then they are difficult to integrate
 If modules are large, then they are difficult to understand
 Both tests and systems can be modular
 Testing should be organized into modular components
 small, independent test cases can be designed to test independent modules
 So has to have efficient testing in modular programming approach,
components belonging to a particular module shall be organized and the
other in which they are to be tested shall be streamlined using a test
procedure
 Test cases related to components shall be grouped and presented
 Components and related dependency information shall be maintained
 If the system is modular, the tests can also be modular which results in
the efficiency of the system as well as in the efficiency of testing process
 Proper care should be taken to minimize the effort needed for test design,
debugging and test execution with out compromising the efficiency

Small vs Large

 Programming in the large, means constructing programs that consists of

many components written by many different programmers
 Example for programming in the large- The software is developed by
several people with a few thousands of statements for more than 5 years
 Programming in the small, is what we do for ourselves in the privacy of
our own offices
 Example for programming in the small- Home work exercises for college
students, personal scripts to manage our data etc.
 Qualitative and Quantitative changes occur with size and so must testing
methods and quality criteria
Builder vs Buyer

 Most of the software's are written and used by the same organizations
 Unfortunately, this situation id dishonest, because it clouds accountability
 If there is no separation between builder and buyer, there can be no
accountability

Model for Testing

 The image shows a model of testing process

 It includes three models: A model of the environment, a model of the
program and a model of the expected bugs

 Tests are formal procedures where

Inputs must be prepared

Outcomes should be pre directed
Tests should be documented
Commands need to be executed
Results are to observed

 All these errors are subjected to error

 A typical software system goes through with following three test

Unit/Component Testing
Integration Testing
System Testing
Unit/Component Testing

 A unit is the smallest testable piece of software that can be compiled,

assembled, linked, loaded etc
 A unit is usually the work of one programmer and consists of several
hundred or fewer lines of code
 Unit Testing is the testing we do to show that the unit does not satisfy its
functional specification, or that its implementation structure does not
match the intended design structure
 A component is an integrated aggregate of one or more units
 Component Testing is the testing we do to show that the component does
not satisfy its functional specification or that its implementation structure
does not match the intended design structure
 Unit testing aims at testing each of the components that a system are built
upon. As long as each of them work as they are defined to , then the
system as a whole has a better chance of working together

Integration testing

 Integration is the process by which components are aggregated to created

larger components
 Integration testing is testing done to show that even through the
components were individually satisfactory (after passing componet
testing)
 It checks if the combination of components are incorrect or inconsistent
 It verifying software quality by testing two or more depedent software
modules as a group

System Testing

 A system is a big component

 System Testing is aimed at revealing bugs that cannot be attributed to
components
 It includes testing for performance, security, accountability, configuration
sensitivity, startup and recovery
 System testing enables us to test, verify and validate both the business
requirements as well as the applications architecture

Consequences of Bugs
The consequences of a bug can be measured in terms of human, rather than
machine, some consequences of a bug on a scale of one to ten are:
  1. Mild: The symptoms of the bug offend us gently; a misspelled output
or a misaligned printout.
 2. Moderate: Outputs are misleading or redundant. The bug impacts the
systems performance.

 3. Annoying: The Systems behaviour, because of the bug is

dehumanizing.

Example: Names are truncated or arbitrarily modified.

 4. Disturbing: It refuses to handle legitimate (authorized/legal)

transactions.

Example: The ATM wont give money. Credit card is declared

Invalid.

 5. Serious: It loses track of its transaction. Not just the transaction itself
but the fact that the transaction occurred and accountability is lost.

 6. Very Serious: The bug causes the system to do the wrong transactions.
Instead of gaining a pay check, the system credits it to another account or
converts deposits to withdrawals.

 7. Extreme: The problems are not limited to a few users or to few

transaction types. They are frequent and arbitrary, ( instead of
occasionally infrequent) or for unusual case.

 8. Intolerable: Long term unrecoverable corruption of the database occurs

and the corruption is not easily discovered. Serious consideration is given
to shutting the system down.

 9. Catastrophic: The decision to shut down is taken out of our hands

because the system fails.

 10. Infectious: What can be worse than a failed system? One that corrupts
other systems even though it does not fail in itself; that erodes the social
physical environment; that melts reactors and starts a war.

Taxonomy of Bugs

 There is no universally correct way to categorize bugs. The taxonomy is

not rigid
  A given bug can be put into one or another category depending on its
history and the programmers state of mind
 The major Categories are:
1. Requirements, Features and Functionality Bugs.
2. Structural Bugs
3. Data Bugs and Coding Bugs
4. Interface, Integration and Systems Bugs.
5. Test and Test Design Bugs.

Path Testing is a method that is used to design the test cases. In path testing
method, the control flow graph of a program is designed to find a set of linearly
independent paths of execution. In this method Cyclomatic Complexity is used
to determine the number of linearly independent paths and then test cases are
generated for each path.
It gives complete branch coverage but achieves that without covering all
possible paths of the control flow graph. McCabe’s Cyclomatic Complexity is
used in path testing. It is a structural testing method that uses the source code of
a program to find every possible executable path.
Path Testing Process:

Draw Control Flow Graph

Calculate Cyclomatic Complexity

Make Set of Paths

Create Test Cases

 Control Flow Graph:

Draw the corresponding control flow graph of the program in which
all the executable paths are to be discovered.
 Cyclomatic Complexity:
After the generation of the control flow graph, calculate the
cyclomatic complexity of the program using the following formula.

McCabe's Cyclomatic Complexity = E - N + 2P

Where,
E = Number of edges in control flow graph
N = Number of vertices in control flow graph
 P = Program factor

 Make Set:
Make a set of all the path according to the control flow graph and
calculated cyclomatic complexity. The cardinality of set is equal to the
calculated cyclomatic complexity.

 Create Test Cases:

Create test case for each path of the set obtained in above step.

Path Testing Techniques:

 Control Flow Graph:
The program is converted into control flow graph by representing the
code into nodes and edges.

 Decision to Decision path:

The control flow graph can be broken into various Decision to
Decision paths and then collapsed into individual nodes.

 Independent paths:
Independent path is a path through a Decision to Decision path graph
which cannot be reproduced from other paths by other methods.

Advantages of Path Testing:

1. Path testing method reduces the redundant tests.
2. Path testing focuses on the logic of the programs.
3. Path testing is used in test case design.

REQUIREMENTS, FEATURES AND FUNCTIONALITY BUGS:

Various categories in Requirements, Features and Functionality bugs include:
1.Requirements and Specifications Bugs:
Requirements and specifications developed from them can be incomplete ambiguous, or
self-contradictory. They can be misunderstood or impossible to understand.

The specifications that don't have flaws in them may change while the design is in progress.
The features are added, modified and deleted.

Requirements, especially, as expressed in specifications area major source of expensive

bugs.

The range is from a few percentage to more than 50%, depending on the application and
environment.
What hurts most about the bugs is that they are the earliest to invade the system and the last
to leave

2. Feature Bugs:

Specification problems usually create corresponding feature problems.

A feature can be wrong, missing, or superfluous (serving no useful purpose). A

missing feature or case is easier to detect and correct. A wrong feature could have deep
design implications.

Removing the features might complicate the software, consume more resources, and foster
more bugs.

3. Feature Interaction Bugs:

Providing correct, clear, implementable and testable feature specifications is not enough.

Features usually come in groups or related features. The features of each group and the
interaction of features with in the group are usually well tested.

The problem is unpredictable interactions between feature groups or even between

individual features. For example, your telephone is provided with call holding and call
forwarding. The interactions between these two features may have bugs.

Every application has its peculiar set of features and a much bigger set of unspecified feature
interaction potentials and there fore result in feature interaction bugs.

STRUCTURAL BUGS:
Various categories in Structural bugs include:

Control and Sequence Bugs:

Control and sequence bugs include paths left out, unreachable code, improper nesting of
loops, loop-back or loop termination criteria incorrect, missing process steps, duplicated
processing, unnecessary processing, rampaging, GOTO's, ill-conceived (not properly
planned) switches, sphagetti code, and worst of all, pachinko code.

One reason for control flow bugs is that this area is amenable (supportive) to theoretical
treatment.

Most of the control flow bugs are easily tested and caught inunit testing.
Another reason for control flow bugs is that use of old code especially ALP &
COBOL code are dominated by control flow bugs.

Control and sequence bugs at all levels are caught by testing, especially structural testing,
more specifically path testing combined with a bottom line functional test based on a
specification.

DATA BUGS:

Data bugs include all bugs that arise from the specification of data objects, their formats, the
number of such objects, and their initial values.

Data Bugs are atleast as common as bugs in code, but they arefoten treated as if they did not
exist at all.

Code migrates data:

Software is evolving towards programs in which more and more of the control and
processing functions are stored in tables.

Because of this, there is an increasing awareness that bugs in code are only half the battle
and the data problems should be given equal attention.

CODING BUGS:

Coding errors of all kinds can create any of the other kind of bugs.

Syntax errors are generally not important in the scheme of things if the source language
translator has adequate syntax checking.

If a program has many syntax errors, then we should expect many logic and coding bugs.

The documentation bugs are also considered as coding bugs which may mislead the
maintenance programmers.

INTERFACE, INTEGRATION, AND SYSTEM BUGS:

Various categories of bugs in Interface, Integration, and System Bugs are:

1. External Interfaces:

The external interfaces are the means used to communicate with the world.
These include devices, actuators, sensors, input terminals, printers, and communication
lines.

The primary design criterion for an interface without side world should be robustness.

All external interfaces, human or machine should employ a protocol. The protocol
may be wrong or incorrectly implemented.

Other external interface bugs are: invalid timing or sequence assumptions related to external
signals

Misunderstanding external input or output formats.

Insufficient tolerance to bad input data.

2. Internal Interfaces:

Internal interfaces are in principle not different from external interfaces but they are more
controlled.

A best example for internal interfaces are communicating routines.

The external environment is fixed and the system must adapt to it but the internal
environment, which consists of interfaces with other components, can be negotiated.

Internal interfaces have the same problem as externalinterfaces.

3. Hardware Architecture:

Bugs related to hardware architecture originate mostly from misunderstanding how the
hardware works.

Examples of hardware architecture bugs: address generation error, i/o device operation /
instruction error, waiting too long for a response, incorrect interrupt handling etc.

The remedy for hardware architecture and interface problems is two fold: (1) Good
Programming and

Testing (2) Centralization of hardware interface software in programs written by hardware

interface specialists.

4. Operating System Bugs:

Program bugs related to the operating system are a combination of hardware architecture
and interface bugs mostly caused by a misunderstanding of what itis the operating system
does.

Use operating system interface specialists, and use explicit interface modules or macros for
all operating system calls.

This approach may not eliminate the bugs but at least will localize them and make testing
easier.

Integration Bugs:

Integration bugs are bugs having to do with the integration of, and with the interfaces
between, working and tested components.

These bugs results from inconsistencies or incompatibilities between components.

The communication methods include data structures, call sequences, registers, semaphores,
communication links and protocols results in integration bugs.

The integration bugs do not constitute a big bug category(9%) they are expensive category
because they are usually caught late in the game and because they force changes in several
components and/or data structures.9.

System Bugs:

System bugs covering all kinds of bugs that cannot be ascribed to a component or to their
simple interactions, but result from the totality of interactions between many components
such as programs, data, hardware, and the operating systems.

There can be no meaningful system testing until there has been thorough component and
integration testing.
System bugs are infrequent(1.7%) but very important because they are often found only
after the system has been fielded.

TEST AND TEST DESIGN BUGS:

Testing: testers have no immunity to bugs. Tests require complicated scenarios and
databases.

They require code or the equivalent to execute and consequently they can have bugs.
Test criteria: if the specification is correct, it is correctly interpreted and implemented, and a
proper test has been designed; but the criterion by which the software's behaviour is judged
may be incorrect or impossible. So, a proper test criteria has to be designed. The more
complicated the criteria, the likelier they are to have bugs.

Remedies:

The remedies of test bugs are:

1. Test Debugging:

The first remedy for test bugs istesting and debugging the tests. Test debugging, when
compared to program debugging, is easier because tests, when properly designed are
simpler than programs and donot have to make concessions to efficiency.

2. Test Quality Assurance:

Programmers have the right to ask how quality in independent testing ismonitored.

3. Test Execution Automation:

The history of software bug removal and prevention is indistinguishable from the history of
programming automation aids. Assemblers, loaders, compilers are developed to
reduce the incidence of programming and operation errors. Test execution bugs are virtually
eliminated byvarious test execution automation tools.

4. Test Design Automation:

Just as much of software development has been automated, much test design can be and has
been automated. For a given productivity rate, automation reduces the bug count -be it for
software or be it for tests.

Basics concepts of path testing:

Basis Path Testing is a white-box testing technique based on the control

structure of a program or a module. Using this structure, a control flow graph
is prepared and the various possible paths present in the graph are executed as
a part of testing. Therefore, by definition, Basis path testing is a technique of
selecting the paths in the control flow graph, that provide a basis set of
execution paths through the program or module. Since this testing is based on
the control structure of the program, it requires complete knowledge of the
program’s structure. To design test cases using this technique, four steps are
followed:
1. Construct the Control Flow Graph
2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths
Let’s understand each step one by one. 1. Control Flow Graph – A control
flow graph (or simply, flow graph) is a directed graph which represents the
control structure of a program or module. A control flow graph (V, E) has V
number of nodes/vertices and E number of edges in it. A control graph can
also have:
 Junction Node – a node with more than one arrow entering it.
 Decision Node – a node with more than one arrow leaving it.
 Region – area bounded by edges and nodes (area outside the graph is
also counted as a region.).

Below are the notations used while constructing a flow graph:

Sequential Statements:
If – Then – Else:

Do – While:

While – Do:

Switch – Case:
Advantages of Basic Path Testing

 It helps to reduce the redundant tests

 It focuses attention on program logic
 It helps facilitates analytical versus arbitrary case design
 Test cases which exercise basis set will execute every statement in a
program at least once

Predicates, Path Predicates and Achievable Paths

Predicate:
The logical function evaluated at a decision is called predicate
The direction taken at a decision depends on the value of decision variable

Some examples are: A>0, x + y >= 90...........

Path Predicate:

AND
"W is either negative or equal to 10" is true

Multiway Branches:

The path taken through a multiway branch such as computed GOTO, case
statement, or jump tables cannot be directly expressed in TRUE/FALSE terms.

Although, it is possible to describe such alternatives by using multi valued

logic, a practical approach is to express multiway branches as an equivalent set
of if... then...else statements
For example, a three way case statement can be written as:
if case = 1 DO A1
ELSE (IF Case = 2 DO A2 else DO A3 END IF) END IF
Path Sensitizing
Review: Achievable and Unachievable Paths:

 We want to select and test enough paths to achieve a satisfactory notion

of test completeness, such as C1 + C2
 Extract the programs control flow graph and select a set of tentative
covering paths
 For any path in that set, interpret the predicates along the path as needed
to express them in terms of the input vector
 In general, individual predicates are compound or may become
compound as a result of interpretation
 Trace the path through by multiplying the individual compound
predicates to achieve a Boolean expression such as

(A + BC) (D + E) (FGH) (IJ) (K) (I) (L)

 Multiply the expression to achieve a sum of products form:

ADFGHIJKL + AEFGHIKL + BCDFGHIJKL + BCEFCHIJKL

 Each product term denotes a set of inequalities, that if solved will yield an
input vector that will drive the routine along the designated path
 Solve any one of the inequality sets for the chosen path, and you have
found a set of input values for the path
 If you can find a solution, the the path is achievable
 If you cannot find a solution, then the path is achievable
 If you cannot find a solution to any of the sets of inequalities, the path is
not achievable
 The act of finding a set of solutions to the path predicate expression is
called path sensitization

Heuristic Procedures for Sensitizing Paths:

 This is a workable approach, instead of selecting the paths without

considering how to sensitize, attempt to choose a covering path set that is
easy to sensitize and pick hard to sensitize paths only as you must to
achieve coverage
 Identify all variables that affect the decision
 Classify the predicates as dependent or independent
 Start the path selection with uncorrelated, independent predicates
 If coverage has not been achieved using independent uncorrelated
predicates, extend the path set using correlated predicates
  If coverage has not been achieved, extend the cases to those that involve
dependent predicates
 Finally, use correlated and dependent predicates

Path Instrumentation:
Path Instrumentation is 4 types as follows:
Interpretive Trace Program
Traversal Marker or Link Marker
Two Link Marker Method
Link Counter

Interpretive Trace Program:

An Interpretive Trace Program is the one that executes every statement in order,
and records the intermediate values of all calculations, the statement labels
traversed etc.
If we run the tested routine under a trace, then we have all the information
needed to confirm the outcome and furthermore, to confirm that it was achieved
by the intended path
The trouble with traces is that they give us far more information than we need
In fact, the typical trace program provides so much information that confirming
the path from its massive output dump is more work than simulating the
computer by hand to confirm the path

Traversal Marker or Link Marker:

A simple and effective form of instrumentation is called a Traversal Marker or
Link Marker
Name every link by a lowercase letter
Instrument the links so that the links name is recorded when the link is executed
The succession of letters produced in going form the routines entry to its exit
should, if there are no bugs, exactly correspond to the path name
Two Link Marker Method

The solution to the problem of single link marker method is to implement two
markers per link, one at the beginning of each link and one at the end

The two link markers now specify the path name and confirm both the
beginning and end of the link

Link Counter

A less disruptive (and less informative) instrumentation method is based on

outcomes

Instead of a unique link name to be pushed into a string when the link traversed,
we simply increment a link counter, we now confirm that the path length is
expected

The same problem that led tus to double link markers also leads us to double
link counters

Application of Path Testing:

Integration, Coverage and Paths in called Components

New Code
Maintenance
Rehosting

Integration, Coverage and Paths in called Components:

Path testing methods are mainly used in unit testing, especially for new software
The new component is first tested as an independent unit with all called
components and co-requisite components replaced by stubs. A simulator of low-
level components that is more reliable than the actual component

Path testing clarifies the integration issues

C1 coverage at the system level ranges from 50% to 85%

We gave no statistics for C 2 coverage in system testing because it is impossible

to monitor C2 coverage without disrupting the system's operation

Note:

Co-requisite: A formal course of study required to be taken simultaneously with

another

New Code:

New code should always be subjected to enough path testing to achieve C 2

Stubs are used where it is clear that the bug potential for the stub is significantly
lower than that of the called components

Old, trusted components will not be replaced by stubs

Some consideration is given to paths within called components

Typically, we will try to use the shortest entry/exit path that will do the task

Maintenance:

There is a great difference between maintenance testing and new code testing
Maintenance testing is a completely different situation

It involves modifications which are accommodated in the system, as required

Path testing is used firstly on the modified component

Rehosting:

Path testing with C1+C2 coverage is a powerful tool for rehosting old software

We get a very powerful, effective, rehosting process when C 1+C2 coverage is

used in conjunction with automatic or semiautomatic structural test generators
Software is rehosted because it is no longer cost effective to support the
environment in which it runs

The objective of rehosting is to change the operating environment and not the
rehosted software
Rehosting from one COBOL environment to another is easy by comparison

Rehosted software can be modified to improve efficiency and/or to implement

new functionality, which had been difficult in the old environments

The test suites(collection) and all outcomes of the old environment become the
specification for the rehosted software