Test Techniques

Test Techniques
Categories of Test Techniques and their
characteristics
• Black-box test techniques (also called behavioral or behavior-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 nonfunctional testing. Black-box test techniques
concentrate on the inputs and outputs of the test object without
reference to its internal structure.
• 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.
• 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.
Common Characteristics – Black Box
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
Common Characteristic – White Box
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)
Specifications are often used as an additional source of information
to determine the expected outcome of test cases
Common Characteristic – Experience Based
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
Black Box Testing
1) Equivalence Partitioning(EP)
• 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 (see Kaner 2013 and
Jorgensen 2014). There are equivalence partitions for both valid and invalid
values.
• Each value must belong to one and only one equivalence partition
• 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.
Applicable at all test levels.

• Eg: System that user enter his marks for a subject.

Black Box Test
2) 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 (Beizer 1990).
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.
Example:
Example
• Given that Exam grades are determined using

Grade Marks
A 80-100
B 60-79
C 50-59
F Below 50
What are the values for testing if the following technique is used:
Black Box Test :Decision table testing
• Combinatorial test techniques are useful for testing the
implementation of system requirements that specify how different
combinations of conditions result in different outcomes.
• 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
Decision table (Continued.)
• For system which contains logical conditions and business rules that
are complex
• define input conditions and action of the system base time or false
value
• decision table defines:
Condition/Rules
• a set of trues and1 or false what Tactions
Condition T needed.
Condition 2 T T
• table: Actions
Action 1 Y
Action 2 Y
Decision Table Continued.
• The common minimum coverage standard for decision table testing is to
have at least one test case per decision rule in the table. This typically
involves covering all combinations of conditions. Coverage is measured as
the number of decision rules tested by at least one test case, divided by the
total number of
decision rules, normally expressed as a percentage.
• Example:
A priority customer who order more than RM10,000
is entitled to a 10% discount. An additioal 5% if he use a debit card.
Priority customer who order less than Rm10,000 shall receive RM50 bonus
discount.
Non-priority customer shall be ginven RM5 discount on any purchase.
Black Box Testing – State Transition
• A state transition table shows all valid transitions and potentially invalid
transitions between states, as well as the events, guard conditions, and
resulting actions for valid transitions. State transition diagrams normally
show only the valid transitions and exclude the invalid transitions.
• 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 codeor an entire business process.
State transition (Continued.)
• 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. For more information on coverage criteria for state transition
testing .
• Example:
ATM card shall be inserted into the machine
Then the machine shall wait for the pin
The atm machine shall allow the user to enter 1st pin, 2nd pin and 3rd pin until correct pin is
obtained.
If the pin is correct, the atm status shall change to ready and access to account is allowed.
After 3rd attempt of invalid pin, the atm shall reject and take the card away from the user.
Black Box Testing – Use Case Testing
• Tests can be derived from use cases, which are a specific
way of designing interactions with software items,
incorporating requirements for the software functions
represented by the use cases. 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).
• A use case can include possible variations of its basic
behavior, including exceptional behavior and error handling
(system response and recovery from programming,
application and communication errors, e.g., resulting in an
error message). Tests are designed to exercise the defined
behaviors (basic, exceptional or alternative, and error
handling). Coverage can be measured by the percentage of
use case behaviors tested divided by the total number of
use case behaviors, normally expressed as a percentage
White Box Testing
• Complement Black Box Testing
• Test the structure of the program / code
• Example of structure includes:
• Statements
• Decision
• Path
Types of structures
• Control Flow-Based

• Data Flow-Based
– All definitions (all defs)
– All definition-use pairs (all def-uses)
•
• Condition-Based
– (Simple) Condition coverage
– Multiple Condition coverage
Example
int main ()
{
int a: //L1
cout << "Enter value : \n"; //L2
cin >> a; //L3
if (a >= 100) //L4
{
for (int n = 1; n<=10 ; n++) //L5
{
cout << "Hello \n"; //L6
}
}
cout << "Thank you \n" ; //L7
return 0; //L8
}
Example (Continued.)
• Statement coverage:

• Decision Coverage:

• Path coverage:

• Boundary Interior coverage:

White Box Testing (Continued.)
• Statement Testing and Coverage
Statement testing exercises the executable statements in the code.
Coverage is measured as the number of statements executed by the
tests divided by the total number of executable statements in the test
object, normally expressed as a percentage.
• Decision Testing and Coverage
Decision testing exercises the decisions in the code and tests the code
that is executed based on the decision outcomes. To do this, the test
cases follow the control flows that occur from a decision point (e.g.,
for an IF statement, one for the true outcome and one for the false
outcome; for a CASE statement, test cases would be required for all
the possible outcomes, including the default outcome).Coverage is
measured as the number of decision outcomes executed by the tests
divided by the total number of decision outcomes in the test object,
normally expressed as a percentage.
Statement and Decision coverage
• Decision have higher coverage . Why ?
Experience Based Techniques
• Error Guessing

• Exploratory Testing

• Checklist-Based Testing

• When it should be applied ?

Error Guessing
• Error guessing is a technique used to anticipate the occurrence of mistakes,
defects, and failures, based on the tester’s knowledge
How the application has worked in the past
What types of mistakes the developers tend to make
Failures that have occurred in other applications

• A methodical approach to the error guessing technique is to create a list of

possible mistakes, defects,
and failures, and design tests that will expose those failures and the defects
that caused them.
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.
• Exploratory testing is sometimes conducted using session-based testing to
structure the activity. In session-based testing, exploratory testing is
conducted within a defined time-box, and the tester uses a test charter
containing test objectives to guide the testing. The tester may use test
session sheets to
document the steps followed and the discoveries made.
• Exploratory testing is most useful when there are few or inadequate
specifications or significant time pressure on testing. Exploratory testing is
also useful to complement other more formal testing techniques.
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.

• Checklists can be created to support various test types, including functional and
non-functional testing. In the absence of detailed test cases, checklist-based
testing can provide guidelines and a degree of consistency. As these are high-level
lists, some variability in the actual testing is likely to occur, resulting
in potentially greater coverage but less repeatability.