Finding the right balance between manual software testing and automation is all about optimizing manual efforts as much as possible at any given moment.
Getting started may be as simple as employing a test utility that removes or reduces a repetitive manual task. Another step in the right direction could be creating a risk-based test case hierarchy and using it to limit manual testing to that which delivers the highest return on investment.
No matter how you proceed, you need the right tool for the right job.
Several considerations should go into selecting software test automation tools, including your organization’s:
- Business objectives
- Portfolio and technology
- Technology strategy for the coming years
- Team’s capabilities
- Testing objectives
- Toil (where you are spending time with manual testing today)
At SQA, part of our approach is typically completing a discovery session in which we uncover answers to these questions for our clients. Otherwise, simply picking a popular tool might not meet the need.
Keep in mind that there is a lot of variation in automation tools. Some are very specialized to do one thing. Some are designed to do everything. Be sure to understand what tools you already have in-house, and what is your particular need.
Consider code versus low-code or no-code
Code-based automation solutions are often the most extensible, adaptable, and maintainable tools. However, they can come with a higher technical “cost to entry”.
New low-code and no-code test tools on the market are easier to maintain and adapt than previous-generation tools. They can also temporarily increase the efficiency and value of manual testers. So, as a bridge to more software test automation, they can be an attractive option — as long as their pros and cons are understood:
- Pros — They require minimal to moderate technical knowledge to get started. Also, many new tools have powerful features out of the box, which can be a plus if they work with your technical stack and code base.
- Pro/Con — They do not remove test automation complexity, but rather abstract it away from the tester. Some technical resources still must be available to the automation team. Also, their underlying code base can be accessed to extend capabilities; however, doing so defeats the low-code/no-code value proposition because it re-introduces complexity.
- Cons — They are not as reliable as code-based tools or the best human test analysts, and they ultimately may do little to develop your testers’ basic automation skills.
Sunset old tools strategically
It makes practical sense to leverage any automation tools you already have as much as possible. But, be sure to sunset any tools that do not provide the efficiency, scalability, and velocity you need. Don’t buy into the “sunk cost” fallacy of sticking with older-generation tools and less-maintainable approaches just because you have made a sizeable investment in them over the years — because there are ways to move from old to new technology and approaches without throwing away your investment and starting over.
A highly effective approach is a “just-in-time” replacement strategy: Rather than sunsetting a suit of test cases all at once, sunset individual scripts when the code segment they support is replaced or rewritten. This might mean running an increasingly growing new-generation test suite in parallel with an ever-shrinking legacy test suite, but eventually the legacy suites will retire themselves.
For more information about introducing automation into manual testing, read the guide, Software Testing in IT: How to Bridge the Gap Between Manual Testing and Automation