Matt Archer's Blog

  • New Book

    I'm working on a new book. View the home page for the 'Tips for manual testers working in an agile environment' book
  • Enter your email address to receive notifications of new posts by email.

  • Subscribe

Rational Functional Tester: Planning Test Automation

Posted by Matt Archer on October 28, 2008

This post is part 1 of a series of 5 posts about test automation with Rational Functional Tester.  I originally created the material as a white paper in 2004 when I was coaching a project that was new to GUI-level automation and also to RFT.  I recently discovered it during a clean up and whilst some on my ideas have changed over the past 4 years, I’m happy that most of it still holds up as good advice.  Maybe one day I’ll update it.

The other posts in this series are (Part 2) Test Automation Architecture, (Part 3) Creating Automated Tests, (Part 4) Reviewing Automated Tests and (Part 5) Using and Maintaining Automated Tests.

Planning Test Automation

Capture Project Background
Start the automation development effort by understanding the project background.  Pay particular attention to the way that the application is currently tested and how the testing process relates to other disciplines within the software development lifecycle, such as requirements, coding, and configuration and change management.  Review any existing process documentation and consider augmenting the process with additional information that describes how test automation will be incorporated.

Scope the Automation Effort
Many automation development efforts fail to meet project expectations due to poorly managed scope and a lack of clarity and visibility around the motivation for adopting automated testing.  Spend some time analysing the problem behind the motivation to ensure test automation is the correct solution.  Communicate the expected benefits of automated testing in terms of the problems it will solve.

Sometimes the tests to be automated to already exist in terms of manual test scripts.  Before the automation development effort begins, it is important to agree what will be automated, if any.  This can be defined using a variety of methods.  Some project teams find it easier to express the scope of the test automation in terms of existing manual test scripts, simply by providing a list of existing manual script names or IDs.  Other project teams find it easier to express the scope of the test automation by subdividing the application into different areas of feature-set and identifying which areas will be automated.  Either way, it is a good idea to agree what will be automated before starting the automation development effort.

Collate and Refine Manual Test Scripts
If a collection of manual test scripts already exist, there is a possibility that over time they have grown organically and become unsynchronised with the application requirements.  Review the existing manual test scripts against the application’s requirements and remove any duplicate or redundant tests.  Ensure that the purpose of the test is unambiguous.  Furthermore, ensure that any data and information exchanged between the tester and the application is well understood.

To support maintainability and reduce intellectual complexity, an automated test should be atomic and avoid unnecessarily long sequences of user actions and verification points.  To maintain a one-to-one mapping between manual test scripts (which should be kept up-to-date, even when the test automation exists) it may be necessary to divide a single manual test script into one or more smaller tests.  Provide any new tests with a unique name or ID and document the test steps and verification points appropriately.

Identify Test Suites
It can be useful to arrange the refined manual test script into a number of test suites.  A single test suite should focus on a specific area of the application and state the sequence in which the containing tests are executed.  By cleverly sequencing tests within a test suite, different tests can support each other.  That is to say, an early test in a test suite can manipulate the application into a particular state that can be used as the foundation for a subsequent test in the test suite.  Test suites can also be used to manage the scope of the automation development effort and be used to focus the test team on a specific subset of the tests to be automated.


6 Responses to “Rational Functional Tester: Planning Test Automation”

  1. […] Rational Functional Tester: Planning Test Automation […]

  2. […] Rational Functional Tester: Planning Test Automation […]

  3. Inder P Singh said

    Other possible tasks that could be done during test automation planning include:
    1) Planning test data generation, maintenance and control
    2) Planning configuration management of test cases, test scripts etc.
    3) Estimation of all the planned tasks

    Inder P Singh

  4. Thanks for your comment Inder, I agree, the 3 things you mention should all be considered during test automation planning, especially configuration management as I’m a firm believer that if you’re going to write code to test code (which is what automated test scripts ultimately are) then you should treat it with the same care as if you were writing the software itself.

    I find estimating test automation tasks interesting because it can be relatively easy to estimate how long it will take, assuming everything goes to plan, but it’s all those unknown GUI components that looked innocent at the outset but turned out to be really tricky to automate that can end up invalidating the estimate.

    I’ve seen projects waste huge amounts of time trying to automate aspects of an application that really should never have been attempted in the first place – often losing out on more valuable automated tests as a consequence. For this reason, I try to be strict with test automation estimates and often treat then as a maximum amount of time to spend in a given iteration rather than a guide, as I’ve found that tester’s who like automating will quite happily automate all day, every day, which is rarely good for a project.

  5. Inder P Singh said

    Thanks for the additional tips!

  6. Abitha said

    Hi Matt,

    Can you throw some light how “configuration management” can be done in RFT ? Have you already written about that, if so please direct me to that page!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s