Testing Concepts ClassBook Lesson04
Testing Concepts ClassBook Lesson04
Dynamic Testing involves working with the software, giving input values
and validating the output with the expected outcome
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
Characteristics of White-box Test Techniques
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
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.
Input Output
Black Box Test Techniques
Equivalence Partitioning
Boundary Value Analysis
Decision Table Testing
State transition testing
Use Case Testing
Error Guessing
4.2.1 Equivalence Partitioning
There are equivalence partitions for both valid and invalid values.
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).
Assumption: If one value in a group works, all will work. One from each partition is
better than all from one.
Guidelines & Examples to identify Equivalence Classes
If an input condition specifies that a variable, say count, can take range of
values(1 - 999). There is one valid equivalence class (1 < count <
999) and two invalid equivalence classes (count < 1) & (count
>999)
0 999 1000
1
4.2.2 Boundary Value Analysis
E.g. From previous example, we have valid equivalence class as (1 < count <
999). Now, according to boundary value analysis, we need to write test cases for
count=0, count=1,count=2,count=998,count=999 and count=1000 respectively.
0 2 998 1000
1 999
E.g. If we have to test the function int Max(int a , int b) the Boundary Values for
the arguments of the functions will be :
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.
o The values of the conditions and actions are usually shown as Boolean values
(true or false) or can also be numbers or ranges of numbers.
Notations in Decision Tables
For conditions:
— means the value of the condition doesn’t matter (may also be shown as N/A)
For actions:
Blank means the action should not occur (may also be shown as – or N or F or 0)
Example of Decision Table
Advantages of Decision Table Testing
1. The strength of decision table testing is that it helps to identify all the
important combinations of conditions, some of which might otherwise be
overlooked.
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.
If the same event can result in two or more different transitions from the same state, that
event may be qualified by a guard condition.
The state change may result in the software taking an action (e.g., outputting a calculation or
error message).
Example :
The program starts with an introductory menu. As an option is selected the program changes
state and displays a new menu. Eventually it displays some information , data input screen.
Each option in each menu should be tested to validate that each selection made takes us to
the state we should reach next.
Guidelines & Examples of State Transition Testing
4.2.5 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).
Each use case specifies some behavior that a subject can perform in
collaboration with one or more actors.
Interactions between the actors and the subject may result in changes
to the state of the subject.
4.3 White Box Test Techniques
White box is logic driven testing and permits Test Engineer to examine the
internal structure of the program
Make sure that each statement, decision branch, or path is tested with at least
one test case.
Test cases must be such that all statements in the program is traversed at
least once.
Example :
the code.
B
a=2
Or
Yes E
x>1
No x=x+1
D
4.3.2 Decision Coverage
D
4.3.3 Value of Statement and Decision Testing
Statement coverage helps to find defects in code that was not exercised by
other tests. Decision coverage helps to find defects in code where other tests
have not taken both true and false outcomes.
(Path ACE)
No x=x/a
Test Case2 : a=3, b=0, x=0
(Condn1 is True,Condn2 is False,Condn3 B
is False)
(Path ACD)
Test Case3 : a=1, b=0, x=3
a=2
Or
Yes E
(Condition1 is False,Condition2 is True) x>1
(Path ABE)
No x=x+1
Test Case4: a=1, b=1, x=1
(Condition1 is False,Condition2 is False) D
(Path ABD)
Condition Coverage
a>1 C
a>1 a>1 C a>1 C
C &&
&& && &&
b=0
b=0 b=0 b=0
x=x/a
x=x/a x=x/a x=x/a B
B B B
a=2 E
a=2 a=2 E a=2 E
E ||
|| || ||
x>1
x>1 x>1 x>1
x=x/b
x=x/b x=x/b x=x/b D
D D D
a=2, b=0, x=3 a=1, b=0, x=0 a=1, b=0, x=3 a=3, b=0, x=0
Cyclomatic Complexity
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.
Coverage can be difficult to assess and may not be measurable with these
techniques.
Error Guessing
Exploratory Testing
Checklist-based Testing
4.4.1 Error Guessing
It is an ad hoc approach
Example :
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.
Checklists can be created to support various test types, including functional and
non-functional testing.
As these are high-level lists, some variability in the actual testing is likely to
occur, resulting in potentially greater coverage but less repeatability.
Check-list based Technique
Flexibility.
Easy to create.
Team integration.
Deadlines control.
Test case reusability can help in cutting down costs incurred in missing
out on important testing aspects.
innovative testing strategy can be added in the testing checklist.
Difficulties of using checklists in testing
Different interpretation
“Holes” in coverage.
Item overlap.
Reporting problems.
Summary
A. Flow graph
1. Code coverage
D. Flow chart
E. Condition testing