Home > Articles > Programming

This chapter is from the book

29.9 Flexibility of the Automation System

Mike Bartley, United Kingdom

Lecturer and consultant

We developed our test automation system ourselves and devised ways to adapt our automated testing to be more efficient in ways that we have not seen elsewhere.

Because we had already developed an inhouse software version control and build system, it was fairly easy to integrate our automation tool with our build system. This made our testing more efficient because we could selectively test only those modules that had changed, as shown by our source code dependency tree. If nothing that a particular test depended on had changed, that test would not be executed. This dramatically reduced the build and cycle time and thus allowed us to put in place continuous integration of builds and tests. We did keep an option that forced all tests to rebuild and run if we wanted to run a full regression test.

We made it easy to remove tests from the test suite when a test needed updating because of changes in the software it was testing. Although we were then cutting down on the test coverage because the test(s) were not run, it meant that the maintenance of those tests didn’t have to be done immediately, thereby stopping the rest of the test suite from running.

We extended this to a way of “banning” specific tests for various reasons:

  • The software has changed, but the tests have not yet been updated.
  • A test is known to be giving a false failure (i.e., it fails but it should pass).
  • A test is not restoring test machines to a known good state.

This idea proved to be a major benefit to our efficiency.

  • + Share This
  • 🔖 Save To Your Account