The document discusses tool support for software testing. It describes different types of testing tools, including tools for test management, static analysis, test specification, test execution, performance and monitoring, and specific application areas. It also discusses effectively using tools by outlining potential benefits like reduced work and risks like unrealistic expectations. Finally, it provides guidance on introducing tools to an organization, including running a pilot project and factors for success like training and continuous improvement.

1. TOOL SUPPORT FOR TESTING
Referensi Graham et.al (2006)
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Presentation of Jeri Handika
TESTING IMPELEMENTATION SYSTEM
Program Studi S1
Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau

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

3. CONTENT
 TYPES OF TEST TOOL
 EFFECTIVE USE OF TOOLS: POTENTIAL
BENEFITS AND RISKS
 INTRODUCING A TOOL INTO AN
ORGANIZATION

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

5. 2. Tool support for management of testing and tests
Whatdoes'testmanagement'mean?Itcouldbethemanagementof
tests’oritcouldbe'managingthetestingprocess'.Thetoolsinthis
broadcategoryprovidesupportforeitherorbothofthese.The
managementoftestingappliesoverthewholeofthesoftware
developmentlifecycle,soatestmanagementtoolcouldbeamong
thefirsttobeusedinaproject.Atestmanagementtoolmayalso
managethetests,whichwouldbeginearlyintheprojectandwould
thencontinuetobeusedthroughouttheprojectandalsoafterthe
systemhadbeenreleased.Inpractice,testmanagementtoolsare
typicallyusedbyspecialisttestersortestmanagersatsystemor
acceptancetestlevel.

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

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

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

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

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

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

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

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

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

15. 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!

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

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

18. Slide Title
Product A
• Feature 1
• Feature 2
• Feature 3
Product B
• Feature 1
• Feature 2
• Feature 3