Software Testing

Abdul Jaleel
Senior Testing Trainer
Talent Sprint
Content
Module 4 – Test Design Techniques
Introduction to Test Techniques

What is a testing technique?

A procedure for selecting or designing tests

A way of deriving good test cases

A way of objectively measuring a test effort

Testing should be rigorous, thorough and systematic

 Using techniques makes testing much more effective
Efficient testing: Effective testing: Different people:
find faults with find more faults similar probability
less effort • Focus attention on to find faults
• Avoid duplication specific types of fault • Gain some
• Systematic techniques • Know you're testing independence of
are measurable the right thing thought
Test Techniques – Advantages
 Test Coverage – Introduction
Test Coverage is the extent to which various tests are exercised in
the test suite. Generally, Test Coverage is measured in terms of:

Code Coverage
The extent to which the code has been exercised by the test suite
is known as Code Coverage.

Functional/Requirements Coverage
The extent to which the requirements or functionality have been
exercised by the test suite is known as Requirements Coverage or
Functional Coverage.
Test Coverage – Introduction

Test Suite Software

Code
Requirements
Using Structural Coverage
Spec Enough
Software tests?
Tests
Results OK?
What's
covered?
More tests Coverage OK?

Stronger structural
techniques (different
structural elements)

Increasing coverage
Measurement
Measurement
• Objective assessment of thoroughness of testing
with respect to use of each technique.
• Useful for comparison of one test effort to another

60% Equivalence Partitions

Project A 50% Boundaries
75% Branches

40% Equivalence Partitions

Project B 45% Boundaries
60% Branches
Test Design Techniques
Testing Techniques

Scripted Testing Experience Based

Static Dynamic Error-Guessing

Testing Testing Technique

People-Based Black Box

Testing Testing Exploratory
Testing
Tool-Based White Box
Testing Testing
Scripted Testing
Scripted Based Testing
 The main philosophy of scripted testing

“Plan your work, work your plan”

 Scripted Based Testing – When

When the tests are detailed enough so that some

Repeatability
one other than the author to execute it in an
identical way.

Test creation does not depend on the

Objectivity extraordinary skill of the person creating the test
but is based on well understood test design
principles.

Traceability from requirements, design, and code

Auditability
to the test cases and back again.
Scripted Based Testing – Types

Static (non- Functional Structural

execution) (Black Box) (White Box)
•Examination •Based on •Based on
of behaviour /
documentati structure
on,
functionali
ty of of
source code
listings, etc.
Static Testing software software
Dynamic Testing
Black Box Testing Techniques
Black Box Testing – Definition

Black Box testing is a strategy in which testing is

based solely on the requirements and specifications.

Black Box testing does not requires knowledge of the

internal paths, structure, or implementation of SUT.
Black Box Testing – Process
Black Box Testing Process
1 The requirements or specification are analyzed

2 Valid and Invalid inputs are chosen

3 Expected outputs for those inputs are determined

4 Tests are constructed with the selected inputs

5 The tests are run

6 Actual outputs are compared with the expected outputs

7 A determination is made as to the proper functioning of the SUT

Black Box Testing – Types

Techniques defined in BS 7925–2 standards

Techniques Design Measurement
Equivalence Partitioning  
Boundary Value Analysis  
State transition testing  
Decision Table  
Cause-effect Graphing  
Syntax Testing  
Random Testing  
Equivalence Class Partition
We have to write a program for a module of a human
resources system that processes the employment
applications based on person’s age and corresponding
organization rule:
Age Applicable Organization Rule

0 - 16 Don’t hire

16 - 18 Can hire on a part-time basis only

18 - 55 Can hire as a full-time employee

55 - 99 Don’t hire

How will you test these requirements?

If not,
Test then which
it using valuesages:
all possible will you
0, 1,choose and
2, 3…, 98, why?
98, 99?
Equivalence Class Partition
If (applicantAge == 0) hireStatus="NO";
If (applicantAge == 1) hireStatus="NO";
If (applicantAge == 14) hireStatus="NO";
If (applicantAge == 15) hireStatus="NO";
If (applicantAge == 16) hireStatus="PART";
If (applicantAge == 17) hireStatus="PART"; How many
If (applicantAge == 18) hireStatus="FULL"; of you think
If (applicantAge == 19) hireStatus="FULL";
that the
...
If (applicantAge == 53) hireStatus="FULL";
code must
If (applicantAge == 54) hireStatus="FULL"; be written
If (applicantAge == 55) hireStatus="NO"; like this?
If (applicantAge == 56) hireStatus="NO";
...
If (applicantAge == 98) hireStatus="NO";
If (applicantAge == 99) hireStatus="NO";

Fortunately programmers do not write the code like this.

Equivalence Class Partition
Some may prefer writing it the following way:

If (applicantAge >= 0 && applicantAge <=16)

    hireStatus="NO";

If (applicantAge >= 16 && applicantAge <=18)

    hireStatus="PART";

If (applicantAge >= 18 && applicantAge <=55)

    hireStatus="FULL";

If (applicantAge >= 55 && applicantAge <=99)

    hireStatus="NO";

Whatever the way is, how will you test the

module?

If not,
Test then
it using which ages:
all possible values
0, 1, will
2, 3…,you choose
98, 98, 99? and why?
Equivalence Class Partition
Equivalence Class Partitioning

Is the process of methodically reducing the huge (infinite) set

of possible test cases into a much smaller, but still equally
effective set.
Group of Tests

Form an Equivalence Class, if you believe that:

If one test doesn’t
If one test catches
They all test the catch a bug, the
a bug, the others
same thing. others probably
probably will too.
won’t, either.
Equivalence Class Partition

Equivalence Class Partitioning

Test Case 1 TEST

Test Case 2 CASE
Test Case 3 Test Case 4

Is the Answer
Equivalence Class Partition
Pick up random values from
Divide (partition) the inputs
each partition and test the
and outputs
system

Assumption: If one value One from each partition better

works, all will work... than all from one...

System Inputs and Outputs

Deciding Valid and Invalid Test Data Ranges for Each Partition

Invalid Valid Invalid

0 1 99 100
ECP – Approach

Design-by Contract

Testing-by Contract

Defensive Testing
 Design by Contract
What is Design-by Contract ?
A promise made to the customer about how we are going to design the
software
Invalid
Valid
Input Input !
Input Output
Invalid
Valid Output
Output
Module

Pre- Post-Conditions
Conditions

Design-by Contract is a software design approach, wherein

post-conditions, corresponding pre-conditions and variants
are specified along with the formal, precise and verifiable
interface for a module.
Testing by Contract

Valid Input Valid Output

Module

Gives

Test only pre-conditions. If they are satisfied,

then output remains valid…
This means, test the module with just valid data.
Defensive Testing
Test pre-conditions only. If they are satisfied, then
output remains valid.

Is this statement remains true in all conditions?

What if pre-conditions are violated during

production?
Defensive Testing
Is an approach wherein:

Module should accept any kind of input.

If normal pre-conditions meet, normal

post conditions too will meet.

If pre-conditions haven’t met then system

should through an exception.

So, you should be testing if system is

throwing exceptions or not.
 Defensive Testing

Design-by Contract

and Don’t create test cases for invalid inputs.

Testing-by Contract

Defensive Testing Create test cases for invalid inputs too.

Equivalence Class Partition
Applicability
Most suited to systems in which much of the input data takes
on values within ranges or within sets

Advantages
It enables a tester to select a subset of test inputs with a high
probability of detecting a defect
Disadvantages
It makes the assumption that the data in the same equivalence
class is processed in the same way by the system
ECP – Example 1
The Electricity bill computed by the service provider has a fixed
component as well as a running component. All customers are charged
at a rate of $40 flat as a fixed component. In addition to this, they would
be changed a running component . The rules for this are given below:
If the number of units consumed by the consumer is less than 10 units,
then the running cost is not charged for the consumer.
If the number of units is between 11 and 20, then the running cost is
charged at $1 per unit.
If the number of units is between 21 and 40, then the running cost is
charged at $2 per unit.
If the number of units exceeds 40, then the running cost is charged at $5
per unit.
Use Equivalence class partitioning to decide on the test cases to be
designed
ECP – Example 2
A user in a Small Savings investment bank may have fixed savings of
Rs 10,000 invested over a period of 45 days to 5 years. The interest
rate computed on the fixed savings is based on the duration of the
investment. The rules for this are given below:
If the duration of the investment is for 45 days, then the interest rate is
8% pa.
If the duration of investment is greater than 45 days but less than
1year, then the interest rate is 8.5% pa.
If the duration of investment is between 1 and 3 years, then the
interest rate is 9.5% pa.
If the duration is greater than 3 years, then the interest rate is 10.5%
pa.
Use Equivalence class partitioning to decide on the test cases to be
designed.
Boundary Value Analysis
 BVA (Boundary Value Analysis)

A Technique Complimentary to

ECP
Boundary Value Analysis (BVA)
Boundary Value Analysis
BVA is the act of dividing the given input set by a relation into
groups or classes which is treated the same by the module or
which should produce the same result.
Boundary Value Analysis (BVA)

Faults tend to lurk near Boundaries are good place Test values on both sides
boundaries to find faults of boundaries

Extend the range a bit to test more extensively

Invalid Valid Invalid

-1 0 1 2 98 99 100 101
 Boundary Value Analysis (BVA)
Look at the highlighted parts in the code:

If (applicantAge >= 0 && applicantAge <=16)

    hireStatus="NO";

If (applicantAge >= 16 && applicantAge <=18)

    hireStatus="PART";

If (applicantAge >= 18 && applicantAge <=55)

What if person applied for a job is of 16 years Age?
    hireStatus="FULL";

If (applicantAge >= 55 && applicantAge <=99)

    hireStatus="NO";

In the first instance, if condition is true, as per rule 1 system will show “Don’t
Hire”.
In the second instance, if condition is true, as per rule 2 system will show “Can
hire on a part-time basis only”.
Boundary Value Analysis (BVA)
Applicability
Typically be suited to systems in which much of the input data
takes on ranges of values or within sets

Advantages
Boundaries & conditions are the two major sources of defect
in software products. This technique aims to identify defects
in these areas.

Disadvantages
Does not work well for Boolean and logical variables.
BVA – Example 1

2-64 characters
Only 6 digits and 1st digit should be
non-zero
$500 to $ 9000

1 to 30 years

Minimum $10

Let’s see an approach to

test each field
BVA – Solution 1
Invalid Valid Invalid

1 2 64 65
A to Z
a to z
‘-’ and ‘_’
Valid Characters Within Boundary

Invalid
Conditions Valid Partitions Invalid Partitions Valid Bound Bound
2 – 64
Characters < 2 Characters 2 Char 1 Character
Customer
Name > 64 Characters 65 Character
Valid
Characters Invalid 64 Char
0 Character
Characters
BVA – Solution 1
Invalid Valid Invalid

5 6 7

Non-zero : Valid
First Character
Zero : Invalid

Conditions Valid Partitions Invalid Partitions Valid Invalid

Boundaries Boundaries
6 Digits < 6 Digits 100000 5 Digits
> 6 Digits 6 Digits
Account
Number 1st Digit: Non- Invalid
zero Characters 999999
0 Digits
Non-digit
BVA – Solution 1
Invalid Valid Invalid

499 500 9000 9001

**Assuming that cents are rounded-off.

Invalid
Conditions Valid Partitions Invalid Partitions Valid Bound Bound
500 – 9000 < $500 500 499
> $9000
Account
Number Valid 0
9000 9001
Characters Non-Numeric
NULL
BVA – Solution 1
Invalid Valid Invalid

364 days 1 year 30 Years 31 Years

Invalid
Conditions Valid Partitions Invalid Partitions Valid Bound Bound
1 Year – 30 Years < 1 Year 1 Year, 2 Years 364 Days
> 31 Years
Term of Loan Valid 29 Years,
Characters Non-Numeric 30 Years 31 Years
NULL
BVA – Solution 1
Invalid Valid

$9 $10

Conditions Valid Invalid Valid Invalid

Partitions Partitions Bound Bound
Monthly $10 < 10 $ 10, $11 $9
Repayment
BVA – Solution 1
Valid Invalid Valid Invalid
Condition Tag Tag Tag Tag
Partitions Partitions Boundaries Boundaries
Customer 2-64 chars V1 <2 chars X1 2 chars B1 1 char D1
name Valid chars V2 >64 chars X2 64 chars B2 65 chars D2
invalid char X3 0 chars D3
Account 6 digits V3 <6 digits X4 100000 B3 5 digits D4
number 1 non-zero
st
>6 digits X5 999999 B4 7 digits D5
1st digit = 0 X6 0 digits D6
or non- X7
digit
Loan 500-9000 V4 <500 X8 500 B5 499 D7
amount >9000 X9 9000 B6 9001 D8
0 X10
Non-integer X11
null X12
Decision Table Testing
Decision Table – Introduction
Decision Table
‘Decision Tables’ are used to describe and analyze problems
that contain procedural decision situations that are
characterized by one or more conditions
Decision Table

Condition Entry
Rule – 1 Rule – 2 ------ Rule – p
Conditions
Condition Stub

Condition – 1
Condition – 2
------
Condition – m
Actions
Action – 1
Action
Stub

Action – 2
------
Action – n
Action Entry
Decision Table
Applicability
Can be used whenever the system must implement complex
business rules.

Advantages
Enables us to look at and consider “dependence,”
“impossible,” and “not relevant” situations and eliminate some
test cases.

Disadvantages
When the number of conditions is large then the decision
table becomes very huge and cumbersome.
Decision Table – Example 1
The following instructions were taken from a
University Examination Application Form. Examine
them and create a Decision Table to represent the
University Rules and thereby decide on the test cases to
be designed.
 A candidate appearing for the exam should have a minimum 80%
attendance,
 Has attended 3 internal tests with an average of 10 or more marks or
 Has attended 2 internal tests with an average of 15 or more marks and
 Has taken up the external examination and scored more than 35
marks
 If the above conditions are fulfilled, then the student can be
considered as pass in that subject
 Decision Table – Solution
Condition Entry
R R R R R R R R R9 R1 R11 R1 R13 R1 R15 R1
1 2 3 4 5 6 7 8 0 2 4 6
Condition Stub

Conditions

C1 T T T T T T T T F F F F F F F F
C2 T F T F T F T F T F T F T F T F
C3 T T F F T T F F T T F F T T F F
C4 T T T F F F F T T T T F F F F T
Actions
A1 T T T
Action
Stub

A2 F F F F F F F F F F F F F

Action Entry
 Decision Table – Example 2
Suppose, You are to testing an insurance system to be used for
making decisions about whether policy can be granted to a
customer or not and accordingly, what discount should be
given to the customer?
Inputs
Conditions Rule 1
TC1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 6 Rule 8

Married? N N N N Y Y Y Y

Drinks? N N Y Y N N Y Y

Good Student? N
Each Rule
Y
becomes
N
a TestY Case. N Y N Y

Expected
Actions Results Rule 1
TC1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 … Rule P

Grant Policy Y Y Y Y Y Y Y Y

Discount 10 15 - 10 25 40 15 25
Decision Table – Example 3
Based on the specifications given below, construct a decision table and
choose appropriate action for each business rule. Also, develop the test
cases to cover all possible combinations:

Specifications:
A credit card processing system validates the cards based on the following rules:
• It will check for the following:
• Does the person hold the entered credit card, and is the other information
correct? (Is it a real account?)
• Is the credit card still active or has it been cancelled? (Active Account?)

The combinations of these conditions determine the possible actions from the
following:
• Should we approve the transaction?
• Should we call the card holder (e.g., to warn them about a purchase from a
strange place)?
• Should we call the vendor (e.g., to ask them to seize the cancelled card)?
State Transition Testing
State Transition Table – Introduction
State Transition Table
State-Transition diagrams are an excellent tool to capture
certain types of system requirements and to document
internal system design.
State Transition Table – Introduction
Is a condition in which a system is waiting for one
State or more events. It is generally represented by
Circles.
Represents a change from one state to another
Transition caused by an event. In the diagrams, Transitions
are represented by arrows.
Is something that causes the system to change
Event state. In the diagrams, Events are represented by
labels on a transition.
Is an operation initiated because of a state change. Actions
Action occur on transitions between the states and are represented
by the commands following the "/".
State Transition Table – Example 1
Consider a leave application system in an organization. An
employee can raise a request for a leave, and if he is eligible
for a leave (based on the number of days he has already
taken etc), the application is sent to the Manager for
approval. The manager then validates and approves or
rejects the leave based on the duration, reason for taking
leave.
Use State Transition diagram to represent the scenario and
derive the number of test cases for the same.
State Transition Table – Solution
State Transition Table – Example 2
Based on the following requirements, create a State Transition
Diagram and then derive the test cases:
• Provide information including departure and destination cities, dates
and times.
• A reservation agent uses this information to make a reservation.
• At this point, the Reservation is in Made state.
• The system creates and starts a timer.
• If the timer expires before the reservation is paid for, the reservation is
cancelled by the system.
• When money is paid, through initiation of the PayMoney action, the
system goes into “Paid” state.
– Events may have parameters associated with them. For example, Pay
Money may indicate Cash, Check, Debit Card or Credit Card.
State Transition Table – Example 2
• When the ticket is printed, the system goes into ‘Ticketed’ State
• Upon boarding the plane, the customer gives the boarding pass along
with the ticket, which signals that the ticket has been ‘Used’.
– Anything else after this state?
• If the Reservation is not paid on time, the PayTimer expires and the
reservation is cancelled for non-payment.
• A reservation may become cancelled, if the customer wishes to do so.
– This can happen prior to the payment or after the payment.
– If after the payment, a refund needs to be generated.
– The customer has to return printed ticket to the agent for refunding
it.
State Transition Table – Solution
Prin
t /Tic
ey
Pay Mon ket

Paid

Cancel/r
er im

Made Cancel
Ticketed
ay t

efund
art p

Give Ticket
Pay Timer
t

Expires
fo/s

urn
et und
In

R
l[ ref
Give

Cancelled BY e
Cancelled
Cust anc et]/
Non Pay C ck
Ti

Used
 State Transition Table – Solution
Create a set of test cases such that all states are "visited" at
least once under test. P rint
Pay Money Tic /
ket
1

Cancel/r
2 Made Paid
3 Cance
Ticketed
l
er art

Give Ticket
Pay Timer

efund
t

Expires
fo/s

u rn
t nd
e In

e
tim

Cancelled
Cancelled BY
el[R refu
Giv

Cust nc et]/
pay

Non Pay a
C ck
Ti
Used

A weak level of test coverage.

 State Transition Table – Solution
Create a set of test cases such that all states are "visited" at least
once under test.
Prin
Pay Money t/T
1 ic ket
2

Cancel/r
3 Made Paid
4 Cancel
5 Ticketed

efund

Give Ticket
Pay Timer
er art

Expires
t
pay Info/s

urn
t nd
tim

Cancelled BY e
l[R refu
e

Cancelled e
Giv

Cust nc et]/
Non Pay a
C ck
Ti
Used

A strong coverage.
State Transition Table – Exercise 1
Consider a Purchase Order Management System. Each
purchase order which is raised by the sales team must be
initially approved by the manager of the employee and the
Head of Purchasing. Additionally, if the capital expenses are
more than $12,000, then it needs to be approved by the Head
of Finance.
Use State Transition diagram to represent the scenario and
derive the number of test cases for the same.
State Transition Table – Solution
 White Box Testing

White Box
Dynamic Testing – White Box Testing
White box testing is a Program based testing to estimate the
completeness and correcteness of internal logic of each program
structure. Also called as Structural or Glass Box or Clear Box or
Open Box Testing.

Note:
To implement White Box testing techniques, testers should have
detailed programming skills.
White Box Testing – Process
Step 1 The SUT’s implementation is analyzed

Step 2 Paths through the SUT are identified

Step 3 Perform path sensitization

Step 4 Expected results for the inputs are determined

Step 5 The tests are executed

Step 6 Actual outputs are compared with expected outputs

Step 7 Proper functioning of the SUT is determined

White Box Testing – Types
The Structure-Based or White Box Testing Techniques,
as described in BS 7925-2 standards, are :
Statement Testing
Branch / Decision Testing
Data Flow Testing
Branch Condition Testing
Branch Condition Combination Testing
Modified Condition Decision Testing
LCSAJ (Linear Code Sequence and Jump)
Note:
All these techniques can also be used as Measurement Techniques.
Statement testing & Coverage

In Component testing, statement coverage is the assessment

of the percentage of executable statements that have been
exercised by a test case suite.

The statement testing technique derives test cases to

execute specific statement, normally to increase statement
coverage
Statement testing & Coverage
A Statement is
An entity in a programming language, which is typically the
smallest indivisible unit of execution.

Statement  Coverage is
The percentage of executable statements that has been
exercised by a test suite

Number of Statements Exercised

Statement Coverage =
Total Number of Statements
Statement Testing – Objective
The objective of the statement testing is to show that
the executable statements within a program have been
executed at least once.

Example:
• Program has 100 statements
• Tests exercise 87 statements ?
• Then, the statement coverage = 87%

Typical ad hoc testing achieves 60 - 75%

Statement Testing – Example 1

 If all statements in a program have been executed

by a set of tests then 100% statement coverage has
been achieved.
 For the above example one Test is require to
achieve 100% statement coverage.
Statement Testing – Example 2

 If all statements in a program have been executed

by a set of tests then 100% statement coverage has
been achieved.
 One test would be required to execute all three
executable statements
Statement Testing – Example 3

 If all statements in a program have been executed

by a set of tests then 100% statement coverage has
been achieved.
 One test would be required to execute all three
executable statements
Statement Testing – Example 4
READ(a)
IF a > 6 THEN
B=a
ENDIF
PRINT b

 One test would be required to execute all three

executable statements
Statement Testing – Example 5

 Two test would be required to achieve 100%

statement coverage
Statement Testing – Example 6

 Three test would be required to achieve 100%

statement coverage
Statement Testing – Example 7

 Two test would be required to achieve 100%

statement coverage
Decision Testing & Coverage
A Decision is
A program point at which the control flow has two or more
alternative routes.

Decision  Coverage is
The percentage of the decision outcomes that have been
exercised by a test suite

Number of Executed Decision outcomes

Decision Coverage = Total Number of Decision
outcomes
Decision Testing & Coverage
The objective of decision coverage testing is to show all the
decisions within a component have been executed at least
once.

Example:
True
• Program has 120 Decision Outcomes
• Tests exercise 60 Decision Outcomes
• Then the Decision Coverage = 50% False

Typical ad hoc testing achieves 40%

Decision Testing – Example 1

 100% decision coverage for a component is

achieved by exercising all decision outcomes into
the component.
 This would require 2 tests to achieve 100% decision
coverage.
Decision Testing – Example 2

This would require 2 tests to achieve 100% decision

coverage.
i.e. SC = 2 & DC = 2
Decision Testing – Example 3

 This would require 3 tests to achieve 100% decision

coverage.
i.e. SC = 1 & DC = 3
Decision Testing – Example 4

 This would require 1 tests to achieve 100% decision

coverage.
i.e. SC = 2 & DC = 3
Decision Testing – Example 5

 This would require 3 tests to achieve 100% decision

coverage.
i.e. SC = 3 & DC = 3
Decision Testing – Example 6

 This would require 2 tests to achieve 100% decision

coverage.
i.e. SC = 2 & DC = 2
 Cyclomatic Complexity
Cyclomatic Complexity is the measure of number of paths through code.
It is measured using the following formula:
Cyclomatic Complexity C = Number of Decision Points (i.e.
the Decision Boxes in Flow diagram) + 1
Wait for card to be inserted Wait
IF card is a valid card THEN
display “Enter PIN number”
IF PIN is valid THEN Valid Display “Enter
select transaction Card? PIN”
ELSE (otherwise)
display “PIN invalid”
Reject Valid Select
ELSE (otherwise) PIN? Transaction
Card
reject card
End
Display
PIN END
Number of decision boxes/points are = 2 Invalid
The Cyclomatic Complexity = 2 + 1 = 3
Path through the Code 1 2 3 4

1 2 1 2 1 2 3

? ? ? ?

?
Path through the Code

1 2 3 4 5 6 7 8 ….

For as many times as it

is possible to go round
the loop (this can be
?
unlimited, i.e. infinite)
 Statement & Decision Example 1
Read A
Read A
IF A > 0 THEN

IF A = 21 THEN
A>0 A=21 Print
Print “Key” ? ? “Key”
ENDIF

ENDIF
END

Cyclomatic Complexity: 3

Minimum Tests to Achieve:

Statement Coverage: 1

Branch Coverage: 3
 Statement & Decision Example 2
Read A
Read B Read A,
IF A > 0 THEN B
IF B = 0 THEN
Print “No values”
ELSE A>0 YES B=0 NO Print
Print B ? ? “B”
IF A > 21 THEN
Print A
ENDIF YES
YES
ENDIF NO A>21 Print
Print “No
ENDIF ? “A”
Values

NO
Cyclomatic Complexity: 4 END

Minimum Tests to Achieve:

Statement Coverage: 2

Branch Coverage: 4
 Statement & Decision Example 3
Read A
Read B Read A,
IF A < 0 THEN B
Print “A negative”
ELSE
Print “A positive” A<0 YES
ENDIF Print A -ve
?
IF B < 0 THEN
Print “B negative”
NO
ELSE
Print “B positive” Print A +ve
ENDIF

Cyclomatic Complexity: 3
YES
B<0 Print B -ve
?
Minimum Tests to Achieve:

Statement Coverage: 2
NO

Branch Coverage: 2 Print B +ve END

 Statement & Decision Example 4
Read A
Read B Read A,
IF A < 0 THEN B
Print “A negative”
ENDIF
IF B < 0 THEN A<0 YES
Print “B negative” Print A -ve
?
ENDIF
NO

YES
B<0 Print B -ve
?
Cyclomatic Complexity: 3
NO
Minimum Tests to Achieve:
END
Statement Coverage: 1

Branch Coverage: 2
 Statement & Decision Example 5
Read A,B
IF A < 0 THEN Read A,
Print “A negative” B
ENDIF
IF B > 0 THEN
Print “A positive” A<0 YES
ENDIF Print A -ve
?

NO

YES
B>0 Print A +ve
?
Cyclomatic Complexity: 3
NO
Minimum Tests to Achieve:
END
Statement Coverage: 1

Branch Coverage: 2
Use Case Testing
Use Case – Introduction
It the functionality of certain features of an application
which describes the interaction between the ‘Actor’,
‘Action’ and ‘Response’

Use Cases do not only describe the way that the product is
likely to be used, but also describe the way that the
processes flow through the system.

It is common for the Use Cases to form part of Acceptance

Tests, and may have involvement from the customer or
end user.
Use Case
ACTORS USE CASES Use Case
Is a scenario that describes
the use of a system, by an
Create actor, to accomplish a
Course specific goal.

Administrator

Enroll

Actor
Is a user playing a role in the
system, seeking to use the
Student Drop system to accomplish
something worthwhile.
Use Case – Template
Use Case Component Description
Use Case Number Or Identifier <A unique identifier for this use case >

Use Case Name <The name should be the goal stated as a short
active verb phrase >
Primary Actor <Role name or description of the primary actor >

Preconditions <The required state of the system before the use case
is triggered >
Success End Conditions <The state of the system upon successful completion
of this use case >
Failed End Condition <The state of the system if the use case cannot
execute to completion >
Trigger <The action that initiates the execution of the use
case>
Main Success Scenario
Steps Actions Response

Alternate Scenario
Steps Actions Response
Use Case – Example 1
Use Case Component Description

Use Case Number Or Identifier LMS_Student001

Use Case Name Register for a course (A class taught by a

faculty member)

Primary Actor Student

Preconditions None

Success End Conditions The student is registered for the course—The

course has been added to the student’s course
list
Failed End Condition The student’s course list is unchanged

Trigger Student selects a course and “Registers”

Use Case – Example 1
Step Action System Response
1 Selects “Register for a
course” Displays course
Selects course (ex. description
Core Java)
2 Selects section (Mon & Displays section days
Wed 9:00AM) and times
3 Accepts Adds course/section to
student's course list

Basic Flow
Use Case – Example 1
Step Action System response
2a Course does not Display message
exist and exit
4a Section does not Display message
exist and exit
4b Section is full Display message
and exit
6a Student does not Display message
accept and exit

Alternate Flow
 Use Case – Testable Flows

Alternate Flow 1 • No branches

xception Flow 1 • No loops Basic Flow
• No conditions
Alternate Flow 2
Alternate Flow 3

Exception Flow 2
Use Case
• Self Contained Alternate and
xception Flow 3
• Consistent format Exception Flows
Alternate Flow 4
Use Case – Testable Flows

Scenario 1

Scenario 3 Scenario 2 Scenario 1

= Basic Flow + = Basic Flow += Basic Flow
Alternate Flows + Alternate
Exception Flows flows
Experience-Based Testing
Experience-Based Testing
Experienced-based testing performed on the basis of testers
intuition and their experience with similar applications and
technologies.

These techniques can be useful in identifying special tests that are

not captured easily by formal techniques.

Experienced-based testing techniques are applied to augment or

complement systematic techniques.

Types of Experience-Based Testing

Techniques

Error Guessing
Exploratory Testing Technique
Technique
 Error Guessing

• Error guessing is a commonly used experienced-based

technique where testers, generally anticipate the defects based
on experience.
• A structured approach to the error guessing technique is to
enumerate a list of possible errors and to design the tests that
attack these defects.
• This Approach is called as Fault Attack.
 Exploratory Testing Technique

• It is concurrent test design, test execution, test logging and

learning based on a test charter containing test objectives.
• Exploratory Testing is carried out within time-boxes.
• This technique is most useful when there are very few or
inadequate specifications and severe time pressure.
 Thank u 