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