The increased adoption of agile development methodologies has brought with it an increased focus on test automation in testing. Given the need to develop error free and robust software, bring products to market faster and push frequent releases and software upgrades the interactions between testing and development teams have increased considerably. Along with this intermingling, organizations are relying heavily on test automation so that they can test fast and test often. Clearly, test automation is essential to enable development at a sustained pace but does this mean that the role of the manual tester is now redundant? We don’t think so!
While a number of people, mostly non-testers, might believe manual testing is no longer important, the reality is that the role of the manual tester is still relevant, and even important in a comprehensive test strategy. A few days ago, a colleague had posted a question in some LinkedIn groups about the situations where manual testing will continue playing a role? Gauging by the responses it was clear that most of those familiar with testing knew exactly how important the role of a manual tester is. The responses were passionate, detailed and extremely enlightening. Let’s use this post to emphasize the role of a manual tester for those not quite as convinced.
Let’s begin by saying that automated testing and manual testing should not be pitted against one another as both are essential contributors to testing success. For any good test strategy, it is essential to identify ‘what’ to automate as well as ‘how much’ to automate. There are certain testing areas that render themselves wonderfully to automation. Repeatable tests, routine tests such as the regression suite and smoke testing etc. are best automated. Data-driven testing, load testing and static and repetitive tests are also good test automation candidates. The manual testers can play a key role in defining the automation priorities given their intrinsic familiarity with the software, and what it could take to test it.
Having said that, tests that require subjective validation can only be done by humans. For example, the look and feel of an application can only be validated by an individual. Also, application functions that are dynamic and constantly evolving do not render themselves as good automation candidates. Creating automation scripts for them could well be a waste of time. Specific application functions and complex functionalities also need manual testers to test their viability and effectiveness.
Automated tests only perform dictated actions. When testing becomes about discovery, then manual testing becomes non-negotiable. As a case in point, let’s look at a case where the product-under-test is changing incrementally, i.e the code does not fundamentally change from iteration to iteration. Here, it would be the role of those doing functional testing to take a long, hard look at the requirements and define what positive and negative tests should be run. Some of those could be automated and others run manually. The intent of the manual tests could be to test only the code that has been changed since the last iteration. These tests could then be automated if no errors are found in the manual test. The entire automation suite can then be built in such increments – but driven by the solid insights gained from the manual testing.
Since automated tests work in restricted boundaries, they restrict application exploration. In order to build a robust product it is essential that the testing team explores all possible usability scenarios by evaluating “what happens if this is done?” and carve out new testing paths. Since agile development methodologies hinge on the ability to change and adapt those changes, exploratory testing assumes great importance. This testing helps developers and QA professionals gain quality and continuous feedback that allows them to refine their testing practices. By involving human interaction with the software, manual testers are able to assess if the software serves the business purpose – perhaps better than an automated test could.
It is also important to understand that automated testing is great for finding common errors that human eyes can overlook easily. At the same time, automation cannot determine how an app will actually be used. The software can determine if the application functionalities are in place but it cannot determine if the user interface is unappealing or hard to navigate. Manual testing identifies the absence of detailed specifications and helps testers become more creative in their testing efforts which help them find more realistic bugs and faulty functionalities.
Today, testing plays a critical role in software development and clearly, given the speed of deployment testing needs to be fast too. However, a robust strategy cannot be dependent on only one testing format. Sole dependencies on either manual or automated testing will only lead to testing frustration. Organizations have to realize that investing in test automation is essential but at the same time, a focus on manual testing is equally important as automating everything will only add up the costs and waste time and effort. It, thus, becomes important to remember that “if you automate a mess, you get an automated mess”.
(We hope to shortly compile the responses to the Q asked in the LinkedIn groups – do stay tuned if you would like to check those out. There is a wonderful array of responses, and some great information of value to all of us in the testing space.)
