Software test automation is a cool thing. It is what makes the software testing business so interesting. People! Who does not wish to be a hardcore programmers, can jack up their coding skills by building scripts and learning automation tools.
Test automation tools are the all-in-all integrated development environment, the only thing that makes them different from the conventional development language tools is that they operate on one layer plus where the developers work.
So it’s like coding over coding. Something a lot of people still don’t understand.
One other fact that still a lot of testing community nexus are not understanding is that Test Automation cannot survive without strategic manual testing practices. Test Automation practices feed on inputs from manual testing practices.
In a closely knit network of technology practices, the business analysis team on the forefront of client dealings does not interact with test automation teams when they need the assistance of QA team, rather they go for manual regression testers. It is under highly technical issues that test automation team is consulted for resolution of day-to-day issues.
Question is, how do you create a mix of manual and automation teams, and, moreover, which element should be in control; the mechanized scripts or the humans?
The answers have been established quite often in the past. But somehow, the arguments are still not convincing as test managers still confuse themselves in the question of “who does testing?” – Tool or the human?
Over the time, claims also have been made that without test automation it is impossible to do testing. These claims are made without ground realization because it can hurt the very core of hiring and acquiring talents, as fresh graduates and career shifters cannot go into test automation without knowing first how black box testing is carried out or what is the process of quality assurance. These aspects are learned from practices.
Secondly, these claimers also don’t realize that if they hire only test automation resources then there would be no one doing the manual testing. The load of which is then shifted to Development, Support, and Business Analysis departments.
While comparing Development with Testing, we must also understand not to compare the two practices in terms of usage of tools. The reason is simple; Software Development cannot exist without the inclusion of tools, IDEs, knowledge programming logics, data structures, and a certain amount of human efficiency of multi-processing.
Similarly, in the case of software testing, the ball rolls in both directions, to make excel the performance of an average software testers tools becomes a necessity, but that does not mean that the tester cannot survive without it. Unlike developers, testers have the advantage of using the diverse amount of tools to conduct testing, and this does not include just the software test automation; Testers use word processors, image capturing, memory leakage, multiple browser plugins, and communication tools to make their work more efficient; this however is other than the intuitive human skills used in the process.
In all these arguments the most important are the execution parts of both manual and automated testing. On the human side, we need to consider the undeniable facts that humans are a product of their own environment. They can be easily distracted, and their decisions are based on their emotions and physical inputs.
On the other hand, the test automation is something which is based on automated execution of prewritten programming scripts. These scripts are not influenced by the physical and environmental stimulus as their human counterparts do.
However, we must also consider that it is the humans who maneuver these tools and craft the scripts.
We need to perceive this mix from the tool angle. We need to understand the role of the tool rather than the role of the tester. We need to grasp the reality of the skills and excellence, which is to say
“Tools enhances the skills of the human being”
If we can understand this, we would not argue rather think of ways to improve our part in the software testing and development practices.
