SOFTWARE QUALITY ASSURANCE &

TESTING
 LECTURE # 10

SOFTWARE TEST DESIGN TECHNIQUES

Decision Tables

This is a systematic approach where

The decision table is a
the different input combinations
software testing technique which is
and their corresponding system
used for testing the system behavior
behavior are captured in a tabular
for different input combinations.
form.

Also known as the cause-effect table

because of an associated logical
This table helps you deal with
diagramming technique called
different combination inputs with
cause-effect graphing that is
their associated outputs.
basically used to derive the decision
table.
Decision Tables - Example
 Create a decision table for the
given login screen.
 The condition states that if the
user provides the correct
username and password the
user will be redirected to the
homepage.
 If any of the input is wrong,
an error message will be
displayed.
Decision Tables - Example

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Username Invalid Invalid Valid Valid

Password Invalid Valid Invalid Valid

Output Error Error Error Success

Case 1 – Username and password both were wrong. The user is shown
an error message.
Case 2 – Username is wrong, password is correct. The user is shown an
error message.
and so on.
State Transition Testing
 Used where some aspect of the system can be described in
what is called a finite state machine.
 This simply means that the system can be in a (finite) number
of different states, and the transitions from one state to
another are determined by the rules of the 'machine'.
 This is the model on which the system and the tests are based.
Any system where you get a different output for the same
input, depending on what has happened before, is a finite state
system.
 A finite state system is often shown as a state diagram.
State Transition Testing
State Transition Testing - Example
 If you request to withdraw $100 from a bank ATM, you may
be given cash.
 Later you may make exactly the same request but be refused
the money (because your balance is insufficient).
 This later refusal is because the state of your bank account has
changed from having sufficient funds to cover the withdrawal
to having insufficient funds. The transaction that caused your
account to change its state was probably the earlier
withdrawal.
 A state diagram can represent a model from the point of view
of the system, the account or the customer.
Exploratory Testing

Exploratory testing is a
simultaneous learning, test
design, and test execution
process.
In this testing, test planning,
analysis, design and test
execution, are all done together
and instantly.
This testing is about exploring
the system and encouraging
real-time and practical thinking
of a tester.
Exploratory versus Scripted
Testing
 Think of scripted testing as
taking a train. It's on rails. It
will never deviate from that
path.
 Exploratory testing is more
like driving a car. Your
general goal is to get from
point A to B, but you can take
any path and deviation that
catches your eye along the
way.
Exploratory Testing - Example
Test the “Edit Bookmark” functional area in a product.
 There are two possible scenarios for your assignment:
1. Execute a test run
2. Perform exploratory testing of the “Edit Bookmark”
functional area.
 In the first scenario, you would follow the steps outlined in the test
case to verify that each step works, reporting any bugs that are
found. But what if a critical bug — such as a crash, or data loss —
doesn’t occur during these steps?
 You won’t find it.
Exploratory Testing - Example
 In the second scenario, you explore or “test around”
editing bookmarks. At first, you might perform the same steps
as at the beginning of the test case. As testing progresses,
however, you might ask, “What happens when I click Edit,
delete the name, and try to save the bookmark with a blank
field?” Boom! The application crashes and deletes all of the
user data. You just found the most important bug by exploring
something that wasn’t a step in the test case.
Exploratory Testing v/s Ad-hoc
Testing
Exploratory Testing Ad-hoc Testing

 Exploratory testing is a  Ad-hoc testing refers to a

thoughtful methodology to process of unscripted,
Ad-hoc testing. unplanned and impromptu
 Not a hit and trial defect searching.
method of finding a bug.  Hit and trial method of
 ET is somewhat a structured finding a bug.
activity.  Ad-hoc testing is an
unstructured activity.
Statement Testing
 Statement
An entity in a programming language, which is typically the
smallest indivisible unit of execution. Synonyms: source
statement
 Statement testing
A white-box test technique in which test cases are designed to
execute statements.
This technique involves execution of all statements of the source
code at least once.
It is used to calculate the total number of executed statements in
the source code out of total statements present in the source
code.
Statement Testing and Coverage
 Coverage
It measures in some specific way the amount of
testing performed by a set of tests.
 Statement Coverage
Statement coverage derives scenario of test cases under the
white box testing process which is based upon the structure of
the code.
Statement Testing - Example

Scenario # 1: If a = 5, b = 4

To calculate statement coverage of the

first scenario, take the total number of
statements that is 6 and the number of
used statements that is 4.

Statement coverage = 4/6*100

= 400/6
= 66.66%

Total number of statements = 6

Decision Testing
 Decision
A type of statement in which a choice between two or more
possible outcomes controls which set of actions will result.
 Decision Testing
A white-box test technique in which test cases are designed to
execute decision outcomes.
A decision is an IF statement, a loop control statement (e.g. DO-
WHILE or REPEAT-UNTIL), or a CASE statement, where there
are two or more possible exits or outcomes from the statement.
Decision Testing and Coverage

Decision coverage covers all possible outcomes of each and

every boolean condition of the code by using control flow
graph or chart.
 Decision Testing - Example

Scenario # 1: If a = 7

To calculate decision coverage of the first

scenario, take the total number of
decisions that is 2 and the number of used
decision that is 1.

Decision coverage = 1/2*100

= 0.5*100
= 50%

Total number of
decisions = 2
Decision Testing and Coverage
 One more scenario is required to get 100% decision coverage.
 It is important to note that 100% decision coverage
implies 100% statement coverage. (but not vice versa)
Decision v/s Coverage
 To achieve 100% statement coverage of this
code segment just one test case is required, one
which ensures that variable A contains a value
that is greater than the value of variable B, for Read A ​
Read B ​
example, A = 12 and B = 10 If A > B ​
 However, decision coverage requires each Then C = 0 ​
End If
decision to have had both a True and False
outcome. Therefore, to achieve 100% decision
coverage, a second test case is necessary where
A is less than or equal to B. This will ensure
that the decision statement 'IF A > B' has a
False outcome.
Check your knowledge
 One of the most important test goals
for your project is to have 100%
decision coverage. Therefore, we
have to execute the following three
tests for the control flow graph
shown.
 Test01 covers path: A, B, D, E, G
 Test02 covers path: A, B, D, E, F, G
 Test03 covers path: A, C, F, C, F, C, F,
G
Check your knowledge
 Which of the following
statements relating to the decision
coverage goal is TRUE?
 Decision D has not been tested
completely.
 100% decision coverage has been
achieved.
 Decision E has not been tested
completely.
 Decision F has not been tested
completely.
Check your knowledge
 Why are both specification-based and structure-based testing
techniques useful?
 They find different types of defects.
 Using more techniques is always better.
 Both find the same types of defects.
 Because specifications tend to be unstructured.
Check your knowledge
 Why are both specification-based and structure-based testing
techniques useful?
 They find different types of defects.
 Using more techniques is always better.
 Both find the same types of defects.
 Because specifications tend to be unstructured.
Check your knowledge
 What is a key characteristic of structure-based testing
techniques?
 They are mainly used to assess the structure of a specification.
 They are used both to measure coverage and to design tests to
increase coverage.
 They are based on the skills and experience of the tester.
 They use a formal or informal model of the software or
component.