by Nadine Parmelee, Senior Quality Assurance Engineer
Automated testing is a great tool and can be a tremendous asset to a development project, but it can also be a great effort and a money waster when it isn’t properly planned. There are almost as many ways to set up an automation plan as there are tools for automating. How a test team decides to utilize automation will depend in part on the complexity of a project, the expected longevity of a project and an evaluation of how to get the most value from the automation investment. Some teams use automation to create test data; others to run manual tests that are data intensive; still others use it for regression testing purposes. Deciding how best to utilize automation is the first step to creating a better testing process. The automation effort should enhance your overall testing effort and free resources from the most repetitive testing tasks enabling the project to be tested more thoroughly. Here are some of the most basic yet key elements of a good automation plan:
- Planning when to start automating
- Deciding which tool to use
- Choosing which manual tests to automate
- Designing your automation framework
- Dedicating resources to running and maintaining the automated tests
In this series, we’ll begin by discussing when to start creating your automated tests. If you start your automation efforts too early, you risk negating the benefits of the automation effort because of the additional time you’ll spend updating the scripts or automation framework due to project changes. Timing is always a balancing act: the times when you’ll most want to start to utilize automated testing are likely the times when demands on your resources will be greatest. Here are some guidelines for knowing when to begin creating automated tests:
- Manual tests are robust and well organized
A strong, manual test script architecture will lend itself to creating a strong automation architecture. Ad hoc testing will lead to ad hoc automation tests, which may not be as useful as well planned tests.
- Application GUI is fairly stable
If you are starting with record/playback automation, the stability of the GUI (graphical user interface) becomes even more critical. If your development team is still designing the user interface (i.e., where different fields go, what they will be called, what types of controls will be used for each field) your automation tests are going to be playing catch up with the changes.
- Application is structurally sound
Every automated test failure requires some analysis to see if the application has a defect or if the test needs an update. The time required for these analyses can really add up especially when the overall framework of the application is not completely baked.
Later on in this series we will look at ways to determine which automation tool is most useful to your projects, how to determine which manual tests are the best candidates for automation, and ways to build a robust framework that will help you get even more out of your automated tests.