Introducing a Tool Into an Organization

INTRODUCING A TOOL
INTO AN
ORGANIZATION
By Graham et.al
(2006)
UNIVERSITAS SULTAN
SYARIF KASIM RIAU
Rakhes Leo Putra
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-
Program Studi S1 Sistem
Informasi
Jurusan Sistem Informasi
Fakultas Sains dan
Teknologi

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 cost- effective to improve testing practices rather than to try
to find tools to support poor practices. Automating chaos just
gives faster chaos!
1

Of course, we can sometimes improve our own processes in
parallel with introducing a tool to support those practices and we can
pick up some good ideas for improvement from the ways that the tools
work. However, be aware that the tool should not take the lead, but
should provide support to what your organization defines.
The following factors are important in selecting a tool:
 assessment of the organization's maturity (e.g. readiness for change);
 identification of the areas within the organization where tool support
will help to improve testing processes;
 evaluation of tools against clear requirements and objective criteria;
 proof-of-concept to see whether the product works as desired and
meets the requirements and objectives defined for it;
 evaluation of the vendor (training, support and other commercial
aspects) or open-source network of support;
 identifying and planning internal implementation (including
coaching and mentoring for those new to the use of the tool).

One of the ways to do a proof-of-concept is to have a pilot
project as the first thing done with a new tool. This will use the tool in
earnest but on a small scale, with sufficient time to explore different
ways of using the tool. Objectives should be set for the pilot in order to
assess whether or not the concept is proven, i.e. that the tool can
accomplish what is needed within the current organizational context.
A pilot tool project should expect to encounter problems - they
should be solved in ways that can be used by everyone later on. The
pilot project should experiment with different ways of using the tool.
For example, different settings for a static analysis tool, different reports
from a test management tool, different scripting and comparison
techniques for a test execution tool or different load profiles for a
performance-testing tool.
2

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

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

More information and advice about selecting and implementing tools
can be found in [Fewster and Graham, 1999] and [Dustin et al., 1999]. You
should now be able to classify different types of test tools according to the test
process activities that they support. You should also recognize the tools that
may help developers in their testing (shown by '(D)' below). In addition to the
list below, you should recognize that there are tools that support specific
application areas and that general-purpose tools can also be used to support
testing. The tools you should now recognize are:
Tools that support the management of testing and tests:
 test management tool;
 requirements management tool;
 incident management tool;
 configuration management tool.
Tools that support static testing:
 review process support tool;
 static analysis tool (D);
 modeling tool (D).

Tools that support test specification:
 test design tool;
 test data preparation tool.
 Tools that support test execution and logging:
 test execution tool;
test harness and unit test framework tool (D);
 test comparator;
 coverage measurement tool (D);
 security tool.
Tools that support performance and monitoring:
 dynamic analysis tool;
 performance-testing, load-testing and stress-testing tool;
 monitoring tool.

You should be able to summarize the potential
benefits and potential risks of tool support for testing in
general. You should recognize that some tools have special
considerations, including test execution tools, per-
formance-testing tools, static analysis tools and test
management tools.
You should know the glossary terms data-driven
testing, keyword-driven testing and scripting language and
recognize these as associated with test execution tools.

You should be able to state the main principles of
introducing a tool into an organization (e.g. assessing
organizational maturity, clear requirements and objective
criteria, proof-of-concept, vendor evaluation, coaching and
mentoring). You should be able to state the goals of a proof-of-
concept or piloting phase for tool evaluation (e.g. learn about the
tool, assess fit with current practices, decide on standards, assess
benefits).
You should recognize that simply acquiring a tool is not
the only factor in achieving good tool support; there are many
other factors that are important for success (e.g. incremental
roll-out, adapting processes, training and coaching, defining
usage guidelines, learning lessons and monitoring benefits).
There are no specific def- initions for this section.

Introducing a Tool Into an Organization

Introducing a Tool Into an Organization

More Related Content

What's hot (20)

Similar to Introducing a Tool Into an Organization (20)

Recently uploaded (20)

Introducing a Tool Into an Organization