The document discusses tool support for testing software. It covers several types of testing tools, including tools for test management, static testing, test specification, test execution, performance and monitoring, and specific application areas. It notes that tools can provide benefits like reduced repetitive work and greater consistency, but also risks if not implemented properly, such as unrealistic expectations, underestimating costs and efforts, and over-reliance on tools. The document emphasizes that introducing tools requires matching needs, piloting projects to learn how tools fit processes, and success factors like incremental roll-outs, process adaptations, training, and continuous improvement.

1. TOOL SUPPORT FOR
TESTING
Departement information System
Faculty Science and Technology
University of Islam Negri Sultan Syarif Kasim Riau
ROMI WISARTA
11453101627

2. 1.TYPES OF TEST TOOL
1. Test tool classification
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.
2. Tool support for management of testing and tests
What does 'test management' mean? It could be the management of tests’ or it could be
'managingthetestingprocess'.Thetoolsinthisbroadcategoryprovidesupportforeitherorbothof
these.Themanagementoftestingappliesoverthewholeofthesoftwaredevelopmentlifecycle,
soatestmanagementtoolcouldbeamongthefirsttobeusedinaproject.Atestmanagement
toolmayalsomanagethetests,whichwouldbeginearlyintheprojectandwouldthencontinueto
be used throughout the project and also after the system had been released. In practice, test
managementtoolsaretypicallyusedbyspecialisttestersortestmanagersatsystemoracceptance
testlevel.

3. 3. Tool support for static testing
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;
4. Tool support for test specification
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;

4. 5.Toolsupportfortestexecutionandlogging
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);
6. Tool support for performance and monitoring
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).

5. 7. Tool support for specific application areas
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.
8. Tool support using other tools
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.

6. 2. EFFECTIVE USE OF TOOLS: POTENTIAL BENEFITS AND RISKS
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.
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.

7. 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);

8. 3. INTRODUCING A TOOL INTO AN ORGANIZATION
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!

9. 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?).

10. 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.

11. TERIMAKASIH