Read carefully this statement: If your development pipeline does not include any degree of automated testing, you are wasting money. Don’t lose your temper, breathe slowly… Now read that again. Yes: you are losing money. Testing is burning up your budget with each iteration, and, somehow, you are accepting this as “adequate”. I can give you two choices about it: you may find comfort in knowing that you are not alone at all – the amount of manual testing that is still being performed in the industry is astounding -, or you could so something about it.
I will expose three simple points that automated testing surpasses human inquire. And after that, I’ll leave you to make a choice.
First: performing regression tests the old-fashioned way may not cover all possible scenarios. And take note of that “may”, because that’s precisely the key of this issue. “May” or “may not”, because all hand-operated process is not reliable. Humans are prone to errors. Companies tend to mitigate this concern by duplicating: what could slip through the fingers of one operator might be caught by another. You may even add a third redundant check, just to make sure, in the behalf of quality.
If this is the road we are travelling, then every team has two – or three – assigned testers working on their QA. Or perhaps a cross-team pool of testers was conceived to work on different projects at the same time. Whatever the specific choice, you have too many employees engaged on what is essentially the same task. This is not fail-safing, but profit squandering.
How long does your proofing phase lasts? A week? Two? How many additional environments do you need to run those checks? Testing, pre-production, demo… Is your testing team applying regression more than once on each environment for some reason? Must specific data-sets be provided for a release inspection? How much time does these data-sets take to be prepared? Every additional step, every extra degree, is a potential delay to your time-to-market. What happens when something does not fit the requirements? A bug found on the fourth day of testing means that the whole release goes back into the board, and must be re-scheduled. This is the second concern I am raising from not having automated testing.
Covering the basic steps of your product with automated testing increases your reaction span to trouble. And if you’ve been long enough in this business, by now you know that there is always trouble of some sort. Taking a big load off the shoulders of your QAs will increase the amount of effort that they bring into the table, so they can focus on the specifics instead of the routine.
I will now make my final point, the one I believe that hurts the most: manual testing makes the effort of your specialists worthless. Sooner or later a new release will be created, and they will have to start from scratch. Their work is not creating any added value at all. Knowing that, like mindless drones, they have to do the same ever again and again damages their morale, and quickly “burns up” any employee. Testing should be increasingly automated because of this: with each iteration a bigger percentage of the functionalities are covered. Each new automated process is 100% reliable, repeatable, and improves your safety net.
If you’re with me so far, this leaves you to make a choice. This is usually when all the doubts and excuses pop up. “Requires specific workers”. “No technology covers all of my needs”. “It’s too late to start now with something new”. Well, the fact is that you don’t have to go fully automated on your first sprint. Start small, then go big. That’s how business is done and how success is achieved, isn’t it?
Also published on Medium.