The 10% Rule To Clean Up Your Automation Suite
Is your automation suite a little over cluttered? Consider the 10% rule
Break down traditional QA silos by empowering developers to own quality checks.
Automation, it seems we can’t get enough of it, right? Teams have been convinced that a bunch of automated scripts are the way forward. And while that statement is partly true, it can become too cluttered.
Merriam-Webster defines “automation” as the following:
If we take the first passage: “the technique of making an apparatus, a process, or a system operate automatically.” Applying automation to our tests saves a great deal of manual labour when it involves repetitive steps. Regression testing is a prime example of a process that is commonly automated. So how much is too much? And is there even a thing as too many automated tests?
There’s a popular expression amongst software development teams that reads: “Keep It Simple Stupid”, a.k.a “KISS”. These four words are able to explain a clear objective wherever it’s applied. So how does that relate to automation tests?
Before you break ground, there’s usually a planning phase to help guide your initial steps. The said plan may include the desired programming language, parallelisation, third-party integrations, or deploy pipelines. And you most probably have an idea for the scenario-flows you plan to create first.
The problem comes later down the line after having achieved that initial setup of the automation suite. As time progresses, the initial set of tests no longer feel satisfactory. Those contributing to its maintenance begin to notice the gaps. The thought of “what if” enters their mind and begins to linger. “What if that feature breaks because of …….”. There are copious reasons that could be attached to the end of that sentence.
As engineers, there’s a tendency to sometimes over-engineer. This desire to over-engineer comes from the right place of wanting to do well. But when applied prematurely it can create more damage.
By overlooking KISS, we forget to consider the “Disadvantages of Automation”. Before we know it, we’ve introduced five new test scripts. If those five tests combined only provide 1% of the total value, then you should question their need when comparing it to a single test that provides 5% of the value to the overall suite.
The 10% Rule isn’t something I’ve read involving automation before, so this may well be a first. Automated tests should help provide value. Your time and mental capacity shouldn’t be occupied by test scripts that exist as a result of over-engineering. Go into your automation suite, and look at the test scripts that you know barely assert anything.
The aim is to identify 10% of your test scripts that can be let go. You may surpass the 10% mark, or fall slightly under, but being able to identify and remove those pointless tests should help to:
- Reduce total runtime.
- Decrease maintenance effort.
- Free up your mental capacity.
- Remove clutter!
If you’re struggling to weed out the fluff from the gold, ask yourself the following:
- Does the automated scenario involve a high engagement feature?
- Does anyone actually use this feature?
- Is there a test that is similar to this one? And can they be combined?
Remember that less is more. You want to give attention to the set of tests that bring value. You don’t want to spend 30mins± constantly maintaining fluff.
To conclude, there is such a thing as too many automated tests. Apply the 10% Rule to identify and remove the clutter that only adds noise. An automation suite with 100+ test scripts instead of 81, may look impressive on the outside, but the required maintenance doesn’t deserve your time.
Like what you’ve read? Clap, check out my other articles. Stay tuned for more!
