UNIT-5

TESTING TOOLS
 INTRODUCTION
• Testers use many tools during a software-test
life cycle.

• Tools may be used for testing, for

documenting defects or for preparing test
artifacts.
 SOFTWARE TOOLS
• Defect-tracking tools
• Regression-testing tools
• Configuration tools
• Communication tools
• Simulations
 HARDWARE TOOLS
• Machines
• Servers
• Printers
• Routers
 FEATURES OF TEST TOOL
• A test tool is a vehicle for performing test
process.
• Each tool has a specific purpose.
• Tools can be used in an entire SDLC for all
verification and validation activities.
 GUIDELINES FOR SELECTING A TOOL
• The tool must match its intended use
• Selecting a tool that is appropriate for a life-
cycle phase is very important
• Matching a tool with the skills of testers is also
essential
• Select affordable tools
• Backdoor entry of tools must be prevented.
 TOOLS AND SKILLS OF TESTERS
• User skills
• Programming skills
• System skills
• Technical skills
 STATIC TESTING TOOLS
• Static testing tools are used during static
analysis of a system.
Types:
• Code-profiling(complexity) tools
• Data-profiling tools
• Test-data generators
• Syntax-checking tools
 DYNAMIC TESTING
• Dynamic testing tools are used at different
levels of testing starting from unit testing and
which may go up to system testing and
performance testing.
• Areas covered:
• Regression testing
• Defect tracking and communication systems
• Performance ,load, stress-testing tools
 ADVANTAGES OF USING TOOLS
• Tools work faster than human beings
• Tools are consistent in behaviors and are not
prone to fatigue
• Some areas in software development can be
tested only by tools
 DISADVANTAGES
• Wrong selection or wrong usage of tool can
lead to disasters
• People using the tool must be adequately
trained
• Cost-benefit analysis before acquiring a tool
• Maintaining scripts in changing requirements
may be difficult
 WHEN TO USE AUTOMATED TEST
TOOLS
• Number of iterations of testing:
If same test case is executed many times,automation is best option
• Complexity of test cases:
Simple repetitive test case may be given to a tool, where testers have
to take a lot of decisions ,may not be automated
• Test case dependency:
When success or failure of one test case has a direct effect on the next
test case, automation may be avoided
 TESTING USING AUTOMATED TOOLS

• Test automation is the use of

software/hardware combination as the case
may be to create test plans, test cases,
definitions of test iterations, control the
execution of tests.
 PARTIAL AUTOMATION
• Automating parts of testing, but not all of the software-testing
process
Points to remember when thinking of test automation:
• Platform and os independence
• Data-driven capability
• Customizable reporting of testing activities
• Easy debugging and logging of application
• Distributed application support may be available
FRAMEWORK APPROACH IN AUTOMATION

• A framework is an integrated system that sets

the rules of automation of a specified product.

• This system integrates the function libraries,

test data sources ,object details and various
reusable modules.
 SYNCHRONISATION
• A distributed test case consists of two or more
parts, each processes on a different system,
that interact with each other
• AUTOMATIC SYNCHRONISATION:
If synchronization is to take place automatically
at run time during testing, the system will
determine when it shall take place as per the
defined criteria
• USER-DEFINED SYNCHRONISATION:
Each event is defined by a list of the systems
that will participate in the event and a sync
point number to be used for synchronization
 DIFFICULTIES WHILE INTRODUCING NEW
TOOLS
1)Organizational obstacles:
• Cost of the tool
• Training requirements
• Unwillingness in learning new skills
2)Tool problems
3)Environmental problems
 PROCESS OF PROCUREMENT OF COTS
• Goals to be met
• Objectives for the tool
• Acquisition plan
• Selection criteria
• User review of candidate
• Score candidate
• Select tool
• Procure tool
• Evaluation tool
• Implementation plan
• Training plan
• Orientation
• Modifications in tool/environment
• Training
• Use in operating environment
• Evaluation report
• Determine if goals are met or not
 PROCUREMENT OF TOOLS FROM CONTRACTOR

Difference between IN-HOUSE SOFTWARE DEVELOPMENT AND

SOFTWARE DEVELOPED BY A CONTRACTOR:

• Control over development process used by vendor

• Control over-Resources from vendor-side
• Cultural differences between vendor and customer
• Communication barriers between vendor and customer
• Employee morale and support from development team
• Root causes of the problems may not be addressed effectively
by vendor
 PROCESS OF PROCUREMENT OF TOOLS
FROM CONTRACTOR
• Goals to be met
• Objectives for the tool
• Acquisition plan
• Technical requirement document
• User review of requirements
• Request for proposal(RFP)/Request for quotation(RFQ)/
Request for Information(RFI)/
• Solicitation of proposal
• Technical evaluation
• Source selection
• Procure tool
• Evaluation plan
• Implementation plan
• Training plan
• Tool received
• Acceptance testing
• Orientation
• Modifications in tool
• Training
• Use in operating environment
• Evaluation report
• Determine if goals are met or not