Module-4

Perspective on Testing: Basic Definitions,

Test Cases, Insights from a Venn Diagram,
Identifying Test Cases, Levels of Testing.
Examples: Generalized Pseudocode, The
Triangle Problem, The Next Date Function,
The Commission Problem.
Textbook 2: Ch. 1, Ch. 2
 A Perspective on Testing
Basic Definitions
• Error—People make errors. A good synonym is mistake. When people make mistakes
while coding, we call these mistakes bugs. Errors tend to propagate; a requirements error
may be magnified during design and amplified still more during coding.
• Fault—A fault is the result of an error. It is more precise to say that a fault is the
representation of an error, where representation is the mode of expression, such as
narrative text, Unified Modeling Language diagrams, hierarchy charts, and source code.
Defect is a good synonym for fault, as is bug.
• Faults can be elusive. An error of omission results in a fault in which something is missing
that should be present in the representation. This suggests a useful refinement; we might
speak of faults of commission and faults of omission. A fault of commission occurs when
we enter something into a representation that is incorrect. Faults of omission occur when
we fail to enter correct information. Of these two types, faults of omission are more
difficult to detect and resolve.
• Failure—A failure occurs when the code corresponding to a fault executes. Two subtleties
arise here: one is that failures only occur in an executable representation, which is usually
taken to be source code, or more precisely, loaded object code; the second subtlety is
that this definition relates failures only to faults of commission
• Incident—When a failure occurs, it may or may not be readily apparent to
the user (or customer or tester). An incident is the symptom associated
with a failure that alerts the user to the occurrence of a failure.
• Test—Testing is obviously concerned with errors, faults, failures, and
incidents. A test is the act of exercising software with test cases. A test has
two distinct goals: to find failures or to demonstrate correct execution.
• Test case—A test case has an identity and is associated with a program
behavior. It also has a set of inputs and expected outputs

A testing life cycle.

 Test case
• Test case execution entails establishing the necessary preconditions, providing
the test case inputs, observing the outputs, comparing these with the expected
outputs, and then ensuring that the expected postconditions exist to
determine whether the test passed.
• From all of this, it becomes clear that test cases are valuable—at least as
valuable as source code. Test cases need to be developed, reviewed, used,
managed, and saved
 Test Case
TEST CASE
it is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly.
The process of developing test cases can also help find problems in the
requirements or design of an application.
Test Case Template
A test case can have the following elements. Note, however, that a test
management tool is normally used by companies and the format is determined by
the tool used.
Contd..
Contd..
 Insights from a Venn diagram

Insights from a Venn Diagram

Testing is fundamentally concerned with behavior, and behavior is orthogonal to the
code- based view common to software (and system) developers
A quick distinction is that: ‒ The code-based view focuses on what it is ‒ The
behavioral view considers what it does.
Contd..
Contd..
 Identifying Test Cases
• Two fundamental approaches are used to identify test cases; traditionally,
these have been called functional and structural testing.
• Specification-based and code-based are more descriptive names, and they will
be used here.
• Both approaches have several distinct test case identification methods; they
are generally just called testing methods.
• They are methodical in the sense that two testers following the same
“method” will devise very similar (equivalent?) test cases.
 What is Structural Testing ?

Structural testing, also known as glass box testing or white box testing is an approach
where the tests are derived from the knowledge of the software's structure or internal
implementation.
The other names of structural testing includes clear box testing, open box testing, logic
driven testing or path driven testing.
Structural Testing Techniques:
Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests.
Branch Coverage - This technique is running a series of tests to ensure that all
branches are tested at least once.
Path Coverage - This technique corresponds to testing all possible paths which
means that each statement and branch are covered.
 Contd..
Advantages of Structural Testing:
• Forces test developer to reason carefully about implementation
• Reveals errors in "hidden" code
• Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of Structural Box Testing:
• Expensive as one has to spend both time and money to perform white box
testing.
• Every possibility that few lines of code is missed accidentally.
• In-depth knowledge about the programming language is necessary to perform
white box testing.
 What is Functional Testing?
• Functional testing is a quality assurance (QA) process[1] and a type of black-box testing
that bases its test cases on the specifications of the software component under test.
• Functions are tested by feeding them input and examining the output, and internal
program structure is rarely considered (unlike white-box testing).
• Functional Testing is a testing technique that is used to test the features/functionality of
the system or Software, should cover all the scenarios including failure paths and
boundary cases.
• It is basically defined as a type of testing which verifies that each function of the
software application works in conformance with the requirement and specification.
• This testing is not concerned about the source code of the application.
• Each functionality of the software application is tested by providing appropriate test
input, expecting the output and comparing the actual output with the expected output.
• This testing focuses on checking of user interface, APIs, database, security, client or
server application and functionality of the Application Under Test.
 The other major Functional Testing techniques
include:
• Unit Testing
• Integration Testing
• Smoke Testing
• User Acceptance Testing
• Localization Testing
• Interface Testing
• Usability Testing
• System Testing
• Regression Testing
• Globalization Testing
 Test-generation Strategies
• Test-generation any form of test generation uses a source document.
• In the most informal of test methods, the source document resides in the mind
of the tester who generates tests based on a knowledge of the requirements.
• In several commercial environments, the process is a bit more formal.
• The tests are generated using a mix of formal and informal methods either
directly from the requirements document serving as the source.
• In more advanced test processes, requirements serve as a source for the
development of formal models
 Contd..
Model based: require that a subset of the requirements be modeled using a formal
notation (usually graphical).
Models: Finite State Machines, Timed automata, Petri net, etc. Specification based:
require that a subset of the requirements be modeled using a formal mathematical
notation.
Code based: generate tests directly from the code
Comparing specification-based test case identification methods
Comparing code-based test case identification methods
Error and fault taxonomies
Error and Fault Taxonomies Process versus Product process refers to
how we do something, and product is the end result of a process SQA is
more concerned with reducing errors endemic in the development
process, while testing is more concerned with discovering faults in a
product. Faults can be classified in several ways:
• the development phase where the corresponding error occurred,
• the consequences of corresponding failures,
• difficulty to resolve,
• risk of no resolution, and so on
contd….
Contd..
Contd..
Contd..
Contd..
Levels of Testing

Levels of abstraction and testing in waterfall model.

Generalized pseudocode,
• Pseudocode is an informal high-level description of the operating principle of a
computer program or other algorithm.
• It uses the structural conventions of a normal programming language, but is
intended for human reading rather than machine reading.
• Pseudocode typically omits details that are essential for machine understanding
of the algorithm, such as variable declarations, system-specific code and some
subroutines.
• The programming language is augmented with natural language description
details, where convenient, or with compact mathematical notation.
• The purpose of using pseudocode is that it is easier for people to understand than
conventional programming language code, and that it is an efficient and
environment-independent description of the key principles of an algorithm.
• Pseudocode provides a “language neutral” way to express program source code.
• Pseudocode given here is based on visual basic.
The triangle problem
The triangle problem is the most widely used example in software
testing literature.
Problem Statement
• Simple version: The triangle program accepts three integers, a, b, and
c, as input. These are taken to be sides of a triangle. The output of the
program is the type of triangle determined by the three sides:
Equilateral, Isosceles, Scalene, or Not A Triangle.
• Sometimes, this problem is extended to include right triangles as a
fifth type.
Contd..
• Improved version: The triangle program accepts three integers, a, b,
and c, as input. These are taken to be sides of a triangle. The integers
a, b, and c must satisfy the following conditions:
Contd..

• Isosceles, Scalene, or Not A Triangle. If an input value fails any of

conditions c1, c2, or c3, the program notes this with an output
message, for example, ―Value of b is not in the range of permitted
values.ǁ If values of a, b, and c satisfy conditions c4, c5, and c6, one of
four mutually exclusive outputs is given:
1. If all three sides are equal, the program output is Equilateral.
2. If exactly one pair of sides is equal, the program output is Isosceles.
3. If no pair of sides is equal, the program output is Scalene.
4. If any of conditions c4, c5, and c6 is not met, the program output is
Not A Triangle.
Discussion

• Perhaps one of the reasons for the longevity of this example is that it
contains clear but complex logic.
• It also typifies some of the incomplete definitions that impair
communication among customers, developers, and testers.
• The first specification presumes the developers know some details
about triangles, particularly the triangle inequality: the sum of any
pair of sides must be strictly greater than the third side.
Traditional Implementation

• The traditional implementation of this grandfather of all examples has

a rather FORTRAN- like style.
• The flowchart for this implementation appears in Figure 2.1. Figure
2.2 is a flowchart for the improved version. The flowchart box
numbers correspond to comment numbers in the (FORTRAN like)
pseudocode program given next.
Contd..
• The variable ―matchǁ is used to record equality among pairs of the
sides. A classic intricacy of the FORTRAN style is connected with the
variable ―ma tchǁ: notice that all three tests for the triangle
inequality do not occur.
• If two sides are equal, say a and c, it is only necessary to compare
a + c with b. (Because b must be greater than zero, a + b must be
greater than c because c equals a.) This observation clearly reduces the
number of comparisons that must be made.
• The efficiency of this version is obtained at the expense of clarity
(and ease of testing).
a b c Expected Output

3 3 3 Equilateral

3 3 2 Isosceles

3 4 5 Scalene

1 2 3 Not a Triangle

0 2 2 Not a Triangle

-1 2 3 Invalid input
Condition Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6
All sides > 0 Y Y Y Y Y N
Triangle
inequality is Y Y Y N Y —
satisfied
a=b=c Y N N — N —
Exactly two
sides equal
— Y N — N —
(a=b, b=c, or
a=c)
All sides
— — Y — Y —
different
Action
Not a
(Triangle Equilateral Isosceles Scalene Scalene Invalid Input
Triangle
Type)
Contd..
Contd..
Contd..
EndIf
‗
End Triangle1
Structured Implementations
• The pseudocode for [Improved Version]
Contd..
The Next Date Function
• the complexity in the triangle program is due to the relationships
between inputs and correct outputs.
• We will use the Next Date function to illustrate a different kind of
complexity—logical relationships among the input variables.
Contd..
• As we did with the triangle program, we can make our problem statement
more specific.
• This entails defining responses for invalid values of the input values for the
day, month, and year.
• We can also define responses for invalid combinations of inputs, such as
June 31 of any year.
• If any of conditions c1, c2, or c3 fails, NextDate produces an output
indicating the corresponding variable has an out-of-range value—for
example, ―Value of month not in the range 1...12.ǁ Because numerous
invalid day–month–year combinations exist, NextDate collapses these into
one message: ―Invalid Input Date.ǁ
• Two sources of complexity exist in the Next Date function: the complexity
of the input domain discussed previously, and the rule that determines
when a year is a leap year.
• A year is 365.2422 days long; therefore, leap years are used for the ―extra
dayǁ problem.
• If we declared a leap year every fourth year, a slight error would occur.
• The Gregorian calendar (after Pope Gregory) resolves this by adjusting leap
years on century years.
• Thus, a year is a leap year if it is divisible by 4, unless it is a century year.
Century years are leap years only if they are multiples of 400 (Inglis, 1961);
thus, 1992, 1996, and 2000 are leap years, while the year 1900 is not a leap
year.
• The Next Date function also illustrates a sidelight of software testing.
Scenario Input Date Expected Output

End of January 31-01-2025 01-02-2025

Non-leap year February end 28-02-2023 01-03-2023

Leap year February 29-02-2024 01-03-2024

End of April (30-day month) 30-04-2025 01-05-2025

End of year 31-12-2025 01-01-2026

Invalid day 32-01-2025 Error / Invalid

Invalid month 15-13-2025 Error / Invalid

Test Case Design
✅ 1. Equivalence Partitioning (EP)
We divide the input into valid and invalid partitions for day, month, and year:

Test Case Input Date Description Expected Output

TC1 15-05-2025 Valid mid-range date 16-05-2025

TC2 32-01-2025 Invalid day (too high) Error / Invalid

TC3 00-03-2025 Invalid day (too low) Error / Invalid

Invalid month (too

TC4 25-13-2025 Error / Invalid
high)

TC5 10-00-2025 Invalid month (too low) Error / Invalid

Valid Feb non-leap

TC6 28-02-2023 01-03-2023
year

TC7 29-02-2024 Valid Feb leap year 01-03-2024

 2. Boundary Value Analysis (BVA)
We test around the edge values of months and days:

Test Case Input Date Description Expected Output

TC8 30-04-2025 End of 30-day month 01-05-2025

TC9 31-01-2025 End of 31-day month 01-02-2025

TC10 31-12-2025 End of year 01-01-2026

TC11 01-01-2025 Beginning of year 02-01-2025

Day before leap day

TC12 28-02-2024 29-02-2024
(leap year)

TC13 29-02-2024 Leap day 01-03-2024

TC14 28-02-2023 Non-leap year Feb end 01-03-2023

Implementations
T he Commission Problem
• It contains a mix of computation and decision making, so it leads to
interesting testing questions.
• Our main use of this example will be in our discussion of data flow
and slice-based testing.
Problem Statement
• A rifle salesperson in the former Arizona Territory sold rifle locks,
stocks, and barrels made by a gunsmith in Missouri.
• Locks cost $45, stocks cost $30, and barrels cost $25. The salesperson
had to sell at least one lock, one stock, and one barrel (but not
necessarily one complete rifle) per month, and production limits were
such that the most the salesperson could sell in a month was 70 locks,
80 stocks, and 90 barrels.
• After each town visit, the salesperson sent a telegram to the Missouri
gunsmith with the number of locks, stocks, and barrels sold in that
town.
• At the end of a month, the salesperson sent a very short telegram
showing –1 lock sold.
• The gunsmith then knew the sales for the month were complete and
computed the salesperson‘s commission as follows: 10% on sales up
to (and including) $1000, 15% on the next $800, and 20% on any sales
in excess of $1800.
• A salesperson earns a commission based on the total number of units
sold in three different product categories: locks, stocks, and barrels.
• Each category has a price, and the total sales are calculated. The
commission is calculated based on total sales as follows:
• 💰 < $1000 → 10% commission
• 💰 $1000 to $1800 → 10% on first $1000 + 15% on remainder
• 💰 > $1800 → 10% on first $1000 + 15% on next $800 + 20% on the
rest
Discussion
• This example is somewhat contrived to make the arithmetic quickly visible
to the reader.
• It might be more realistic to consider some other additive function of
several variables, such as various calculations found in filling out a US 1040
income tax form.
• (We will stay with rifles.) This problem separates into three distinct pieces:
the input data portion, in which we could deal with input data validation (as
we did for the triangle and NextDate programs), the sales calculation, and
the commission calculation portion. This time, we will omit the input data
validation portion.
• We will replicate the telegram convention with a sentinel-controlled while
loop that is typical of MIS data gathering applications.
 Commissi
Valid Total Descriptio
TC# Locks Stocks Barrels on
Inputs? Sales n
Expected
$45+$30+ 10% of Minimum
TC1 1 1 1 ✅ $25 = $100 = valid
$100 $10 inputs
Locks
TC2 0 5 5 ❌ Invalid Error below
minimum
Locks
TC3 71 5 5 ❌ Invalid Error above
maximum
Edge of
10% of
1st
TC4 10 10 10 ✅ $1000 $1000 =
commissio
$100
n slab
contd…