Chapter 3: Functional (Black Box) Testing

I don't need to know how they make Coca-Cola. I think it

tastes just fine not knowing what the ingredients are.

---Colin Hanks

1 Tadele M.
 Black Box Testing

 In black box testing items are treated as black box

whose logic is unknown.
 All that is known is what's goes in and what comes
out; the input and the output.
 Testers perform black box testing by examining
the software’s external behavior and evaluating its
functionality against specified requirements.

Focuses on the functional requirement of the software also called

behavioral testing

2
 Example of Black Box Testing
 A simple black box testing example for a login functionality of a web application without having
access to the internal code or implementation details.
 Test Case Name: Verify successful login with valid credentials.
 Test Steps:
 Open the web browser.
 Enter the URL of the application’s login page.
 Enter a valid username in the username field.
 Enter a valid password in the password field.
 Click on the “Login” button.
 Wait for the application to process the login request.
 Expected Result: The user should be successfully logged into homepage.
 Test Case Status: PASS (if the user is redirected to the homepage)

3
 Features of Black Box Testing
Key characteristics of black box testing include:
 Focus on External Behavior: Black box testing emphasizes evaluating the software’s functionality
from an end-user perspective, focusing on how the system behaves with different inputs and usage
scenarios.
 Independence from Internal Code: Testers conducting black box testing do not require
knowledge of the internal code or implementation details, making it suitable for testers who may not
have programming expertise.
 Requirement-Based Testing: Test cases in black box testing are designed based on the software’s
requirements and specifications. This ensures that the application meets the intended functionality and
business objectives.
 Real-World Scenario Testing: Black box testing helps simulate real-user conditions, allowing
testers to identify defects that might arise during actual usage of the software.
 Validation of Interfaces: It is effective in verifying the accuracy of the software’s interfaces, ensuring
that inputs and outputs are correctly handled.

4
 Limitations of Black Box Testing

 Limited Code Coverage: Black box testing may not explore all possible code paths or
internal logic, potentially leaving certain defects undetected.
 Inability to Test Complex Algorithms: It may not be effective at validating complex
algorithms or intricate business logic that requires knowledge of the internal code.
 Dependency on Requirements: Test cases are heavily dependent on the accuracy and
completeness of the provided requirements. Incomplete or ambiguous requirements can
result in incomplete testing.
 Difficulty in Error Localization: Identifying the root cause of defects detected in
black box testing can be challenging, as testers lack access to internal code.

5
 Black Box Testing…
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.
 Behavior or performance errors
 Initialization and termination errors.
Commonly used Black Box methods :
1. Error guessing
2. Equivalence partitioning
3. Boundary-value analysis

6
 Error guessing techniques

 It is a type of black box testing technique which does not have any defined structure to find
the error.
 The tester uses the experience of the tester or analyst having prior experience with similar
applications to guess the problematic areas of the software.
 Its accomplishment is dependent on the ability and product knowledge of the tester because
a good test engineer knows where the bugs are most likely to be, which helps to save lots of
time.
 It can be done by those people who have product knowledge; it cannot be done by those
who are new to the product.
 With this, we cannot give the surety of the product quality.

7
 Error guessing techniques

The main purpose of this technique is to identify common errors at any level of
testing by exercising the following tasks:
 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.

8
 Equivalence Class partitioning
 Divide the input space into equivalent classes.
 If the software works for a test case from a class then it is likely to work for all
 Can reduce the set of test cases if such equivalent classes can be identified
 Getting ideal equivalent classes is impossible, without looking at the internal
structure of the program
 For robustness, include equivalent classes for invalid inputs too.
 Example: Look at the following taxation table

Income Tax Percentage

Up to and including 500 0
More than 500, but less than 1,300 30
1,300 or more, but less than 5,000 40
9
 Equivalence Class partitioning…
 Based on the above table 3 valid and 4 invalid equivalent classes can be found
 Valid Equivalent Classes
 Values between 0 to 500, 500 to 1300 and 1300 to 5000
 Invalid Equivalent Classes
 Values less than 0, greater than 5000, no input at all and inputs containing
letters
 From this classes we can generate the following test cases
Test Case ID Income Tax
1 200 0
2 1000 300
3 3500 1400
4 -4500 Income can’t be negative
5 6000 Tax rate not defined
6 Please enter income
7 98ty Invalid income
10
 Boundary value analysis
 It has been observed that programs that work correctly for a set of
values in an equivalence class fail on some special values. Bugs lurk in corners and congregate
at boundaries.
 These values often lie on the boundary of the equivalence class. (Boris Beizer, Software testing techniques)
 A boundary value test case is a set of input data that lies on the edge of
a equivalence class of input/output.
 If the program works correctly for these extreme cases, then it will
work correctly for all values in between the valid partition.
 Example
 Using an example in ECP generate test cases that provides 100% BVA
coverage.
< 0 0<income<500 500<income<1300 1300<income<5000 > 5000

 So, we need from12 – 14 ( 2 for no and character entries) test cases to

achieve the aforementioned coverage
11
 Cause Effect graphing
 Equivalence classes and boundary value analysis consider each input separately.
 To handle multiple inputs, different combinations of equivalent classes of inputs
can be tried.
 Number of combinations can be large – if n is different input conditions such that
each condition is valid/invalid, then we will have 2n test cases.
 Cause effect graphing helps in selecting combinations as input conditions
 A cause is a distinct input condition, and an effect is a distinct output condition (T/F).

12
 Cause Effect graphing…
 The steps in developing test cases with a cause-and-effect graph are as follows
 Decompose the specification of a complex software component into lower-level units.
 Identify causes and their effects for each specification unit.
 Define the rules
 Create Boolean cause-and-effect graph.
 Causes and effects are nodes
 dependency b/n nodes are represented by arcs
 Annotate the graph with constraints that describe combinations of causes and/or effects that
are not possible due to environmental or syntactic constraints (if needed).
 The graph is then converted to a decision table.
 The columns in the decision table are transformed into test cases

13
 Cause Effect graphing…
 Consider the following set of requirements as an example:
 Requirements for Calculating Car Insurance Premiums:
 R00101 For females less than 65 years of age, the premium is $500
 R00102 For males less than 25 years of age, the premium is $3000
 R00103 For males between 25 and 64 years of age, the premium is $1000
 R00104 For anyone 65 years of age or more, the premium is $1500
 The causes and their effects identified from the specification are:

14
22
 Cause Effect graphing…
 Define the Rules
 If gender is female and age is less than 65, the premium is $500
 If gender is male and age is less than 25, the premium is $3000
 If gender is male and age is b/n 25 and 65, the premium is $1000
 If gender is male or female and age is greater than 65, the premium is $1500
 Now, Draw the cause/ Effect graph from the rules

23
15
 Cause Effect graphing…
 The graph is converted to decision table
 Since we have 5 input conditions we will have 2^5 = 32 columns
 However , for simplicity only 6 are shown in this limited-entry decision
table.

 From this table the test cases can be generated as shown in the next table
16
 Cause Effect graphing…
 Generate the test cases
 The columns in the decision table are converted into test cases.

17
 Tools used for Black Box Testing

 Tools used for Black box testing largely depends on the type of black box testing you are
doing.
 Functional/ Regression Tests you can use – QTP, Selenium

 For Non-Functional Tests, you can use – LoadRunner, Jmeter

18
 Test Plan
 Testing usually starts with test plan and ends with acceptance
testing.
 Test plan is a general document that defines the scope and
approach for testing for the whole project
 Inputs are SRS, project plan, design, code, …
 Test plan identifies what levels of testing will be done, what
units will be tested, etc in the project
 It usually contains
 Test unit specifications: what units need to be tested separately
 Features to be tested: these may include functionality, performance,
usability,…
 Approach: criteria to be used, when to stop, how to evaluate, etc
 Test deliverables
 Schedule and task allocation

19
 IEEE 829 Test Plan Structure
 Test Plan Identifier  Test Deliverables
 References  Testing Tasks
 Introduction  Environmental Needs
 Test Items  Responsibilities
 Features To Be Tested  Staffing And Training Needs
 Features Not To Be Tested  Schedule
 Approach  Risks And Contingencies
 Item Pass/Fail Criteria  Approvals
 Suspension Criteria And Resumption Requirements  Glossary

20