‘Can’ and ‘Should’ a Manual Tester Automate?

“In an age of specialization people are proud to be able to do one thing well, but if that is all they know about, they are missing out on much else life has to offer.” Dennis Flanagan

The late Dennis Flanagan, the editor of Scientific American for over 37 years, had probably seen his fair share of free thinkers and eclectic geniuses and in that light, probably knew a thing or two about the pitfalls of narrow specializations. The world of software development and software testing, though, has often sworn by the value of being a specialist, or a “domain expert” if you prefer. When you enter spaces like Automation Testing though it may be time to challenge some of these beliefs. We have spoken in the past about whether “Test Automation is a task for Developers or Testers” – one way to look at the specialization v/s multi-tasking debate. In this post let’s look at another angle – should those identified as “Manual Testers”, the specialists in executing test cases, take on the task of automation testing?

We have spoken often of the business reasons to automate your software testing. The need of the hour is for more releases, of an extremely high quality, following close on the heels of each other. Faster time to market and higher quality is the mantra. This means a much greater pressure on software testing and a reduced window of time in which to accomplish that testing. It is also a fact of business that resources are constrained and skilled resources are not easily available. These are all good arguments to have multi-skilled resources that have the capability to address a variety of tasks effectively and efficiently – in other words, to have your manual testing “specialists” take on automation testing tasks too.

So, there is a business reason to encourage such flexibility. But, is there any real value, any functional benefit to doing so? Our vote would be a definite “YES”. Consider this – the primary task of the testers is to “break” the product. Their efforts are focused on finding the problems before the customers find them. To this end they are intimately familiar with the product, it’s use-cases, the stress points, required performance standards and, also potential points of “breakage”. The most critical responsibility of the tester is to simulate all the ways in which the end-user would use the product. For automated testing to be effective, all this knowledge has to mandatorily be built into the suite and this is where the knowledge of the manual testers can make a crucial impact. That apart, automating takes time and effort and in that context, the smart money is always on picking those tests to automate which can deliver maximum bang for the buck – the most likely use-cases, the critical points of failure, and the most “at-risk” scenarios. The tremendous value the manual testers can add to the process of making this selection is very apparent, and desirable.

It would thus appear that a strong case can be made for manual testers to contribute to test automation. That said, though, what could be the challenges in making this work? Well, the chief challenge has usually been the lack of coding/programming skills among the manual testers. Building test automation suites calls for a certain level of scripting knowledge – not a skill commonly found among testers. This is not necessarily such an insurmountable hurdle anymore, though. Long-time followers of our blog probably know where we are going next – yes to “Scriptless automation” using tools like our very own Qualitia for Selenium and QTP. We have mentioned in the past how this approaches does not call for programming skills. Scriptless automation, or codeless automation, works on “building blocks” or code assets. Those building the suite can build tests that can be selected and edited without coding. Such a scriptless automation tool gives manual testers the flexibility to easily automate. This would suggest a “best of both worlds” option – get the manual testers to contribute to the test automation without being constrained by their (lack of) coding skills.

In this specific context, at least, we would have to come down on the side of those preaching “flexibility” rather than “specialization”. We believe that there is good reason to do so – even if we are not quite as vehement in that belief as American science fiction author Gregory Benford who said, “I’ve always felt that specialization is best left to the insects.”



Monica Paul