Can and Should a Manual Tester Automate?
Can and Should a Manual Tester Automate?
The world of software testing swears by the value of being a domain expert—but when it comes to automated testing, it may be time to challenge some of these beliefs.
Join the DZone community and get the full member experience.Join For Free
Open source vulnerabilities are on the rise. Read here how to tackle them effectively.
“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, probably saw his fair share of free thinkers and eclectic geniuses and in that light and 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 “domain expert.” 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. 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, its use cases, the stress points, required performance standards, and 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 that 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 and programming skills among the manual testers. Building test automation suites call for a certain level of scripting knowledge, which is not a skill commonly found among testers. This is not necessarily such an insurmountable hurdle anymore, though.
We have mentioned in the past how the scriptless automation approach 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. A scriptless automation tool gives manual testers the flexibility to easily automate. This would suggest a best-of-both-worlds option that gets the manual testers to contribute to 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 a 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.”
Opinions expressed by DZone contributors are their own.