How to Develop an Automated Testing Strategy
It's not news that test automation reduces QA costs and speeds up deployment, but make sure your team is doing test automation right for maximum benefits.
Join the DZone community and get the full member experience.Join For Free
In QA, testing automation is seen as one of the biggest promoters of speed. Testing automation is critical to maintaining quality during fast release cycles. Software tools can run automated scripts that help testers reduce repetitive tasks and shorten the time it takes to produce quality testing results.
The speed and reliability of automated testing has made it an essential DevOps practice. It keeps software development processes agile and lean. Automated testing is on the rise: there has been an 85% jump in test automation across all industries over the past two years. New techniques like predictive analytics and self-learning platforms are just getting started. While new technologies allow teams to reduce the overall number of test cases—instead of repeating them—many teams still struggle with the earliest capabilities of test automation: repetition and regression testing. In fact, 41% of IT teams self-identify as not having the right automated testing methods in place. That’s a shame, since test automation reduces QA costs. Unfortunately, teams still struggle to realize those benefits because of the difficulty of writing scripts with longevity and maintaining them over time.
Here are some important steps and requirements when developing a test automation strategy that will increase throughput and free up teams to focus on quality enhancements that drive revenue.
Choosing the Right Test Cases to Automate
Writing automated test scripts can be time-consuming. It’s not possible to automate everything, so the key to getting maximum ROI from time and money spent on automation is to develop a strategy that increases velocity in the short and long term. Keyword-based tests allow QA engineers to boost their ROI on time spent. These tests are a lot faster to write because they run on keywords understood by the app and the automation software instead of using a complex scripting language.
But because keyword-based tests must be maintained and updated over time, you have to be just as smart about choosing which test cases to automate:
- Repetitive tests.
- Large data sets.
- High risk.
- Tests for different browsers or environments.
Overall, the test cases that should be automated will depend on the software and on the team’s capabilities but the one constant is identifying those that will heighten quality while freeing up time. Writing test cases for base functionality allows for more thorough manual exploration of new features.
Running Test Automation Throughout a Sprint
Testing “early and often” is the biggest tenet of QA in an agile team. The goal for speedy releases in agile is for everyone to be finished with a sprint at the same time—QA wraps up at the same time as development.
Of course, this isn’t always possible, even in the leanest of teams, but by planning test automation strategically, it is possible to approach this goal.
Before the Sprint
High-level automated tests can be written using keywords that correlate with business requirements. This allows testing to begin before the development of new functionality, so long as each keyword corresponds with a known command. Keyword-based tests can be as simple as “login, upload a file, logout.” These should be task-oriented, and not focused on the details.
During the Sprint
As soon as new functionality is built, unit testing comes into play. Unit testing simply means testing one unit (an even smaller breakdown than function or feature) at a time, and it’s an important method to employ when attempting to really extract value from automation. Detailed scripts can be written one unit at a time, as the code becomes available from the development team.
After the Sprint
In the event that testing does start to lag a sprint behind development, automated testing can help QA catch up. This is when an external solution can really come to the rescue. Having off-site QA engineers develop scripts for past sprints can bring in-house teams together. The importance of that can’t be overstated. When teams are working on the same sprint, they can speak the same language and help improve the testability of the product as it is being built.
Developing Automated Tests That Last
Automated testing can get messy. Tests that were once relevant can become useless. Individual scripts can have too many validation steps, convoluting the most important results. If choosing test cases is the “what” and developing and running scripts continuously is the “when,” then creating test cases built to last is the “how.”
Writing Small Test Cases
Automated test cases should be small. With scripted manual testing, it’s common to write dozens of steps to perform a single critical action. In fact, many manual scripts always start from the top: with logging in. They detail all the navigation steps before stating the core action to be tested.
With automated scripts, however, it’s necessary to break things down into sequences of steps and test those sequences individually. So, navigation would come separate from interaction or task completion. Underwriting instead of overwriting scripts protects them in the event of inevitable app changes. The more broken up and small individual tests cases are, the less likely they will have to be tossed out or rewritten. Instead, it will be easier to target the few test cases that are affected by changes to the app.
Writing Test Cases Independent of UI
The second way to keep automated tests flexible is to not make them dependent on UI. This is a lot easier when using keyword-based tests as opposed to a scripting language like JScript. Whenever possible, tests should be written in action terms supported by backend functions in a domain language approach, rather than using the name of UI elements or pathways that may change as the creative process moves along.
This is particularly important for agile teams writing scripts for the current sprint, because then app changes aren’t a case of the script becoming unusable in the future, but of being unusable now.
Automated software testing is only as revolutionary as it’s designed to be, so any time spent strategizing automation efforts is time well spent. The key is to identify test cases that will stay relevant over time and write scripts in a way that protects them from inevitable change as much as possible. Undoubtedly, test automation is an important skillset for QA engineers today.
Published at DZone with permission of Dayana Stockdale, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.