1. Test Effectiveness
(“doing the right thing“)
- How much the customer's requirements are satisfied by the system?
- How well the customer specifications are achieved by the system.
Test Effectiveness can be improved by following
• Testing Principles
• Test Design Techniques
2. Testing Principles:
Testing is to prove Presence of Defects but not Absence of Defects.
Early Testing is necessary.
Testing should be started as early as possible which can prevent Fault Migration and Fault
Multiplication. Also, defects found early are easy, cheap and quicker to correct.
Testing is Context Dependent.
Testing is dependent of context of usage. (For ex. Aircraft or Health care software needs
more testing than Finance or Banking software).
3. Testing Principles (Cont..)
Exhaustive Testing is Impractical.
Testing with all possible set of Input’s with all possible circumstances.
Instead we should prefer any of the below,
Risk based Testing
Testing based on the Context of Usage
Testing based on Test Objectives
Defect Clustering (80:20 rule).
80% of Defects can be found in 20% of the Software.
This principle suggests most of the defects in s/w are concentrated in few zones of the s/w only. During Testing,
based on the Defect distribution, testing should be focussed more at such zones which exhibit more defects
and chances are that we shall find many more defects from such zones only.
4. Testing Principles (Cont..)
Pesticide Paradox.
Test scripts should be regularly reviewed and revised.
If the same tests are repeated over and over again, eventually the same set of test cases will no longer
find any new defects. To overcome this “Pesticide Paradox”, Test scripts needs to be regularly reviewed
and revised and new different tests needs to be written to find potentially more defects.
Absence of Errors Fallacy.
No Software can be 100% defect free. Software can achieve its Quality not only when it has 0% defects,
it is possible when it meets the “Purpose and Reasonable Expectations” of the Client.
5. Test Design Techniques:
Structure-based or White-box Technique
White Box Testing is a software testing method in which the internal
structure/design/implementation of the item being tested is known to the tester. It can be done
in five different ways as described below,
Control Flow analysis
Data Flow Analysis
Statement Coverage
Decision Coverage
Path Coverage
6. Structure-based or White-box
Technique(Cont..)
Control Flow Analysis
It is the assessment of the flow of control through the program in detecting error
conditions such as,
Logical Errors
Syntax Errors
Unreachable Code
Missing Links
7. Structure-based or White-box
Technique(Cont..)
Data Flow Analysis
Analysing the flow of data in terms of how it is being referenced, used, modified,
stored, destroyed etc... through the program execution such as,
Variable being called in the program before initialized
Variable initialized but not being called in the program
Mis-Match in operations with respect to the data types declared
8. Structure-based or White-box
Technique(Cont..)
Statement Coverage
Statement Coverage is the assessment of the percentage of executable statements that
have been exercised by a test case suite.
Decision Coverage:
It is the assessment of the percentage of decision outcomes that have been exercised
by a test case suite.
Path Coverage:
It is the assessment of the number of paths (Independent ways of a program can be
executed) that have been exercised by a test case suite
9. Specification-based or Black-box
Technique (Cont..)
Equivalence Class Partitioning:
Example: A requirement which accepts only the age entered should be between (18 to 60).
Valid Equivalence class – 18 to 60
Invalid Equivalence class – age less than 18 to age greater than 60
Boundary value Analysis:
Example: A requirement which accepts only the age entered should be between (18 to 60).
Valid Boundaries – age 17, 18, 60 and 61
Invalid Boundaries – age less than 17 and age greater than 61
Optional valid boundaries – age 19 and 59
10. Specification-based or Black-box
Technique (Cont..)
Decision Table Testing:
To test for combination of input’s which gives different results based on the input,
Decision Table Testing is preferred.
Example:
11. Specification-based or Black-box
Technique (Cont..)
State Transition Testing:
A State Transition Table is a table showing what a finite state machine will move to,
based on the current state and other inputs.
Example:
12. Specification-based or Black-box
Technique (Cont..)
Use Case Testing:
NOTE: UseCase is a Pictorial representation of the user requirements (from the starting
point of the software till the end point).
Partition the flow of UseCase into smaller portions and evaluating whether the system
behaves as expected is UseCase Testing.
Example:
13. Test Design Techniques (Cont..)
Experience-based Technique
This sort of testing is done in the below mentioned circumstances,
In addition to the planned Testing,
When detail Documentation is not available.
Time and Budget constraint.
It is done using 2 methods, they are
Error Guessing
Guessing likely Errors in the application using previous similar experiences and designing a Test script based on that.
Exploratory Testing
It is done when no Documentation is available, Exploring the Software and coming up with the Test scripts.
It is mostly done during ‘Maintenance Testing’.