An often debated question is whether “manual testers should learn programming and be able to code”. While there is no unanimous answer to this question, let’s look at this debate slightly differently. While at the very core we will continue to need both manual and automation testers and each of them bring in their unique value propositions, it is definitely going to be beneficial to expose both groups to what the other group is working on. Doing so, is helpful in several ways including:
Join one group to take on relevant portions of the other group’s work
When the two groups of testers work in isolation there is a lot of wasted effort, disconnect and more importantly lack of a concerted testing effort in building the right test coverage. If the manual testers are exposed to what the automation testers do and vice versa, apprehensions if any are reduced and in the process, they are learning newer things they can take on, on their plate.
Load balancing the team’s tasks
The ramp up we talked about in the previous point, whether or not it is helpful on an ongoing basis, definitely comes in handy in situations where one team is overworked. For example, typically a lot of the automation testing services heavy lifting may be done earlier in the testing cycle, while in the later stages, they are being run in an unattended mode calling the tester’s attention primarily for results analysis. In such situations the automation tester who is trained to help with manual testing as well, is able to bring in much better value to the team and to the product under test.
Developing a sense of appreciation for each other
Cross ramping of testers, if not for anything else, should be done to build appreciation for each other’s role. Automation testers, sometimes tend to look down upon manual testers, while manual testers may have their own inhibitions about test automation. Such a cross exposure, builds a great sense of appreciation for each other promoting better collaboration in the testing team.
Easier to understand and create automated test scripts
It will be simple for a tester to write automated test scripts if they are skilled in programming, which is required for Continuous Integration (CI). Automation is even possible for UI, API, and performance testing. This quickens the testing process and gives the tester more time to concentrate on exploratory testing to find new problems. The ability to create automated scripts is only part of the puzzle; the SDET (Software Development Engineer in Test) can set up and deconstruct their test harness and test cases by understanding the methods and functions created by the developers. As a result, QA specialists are freed up to concentrate on other crucial aspects of testing since they no longer need to recreate these functions themselves.
Software testers do not need to be skilled programmers, but the value of these record/playback tools is limited by the robustness and complexity of the application. Some tests are difficult to fully automate, and when the app is updated, they frequently fail. Coding experience helps testers overcome both expected and unexpected difficulties.
Who will test the code that testers write now that they are learning to code? is a crucial question that is raised. Can they test their own code objectively in the same way they test developer-written code?
One issue we encounter is that programmers test using the way they intended the software to operate in the best-case scenario because they already have an idea of how the application will function. People in the real world disregard what seems to be the “correct” way to use an application and instead discover problems by using it in novel ways. It is preferable for a software tester to find these errors than for your customers, and devoted testers have mastered the art of breaking software.
With the increased acceptance of Agile in the software development world, the lines between a developer and tester, a manual and automated tester are all blurring. While one may not completely gobble another, it is becoming increasingly important for one to understand and train on the other, to step in as and when required.
As for the manual tester, automation is no more a long shot. With versatile frameworks that are shaping up (both as commercial out of box solutions and customized open source solutions), test automation is well within the reach of manual testers, who have no prior experience with programming. Their functional product knowledge with an appreciation for test automation can easily help them take on test automation, ably supported by the automation engineers.
When this happens, there is no longer the debate of whether manual testers should learn programming or whether automation is reserved to a select few. Manual testers have now expanded their impact and taken on relevant portions of test automation still letting their automation counterparts, drive tasks they are best at.
So, let’s shatter any inhibitions and make it an open swing door that exists between manual and automated testing.