24/06/2021

Black-Box ,White-Box and

Experience Based Testing
Lecture 5

Categories of Test Techniques and Their Characteristics

Black-Box Testing Techniques

White-Box Testing Techniques

Experience Based Testing Techniques

1
 24/06/2021

Black-box test techniques

•Black-box test techniques (also called behavioural or behaviour-based techniques) are
based on an analysis of the appropriate test basis (e.g., formal requirements
documents, specifications, use cases, user stories, or business processes).
•These techniques are applicable to both functional and non functional testing.
•Black-box test techniques concentrate on the inputs and outputs of the test object
without reference to its internal structure.

Categories of Test Techniques and Their

Characteristics
Common characteristics of black-box test techniques include the following:
Test conditions, test cases, and test data are derived from a test basis that may include
software requirements, specifications, use cases, and user stories
Test cases may be used to detect gaps between the requirements and the
implementation of the requirements, as well as deviations from the requirements
Coverage is measured based on the items tested in the test basis and the technique
applied to the test basis(documentation on which the test cases are based)

2
 24/06/2021

White-box test techniques

•White-box test techniques (also called structural or structure-based techniques) are
based on an analysis of the architecture, detailed design, internal structure, or the code
of the test object.
•Unlike black-box test techniques, white-box test techniques concentrate on the structure
and processing within the test object.

Categories of Test Techniques and Their

Characteristics
Common characteristics of white-box test techniques include::
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 of 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) and the technique applied to the
test basis

3
 24/06/2021

Experience-based test techniques

•Experience-based test techniques leverage the experience of

developers, testers and users to design, implement, and
execute tests.
•These techniques are often combined with black-box and
white-box test techniques.

Categories of Test Techniques and Their

Characteristics
Common characteristics of experience-based test techniques include::
Test conditions, test cases, and test data are derived from a test basis
that may include knowledge and experience of testers, developers,
users and other stakeholders
This knowledge and experience includes expected use of the software,
its environment, likely defects, and the distribution of those defects

4
 24/06/2021

1. Black Box testing techniques

• There are various test case design techniques applied for black-box
testing:
1.Boundary Value Analysis
2.Equivalence partitioning
3.State Transition Testing
4.Decision Table Testing
5.Use Case Testing

1.Equivalence partitioning
•Equivalence partitioning divides data into partitions (also known as equivalence classes) in such a
way that all the members of a given partition are expected to be processed in the same way. There
are equivalence partitions for both valid and invalid values.
Valid values are values that should be accepted by the component or system. An equivalence
partition containing valid values is called a "valid equivalence partition."
Invalid values are values that should be rejected by the component or system. An equivalence
partition containing invalid values is called an "invalid equivalence partition."
Partitions 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).

10

5
 24/06/2021

1.Equivalence partitioning
Any partition may be divided into sub partitions if required.
Each value must belong to one and only one equivalence partition.
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 be undetected.
To achieve 100% coverage with this technique, test cases must cover all identified partitions
(including invalid partitions) by using a minimum of one value from each partition.
Coverage is measured as the number of equivalence partitions tested by at least one value,
divided by the total number of identified equivalence partitions, normally expressed as a
percentage.

11

1.Equivalence partitioning

12

6
 24/06/2021

1.Equivalence partitioning example

• Assume, we have to test a field which accepts Age 18 – 56
• Valid Input: 18 – 56
• Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57 (>=57)
• Valid Class: 18 – 56 = Pick any one input test data from 18 – 56
• Invalid Class 1: <=17 = Pick any one input test data less than or equal to 17
• Invalid Class 2: >=57 = Pick any one input test data greater than or equal to 57
• We have one valid and two invalid conditions here.

13

Boundary Value Analysis

• Boundary value analysis (BVA) is an extension of equivalence partitioning, but can only be used
when the partition is ordered, consisting of numeric or sequential data. The minimum and
maximum values (or first and last values) of a partition are its boundary values
• Behavior at the boundaries of equivalence partitions is more likely to be incorrect than behavior
within the partitions. It is important to remember that both specified and implemented
boundaries may be displaced to positions above or below their intended positions, may be
omitted altogether, or may be supplemented with unwanted additional boundaries.
• Boundary value analysis and testing will reveal almost all such defects by forcing the software to
show behaviors from a partition other than the one to which the boundary value should belong.
• Boundary value analysis can be applied at all test levels. This technique is generally used to test
requirements that call for a range of numbers (including dates and times).
• Boundary coverage for a partition is measured as the number of boundary values tested, divided
by the total number of identified boundary test values, normally expressed as a percentage.

14

7
 24/06/2021

Boundary Value Analysis

15

Boundary Value Analysis Example

Assume, we have to test a field which accepts Age 18 – 56
Boundary Value Analysis
Minimum boundary value is 18
Maximum boundary value is 56
Valid Inputs: 18,19,55,56
Invalid Inputs: 17 and 57
Test case 1: Enter the value 17 (18-1) = Invalid
Test case 2: Enter the value 18 = Valid
Test case 3: Enter the value 19 (18+1) = Valid

16

8
 24/06/2021

Decision Table Testing

• Decision tables are a good way to record complex business rules that a system must
implement. When creating decision tables, the tester identifies conditions (often
inputs) and the resulting actions (often outputs) of the system.
• These form the rows of the table, usually with the conditions at the top and the actions
at the bottom. Each column corresponds to a decision rule that defines a unique
combination of conditions which results in the execution of the actions associated with
that rule.
• The values of the conditions and actions are usually shown as Boolean values (true or
false) or discrete values (e.g., red, green, blue), but can also be numbers or ranges of
numbers. These different types of conditions and actions might be found together in
the same table.

17

Decision Table Testing

In Decision table technique, we deal with combinations of inputs. To identify the test
cases with decision table, we consider conditions and actions. We take conditions as
inputs and actions as outputs
The common notation in decision tables is as follows:
For conditions:
Y means the condition is true (may also be shown as T or 1)
N means the condition is false (may also be shown as F or 0) means the value of
the condition doesn't matter (may also be shown as N/A) For actions:
X means the action should occur (may also be shown as Y or T or 1)
Blank means the action should not occur (may also be shown as — or N or F or 0)

18

9
 24/06/2021

Decision Table Testing

• Login page validation. Allow user to login only when both the ‘User ID’
and ‘Password’ are entered correct.
• Here the Conditions to allow user to login are Enter Valid User Name and
Enter Valid Password.
• The Actions performed are Displaying home page and Displaying an error
message that User ID or Password is wrong .

19

State Transition Testing

• Components or systems may respond differently to an event depending on current conditions or
previous history (e.g., the events that have occurred since the system was initialized). The
previous history can be summarized using the concept of states.
• A state transition diagram shows the possible software states, as well as how the software enters,
exits, and transitions between states.
• A transition is initiated by an event (e.g., user input of a value into a field). The event results in a
transition. The same event can result in two or more different transitions from the same state.
• The state change may result in the software taking an action (e.g., outputting a calculation or
error message).

20

10
 24/06/2021

State Transition Testing

21

State Transition Testing

• Tests can be designed to cover a typical sequence of states, to exercise all states, to
exercise every transition, to exercise specific sequences of transitions, or to test invalid
transitions.
• State transition testing is used for menu-based applications and is widely used within
the embedded software industry. The technique is also suitable for modeling a business
scenario having specific states or for testing screen navigation. The concept of a state is
abstract — it may represent a few lines of code or an entire business process.
• Coverage is commonly measured as the number of identified states or transitions
tested, divided by the total number of identified states or transitions in the test object,
normally expressed as a percentage.

22

11
 24/06/2021

State Transition Testing Example

• Using state transition testing, we pick test cases from an application where we need to
test different system transitions. We can apply this when an application gives a
different output for the same input, depending on what has happened in the earlier
state.
Example
• Withdrawal of money from ATM. ‘User A’ wants to withdraw 30,000 from ATM. Imagine
he could take 10,000 per transaction and total balance available in the account is
25,000. In the first two attempts, he could withdraw money. Whereas in the third
attempt, ATM shows a message as “Insufficient balance, contact Bank”. Same Action
but due to change in the state, he couldn’t withdraw the money in the third
transaction.

23

Use Case Testing

• The use case is functional testing of the black box testing used to identify
the test cases from the beginning to the end of the system as per the
usage of the system.
• By using this technique, the test team creates a test scenario that can
exercise the entire software based on the functionality of each function
from start to end.
• It is a graphic demonstration of business needs, which describe how the
end-user will cooperate with the software or the application.

24

12
 24/06/2021

Use Case Testing

• Tests can be derived from use cases, which are a specific way of designing interactions
with software items. They incorporate requirements for the software functions.
• Use cases are associated with actors (human users, external hardware, or other
components or systems) and subjects (the component or system to which the use case
is applied).
• Each use case specifies some behavior that a subject can perform in collaboration with
one or more actors .
• A use case can be described by interactions and activities, as well as preconditions,
postconditions and natural language where appropriate. Interactions between the
actors and the subject may result in changes to the state of the subject.
• Interactions may be represented graphically by work flows, activity diagrams, or
business process models.

25

Use Case Testing -Login Use Case Example

1. Introduction
This use case outlines the steps that need to be followed in order to login into the system
2. Actors
1. Administrator
2. Student
3. Faculty
3. Pre-Condition
The user/actor must have valid credentials
4. Post-Condition
If use case is successfully executed, the user/actor should be logged into the system,
otherwise, the state remains unchanged.
5. Basic Flow
Login
1. The page will request the user/actor to provide valid credentials
2. User/actor enters the credentials
3. User/actor enters into the system
6. Alternate Flow
Invalid Credentials
1. If user/actor provides invalid credentials in the basic flow, a validation message or
error message should appear. Hence, returning the user to the basic flow..
7. Special Requirements
None
8. Associated Use Case(s)
None

26

13
 24/06/2021

Use Case Testing

• Use Case Document Review: Tester should review the document and verify that all the use cases
are complete and conform to the specified requirements.
• Special Data Conditions: Tester should verify validity checks for special symbols. For example: for
email address ‘@’ and ‘.’ symbols should be validated for such inputs.
• Mandatory Data Inputs: Tester should validate such inputs without which, execution of a function
is not possible. For example: In the login form, both username and password are mandatory and
a validation check should be in place. Similarly, there are some fields which are not mandatory to
fill such as telephone number, registration number, etc.
• Domain-specific Checks: Tester should ensure that domain-specific checks are in place because
they are crucial to the business. In our university registration system, for example, a student
should only able to add/drop only one course per semester and a student must able to login only
with the roll number, etc.
• Basic and Alternate Flow: Tester should make sure that both flows function in the correct order.

27

Techniques in White Box Testing

The main techniques in white box testing are
1.Statement Coverage
2.Branch Coverage
3.Path Coverage

28

14
 24/06/2021

Techniques in White Box Testing

1) Statement coverage:
• In a programming language, a statement is nothing but the line of code
or instruction for the computer to understand and act accordingly.
• A statement becomes an executable statement when it gets compiled
and converted into the object code and performs the action when the
program is in a running mode.
• “Statement Coverage”, as the name itself suggests, it is the method of
validating whether each and every line of the code is executed at least
once

29

Statement Coverage Testing

30

15
 24/06/2021

Techniques in White Box Testing

2) Branch Coverage:
• “Branch” in a programming language is like the “IF statements”. An IF statement has two branches:
True and False.
• So in Branch coverage (also called Decision coverage), we validate whether each branch is executed at
least once.
• In case of an “IF statement”, there will be two test conditions:
• One to validate the true branch and,
• Other to validate the false branch.
• Hence, in theory, Branch Coverage is a testing method which when executed ensures that each and
every branch from each decision point is executed.

31

Branch Coverage Testing

32

16
 24/06/2021

Techniques in White Box Testing

3) Path Coverage
• Path coverage tests all the paths of the program.
• This is a comprehensive technique which ensures that all the paths of the
program are traversed at least once.
• Path Coverage is even more powerful than Branch coverage. This
technique is useful for testing the complex programs.

33

Path Coverage Testing

• In this example, there are several possible
paths through the code eg
• 1, 2
• 1, 3, 4, 5, 6, 8
• 1, 3, 4, 7, 6, 8

34

17
 24/06/2021

Experience Based Testing

•When applying experience-based test techniques, the test cases are
derived from the tester's skill and intuition, and their experience with
similar applications and technologies.
•These techniques can be helpful in identifying tests that were not easily
identified by other more systematic techniques.
•Depending on the tester's approach and experience, 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.

35

Experience Based Testing Techniques

1. Error Guessing
2. Exploratory Testing
3. Checklist Based Testing

36

18
 24/06/2021

Experience Based Testing

1) Error Guessing
•Error guessing is a technique used to anticipate the occurrence of errors, defects, and failures,
based on the tester's knowledge, including:
How the application has worked in the past
What kind of errors tend to be made
Failures that have occurred in other applications
• This technique completely depends on the tester’s experience. The more experienced the
tester is, the more errors he can identify. Several testers and/or users can also team up to
document a list of possible errors , and this can add a lot of value.
• Another way of error guessing is the creation of defect and failure lists. These lists can use
available defect and failure data as a starting point and can then expand by using the testers’
and users’ experience. This list can be used to design tests and this systematic approach is
known as fault attack.

37

Experience Based Testing

2) Exploratory Testing
•In exploratory testing, informal (not pre-defined) tests are designed, executed, logged,
and evaluated dynamically during test execution.
•The test results are used to learn more about the component or system, and to create
tests for the areas that may need more testing.
•This is used when specifications are either missing or inadequate and where there is
severe time pressure.
•A test charter of test objectives is first created and based on the test objectives, test
cases are designed, executed and logged, all these activities occur concurrently along
with learning about the application within a fixed time frame.
•The test objectives help maintain the focus and maximize testing within the limited
time frame.

38

19
 24/06/2021

Experience Based Testing(Exploratory Testing)

Identify the risks Identify what to
Categorize the kinds of
1. Classify the Seek the root cause and develop ideas 2. Create a test test, how it can be
problems commonly
bugs. of these problems. to test the charter. tested, and what
found in past projects.
application. factors to consider.

An extension or
Describe the Define how users Two testers work Interruptions do
3. Create a time reduction of 45
starting point of will utilize the together for at not occur during
box. minutes is
testing. system. least 90 minutes. the 90 minutes.
acceptable.

Testers react to the

response of the application 4. Review the Analyze coverage
Assess the defects. Learn from the test.
and prepare for the correct results. areas.
outcome.

Compare results to Check for needed

5. Debrief. Compile results.
the character. additional testing..

39

Experience Based Testing

3) Checklist-based Testing
•In checklist-based testing, testers design, implement, and execute tests to cover test
conditions found in a checklist.
•As part of analysis, testers create a new checklist or expand an existing checklist, but
testers may also use an existing checklist without modification.
•Such checklists can be built based on experience, knowledge about what is important for
the user, or an understanding of why and how software fails.
•As these are high-level lists, some variability in the actual testing is likely to occur,
resulting in potentially greater coverage but less repeatability.

40

20
 24/06/2021

Experience Based Testing

3) Checklist-based Testing

What constitutes Checklist Based Testing?

•The testing professional uses a generalized list of scheduled tasks and standard rules
against which the software application needs to be tested for flaws.
•These manual like "to-do" lists can be a physical or a mental list or a list prepared for
online circulation. Such lists then form the "checklist" which enumerates all the
conventional actions performed phase-wise during the testing cycle.
•With the completion of each phase, the listed activities are ticked off step by step.

41

Experience Based Testing

A checklist example for testing the image uploading functionality:
 Checking for image uploading path.
 Checking for image uploading.
 Check for image uploading with different extensions such as JPEG or BMP.
 Checking for uploading images with same names.
 Check if the image is getting uploaded within the maximum allowable size and if not,
it is necessary to verify that an error message is appearing.
 Check if the bar showing the progress of image uploading is appearing or not.
 Checking the functionality of the cancel button at the time of image upload.
 Checking for multiple image uploading.
 Checking for good quality of uploaded image.
 Checking if the user can save the image post the uploading process.

42

21
 24/06/2021

Next Week
Test Cases

43

22