SENG5441 1/10/2025

SENG5441-STQA
Chapter – 3 – SOFTWARE TEST TYPES

Test design Techniques IEEE 829 standard

Software Testing and Quality Assurance 2

Software Testing and Quality Assurance 1

SENG5441 1/10/2025

Four software test types

• A test type is focused on a particular test objective
• Functional Testing
• Non-functional testing
• Structural testing
• Change-related testing

Software Testing and Quality Assurance 3

Functional Testing
• The function of a system (or component) is 'what it does‘.
• Functional Testing - testing performed to evaluate if a
component or system satisfies functional requirements. (ISO
24765)
• This is typically described in a requirements specification, a
functional specification, or in use cases.
• Functional testing considers the specified behavior and is
often also referred to as black-box testing.
• This is not entirely true, since black-box testing also includes non-
functional testing. Software Testing and Quality Assurance 4

Software Testing and Quality Assurance 2

SENG5441 1/10/2025

Functional Testing - ISO 9126

• ISO 9126 – focuses on
• Suitability
• Interoperability
• Security
• Accuracy and
• Compliance
• Testing functionality can be done from two perspectives:
• requirements-based
• Uses a specification of the functional requirements for the system as the basis for designing
tests.
• business-process-based
• Uses knowledge of the business processes.
• The techniques used for functional testing are often specification-based.

Software Testing and Quality Assurance 5

FUNCTIONAL testing Approaches

1. Requirement-Based Testing
2. Boundary Value Analysis (BVA)
3. Equivalence Partitioning
4. Decision Table Testing
5. State Transition Testing
6. Use Case Testing
7. Exploratory Testing
8. Regression Testing

Software Testing and Quality Assurance 6

Software Testing and Quality Assurance 3

SENG5441 1/10/2025

1. Requirement-Based Testing
• Creating test cases directly from the functional requirements or
business use cases of the application.
• Can be done by
1. Analyzing functional requirements, specifications, and user stories.
2. Identifying key functionalities and their expected outcomes.
3. Writing test cases for all scenarios, including positive and negative cases.
• Example in banking application:
• Requirement: The system must allow users to transfer funds between
accounts.
• Test Case: Verify fund transfer with valid inputs, invalid inputs, and no inputs.
• IT ensures all documented requirements are covered by tests.
Software Testing and Quality Assurance 7

Equivalence partitioning /EP/

• It is a common sense approach to testing
• The idea is:
• to divide (i.e. to partition) a set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them equivalently), hence
'equivalence partitioning'.
• Also known as equivalence classes
• Groups of inputs that are treated the same by the system under test.
• Each partition should produce the same outcome.
• It is all-round specification-based black-box technique.
• Applied at any level of testing.
• Often, it is a good technique to use first.

Software Testing and Quality Assurance 8

Software Testing and Quality Assurance 4

SENG5441 1/10/2025

Equivalence partitioning /EP/ cont …

• It requires only one condition from each partition.
• If one condition in a partition works, we assume all of the
conditions in that partition will work, and so there is little point in
testing any of these others.
• Conversely, if one of the conditions in a partition does not work,
then we assume that none of the conditions in that partition will
work so again there is little point in testing any more in that
partition.

Software Testing and Quality Assurance 9

Equivalence partitioning /EP/ cont …

• used to reduce the number of test cases while ensuring thorough
coverage.
• Instead of testing every input value, testers select one representative
value from each partition.
• Types of Partitions:
• Valid Partition: Contains valid inputs that the system should accept and
process correctly.
• Invalid Partition: Contains invalid inputs that the system should reject or
handle appropriately.

Software Testing and Quality Assurance 10

Software Testing and Quality Assurance 5

SENG5441 1/10/2025

Equivalence partitioning /EP/ - Registration

system ?
• Spec.
• Username: Must be alphanumeric , Length: 5–15 characters.
• Password: Must have a minimum of 8 characters, Must include at
least one uppercase letter, one lowercase letter, one number, and one
special character.
• Email: Must follow standard email format
• Phone Number: Must be numeric and have 10 digits.
• Date of Birth: User must be at least 18 years old.

Software Testing and Quality Assurance 11

Req’t field Valid Partition Invalid Parition

Username Strings with 5–15 Less than 5 characters

alphanumeric characters More than 15 characters
Non-alphanumeric characters

Password Proper email format Missing "@" symbol

Missing domain
Invalid characters

Phone Number Numeric string with exactly Less than 10 digits

10 digits More than 10 digit
Non-numeric characters

Date values where age is 18 Dates where age is less than 18

years or older Invalid date formats

Software Testing and Quality Assurance 12

Software Testing and Quality Assurance 6

SENG5441 1/10/2025

Equivalence partitioning /EP/ - Example

• a savings account in a bank earns a different rate of interest
depending on the balance in the account. In order to test the
software that calculates the interest due, we can identify the ranges
of balance values that earn the different rates of interest. For
example, if a balance in the range $0 up to $100 has a 3% interest
rate, a balance over $100 and up to $1000 has a 5% interest rate,
and balances of $1000 and over have a 7% interest rate, we would
initially identify three valid equivalence partitions and one invalid
partition as shown below.
Invalid Valid (for 3% interest) Valid (for 5%) Valid (for 7%)
partition
-$0.01 $0.00 - $100.00 $100.01 - $999.99 $1000.00
Software Testing and Quality Assurance 13

Boundary value analysis /BVA/

• It is based on testing at the boundaries between partitions.

Software Testing and Quality Assurance 14

Software Testing and Quality Assurance 7

SENG5441 1/10/2025

Decision Table Testing

• Why ?
• EP/BVA applied to specific situations or inputs.
• Decision table is a good way to deal with combination of things/inputs.
• Decision Table – also called ‘cause effect’ table, b/c there is an associated
logic diagramming technique called ‘ cause-effect graphing’.
• There should be systematic way of selecting combinations of inputs.
• Used with EP
• Helps in selection of effective test cases and finds problems and
ambiguities in specification.

Software Testing and Quality Assurance 15

1. Empty decision table

4. Decision table with additional outcomes

2. Decision table with input combinations

3. Decision table with combinations and outcomes 5. Decision table with changed outcome
Software Testing and Quality Assurance 16

Software Testing and Quality Assurance 8

SENG5441 1/10/2025

State transition testing

• State transition testing is used where some aspect of the system can
be described in that 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'.

State diagram for PIN entry,

Note: All states not listed here

Software Testing and Quality Assurance 17

State transition testing cont …

• Testing for invalid transitions
• In order to see the total number of combinations of states and transitions,
both valid and invalid, a state table is useful.
• The state table lists all the states down one side of the table and all the
events that cause transitions along the top (or vice versa).
• Each cell then represents a state-event pair.
• The content of each cell indicates which state the system will move to, when
the corresponding event occurs while in the associated state.
• This will include possible erroneous events - events that are not expected to
happen in certain states. These are negative test conditions.

Software Testing and Quality Assurance 18

Software Testing and Quality Assurance 9

SENG5441 1/10/2025

State transition testing cont …

• State table for PIN example

Software Testing and Quality Assurance 19

Use case testing

• A use case
• is a description of a particular use of the system by an actor (a user of the
system).
• They serve as the foundation for developing test cases mostly at the system
and acceptance testing levels.
• can uncover integration defects, that is, defects caused by the incorrect
interaction between different components.
• Use case testing
• is a technique that helps us identify test cases that exercise the whole
system on a transaction by transaction basis from start to finish.

Software Testing and Quality Assurance 20

Software Testing and Quality Assurance 10

SENG5441 1/10/2025

Use case testing cont …

• System requirements can also be specified as a set of use cases.

Partial use case for

PIN entry

Software Testing and Quality Assurance 21

Reading Assignment
• Exploratory testing
• Regression testing
• Error Guessing

Software Testing and Quality Assurance 22

Software Testing and Quality Assurance 11

SENG5441 1/10/2025

BlackBox testing techniques

Summary • EP, BVA, DT, ST, Error
guessing

BlackBox testing types BlackBox testing Process

• Functional Testing • Test planning
• Non-functional testing • Test case design
• User acceptance testing • Test execution
• Regression testing • Result analysis

Software Testing and Quality Assurance 23

Key terms
• Boundary value analysis
• Decision table testing
• Equivalence partitioning
• State transition testing
• Use case testing

Software Testing and Quality Assurance 24

Software Testing and Quality Assurance 12