SE

Pressman – 7 th edition
MACFAST
Lat-00 reg- 00
Overview

• The importance of software testing to software

quality can not be overemphasized. Once source
code has been generated, software must be tested
to allow errors to be identified and removed before
delivery to the customer. While it is not possible to
remove every error in a large software package, the
software engineer’s goal is to remove as many as
possible early in the software development cycle. It
is important to remember that testing can only find
errors it cannot prove that a program is free of bugs.
Overview contd..
• Two basic test techniques exist for testing
conventional software, testing module input/output
(black-box) and exercising the internal logic of
software components (white-box). Formal technical
reviews by themselves cannot find all software
defects, test data must also be used. For large
software projects, separate test teams may be used
to develop and execute the set of test cases used in
testing. Testing must be planned and designed.
Quick Look
• What is it?
– Sc must be tested. We need to design tc that will
find errors.1.Exercise internal logic and interfaces
2.exercise every ip and op domains of the pgm
• Who does it?
– S engr at early stages and later specialists
• Why important?
– Reviews and SQA actions can uncover errors
Quick Look..
• What are the steps?
– 1. Internal logic tested – W B testing
– Sw req are exercised using B B testing
• What is the work product?
– Set of tc designed for WB and BB
• How do I know ensure that I’ve done right
– Try to break the sw, evaluate test coverage, etc
• Testing requires that the developer discard
preconceived notions of the “correctness” of
software just developed and then work hard to
design test cases to “break” the software.- Beizer
• Is testing and test case design an admission of
failure ?
• Should testing instill guilt? Is testing really
destructive?
• The answer to these questions is “No!”
File Open - A Sample Test case
• Steps to reproduce:
1. Launch Application
2. Select "File" menu 
File menu pulls down
3. Choose "Open" 
"Open" dialog box appears
4. Select a file to open
5. Click OK
Result: File should open
Test case
• Test case ID: B 001
Test Description: verify B - bold formatting to the
text Revision History:
3/ 23/ 00 1.0- Valerie- Created
Function to be tested: B - bold formatting to the text 
Environment: Win 98
Test setup: N/A
Test Execution:
1. Open program
2. Open new document
3. Type any text 
4. Select the text to make bold. 
5. Click Bold
Expected Result: Applies bold formatting to the text 
Actual Result: pass
Software Testing Objectives/funda

• Testing is the process of executing a program

with the intent of finding errors.
• Testability: “Software ~ is simply how easily a
computer pgm can be tested”- James Bach
• A good test case is one with a high probability
of finding an as-yet undiscovered error.
• A successful test is one that discovers an as-
yet-undiscovered error.
Software Testability Checklist/char

• Operability – the better it works the more efficiently it can be tested.

Fewer bugs ensures better execn of tests.
• Observability – what you see is what you test. Sys states and variables
are visible during execn.
• Controllability – the better the software can be controlled the more
testing can be automated and optimized
• Decomposability – by controlling the scope of testing, the more quickly
problems can be isolated and retested intelligently
• Simplicity – the less there is to test, the more quickly we can test. Pgm
should exibit functional simplicity, structural ~ and code ~.
• Stability – the fewer the changes, the fewer the disruptions to testing
• Understandability – the more information known, the smarter the
testing
Good Test Attributes/charac

• A good test has a high probability of finding an error.-

must visualize the “failure” of sw
• A good test is not redundant. Every test should have a
distinct purpose.
• A good test should be best of breed. Tests with the
highest likelihood of uncovering a whole class of
errors should be used.
• A good test should not be too simple or too complex.
When series of tests are combined, it may mask
errors.
Test Case Design Strategies

• Black-box or behavioral testing – knowing the

specified function a product is to perform and
demonstrating correct operation based solely on its
specification without regard for its internal logic.
Also called Fnl or strl T.
• White-box or glass-box testing – knowing the
internal workings of a product, tests are performed
to check the workings of all possible logic paths. WB
can be done only after the component level design
(s code) exists.
White-box Testing
• WB is predicated on close examination of proc
detail
• WB testing is a test case design philosophy
that uses the control structure described as
part of component level design to derive test
cases.
WB testing
• WB takes care of the following questions.
White-Box Testing Questions

• Can you guarantee that all independent paths

within a module will be executed at least once?
• Can you exercise all logical decisions on their
true and false branches?
• Will all loops execute at their boundaries and
within their operational bounds?
• Can you exercise internal data structures to
ensure their validity?
WB testing..
• White-box testing (also known as clear box testing,
glass box testing, transparent box testing, and
structural testing) is a method of testing software
that tests internal structures or workings of an
application, as opposed to its functionality (i.e.
black-box testing). In white-box testing an internal
perspective of the system, as well as programming
skills, are used to design test cases. The tester
chooses inputs to exercise paths through the code
and determine the appropriate outputs.
WB testing..
• While white-box testing can be applied at the
unit, integration and system levels of the software
testing process, it is usually done at the unit level.
It can test paths within a unit, paths between
units during integration, and between subsystems
during a system–level test. Though this method of
test design can uncover many errors or problems,
it might not detect unimplemented parts of the
specification or missing requirements.
• White-box test design techniques include:

• Control flow testing

• Data flow testing
• Branch testing
• Basis Path testing
• Statement coverage
• Decision coverage
Basis Path Testing
• BPA is a WB testing techniq – Tom McCabe.
• BPA enables the test case designer to derive a
logical complexity measure of a proc design and
use this measure as a guide for defining a basis
set of execn paths. Guarantees atleast 1 time
excn of every stmt.
• Flow graph / Pgm graph – is a simple notation
for the repn of control flow. Depicts logical
control flow
Flow graph *
• Each construct of pgm is a FG symbol
• F G allows you to trace pgm paths readily.
• F chart depicts pgm control structure while F graph is
the repn of control flow
• 18.1
• 18.2
• F Graph node – each circle - rep procedural stmts
• Edges / Links – rep flow of control
• Regions- compound condition – Predicate node
Rpt*
Flow chart
Flow graph
Compound logic

• Each node that contains a condition is called a

predicate node and is characterized by two or more
edges emanating from it.
Rpt*
Independent pgm path
• Independent path is any path thru the pgm
that introduces at least one new set of
processing statements or a new condition.
• Wrt 18.2(b) independent paths are as:
– Path 1 – 1 11
– Path 2 – 1 2 3 4 5 10 1 11
– Path 3 – 1 2 3 6 8 9 10 1 11
– Path 4 – 1 2 3 6 7 9 10 1 11
Rpt*
• Path 1 – 4 constitute the basis set for the flow
graph in fig 18.2(b) ie: if we can design tests
to force execn of these paths (basis set), every
statement in the pgm will have been
guaranteed to be executed on its T F sides at
least once
• Similarly no: of diff basis sets can be derived for
a given proc design. ie:Basis set not unique
• But how many paths to look for?
• Cyclomatic complexity is the answer.
• CC is the sw metric that provides a qualitative
measure of the logical complexity of a pgm
• Value of cc determines the no: of independent paths
in the basis set of a pgm and provides us with an
upper bound for the no: of tests that must be
conducted to ensure that stmts have been executed at
least once
• High values of V(G)- likely to be error prone even
though no guarantee
Find the C Complexity?
Thus…
• White-box technique usually based on the program flow
graph
• The cyclomatic complexity of the program computed from
its flow graph using the formula V(G) = E – N + 2 or by
counting the conditional statements in the program design
language (PDL) representation and adding 1
• Determine the basis set of linearly independent paths (the
cardinality of this set id the program cyclomatic complexity)
• Prepare test cases that will force the execution of each
path in the basis set.
Deriving test cases- BPT steps
• Wrt procedure average, to deter the basis set
• S1: using the design/code draw Fgraph
• S2: determine the cyclomatic complexity
• S3: determine a basis set of independ paths
• S4: Prepare test cases that force execn of each
path in the basis set
• CC of flow graph is 6. ::: 6 regions; 17edg-13 nodes
+2 =6; 5 predic nodes +1 =6

• The basis set (independent paths) of 6 is found out.

• Prepare Test cases for all basis paths

Graph matrices
• A ds called ~ is used to develop a sw tool that
assist in BP Testing
• A ~ is a square matrix whose size (r & c) is
equal to the no of nodes on the flow graph
• Graph – tabular repn but when we add a link
weight to each matrix entry, GM is a powerful
tool for evaluating pgm str
Graph matrices …
The procedure for deriving the flow graph and even
determining a set of basis paths is amenable to
mechanization. A data structure, called a graph matrix(square
matrix) can be quite useful for developing a software tool that
assists in basis path testing.
Graph matrices … *
Graph matrices …
• The link weights can be assigned other, more
interesting properties:
– The probability that a link (edge) will be execute.
– The processing time expended during traversal of a link
– The memory required during traversal of a link
– The resources required during traversal of a link.
• Using additional techniques of algorithms, the
analysis required to design test cases can be
partially or fully automated.
Control Structure Testing
• BPT is one of the no: f techniques used for CST
• All though BPT is simple and highly effective, it
is not self sufficient in itself. Other variations
of ~ are –
– Condition testing
– Data flow testing
– Loop testing* -
Control Structure Testing

• White-box technique focusing on control structures present in the software

• Condition testing (e.g. branch testing) – focuses on testing each decision
statement in a software module, it is important to ensure coverage of all
logical combinations of data that may be processed by the module (a truth
table may be helpful)
• Data flow testing – selects test paths based according to the locations of
variable definitions and uses in the program (e.g. definition-use chains*)
Every DU chain will be covered once
• Loop testing – focuses on the validity of the program loop constructs (i.e.
simple loops, concatenated loops, nested loops, unstructured loops),
involves checking to ensure loops start and stop when they are supposed
to (unstructured loops should be redesigned whenever possible) ~ is a WB
testing technique.
• Data flow testing is a technique used to detect
improper use of data in a program. By looking
data usage, risky areas of code can be found
and more test cases can be applied. To test
data flow we devise control flow graph.
Loop Testing
• Loop testing is a white-box testing technique
that focuses exclusively on the validity of loop
constructs. Four different classes of loops can
be defined: simple loops, concatenated loops,
nested loops, and unstructured loops
Loop Testing
Black Box Testing

• Black box testing is a software testing techniques in

which functionality of the software under test (SUT)
is tested without looking at the internal code
structure, implementation details and knowledge of
internal paths of the software. This type of testing is
based entirely on the software requirements and
specifications.
• In Black Box Testing we just focus on inputs and
output of the software system without bothering
about internal knowledge of the software program.
Black Box Testing -DEFINITION
• Black Box Testing, also known as Behavioral
Testing, is a software testing method in which
the internal structure/design/implementation
of the item being tested is not known to the
tester. These tests can be functional or non-
functional, though usually functional.
Black-Box Testing Questions

• How is functional validity tested?

• How is system behavior and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input
values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system
tolerate?
• What effect will specific combinations of data have on
system operation?
• BB testing answers these qns

• Blackbox testing tends to be applied during

later stages of testing
• This method of attempts to find errors in the
following categories:
– Incorrect or missing functions
– Interface errors
– Errors in data structures or external database
access
– Behavior or performance errors
– Initialization and termination errors
EXAMPLE
• A tester, without knowledge of the internal
structures of a website, tests the web pages
by using a browser; providing inputs (clicks,
keystrokes) and verifying the outputs against
the expected outcome.
Black box testing - Steps

• Here are the generic steps followed to carry out any type of
Black Box Testing.
– Initially requirements and specifications of the system are examined.
– Tester chooses valid inputs (positive test scenario) to check whether
SUT processes them correctly . Also some invalid inputs (negative test
scenario) are chosen to verify that the SUT is able to detect them.
– Tester determines expected outputs for all those inputs.
– Software tester constructs test cases with the selected inputs.
– The test cases are executed.
– Software tester compares the actual outputs with the expected
outputs.
– Defects if any are fixed and re-tested.
LEVELS APPLICABLE TO
• Black Box Testing method is applicable to all
levels of the software testing process:
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
• The higher the level, and hence the bigger and
more complex the B box
      
• While White Box Testing (Unit Testing) validates internal structure and
working of your software code, the main focus of black box testing is on the
validation of your functional requirements.
• To conduct White Box Testing , knowledge of underlying programming
language is essential. Current day software systems use a variety of
programming languages and technologies and its not possible to know all of
them. Black box testing gives abstraction from code and focuses testing
effort on the software system behaviour.
• Also software systems are not developed in a single chunk but development
is  broken down  in different modules. Black box testing facilitates testing
communication amongst modules (Integration Testing) .
• In case you push code fixes in your live software system , a complete system
check (black box regression tests) becomes essential.
• White box testing has its own merits and help detect many internal errors
which may degrade system performance
Tools used for Black Box Testing:

• For Functional/ Regression Tests you can use –

QTP now HP Unified Functional Testing (UFT)
• For Non-Functional Tests you can use -
Loadrunner
BLACK BOX TESTING TECHNIQUES
• Graph Based Testing Methods
• Equivalence partitioning
• Boundary Value Analysis
• Orthogonal Array Testing
• Model Based Testing
• Testing for specialized environments
• Cause Effect Graphing
• Error Guessing
Graph-based Testing Methods
• you begin by creating a graph—a collection of nodes that
represent objects, links that represent the relationships
between objects, node weights that describe the properties
of a node (e.g., a specific data value or state behavior), and
link weights that describe some characteristic of a link.
• A directed link (represented by an arrow) indicates that a
relationship moves in only one direction. A bidirectional link,
also called a symmetric link, implies that the relationship
applies in both directions. Parallel links are used when a
number of different relationships are established between
graph nodes.
Graph-based Testing Methods..
• Black-box methods based on the nature of the relationships (links)
among the program objects (nodes), test cases are designed to
traverse the entire graph
• Beizer describes a no: of behavioral testing methods that can make
use of graphs:
– Transaction flow testing – nodes represent steps in some transaction and links
represent logical connections between steps that need to be validated
– Finite state modeling – nodes represent user observable states of the
software and links represent transitions between states
– Data flow modeling – nodes are data objects and links are transformations
from one data object to another
– Timing modeling – nodes are program objects and links are sequential
connections between these objects, link weights are required execution times
Graph-based Testing Methods
• S1: understand the objects that are modeled in
sw and the relationships that connect these
objects.
• s2: define a series of tests that verify “all
objects have the expected relationship to one
another” ie: software testing begins by creating
a graph of important objects and their
relationships
• Links ,directed, bidirectional, parallell
Beizer’s methods BB testing using graphs are: * rpt

• Transaction flow modeling. The nodes represent steps

in some transaction
• Finite state modeling. The nodes represent different
user-observable states of the software
• Data flow modeling. The nodes are data objects, and
the links are the transformations that occur to
translate one data object into another.
• Timing modeling. The nodes are program objects, and
the links are the sequential connections between those
objects.
Equivalence Partitioning

• Black-box technique that divides the input domain into classes of data
from which test cases can be derived
• An ideal test case uncovers a class of errors that might require many
arbitrary test cases to be executed before a general error is observed
• Equivalence class guidelines:
• If input condition specifies a range, one valid and two invalid equivalence
classes are defined
• If an input condition requires a specific value, one valid and two invalid
equivalence classes are defined
• If an input condition specifies a member of a set, one valid and one
invalid equivalence class is defined
• If an input condition is Boolean, one valid and one invalid equivalence
class is defined
Equivalence Class partitioning
• Divide the input space into equivalent classes
• If the software works for a test case from a class the
it is likely to work for all
• Can reduce the set of test cases if such equivalent
classes can be identified
• Getting ideal equivalent classes is impossible
• Approximate it by identifying classes for which
different behavior is specified

Testing 79
Equivalence class partitioning…
• Rationale: specification requires same
behavior for elements in a class
• Software likely to be constructed such that it
either fails for all or for none.
• E.g. if a function was not designed for negative
numbers then it will fail for all the negative
numbers
• For robustness, should form equivalent classes
for invalid inputs also

Testing 80
Equivalent class partitioning..

• Every condition specified as input is an equivalent

class
• Define invalid equivalent classes also
• E.g. range 0< value<Max specified
– one range is the valid class
– input < 0 is an invalid class

– input > max is an invalid class

• Whenever that entire range may not be treated
uniformly - split into classes
Testing 81
Equivalent class partitioning..
• Should consider eq. classes in outputs also and then
give test cases for different classes
• E.g.: Compute rate of interest given loan amount,
monthly installment, and number of months
– Equivalent classes in output: + rate, rate = 0 ,-ve rate
– Have test cases to get these outputs

Testing 82
Equivalence class…
• Once eq classes selected for each of the
inputs, test cases have to be selected
– Select each test case covering as many valid eq
classes as possible
– Or, have a test case that covers at most one valid
class for each input
– Plus a separate test case for each invalid class

Testing 83
Example
• Consider a program that takes 2 inputs – a
string s and an integer n
• Program determines n most frequent
characters
• Tester believes that programmer may deal
with diff types of chars separately
• A set of valid and invalid equivalence classes is
given

Testing 84
Example..

Input Valid Eq Class Invalid Eq class

S 1: Contains numbers 1: non-ascii char
2: Lower case letters 2: str len > N
3: upper case letters
4: special chars
5: str len between 0-N(max)
N 6: Int in valid range 3: Int out of range

Testing 85
Example…
• Test cases (i.e. s , n) with first method
– s : str of len < N with lower case, upper case, numbers, and
special chars, and n=5
– Plus test cases for each of the invalid eq classes
– Total test cases: 1+3= 4
• With the second approach
– A separate str for each type of char (i.e. a str of numbers,
one of lower case, …) + invalid cases
– Total test cases will be 5 + 2 = 7

Testing 86
Boundary value analysis
• A greater number of errors occurs at the boundaries of the
input domain rather than in the “center.”
• Boundary value analysis leads to a selection of test cases that
exercise bounding values.
• Programs often fail on special values
• These i/p values often lie on edge/boundary of equivalence
classes
• Test cases that have boundary values have high yield
• These are also called extreme cases
• A BV test case is a set of input data that lies on the edge of a
eq class of input/output

Testing 89
Boundary Value Analysis

• Black-box technique that focuses on the boundaries of the input

domain rather than its center
• BVA guidelines:
• If input condition specifies a range bounded by values a and b, test
cases should include a and b, values just above and just below a and b
• If an input condition specifies and number of values, test cases should
be exercise the minimum and maximum numbers, as well as values
just above and just below the minimum and maximum values
• Apply guidelines 1 and 2 to output conditions, test cases should be
designed to produce the minimum and maxim output reports
• If internal program data structures have boundaries (e.g. size
limitations), be certain to test the boundaries
BVA...

• For each equivalence class

– choose values on the edges of the class
– choose values just outside the edges
• E.g. if 0 <= x <= 1.0
– 0.0 , 1.0 are edges inside
– -0.1,1.1 are just outside (invalid i/ps)
• E.g. a bounded list - have a null list , a maximum
value list
• Consider outputs also and have test cases generate
outputs on the boundary
Testing 91
BVA.. (test cases for two vars – x and y)

Testing 92
• Popularized by G. Taguchi.
• An orthogonal array is a type of experiment where the columns for the independent
variables are “orthogonal” to one another.
• Benefits:
• 1. Conclusions valid over the entire region spanned by the control factors
• and their settings
• 2. Large saving in the experimental effort
• 3. Analysis is easy
• To define an orthogonal array, one must identify:
• 1. Number of factors to be studied
• 2. Levels for each factor
• 3. The specific 2-factor interactions to be estimated
• 4. The special difficulties that would be encountered in running the
• experiment
OAT
• Orthogonal array testing can be applied to problems
in which the input domain is relatively small but too
large to accommodate exhaustive testing.
• The orthogonal array is a systematic, statistical way of
software testing & is particularly useful in finding
region faults—an error category associated with faulty
logic within a software component.
• The net effects of organizing the experiment in such
treatments is that the same piece of information is
gathered in the minimum number of experiments
• X y z has 3 values associated . So 27 diff t
cases. one input item at a time may be varied
in sequence along each input axis. This results
in relatively limited coverage of the input
domain (lhs)
• When orthogonal array testing occurs, an
L9(3^3) orthogonal array of test cases is
created. The L9 orthogonal array has a
“balancing property”. That is, t c (represented
by dark dots in the figure) are “dispersed
uniformly throughout the test domain,” as
illustrated in rhs. Test coverage across the
input domain is more complete. *
• See example in doc
• Eg: send fn of fax , 81 tc reqd

• The orthogonal array testing approach enables you to provide

good test coverage with far fewer test cases than the
exhaustive strategy.
• Thus, same piece of information is gathered in the minimum
number of experiments and each vector conveys unique
information therefore avoiding redundancy.
• The permutations of factor levels comprising a single treatment
are so chosen that their responses are uncorrelated and
therefore each treatment gives a unique piece of information
Send fn OA
Orthogonal Array Testing -
• Orthogonal array testing is a black box testing technique which is a systematic, statistical
way of software testing. It is used when the number of inputs to the system is relatively
small, but too large to allow for exhaustive testing of every possible input to the systems.
• Orthogonal arrays were originally discovered as a numerical curiosity by monks. The
arrays went largely unnoticed, laying dormant in the aging notes of these monks, until the
1950s.
• Sometimes the ip domain is relatively limited. ie: no: of ip parameters is small and each
parameter are clearly bounded. OAT useful in finding region faults

• Runs: the number of rows in the array. This directly translates to the number of test cases
that will be generated by the OATS technique.
• Factors: the number of columns in an array. This directly translates to the maximum
number of variables that can be handled by this array.
• Levels: the maximum number of values that can be taken on by any single factor. An
orthogonal array will contain values from 0 to Levels-1.
OAT
• An orthogonal array is an array of values in which
each column represents a factor.
• A factor is
– a variable in an experiment; in our case, a
specific class family in the software system
– Or states of that class family
• Each variable takes on a certain set of values called
levels (rows); in our case, specific classes or states
of those classes
• Each cell is an instance of the class, that is, a
specific object or a particular state
What are orthogonal
arrays
• Consider numbers 1 and 2 – how many pair
combinations are there?
• An orthogonal array is a 2-dimensional array of
numbers that has this property: Choose any two
columns of the array; all the pairwise combinations
of its values will occur in every pair of columns.
Example

Subscript is number of rows in the array. Superscript is number of columns. 2 says

each value is a 1 or a 2.
Orthogonal Array Testing

• Black-box technique that enables the design of a

reasonably small set of test cases that provide
maximum test coverage
• Focus is on categories of faulty logic likely to be
present in the software component (without
examining the code)
• Priorities for assessing tests using an orthogonal array
– Detect and isolate all single mode faults
– Detect all double mode faults
– Mutimode faults
Model-Based Testing

• Black-box testing technique using information contained in the

requirements model (eg: UML) as a basis for test case generation
• Steps for MBT:
– Analyze an existing behavior model for the software or create one. C 7
– Traverse behavioral model and specify inputs that force software to make
transition from state to state.
– Review behavioral model and note expected outputs as software makes
transition from state to state.
– Execute test cases.
– Compare actual and expected results (take corrective action as required).
• MBT helps to uncover errors in software behaviour, and as a
consequence, it is extremely useful when testing event-driven
applications.
Specialized Testing

• Graphical User Interface (GUI) – test cases can be developed from

behavioral model of user interface, use of automated testing tools is
strongly recommended because of large no: of Permutations of cases.
• Client/Sever Architectures – operational profiles derived from usage
scenarios are tested at three levels (client application “disconnected
mode”, client and server software without network, complete
application)
• Applications function tests Testing Approaches
• Server tests
• Database tests
• Transaction tests
• Network communications tests
Specialized Testing contd..
• Documentation and Help ; 2 types viz.
• Review and inspection to check for editorial errors
• Black-Box for live tests -uses the documentation in conjunction with the actual program.
– Graph-based testing to describe program use
– Equivalence partitioning and boundary value analysis to describe classes
of input and interactions
• Real-Time Systems 4 types
• Task testing – test each task independently
• Behavioral testing – Using system models created with automated
tools, it is possible to simulate the behavior of a real-time system
and examine its behavior as a consequence of external events.
• Inter task testing – testing for timing errors
(e.g. synchronization and communication
errors)
• System testing – sw and hw integrated, testing
full system, especially the handling of Boolean
events (interrupts), test cased based on state
model and control specification
Testing Patterns

• Provide software engineers with useful advice

as testing activities begin
• Provide a vocabulary for problem-solvers
• Can focus attention on forces behind a
problem (when and why a solution applies)
• Encourage iterative thinking (each solution
creates a new context in which problems can
be solved
Summary
• The primary objective for t-c design -derive a set of tests
that have the highest likelihood for uncovering errors in
software.
– white-box testing and black-box testing.
• “Testing never ends, it just gets transferred from you [the
software engineer] to your customer. Every time your
customer uses the program, a test is being conducted.”
• By applying test-case design, you can achieve more
complete testing and thereby uncover and correct the
highest number of errors before the “customer’s tests”
begin.
Ariane 5 ESA ‘96

The failure occurred because the horizontal velocity exceeded the maximum value for a
16 bit unsigned integer when it was converted from it's signed 64 bit representation.
This failure generated an exception in the code which was not caught and thus
propagated up through the processor and ultimately caused the failure.
The failure was thus entirely due to a single line of code.
Errors- Casualities
• 85-87, 2 patients died by OD of radiation
delivered by Therac-25 accelerator- control sw
failure
• 91 Gulf War Scud penetrated Patriot
antimissile shield and struck at Dhahran, SA
-28 Americans killed. Israelis found the error.
• 2003 US treasury has generated cheques with
out the name of beneficiary
 "Phased Array Tracking Radar to Intercept
On Target"