UNIT - II

The smart Tester

• Responsibility of testers is to design tests that
– Reveal defects
– Can be used to evaluate software performance, usability & reliability.
– Understand the functionality, input/output domain and the
environment for use of the code being tested
• Testers must select a finite number of test cases from a very large
execution domain
• As testing is done under budget and time constraints, testers get
pressures from management and marketing becoz testing is not
well planned & expectations are unrealistic
• The smart tester must
– plan for testing,
– Select the test cases
– Monitor the process to insure that the resources and time allocated
for the job are utilized
• To carry out these, testers need proper education and training &
management support.
• Novice testers – may try to test a module/component using all
possible inputs and exercise all possible s/w structures. They think
that they can detect all defects.
• But informed & educated tester knows that it is not a realistic
• Tester may select test i/p’s at random
• The goal of the smart tester is to understand
– the functionality,
– input/output domain
– the environment for use of the code being tested
– in detail how the code is constructed for certain types of testing.
• The smart tester needs to use knowledge of the types of defects that
are commonly injected during development /maintenance, to select
the subset of test inputs
• A smart tester who wants to maximize use of time and resources
should develop effective test cases for execution based testing
 Test case Design strategies
• Developing effective test cases is important to an
organization for higher quality testing process.
(Benefits of effective Test cases)
• If test cases are effective, there is
– A greater probability of detecting defects
– More efficient use of organizational resources
– Higher probability for test reuse
– Closer adherence to testing and project schedules and budgets
– The possibility for delivery of high quality s/w product
Approaches to design effective test cases:
1. Black box (functional/specification) test strategy
2. White box(clear/glass box) test strategy
Black box testing /Opaque box testing White box testing
No knowledge of its inner structure of the Focus on the inner structure of the s/w
s/w
Tester only has the knowledge what it does Tester has the knowledge of the structure

Size of the s/w under test can vary from a Tester selects Test cases to exercise specific
simple module, member function, or internal structural elements to check
object cluster to subsystem/ complete whether they are working properly.
system.
• Description of behavior for the s/w may • Test cases are designed to exercise all
come from a formal specification, statements or True/False branches in a
requirements specification, module or method.
input/process/output Diagram, set of • designing, executing & analyzing the
pre/post conditions. results of white box testing is time
• The tester provides the specified i/p to consuming.
the s/w , runs the test and then checks • so, this strategy can be applied to smaller
whether the outputs produced are size s/w
equivalent to those in the specification
Useful for revealing requirements & Useful for revealing design & codebased
specification defects control, logic and sequence defects ,
initialization defects and data flow defects
Test Strategies Tester's View Knowledge sources Techniques / Methods
Requirements
document Equivalence class partitioning
Inputs Specifications Boundary value analysis
Black-box testing
User manual Cause effect graphing
(not code-based)
Models Error guessing
(sometimes called
Domain knowledge Random testing
functional testing)
Outputs Defect analysis data State-transition testing
Intuition Scenario-based testing
Experience
Control flow testing/coverage:
- Statement coverage
- Branch (or decision) coverage
Program code - Condition coverage
Control flow graphs - Branch and condition coverage
White-box testing
Data flow graphs - Modified condition/ decision
(also called
Cyclomatic coverage
code-based or
complexity - Multiple condition coverage
structural testing)
High-level design - Independent path coverage
Detailed design - Path coverage
Data flow testing/ coverage
Class testing/coverage
Mutation testing
 Blackbox Testing Strategies
• Random Testing
• Equivalence Class Partitioning
• Boundary Value Analysis
• Other black box test design approaches
– Cause-and-Effect Graphing
– State Transition Testing
– Error Guessing
•
 Random Testing
• Each s/w module or system has an i/p domain from which test i/p data is selected. If
a tester randomly selects inputs from the domain, it is called random testing

• Eg: if the valid i/p domain for a module is all +ve integers between 1 and 100, the
tester will randomly select values from within that domain . Eg. 55,24,3 might be
chosen

• Issues :
– Are the three values adequate to show that the module meets its specification when the tests
are run? Should additional or fewer values be used to make the most effective use of
resources?
– Are there any i/p values, other than those selected, more likely to reveal defects? (Should +ve
integers at the beginning of the domain or end of the domain be specifically selected as inputs?)
– Should any values outside the valid domain be used as test inputs? (Eg: should test i/p data
include floating point values, -ve values, integer values greater than 100?)
• Use of random test i/ps may save time & effort that test i/p selection methods
require. But many test experts says that selecting test i/ps randomly has very little
chance of producing an effective set of test data.

• Tools are available for generating random test data for stress tests. Tester specifies
the range for the random value generator or the test i/ps are generated according to
a statistical distribution associated with a pattern of usage
 Equivalence class partitioning
• Equivalence class partitioning will be a good approach to select test i/ps, if
the tester views a s/w as a blackbox with well defined i/ps and o/ps.

• Equivalence class partitioning results in a partitioning of the i/p domain of

the s/w under test. o/p domain can also be partitioned.

• The finite number of partitions/equivalence classes allow the tester to

select a given member of an equivalence class as a representative of that
class.

• A test value in a particular class is equivalent to a test value of any other

member of that class.

• If one test case in a particular equivalence class reveals a defect, all the
other test cases based on that class may reveal the same defect.

• If a test case in a particular equivalence class did not reveal a defect, all the
other test cases based on that class may not reveal the same defect.
• Advantages:
– It eliminates the need for exhaustive testing, which is not feasible
– It guides a tester in selecting a subset of test i/ps with a high
probability of detecting a defect
– It allows a tester to cover a larger domain of inputs/outputs with a
smaller subset selected from an equivalence class
• How does the tester identify equivalence classes for the i/p
domain?
– First Approach
• Use a set of ‘interesting ‘ i/p conditions (Glen Myers called)
• i/p conditions come from a description in the specification of the s/w to
be tested
• The tester uses the conditions to partition the i/p domain into
equivalence classes and then develops a set of test cases to include all the
classes
• The tester and the analyst interact during the analysis phase to develop
– A set of testable requirements
– Correct and complete input/output specification
• From these the tester develops
– A high level test plan
– A preliminary set of black box test cases for the system
•
• Important points to equivalence partitioning:
1. Tester must consider both valid and invalid equivalence classes.
2. Equivalence classes may also be selected for output conditions
3. The derivation of input or outputs equivalence classes is a
heuristic process.
• i.e. There are no hard and fast rules for identifying the partitions. Given
the same set of conditions, individual testers may make different
choices of equivalence classes. Experience makes the tester to select
appropriate equivalence classes .
4. In some cases, it is difficult to identify equivalence classes.
Reasons:
• Conditions/boundaries that help to define classes may be
absent/obscure
• There may be a very larger/ smaller number of equivalence classes for
the problem domain
• These problems are due to ambiguous, contradictory,
incorrect/incomplete specification/requirements description.
So, tester should meet analysts to clarify these documents. And also, tester
should meet users or client group if needed.
For some software problem, defining equivalence classes is difficult. Eg. s/w
that use tax code
 Myers conditions/guidelines for
selecting input equivalence classes
Cond If Specifying Select the no.of Select the Example
ition the input valid no.of invalid
No. condition for equivalence equivalence
software classes classes
under test is
1 Range of 1 valid class ( 2 invalid range 1-300
Values covers the classes Valid : includes all values from
allowed range) (outside each 1 to 300
end of range) Invalid: 1) includes all values
less than 1
2) All values greater than 300
2 Number of 1 valid class ( 2 invalid A house can have one to four
values covers the classes owners
allowed (outside each Valid : includes all valid
number of end of the number of owners
values) allowed Invalid: 1) less than one
number) owner
2) greater than four owners
Cond If Specifying Select the no.of Select the Example
ition the input valid no.of invalid
No. condition for equivalence equivalence
software classes classes
under test is
3 Set of valid 1 valid class ( 1 invalid class {RED,BLUE,GREEN,YELLOW}
input values contains all the (any value Valid : includes any value in
members of the outside the the set
set) set) Invalid: all other input
4 Must be 1 valid class 1 invalid class( First character of a user name
condition (includes the doesn’t must be a letter
must be include the Valid : first character is the
condition) must be letter
condition) Invalid: first character is not a
letter
5 Not handled further partitioned into smaller equivalence classes
in an
identical way
 A specification o
Function square_root
message(x:real)
when x>=0.0
reply(y:real)
Where y>=0.0 & approximately (y*y, x)
Otherwise reply exception imaginary_square_root
End function