Improving the maintainability of automated tests

Posted on by

Introduction

Lots of companies, and teams have a burden of unreliable, problematic, automated tests that are troublesome and time-consuming to maintain. We need ways to address these poor-quality tests, ways to recover from the current unhealthy situation to a healthy environment where the tests are reliable, trustworthy, and easy to maintain as the underlying software changes.

For new test automation projects and teams, with the ‘luxury’ of starting fresh, you might also find these topics salutary, advance warning of a situation you might end up in if you don’t apply good test automation practices from the outset. Don’t say you weren’t warned 🙂

Here are the initial topics I’m going to cover

  • Re-engineering and Refactoring automated tests
  • Understanding Critical Success Factors for test automation
  • Applying Design Patterns
  • Design and Structure your test automation code
  • Coping with large volumes of ‘legacy’ and ‘broken’ tests (including record & playback)
  • Remove boiler-plating or dumbed-down interfaces
  • Making the interaction with web pages resilient and robust (using IDs, working with developers, etc).
  • Don’t be fooled (again) avoid being beguiled by automated tests
  • Sunk by dependencies (e.g. on live back-end servers). Coping with Environmental Issues.
  • Slow tests
  • Modelling Techniques
  • The intersection of automation and in-person testing
  • Three possible outcomes of a test
  • Writing readable code
  • Stringing tools together
  • Patterns for: Data creation, reuse, sharing and cleanup
  • Designing tests to safely run in parallel

One of my aims is to create a useful, succinct guide to help you, and others, create and establish useful, readable and maintainable automated tests for your software projects. I’m drawing on the work, experience and expertise of various people in the software testing communities, and welcome your input and ideas.

2 thoughts on “Improving the maintainability of automated tests”

  1. Hi Julian,

    I was wondering what you thought of the following blog entry;

    http://sellotapetest.blogspot.com/2010/12/introducing-test-automation-fire.html

    I came up with this concept a couple of months ago. My aim too is to find the “secret” of successful test automation, something which appears to very hard to capture.

    [Julian’s Reply] Thanks for the link to your blog. I agree test automation needs to be scalable, stable and maintainable to varying degrees depending on the needs of the respective project e.g. I can create a useful automated test that’s intended to be short-lived which wouldn’t need to be as scalable as high-volume automated tests for a million-user reliability performance test we intend to make part of a core regression test suite. At the risk of stating the ‘obvious’ you’ve not mentioned correctness or potency of the tests. I could meet your requirements by writing a ‘return true’ test, but it wouldn’t test the code/application for correctness and it would be an impotent test. I assume you’re assuming the reader takes these as a given; however since you’re going to the effort to describe qualities that others might assume, I’d like to explicitly mention these 2 additional tenets to your trio.

    Thanks again for the comments. I hope you write some additional posts on your blog soon.

Comments are closed.