Overview

1 Testing technique
2 Black Box Testing
Black box testing techniques
Random testing (RT)
Equivalence class testing(EC)
Boundary values testing (BV)
Decision tables (DT)
State-transition Testing
Use Case Based Testing

3 White Box
4 Experience Based
5 Choosing Design Techniques

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 1 / 76
 Testing technique

What Is A Testing Technique ?

Testing techniques are structured methods used to design test cases.

Help you to answer:
What should we test?
How should we test it?
How many test cases are enough?
Are we testing the right things?
Rather than randomly testing, techniques guide us to:
Increase coverage
Detect important defects earlier
Use our resources efficiently
There are different technique and each test tehnique tackles a
different situation

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 2 / 76
 Testing technique

Why A testing Technique?

Systematic, efficient, and effective.
Imagine you’re testing a signup form. You could test it by:
Guessing values (hit or miss)
Trying random inputs (unfocused)
Or applying a methodical approach - test boundaries,valid/invalid
data,etc.
Effective
Find more faults
Know you are testing the right thing
Improve test coverage:critical paths and edge cases are validated
Efficient
Find faults with less efforts
Avoid duplication
Systematic techniques are measurable
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 3 / 76
 Testing technique

Categories of Test Design Techniques

Black Box- also known as Behavioral, based on requirement and

functional specification
White Box- also known as Structural, based on code and logic
Experience- also known as Exploratory,based on testers skill and
intuition

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 4 / 76
 Black Box Testing

Black Box Testing

Advantages
Focus on the domain
No need for the code
early test design
Catches logic defects
Applicable at all granularity levels

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 5 / 76
 Black Box Testing

Black-box testing process

Analyze requirements
Choose valid and invalid inputs
Determine expected outputs for those inputs

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 6 / 76
 Black Box Testing Black box testing techniques

Black box testing techniques

Random Testing
Equivalence class testing (EC)
Boundary values testing (BV)
Decision tables
State-transition diagrams
Use case testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 7 / 76
 Black Box Testing Black box testing techniques

Random Testing

Advantage
Uncovers Unexpected Defects
Random Testing explores inputs that structured techniques might
overlook, such as unusual or extreme values.
Example (Req 1.A): Inputting Age = ”123456789” might reveal a
buffer overflow or crash not caught by EC or BV
Quick to Implement
Requires minimal planning—no need to partition inputs or boundaries.
Example: For the HR app’s ”Create Employee” form, a tester can
quickly enter random values like -10, ”xyz,” or 999 without designing
test cases.
Low Resource Overhead
Needs no deep requirement analysis or code knowledge
Example: A junior tester can perform random testing on the HR form
without studying requirements

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 8 / 76
 Black Box Testing Black box testing techniques

Random Testing

Limitation
No coverage guarantee.
Random selection may miss critical areas like boundaries or specific
requirement conditions.
Example (Req 1.A): Random inputs might include 25, 100, -5, but
skip 19 or 20, failing to verify the exact range edges.
Inefficient for Specific Requirements:
Doesn’t target precise validation rules, making it less effective for
verifying detailed specs.
Example: Req 1.A’s ”whole numbers only” needs targeted tests (e.g.,
20.5), which random testing might not hit.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 9 / 76
 Black Box Testing Black box testing techniques

Random Testing

Limitation
High Noise in Results:
Produces many irrelevant or redundant tests, requiring effort to
analyze.
Example: Inputs like Age = ”hello” are obvious failures, wasting time
if overused.
Limited Depth:
Doesn’t explore logical combinations or workflows, focusing only on
single inputs.
Example: Random testing won’t verify complex HR rules (e.g., Age
20–50 + Full-Time → Active), unlike Decision Table Testing.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 10 / 76
 Black Box Testing Black box testing techniques

Equivalence class testing(EC)

EC testing technique makes a partition of the input domain for each

variable or the output range
This partition is dictated by the requirements
The rule is to take for the test case one value from each equivalence
class
It divides the input data of software into different equivalence data
classes.
You can apply this technique, where there is a range in input field.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 11 / 76
 Black Box Testing Black box testing techniques

Challenging for the tester

Different testers find different equivalence classes

The difficulty is to find an appropriate partition not knowing how the
program looks inside.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 12 / 76
 Black Box Testing Black box testing techniques

What about invalid inputs?

Defensive testing – test also invalid inputs. For invalid equiv.

classes look at the boundaries
Testing by contract – only valid inputs
GUIs and strong typed programming languages weaken the need to
use defensive testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 13 / 76
 Black Box Testing Black box testing techniques

Example 1
One input variable
Age field can take the values in the range of 20 to 50

Random Testing value ?

20
30
40
Can we claim that the method is correct ?
How do you expect the code to implement these requirements
specification?
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 14 / 76
 Black Box Testing Black box testing techniques

Example 1

One input variable

Age field can take the values in the range of 20 to 50

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 15 / 76
 Black Box Testing Black box testing techniques

Example 1

One input variable

Age field can take the values in the range of 20 to 50

Partition value

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 16 / 76
 Black Box Testing Black box testing techniques

Example 1

For Req 1.A (age 20–50, whole numbers):

Valid Class:
Ages 20 to 50 (e.g., 35).
Invalid Classes:
Below 20 (e.g., 19).
Above 50 (e.g., 51).
Non-integers (e.g., 20.5).
Non-numeric (e.g., ”abc”).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 17 / 76
 Black Box Testing Black box testing techniques

Example 1

For Req 1.A (age 20–50, whole numbers):

Valid Class:
Ages 20 to 50 (e.g., 35).
Invalid Classes:
Below 20 (e.g., 19).
Above 50 (e.g., 51).
Non-integers (e.g., 20.5).
Non-numeric (e.g., ”abc”).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 18 / 76
 Black Box Testing Black box testing techniques

Example 1
Test case design
Identify variables: 1 input variable, age
input domain: [1..99]
Divide the input domain in equivalence
classes: 4 (there are valid classes)
Create one test case for each equivalence class (test by contract, only
valid inputs)

Test Cases:
Age = 35 (valid).
Age = 19 (invalid).
Age = 51 (invalid).
Age = 20.5 (invalid).
Age = ”abc” (invalid).
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 19 / 76
 Black Box Testing Black box testing techniques

Example 2: Password

What is the minimumm number of Test Cases ?

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 20 / 76
 Black Box Testing Black box testing techniques

Example 2: Password

Test Cases:
1 AB36P (1,4,6)

2 (2)
3 VERYLONG (3)
4 1XY12 (5)
5 A17#%X (7)

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 21 / 76
 Black Box Testing Black box testing techniques

Equivalence Partitioning

Valid values are values that should be accepted by the component or

systems
Invalid values are values that should be rejected by the component or
system
Each value must belong to one and only one equivalence partition
One value from each partition should selected

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 22 / 76
 Black Box Testing Black box testing techniques

Equivalence Partitioning

When invalid equivalence partitions are used in test cases, they should
be tested individually, i.e., not combined with other invalid
equivalence partitions, to ensure that failures are not masked. Failures
can be masked when several failures occur at the same time but only
one is visible, causing the other failures to undetected.
Partition can be identified for any data element related to the test
object, including inputs, outputs, internal values, time-related values
(e.g before or after an event ) and for interface parameters(e.g
integrated components being tested during integration testing)
Any partition may be divided into sub-partitions if required
Equivalent partitioning is applicable at all test levels of testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 23 / 76
 Black Box Testing Black box testing techniques

Equivalence Partitioning Coverage

To achieve 100% coverage with this techniques , test cases must

cover all identified paritions(including invalid partitions) by using a
minimum of one value from each partition
Coverage is measured as the number of equivalence partition tested
by at least one value, divided by the total number of identified
equivalence paritions, normally expressed as a percentage
What is the coverage of Password Test Cases if the selected test cases
by the tester is 1. AB36P (1,4,6), 2. VERYLONG (3) ?

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 24 / 76
 Black Box Testing Black box testing techniques

Equivalence Partitioning Discrete Values

Would the value of the country change the way the software behaves
?
If yes, then every value should be in a separate partition
If no, then all the values can reside in a single partition
Registration Example
Partition 1 Title (Mr,Miss,Mrs. etc)
Partition 2 Country (Egypt, Canada, US, India)
Shipping Example
Partition 1 Title (Mr,Miss,Mrs. etc)
Partition 2 (Egypt)
Partition 2 (Canada)
...
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 25 / 76
 Black Box Testing Black box testing techniques

Equivalence Partitioning Multiple Conditions

Age : (< 20), (20 >= and <= 50), (> 50)
Country : (Egypt), (Canada), (USA), (India)
3partitions + 4partitions = 7Partitions
Test cases:
TC1:(10,Egypt)
TC2: (40,Canda)
TC3:(60,USA)
TC4:(45,India)
In test automation:
Parametrize partitions into data-driven test cases
Integrate with Postman or REST-assured for API testing
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 26 / 76
 Black Box Testing Black box testing techniques

Boundary values testing (BV)

“Bugs lurk in corners and congregate at boundaries [Beizer]

This method is based on the fact that a surprising nr. of faults turned
out to be boundary value faults
Can be applied only when inputs take values from a range. For
boolean values has no sense.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 27 / 76
 Black Box Testing Black box testing techniques

Boundary values testing (BV)

A program is viewed as a function that maps an input domain to a

range of output
BVT focuses on the boundary of the input domain to identify test
cases

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 28 / 76
 Black Box Testing Black box testing techniques

Rule for one input variable

If x is an input variable with values in the range [xmin, xmax] then

test the SUT for:
xmin
just above xmin
a nominal value, xnom
just below xmax
xmax

Test minimum, maximum, just below, just above.

Example (Req 1.A, Age 20–50):
Lower: 19 (Error), 20 (Success), 21 (Success).
Upper: 49 (Success), 50 (Success), 51 (Error).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 29 / 76
 Black Box Testing Black box testing techniques

Rule for more input variables

Multiple Variables:
When multiple inputs have ranges (e.g., Age, Salary, Experience),
testing all boundary combinations is exponential.
Example: 3 variables (Age, Salary, Experience) × 6 boundaries each
(19, 20, 21, 49, 50, 51 for Age) = 6³ = 216 combinations.
Problem: Too many tests for practical execution.

Single Fault Assumption (SFA):

1 Assumes a failure is caused by one faulty variable at a time.
2 Strategy: Hold all but one variable at nominal values (safe,
middle-of-range) and test extremes of one variable.
3 Reduces test cases significantly.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 30 / 76
 Black Box Testing Black box testing techniques

Boundary Value Extensions

Robustness
testing
Worst case
testing
Robust worst
case testing
Special value
testing
Random
testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 31 / 76
 Black Box Testing Black box testing techniques

Decision tables (DT)

Decision table is a 2 dimensional matrix with conditions and actions

on the rows and rules as columns
Can very concisely and rigorously show complex conditions and their
resulting actions while remaining comprehensible to human reader.
Used to document complex business rules that a system must
implement, but can also be used to generate test cases
Use a spreadsheet (Excel)

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 32 / 76
 Black Box Testing Black box testing techniques

Decision tables (DT)

Key Components
Conditions: Input variables or criteria (e.g., Age ≥ 18, Gender = Female).
Actions: Outputs or system responses (e.g., Premium = $500, Deny
Insurance).
Rules: Columns in the table representing unique combinations of condition
outcomes,each mapping to specific actions.

Process
1 Identify conditions from requirements.

2 List possible actions.

3 Create a table with all condition combinations (2n for n conditions,if binary).
4 Map each combination to actions.
5 Derive test cases from rules, optimizing where possible.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 33 / 76
 Black Box Testing Black box testing techniques

Decision tables (DT)

Example : Requirements for Calculating Car Insurance Premiums:

For female between 18 and 64 years of age, the premium is 500
For males between 18 and 64 year of age, the premium is 1000
For anyone 65 years of age or more, the premium is 1500
Anyone less than 18 years of age, can’t get insurance
What is the minimum number of test cases needed to test this requirements

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 34 / 76
 Black Box Testing Black box testing techniques

Decision Tables (DT)

Step-by-Step Decision Table Construction:

1 Identify Conditions:

C1: Age < 18

C2: Age 18–64
C3: Age ≥ 65
C4: Gender = Female
C5: Gender = Male
2 Identify Actions:
A1: Premium = $500
A2: Premium = $1000
A3: Premium = $1500
A4: Deny Insurance

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 35 / 76
 Black Box Testing Black box testing techniques

Decision Tables (DT)

Step-by-Step Decision Table Construction:

1 Determine Rules:
Age < 18: Deny regardless of gender (1 rule).
Age 18–64: Premium depends on gender (Female → $500, Male →
$1000; 2 rules).
Age ≥ 65: Premium = $1500 regardless of gender (1 rule).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 36 / 76
 Black Box Testing Black box testing techniques

Decision Tables (DT)

Step-by-Step Decision Table Construction

Y/N: Indicates if a condition is met (Y = Yes, N = No).

-: Denotes a “don’t care” condition (irrelevant to the action).
X: Marks the action triggered for the rule.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 37 / 76
 Black Box Testing Black box testing techniques

Decision Tables (DT)

Step-by-Step Decision Table Construction:

1 Minimum Test Cases:
Each rule corresponds to one test case (covering unique
condition-action pairs).
4 Rules → 4 Test Cases
TC01 (R1): Age = 17, Gender = Female → Deny Insurance.
TC02 (R2): Age = 30, Gender = Female → Premium = $500.
TC03 (R3): Age = 30, Gender = Male → Premium = $1000.
TC04 (R4): Age = 65, Gender = Male → Premium = $1500.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 38 / 76
 Black Box Testing Black box testing techniques

Test case design

At least one test case for each rule.

If the rule’s conditions are binary (Y/N) one test per condition
combination is enough
If the condition is a range of values, test at low and high end of the
range
Combination DT and boundary testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 39 / 76
 Black Box Testing Black box testing techniques

The technique

Identify conditions and values

Compute maximum nr. of rules
Identify possible actions
Enter all possible rules
Define actions for each rule
Verify the policy (ask the client)

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 40 / 76
 Black Box Testing Black box testing techniques

State-transition Testing

State Transition Testing

State Transition Testing is a black-box test design technique where:
A system is viewed as having a finite number of states.
The system transitions between states in response to events.
Each transition may trigger an action.
You test valid and invalid transitions to verify the system behaves as
expected.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 41 / 76
 Black Box Testing Black box testing techniques

State-Transition Components

Key Components
States: Distinct conditions or modes of the system (e.g., ”Idle,”
”Card Inserted” in an ATM).
Events/Inputs: Triggers causing state changes (e.g., ”Insert Card,”
”Enter PIN”).
Transitions: Rules defining how the system moves from one state to
another (e.g., Insert Card: Idle → Card Inserted).
Actions/Outputs: System responses during transitions (e.g.,
”Display PIN Entry Screen”).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 42 / 76
 Black Box Testing Black box testing techniques

State-Transition Process

Process
1 Identify states from requirements or system behavior.

2 Define events that trigger transitions.

3 Create a state transition diagram to visualize states, events, and
transitions.
4 Build a state transition table to list all transitions, including valid and
invalid ones.
5 Derive test cases to cover:
All valid transitions.
Invalid transitions (what happens if an event is attempted in the wrong
state).
State-specific behaviors (e.g., outputs or invariants).

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 43 / 76
 Black Box Testing Black box testing techniques

State-Transition Example

Example
An ATM system handles user interactions with the following behavior:
States:
S1: Idle: ATM is waiting for a user.
S2: Card Inserted: Card is inserted, awaiting PIN.
S3: Authenticated: PIN is correct, user can select actions.
S4: Card Ejected: Card is returned, session ends.
Events:
E1: Insert Card: User inserts card.
E2: Enter Correct PIN: User inputs valid PIN.
E3: Enter Wrong PIN: User inputs invalid PIN.
E4: Select Transaction: User chooses an action (e.g., withdraw).
E5: Eject Card: ATM returns card (automatic or user-initiated).
E6: Cancel: User cancels operation.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 44 / 76
 Black Box Testing Black box testing techniques

State-Transition Rules

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 45 / 76
 Black Box Testing Black box testing techniques

State Transition Table

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 46 / 76
 Black Box Testing Black box testing techniques

Test case- 0-Switch Coverage

Covers each valid transition once.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 47 / 76
 Black Box Testing Black box testing techniques

Test case- 0-Switch Coverage

Invalid Transition Tests

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 48 / 76
 Black Box Testing Black box testing techniques

Test case design

Dictated by the coverage level:

All-states = a set of test cases that visit all states (weak)

All-events= a set of test cases that trigger all events at least once
(also weak)
All-paths = a set of test cases that executes all paths at least once
(the best but usually impossible)
All-transitions=exercise all transitions (recommended)

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 49 / 76
 Black Box Testing Black box testing techniques

Test case design

All states coverage

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 50 / 76
 Black Box Testing Black box testing techniques

Test case design

All events coverage

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 51 / 76
 Black Box Testing Black box testing techniques

Test case design

All transitions coverage

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 52 / 76
 Black Box Testing Black box testing techniques

What Is Use Case Testing ?

Use Case Testing

Use Case Testing is a black-box testing technique where test cases are
derived from use cases that describe interactions between users (actors)
and the system to achieve specific goals.
Originates from UML (Unified Modeling Language) and requirements
engineering.
Focuses on functional requirements and user behavior.
Each use case models a complete flow of events, including:
Main success scenarios
Alternative flows
Exceptional/edge cases

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 53 / 76
 Black Box Testing Black box testing techniques

Why Use Case Testing?

Benefit
User-centric-Based on real user actions and expectations
Functional coverage-Helps ensure system meets its business objectives
Easy communication-Stakeholders understand test cases derived from
real scenarios
Complements other techniques-Pairs well with state transitions,
equivalence classes, etc.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 54 / 76
 Black Box Testing Black box testing techniques

Online Shopping System – ”Place Order” Use Case

Actors
Customer
Payment Gateway

Preconditions
User is logged in
Cart contains at least one item

Main Flow:
1 User clicks “Place Order”

2 System shows payment options

3 User selects payment method and enters details
4 ayment gateway confirms transaction
5 System places order and shows confirmation
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 55 / 76
 Black Box Testing Black box testing techniques

Online Shopping System – ”Place Order” Use Case

Alternative Flows:
1 Invalid payment → show error, stay on payment screen

2 User cancels during checkout → return to cart

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 56 / 76
 Black Box Testing Black box testing techniques

Test Cases

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 57 / 76
 White Box

White Box

Based on deriving test cases directly from structure of a component or

system, known as structure based, structural or white box techniques
We might know architecture, detailed design, internal structure, or
the code of the test object
Test conditions,test cases, and test data are derived from a test basis
that may include code,software architecture , detailed design,or any
other source information regarding the structure of the software.
Coverage is measured based on the items tested within a selected
structure(e.g the code or interfaces)
Specifications are often used as an additional source of information to
determine the expected outcome of test cases.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 58 / 76
 White Box

White Box

White box testing techniques are used to assess the amount of testing
performed by tests derived from black box based techniques, i.e to
calculate coverage
Then we use the white box techniques to help design additional tests
to increase the test coverage

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 59 / 76
 White Box

Statement Testing and Coverage

To exercise all statements at least once. What would be the values of

exp,title and bonuse

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 60 / 76
 White Box

Statement Testing and Coverage

To exercise all statements at least once. What would be the values of

exp,title and bonuse
exp=20 and title=JR
4 statement/ 4 total statment = 100
Statement coverage is determined by the number of executable
statements covered by test cases divided by the number of all
executables statements in the code under test.
If we test every ”executable” statement , we call this full or 100
percent statement coverage.
Weakest white box criterion.

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 61 / 76
 White Box

Decision Testing and Coverage

To exercise all statements at least once. What would be the values of

exp,title and bonuse
The test cases follow the control flow that occur from a decision
point
For an IF statement, one for the true outcome and one for the false
outcome;
for a CASE statement,test cases would be required for all the possible
outcomes, including the default outcome
Decision coverage is determined by the number of all decisions
outcome covered by test cases divided by the number of all possible
decision outcomes in the code under test

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 62 / 76
 White Box

Decision Testing and Coverage

How much would exp=20 and title = JR give use branch coverage ?

Coverage = 2 Branches / 4 Total Branches 50%

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 63 / 76
 White Box

Decision Testing and Coverage

To achieve 100% decision coverage. How many test cases would you need

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 64 / 76
 White Box

Decision Testing and Coverage

TC1-exp=20 and title =JR

TC1-exp=2 and bonus =700

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 65 / 76
 White Box

The Value of Statement and Decision Testing

Statement testing may provide less coverage than decision testing

Statement coverage helps to find defects in code that was not
exercised by other tests.
Decision coverage helps to find defects in code where other tests have
not taken both true and false outcomes
Achieving 100% decision coverage guarantees 100% statement
coverage (but not vice versa)

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 66 / 76
 Experience Based

Experience Based

Test cases are derived from the users and tester’s skill and intution,
and their experience with similar applications and technologies
These techniques can help identify tests that were not easily identified
by other more systematic techniques
These techniques may achieve widely varying degrees of coverage and
effectiveness
Coverage can be difficult to assess and may not be measurable with
these techniques
These techniques are ofent combined with black-box and white box
test techniques

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 67 / 76
 Experience Based

Commonly Used Experience Based Test Techniques

Error Guessing
Explorator Testing
Checklist based testing

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 68 / 76
 Experience Based

Error Guessing

Error guessing is a technique used to anticipate the occurrennce of

errors, defects, and failures, based on the tester’s knowledge,
including:
How the application has worked in the past
What types of mistakes the developers tend to make
What failures that have occurred in other applications
A methodical more structured approach to the error guessing
technique is called ”Fault Attack”
It is where we create a list of possible mistakes, defects, and failures,
and design tests that will expoes those failures and the defects that
caused them.
Error guessing should support other techniques
The effectiveness of the error guessing techniques varies heavily upon
the tester’s experience

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 69 / 76
 Experience Based

Exploratory Testing
We use the tester’s experience to test the software without going into
the cyle of writing test conditions, test cases, test procedures and so
on. But rather, just sit and try to break the software
During exploratory testing, the tester can incorporate the use of other
black-box, white-box and experince based technqiues.
So theoretically speaking the tester here do test design,test
execution,test loggin and system evaluation all at the same time
concurrently.
The results of the exploratory tests are used to learn more about the
component or system at hand, and to create tests for the areas that
may need more testing
Exploratory testing work products may be created during test
execution, though the exten to which exploratory tests are
documented my vary significantly
Exploratory testing is most useful when there are few or inadequate
specification or significant time pressure on testing.
Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 70 / 76
 Experience Based

Checklist-based Testing

Think of a checklist like a to-do list, a reminder of a list of test

conditions that you need to consider while testing the software
In checklist-based testing, testers design, implement, and execute
tests to cover test conditions found in a checklist
Checklist can be generic or specialized
Generic checklists could be used for all types software to verify any
general software or component properties
Specialized checklists also exist for testing databases application or
testing websites

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 71 / 76
 Experience Based

Checklist for testing the image upload functionality

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 72 / 76
 Choosing Design Techniques

Test Techniques Selection Factors

Regulatory Standards
Customer or contractual requirements
Level of risk
Type of risk
Type of component or system
Test objectives
Documentation available

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 73 / 76
 Choosing Design Techniques

Test Techniques Selection Factors

Knowledge of the testers

Time and budget
Development Life Cyle
Experience of type of defects found
Component or system complexity
Available tools
Expected use of the software
Experienc with using the test

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 74 / 76
 Choosing Design Techniques

Test Techniques Maturity Factors

The maturity of test and development processes

Time constraints
Safety or regulatory requirements
The knowledge and skills of the people involved
The software development lifecycle model being followed

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 75 / 76
 Choosing Design Techniques

Which Technique is Best ?

Always make functional testing the first priority

Consider non-function test cases
Check statement and decision coverage
Use experience-based techniques

Wondimagegn D. (AAIT ) Quality Assurance and Software Testing April 23, 2025 76 / 76