July 26, 2012

6 Pitfalls to avoid when introducing Test Automation – Part 1

Introducing test automation is an exciting time, however, it is also fraught with danger. Silly mistakes or oversights could cost you dear in future, so you need to make sure you don’t stumble over the common pitfalls early on, and clear the hurdles just perfectly.47-automated testing pitfalls

There are 6 very common stumbling blocks when it comes to test automation. The first 3 of these we will cover are Involvement, Preparation and the Selection of Tools at your disposal.

1: Involvement

Put simply, you should increase the involvement of more stakeholders. Automating testing takes both time and effort. Just like any other development project, it should be seen to have goals, timetables and resources.

The key to success is to involve not only testers but also management, developers, business specialists and requirements specialists. Doing so will also lead to a greater and more widespread acceptance of the demands that test automation puts on the organization.

Developing automated testing takes time and it is common that the organization might lose interest and think it is an unnecessary activity which requires precious time and resources, resources which could better be used for other things. Be sure to promote your progress and thus the benefits of automation.

For the same reason, it is also important to carefully select which tests should first be automated. Start by picking a few “low-hanging fruit” in order to elicit a positive attitude about the investment in test automation. This also ensures that the automation project is not viewed as a threat but as a resource that the entire organization can benefit from.

2: Prepare and prepare some more

Careful preparation and a feasibility study are absolutely necessary before attempting to choose an automation framework and appropriate tools. Only after you have identified your needs in an accurate and succinct manner should you select the tool which best solves the problems.

Some of the issues that the feasibility study should cover are:

  • What is the purpose of automating?
  • What goals are we expecting to achieve?
  • What kind of tests should be automated?
  • Is there support for test automation built into the applications that are to be tested?
  • If not, it is possible or cost effective to build it in?
  • Which test methodology is best suited for the application under test?

It is also wise to carry out a proper cost-benefit analysis which will show if and when an investment is profitable in cash terms. Present calculations together with the expected effects to management. Eventually you will probably reach the conclusion that although automated tests do not provide savings to any great extent in and of themselves, there are other advantages which justify the investment.

Examples of these advantages include:

  • Possibility to make informed decisions before a release/deployment.
  • Greater security for developers who thanks to automation can feel more secure when making major changes in the code.
  • The ability to test and get feedback on the outcome after each build.
  • The possibility to test with the wide variety of test data to improve test coverage.

3: Choose the right tool

Choose the right automation tool, as it is what you will be working with! There is a huge range of automation tools to choose from, ranging from free open source tools to commercial tools.

Open source tools have the advantage of being free or at least very cheap to obtain. However, do be aware that maintenance, updates and customizations can be very expensive. Support is not included, so you often have to spend time searching for information on forums. Of course, some open source tools are very unstable and much time might need to be spent on establishing a stable environment.

The commercial tools will in most cases provide a complete and stable framework and usually come with very good support, however, this may come at the cost of requiring a sizable initial investment.

Evaluate the different options thoroughly to find the tool best suited for your application and for your organization. Before deciding which tool to use, it is important to evaluate the tool in your organization.

Perform a ‘proof of concept’ to ensure the tool gives sufficient support to the application to be tested. Such a ‘proof of concept’ may include the selection and automation of a number of representative test cases in order to ensure that the tool works in practice and meets your specified requirements.

Finally, ensure that you choose a tool which supports a common script-/programming language. This increases the possibility of searching the web for solutions to any problems that might arise as well as making it possible to bring in outside help if needed.


Read our articles about How to deal with constant changes in automated testingAutomated testing in Agile Projects, and You can’t work Agile without automated testing.

Share article