Software Testing and

Quality Assurance

Chapter 4: Functional (Black Box) Testing

1
 Brainstorming Questions
 What is the primary goal of black-box testing?
 What is the purpose of equivalence partitioning?
 How do you identify valid and invalid equivalence
classes?
 What is the purpose of boundary value analysis?
How does boundary value analysis complement
equivalence partitioning?
 What is the role of experience in error guessing?
 What is the key concept behind state transition
testing?
 How do you identify the conditions and actions for a
decision table?
2
 What is Functional (Black Box)Testing?
Functional Testing
 It ensures the application does what it's supposed to.
 Verifies that an application's functions work as intended.
 Involves inputting values, observing output, and
comparing to expected results.
Black-Box Testing
 It verifies the application's behaviour without knowing
its inner workings.
 Treats the application as a "black box," focusing on
external behaviour.
 Assesses functionality based on inputs and outputs,
ignoring internal structure.
 A type of functional testing.
3
 Continued…
 Focus: Functional requirements
 Knowledge: No internal structure or code required
 Approach: Define input conditions to test all
functional requirements
 Complements: White-box testing
Benefits
 Tests from a user perspective
 Avoids developer bias
 Identifies defects and ensures quality

4
Continued…

5
 Continued…
 Tester must have a deep understanding of the system's
requirements.
 User should know how the system should behave in
response to the particular action
 Black-box testing attempts to find errors in the following
categories:
 Incorrect or missing functions,
 Interface errors,
 Errors in data structures or external data base access.
 Behaviour or performance errors,
 Initialization and termination errors
6
 Black Box Testing Approaches
1. Equivalence partitioning
2. Boundary-value analysis
3. Error guessing
4. State transition testing
5. Decision Table Testing
6. Use Case Testing

7
 Equivalence partitioning
 Equivalence testing is a black-box testing method
that divides the space of all possible inputs into
equivalence groups such that the program
“behaves the same” on each group
 Two steps:
1. partitioning the values of input parameters into equivalence
groups
2. choosing the test input values

8
 Continued…
1.„„If an input condition for the software-under-test is
specified as a range of values, select one valid equivalence
class that covers the allowed range and two invalid
equivalence classes, one outside each end of the range.‟‟
 For example, suppose the specification for a module says
that an input, the length of a Wire in millimetres, lies in
the range 1–499; then select
 One valid equivalence class that includes all values from
1 to 499.
 Two invalid classes
That consists of all values less than 1, and
That consists of all values greater than 499.

9
 Continued…
2. „„If an input condition for the software-under-test is
specified as a number of values, then select one valid
equivalence class that includes the allowed number of
values and two invalid equivalence classes that are
outside each end of the allowed number.‟‟
 For example, if the specification for a real estate-related module
says that a house can have one to four owners, then we select
 One valid equivalence class that includes all the valid number of
owners
 Two invalid equivalence classes
 Less than one owner and
 More than four owners.

10
 Continued…
3. „„If an input condition for the software-under-test is
specified as a set of valid input values, then select one
valid equivalence class that contains all the members of
the set and one invalid equivalence class for any value
outside the set.‟‟
 For example, if the specification for a paint module
states that the colours RED, BLUE, GREEN and
YELLOW are allowed as inputs, then select
One valid equivalence class that includes the set RED,
BLUE, GREEN andYELLOW, and
One invalid equivalence class for all other inputs.

11
 Continued…
4. „„If an input condition for the software-under-test is
specified as a “must be” condition, select one valid
equivalence class to represent the “must be” condition
and one invalid class that does not include the “must be”
condition.‟‟
 For example, if the specification for a module states
that the first character of a part identifier must be a
letter, then select
o One valid equivalence class where the first character
is a letter and
o One invalid class where the first character is not a
letter.

12
 Boundary Value Analysis
 “Bugs lurk in corners and congregate at
boundaries…” ---Boris Beizer
 The test cases developed based on equivalence class
partitioning can be strengthened by use of a
technique called boundary value analysis.
 Many defects occur directly on, and above and
below, the edges of equivalence classes.
 BVA is a software design technique to determine test
cases off-by-one errors

13
 Continued…
1. If an input condition for the software-under-test is
specified as a range of values, develop valid test cases
for the ends of the range, and invalid test cases for
possibilities just above and below the ends of the range.
 For example if a specification states that an input
value for a module must lie in the range between -
1.0 and +1.0,
 Valid tests that include values -1.0, +1.0 for ends of
the range as well as
 Invalid test cases for values just above and below
the ends - 1.1, +1.1, should be included.

14
 Continued…
2. If an input condition for the software-under-test is
specified as a number of values, develop valid test cases for
the minimum and maximum numbers as well as invalid test
cases that include one lesser than minimum and one greater
than the maximum
 For example, for the real-estate module mentioned
previously that specified a house can have four owners,
 Valid Tests that includes tests for minimum and
maximum values 1, 4 owners
 Invalid tests that include one lesser than minimum and
one greater than maximum 0, 5 are developed.

15
 Continued…
 If the input or output of the software-under-test is
an ordered set, such as a table or a linear list,
develop tests that focus on the first and last
elements of the set

16
 Error guessing
 Error guessing is an unstructured black-box testing
approach.
 It relies on tester experience to identify potential defects.
 It's a less formal method compared to other techniques.
 The main purpose of this technique is to identify
common errors
 Enter blank space into the text fields.
 Null pointer exception.
 Enter invalid parameters.
 Divide by zero.
 Use maximum limit of files to be uploaded.
 Check buttons without entering values

17
 State transition testing
 Black-box technique focused on system behaviour in
response to input conditions.
 Ideal for systems with finite states and sequential
dependencies.
 Steps:
 Identify States: Determine system's possible states.
 Define Transitions: Identify possible transitions between
states.
 Create Test Cases: Design test cases to trigger each
transition.
 Execute Test Cases: Run test cases and observe system's
response.
 Analyse Results: Compare actual and expected
behaviour, identify discrepancies.
18
 Example 1: State transition diagram
 Let’s consider an ATM system function where if the user enters the
invalid password three times the account will be locked. In this
system, if the user enters a valid password in any of the first three
attempts the user will be logged in successfully. If the user enters
the invalid password in the first or second try, the user will be asked
to re-enter the password. And finally, if the user enters incorrect
password 3 time, the account will be blocked.

19
 Decision Table Testing
 A structured testing technique that uses a matrix to map
input conditions to output actions.
 Focuses on complex decision logic within a system.
Why Use Decision Table Testing?
 Systematic Approach: Ensures comprehensive test
coverage.
 Clear Visualization: Easily understand complex decision
logic.
 Efficient Test Case Design: Identifies all possible
combinations of input conditions.
 Improved Test Coverage: Reduces the risk of missing
critical test scenarios.

20
 Components
 Condition Stubs:
 List of input conditions that affect the system's behavior.
 Action Stubs:
 List of possible actions or outputs that the system can produce.
 Rule Columns:
 Combinations of input conditions and corresponding actions.

Fig Decision Table

22
 Continued…
 Conditions:  Rules:
 Credit Score  Rule 1: High Credit Score,
 Income High Income, Low Loan
 Loan Amount Amount -> Approve
 Actions: Loan
 Approve Loan  Rule 2: Low Credit Score,
Low Income, High Loan
 Reject Loan Amount -> Reject Loan
 Refer to Credit
Committee

23
 Use Case Testing
 A black-box testing technique that uses use cases to
identify test scenarios.
 Use Case: A description of how a user interacts with a
system to achieve a specific goal.
 Test Cases: Derived from the use cases to cover various
scenarios and edge cases.
 Why Use Use Case Testing?
 Comprehensive Testing: Covers all functional requirements.
 Risk-Based Testing: Prioritizes testing based on critical use
cases.
 Improved Test Coverage: Ensures all aspects of the system are
tested.
 Enhanced User Experience: Validates the system's usability
and functionality.
24
 Use Case Testing Process
Steps Involved in Use Case Testing:
1. Identify Use Cases:
1. Analyse functional requirements and user stories.
2. Create detailed use case descriptions.
2. Design Test Cases:
1. Develop test cases for each use case scenario.
2. Consider both positive and negative test cases.
3. Define expected outcomes for each test case.
3. Execute Test Cases:
1. Execute test cases manually or using automation tools.
2. Record actual results and compare them to expected
outcomes.

25
 Continued…
4. Log Defects:
1.Document any defects or issues identified
during testing.
2.Assign severity and priority to each defect.
3.Track defect resolution and retesting.
5. Evaluate Test Results:
1.Analyse test results to assess overall system
quality.
2.Identify areas for improvement and additional
testing.

26
Thank you!
Questions?

27