Chapter 6 – 6.3 – Introducing a tool into an organization

  1. State the main principles of introducing a tool into an organization. (K1)
  2. State the goals of a proof-of-concept or piloting phase for tool evaluation. (K1)
  3. Recognize that factors other than simply acquiring a tool are required for good tool support. (K1)

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

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

6.3.2 Pilot project

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.

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

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

More information and advice about selecting and implementing tools can be found in [Fewster and Graham, 1999] and [Dustin et al., 1999].

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *