Path to full test automation
While most teams strive toward automation of repetitive tasks, there remains for many of these teams a continual struggle to achieve effective test automation. With many tools and techniques available, the abundant options too often lead to confusion. It is possible to minimize frustration and increase motivation for test automation by seeking and applying effective approaches.
This paper presents two shortcut methods for approaching test automation.
SHORTCUT #1 | SHORTCUT #2 |
---|---|
Write the code. | Describe test cases as test labels. |
Write the automated tests. | Write code that satisfies the test cases. |
Supplement with additional manual testing, as necessary. | Write tests that correspond to each test label. |
The first method involves building an automated test suite before running any of the test cases manually. Though it does not provide many of the benefits of the test-first approach, it significantly reduces the effort necessary to build and maintain a test suite. We conclude that this method is a good starting point for engineers who have been using a test-late method.
The second method involves defining test cases only with descriptions before writing any code. We acknowledge that it does not improve system design as much as the test-first approach. However, it substantially increases development efficiency by providing much quicker feedback and increasing the quality of the test suite itself. The second method is also an excellent preliminary step toward the test-first method.
A word of caution: These shortcuts should be considered as intermediate steps on the way to complete test automation.
Moving forward with a new understanding
As you consider how best to pursue test automation with your team, keep the following key points in mind.
A serious commitment to test automation can have a positive impact on testing effectiveness and benefits of the resulting test suite.
Deferring the creation of automated tests in a software development lifecycle to any point after manual testing of code changes is highly ineffective—and relatively unproductive. Typically, such an approach results in an automated test suite that has a slight positive effect on the quality of the software.
Writing automated tests in a software development lifecycle before manual testing can significantly reduce the overall effort for ensuring high quality in the implemented changes.
Defining the test cases before writing any code will increase the number of benefits that result from an automated test suite.