This document discusses tool support for software testing. It covers: 1. The types of testing tools available, including test management, static analysis, test data preparation, and test execution tools. 2. The potential benefits of tools in reducing repetitive work and increasing consistency, but also the risks of unrealistic expectations and overreliance. 3. Special considerations for some tool types, like test management tools applying over the whole development lifecycle and different levels of scripting for test execution tools.

1. 1
Student of Information System (http://sif.uin-
suska.ac.id/)
Faculty of Sains And Technology (http://fst.uin-
suska.ac.id/)
State Islamic University of Sultan Syarif Kasim Riau
(https://uin-suska.ac.id/ )
STUDENT AND
BUSINESSMAN

2. T O O L S U P P O R T F O R
T E S T I N G
T E S T I N G I M P E L E M E N T A T I O N S Y S T E M

3. You may be wishing that you had a magic tool that
would automate all of the testing for you. If so, you will be
disappointed. However, there are a number of very useful
tools that can bring significant benefits. In this chapter we
will see that there is tool support for many different aspects
of software testing. We will see that success with tools is not
guaranteed, even if an appropriate tool is acquired - there
are also risks in using tools. There are some special
considerations mentioned in the Syllabus for certain types of
tool: test execution tools, performance testing tools, static
analysis tools and test management tools.

4. 4
1 TYPES OF TEST TOOL
2
EFFECTIVE USE OF TOOLS: POTENTIAL
BENEFITS AND RISKS
3
INTRODUCING A TOOL INTO AN
ORGANIZATION

5. 5
There are other things that computers can do much
better or more quickly than people can do. For
example, can you add up 20 three-digit numbers
quickly? This is not easy for most people to do, so
you are likely to make some mistakes even if the
umbers are written down. A computer does this
accurately and very quickly. As another example, if
people are asked to do exactly the same task over
and over, they soon get bored and then start making
mistakes.
Whatdoes'testmanagement'mean?Itcould bethemanagementof
tests’ or it could be 'managing the testing process'. The tools in this
broad category provide support for either or both of these. The
management of testing applies over the whole of the software
development life cycle, so a test management tool could be among
the first to be used in a project. A test management tool may also
manage the tests, which would begin early in the project and would
then continue to be used throughout the project and also after the
system had been released. In practice, test management tools are
typically used by specialist testers or test managers at system or
acceptancetestlevel.

6. 6
Features or characteristics of static analysis
tools include support to:
• calculate metrics such as cyclomatic complexity or nesting
levels (which can
help to identify where more testing may be needed due to
increased risk);
• enforce coding standards;
• analyze structures and dependencies;
• aid in code understanding;
Features or characteristics of test data
preparation tools include support to:
• extract selected data records from files or databases;
• 'massage' data records to make them anonymous or not
able to be identified with real people (for data protection);
• generate new records populated with pseudo-random
data, or data set up according to some guidelines, e.g. an
operational profile;

7. 7
Features or characteristics of test execution
tools include support for:
• capturing (recording) test inputs while tests are executed
manually;
• storing an expected result in the form of a screen or object
to compare to, the next time the test is run;
• executing tests from stored scripts and optionally data files
accessed by the script (if data-driven or keyword-driven
scripting is used);
In performance testing, many test inputs
may be sent to the software or system where
the individual results may not be checked in
detail. The purpose of the test is to measure
characteristics, such as response times,
throughput or the mean time between failures
(for reliability testing).

8. 8
In this chapter, we have described tools according to their
general functional classifications. There are also further
specializations of tools within these classifications. For
example There are web-based performance-testing tools as
well As performance-testing Tools For back-office systems.
There are Static Analysis Tools For Specific Development
Platforms And Programming languages, Since Each
Programming Language And Every Platform Has Distinct
characteristics. There Are Dynamic Analysis tools that Focus
on security ssues, as well as Dynamic analysis tools For
Embedded systems.
The tools described in this chapter are not the only
tools that a tester can make use of. You may not
normally think of a word processor or a spreadsheet
as a testing tool, but they are often used to store test
designs, test scripts or test data. Testers may also
use SQL to set up and query databases containing
test data. Tools used by developers when
debugging, to help localize defects and check
their fixes, are also testing tools.

9. 1. Potential
benefits of using
tools
There are many benefits that can be gained
by using tools to support testing, whatever
the specific type of tool. Benefits include:
• reduction of repetitive work;
• greater consistency and repeatability;
• objective assessment;
• ease of access to information about tests
or testing.

10. 2. Risks of using
tools
There are many risks that are present when tool
support for testing is introduced And used,
Whatever The Specific Type Of tool. Risks include:
• unrealistic expectations for the tool;
• underestimating the time, cost and effort for the
initial introduction of a tool;
• underestimating the time and effort needed to
achieve significant and continuing benefits from the
tool;
• underestimating the effort required to maintain the
test assets generated by the tool;
• over-reliance on the tool.

11. 3. Special
considerations for
some types of tools
There are tools that can generate scripts by
identifying what is on the screen rather than by
capturing a manual test, but they still generate scripts
to be used in execution; they are not script-free.
There are different levels of scripting. Five are
described in [Fewster and
Graham, 1999]:
• linear scripts (which could be created manually or
captured by recording a manual test);
• structured scripts (using selection and iteration
programming structures);
• shared scripts (where a script can be called by other
scripts so can be re-used - shared scripts also require
a formal script library under configuration
management);
• data-driven scripts (where test data is in a file or
spreadsheet to be read by a control script);

12. 1. Main principles
The place to start when introducing a tool into an
organization is not with the tool - it is with the
organization. In order for a tool to provide benefit, it
must match a need within the organization, and
solve that need in a way that is both effective and
efficient. The tool should help to build on the
strengths of the organization and address its
weaknesses. The organization needs to be ready
for the changes that will come with the new tool. If
the current testing practices are not good and the
organization is not mature, then it is generally more
costeffective to improve Testing practices rather
Than to try to find tools to support Poor practices.
Automating Chaos just gives faster chaos!

13. 2. Pilot project
The objectives for a pilot project for a new tool are:
• to learn more about the tool (more detail, more
depth);
• to see how the tool would fit with existing processes
or documentation, how those would need to change
to work well with the tool and how to use the tool to
streamline existing processes;
• to decide on standard ways of using the tool that will
work for all potential users (e.g. naming conventions,
creation of libraries, defining modularity, where
different elements will be stored, how they and the tool
itself will be maintained);
• to evaluate the pilot project against its objectives
(have the benefits been achieved at reasonable
cost?).

14. 3. Success factors
Success is not guaranteed or automatic when
implementing a testing tool, but many organizations have
succeeded. Here are some of the factors that have
contributed to success:
• incremental roll-out (after the pilot) to the rest of the
organization;
• adapting and improving processes, testware and tool
artefacts to get the best fit and balance between them and
the use of the tool;
• providing adequate training, coaching and mentoring of
new users;
• defining and communicating guidelines for the use of the
tool, based on what was learned in the pilot;
• implementing a continuous improvement mechanism as
tool use spreads through more of the organization;
• monitoring the use of the tool and the benefits achieved
and adapting the use of the tool to take account of what is
learned.

15. THANK YOU
Reference: Graham et al Foundationf of Software Testing