Software Test Design Techniques

Software Test Design Techniques, Black-box test design techniques, White box test design techniques, and Experience-based test techniques.

Software Test Design Techniques

1. Introduction to Software Test Design Techniques

2. Static and Dynamic Test Design Techniques

3. Black-box Test Design Techniques

a.Equivalence Partitioning (EP)

b. Boundary Value Analysis (BVA)

c. Decision Table Testing

d. State Transition Testing

e. Use Case Testing

1. Introduction to Software Test Design Techniques

What is a Technique?

An efficient way of doing or achieving something.

What is Test Design Technique?

A test design technique is used to select a good set of tests from all possible tests for a given system.

Why do we need to use Test Design Techniques?

Exhaustive Testing is not possible, so we need to use Test Design Techniques in order to reduce the size of the input.

Exhaustive Testing is a Test approach in which the test suite comprises all combinations of input values and preconditions.

Exhaustive Testing is not recommendable due to Time and Budget considerations.

Categories of Test Design Techniques?

There are two main categories of Test Design Techniques, They are:

a. Static Techniques
b. Dynamic Techniques

2. Static and Dynamic Test Design Techniques

A. Static Techniques

> Testing of the software documents manually or with a set of tools but without executing the Software.

Two types of static testing techniques

i) Reviews (Manual Examination)

ii) Static Analysis (Automated Analysis)
——————————-
i) Reviews
Types of Reviews

a) Informal Review
b) Walkthrough
c) Technical Review
d) Inspection

ii) Static Analysis
Static analysis tools are typically used by developers, Compilers offer some support for Static analysis,

B. Dynamic Test Design Techniques

> The software is tested by executing it on a computer.

Categories of Dynamic Test Design Techniques

i) Specification-based or Black-box Techniques

a) Equivalence Partitioning (EP)
b) Boundary Value Analysis (BVA)
c) Decision Table Testing
d) State Transition Testing
e) Use Case Testing Etc…

ii) Structure-based or White-box Techniques

a) Statement Testing and coverage
b) Decision Testing and Coverage
c) Condition Testing, Multi Condition Testing etc…

iii) Experience-based Techniques

a) Error Guessing
b) Exploratory Testing

3. Black-box Test Design Techniques

a) Equivalence Partitioning (EP)

b) Boundary Value Analysis (BVA)

c) Decision Table Testing

d) State Transition Testing

e) Use Case Testing

a. Equivalence Partitioning (EP)

• It can be applied at any level of testing (Unit, Integration, System and Acceptance Testing)

• In Equivalence Partitioning, inputs to the Software are divided into groups that are expected to exhibit similar behavior.

• Equivalence Partitions/Classes can be found for both valid data and invalid data.

Example 1 (Data Range):

The tickets field in a Reservation system accepts 1 to 10 Tickets only.

Partition 1 Partition 2 Partition 3

0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)

Example 2 (Data Type):

The customer Identification Number field in a CRM system accepts only numbers.

Partition 1 Partition 2 Partition 3 Partition 4
Alpha bytes Numbers Special Characters Alpha-numeric
(Invalid) (Valid) (Invalid) (Invalid)

Example 3 (Data Size)

Phone Number filed accepts 10 digits number only

Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)

Example 4 (Others)

A Payment management system accepts credit card payments only

Partition 1 Partisan 2 Partisan 3
Credit card Net Banking Cash on Delivery
(Valid) (Invalid) (Invalid)

b. Boundary Value Analysis (BVA)

• The maximum and minimum values of a partition are its boundary values.

• Behavior at the edge of each equivalence partition is more likely to be incorrect than behavior within the partition.

• Boundary value analysis can be applied at all Test levels(Unit, Integration, System and Acceptance Testing).

Example 1:
Partition 1 Partition 2 Partition 3

0 1 to 10 11 to 99 or above
(Invalid) (Valid) (Invalid)

Minimum/maximum 0
Minimum 1
Maximum 10
Minimum 11
Maximum 99
————————————-
Example 3 (Data Size)

Phone Number filed accepts 10 digits number only

Partition 1 Partition 2 Partition 3
Below 10 10 Above 10
(Invalid) (Valid) (Invalid)

Minimum -9
Minimum and Maximum – 10
Maximum -11
—————————————-
Example: User Id field accepts 10 to 20 characters

Partition 1 Partition 2 Partition 3
Below 10 10 to 20 11 to 99

Minimum -1
Maximum – 9

Minimum – 10
Maximum – 20

Minimum – 21
Maximum -99

c. Decision Table Testing

• The decision tables are a good way to capture system requirements that contain logical conditions.

• It may be applied for all situations when the action of the software depends on logical decisions.

BSRB (Govt) System Job eligibility criteria,

Age should be in between 21 and 35

Conditions:
i) For SC or ST Candidates 5 Years age relaxation
ii) For BC Candidates 5 Years age relaxation
iii) PHC Candidates 5 Years age relaxation

Category Age Valid/Invalid
———————————————-
OC 20 Invalid
OC 21 Valid
OC 35 Valid
OC 36 Valid
BC 36 Valid
BC 39 Invalid
SC 39 Valid
PHC 39 Valid
ST 40 Valid
—————————————————–
Banking System interest rates For fixed deposits.
1 to 2 years 7%
2 to 3 Years 8%
3 to 5 Years 10%

Condition:

For Senior citizens 0.5% extra for all ranges

Age Period Interest Rate
———————————–
25 1 year 7%
35 2.5 8%
56 4 10%
66 4 10.5%

d) State Transition Testing

• In State transition Testing Test cases are designed to execute valid and invalid state transitions.

• A System (Application Under Test) may exhibit a different response on current conditions or previous history.

Example: Internet Banking System Fund Transfer operation

Initial Balance: 45000

Transaction      Transaction Amount      Transaction
1                             20000 Successful            (Pass)
2                             20000 Successful            (Pass)
3                             20000 Unsuccessful       (Pass)

e) Use Case Testing

• In Use Case Testing Test Cases are designed to execute User Scenarios or Business Scenarios.

• A Use Case describes interactions between actors, including users and the system.

• A Use case usually has a mainstream scenario and sometimes alternative scenarios.

Example:

Business Scenario: ATM Cash Withdrawal operation

Mainstream Scenario:

1)
User: Inserts ATM Card

System: Asks for PIN

2)
User: Enters PIN

System: Validates PIN and asks to select language

3)
User: Selects Language

System: Asks to select Account Type

4)
User: Selects Account Type

System: Asks to enter Amount

5)
User: Enters Amount

System: Releases Money
————————————————–
Alternatives

2a) Suppose if user enters invalid Pin

System: Shows error message and asks to enter correct PIN
User: Enters Correct PIN
———————–
4a) Suppose if user selects incorrect Account Type

System: Shows error and asks to select correct Account Type
User: Select correct account type

5a) If User enters incorrect amount (More than the balance amount or more than the day limit)

System: Shows Error message and asks to enter correct amount
User: Enters correct amount


Useful Links

Manual Testing Tutorial for Beginners
SQL Tutorial for Beginners
Java Tutorial for Beginners
Python Tutorial for Beginners
Selenium Tutorial for Beginners
Follow me on social media: