Testing automation has come a long way in the last five years. The original automation – record and playback – skimmed the surface of what was possible by recording the tester’s keystrokes, making it possible to repeat (or playback) the process to test more of the same kind of code. It sped up some testing, but it had to be done by QA specialists who were highly skilled in specific software tools and who had deep experience solving the complex tasks required. It did not require any particular knowledge of coding, however.
The downside to this kind of testing today is caused by the exponential growth and variety in the UI layer. Today’s web and mobile platforms present a huge diversity of UI components, making it impossible to create one tool that can work with all of them. Also, system “fatigue” happens when more and more new functionality is added to existing software, leading to longer development times, higher-cost applications and poor functionality. It all renders yesterday’s automation tools inoperable in many cases.
Today’s testing engineer: part developer, part QA engineer, part Dev Ops specialist
Today it is common practice for a QA engineer to develop his/her own auxiliary automation “tools.” This means that s/he needs to know two or three programming languages and a dozen or so libraries/tools for automation. (I will examine the plusses and minuses of some of these tools – like Selenium, Appium and QtWebDriver – in future blogs.) These tools need to be more flexible and powerful than the tools of yesterday, to be useful in a wide variety of testing scenarios which have specific code and other changes that demand adaptability.
At Coherent Solutions, we advocate a hybrid approach for most test scenarios. Automation is highly valuable in regression testing, for instance, and in going through large volumes of test-and-response situations. But manual testing, which has never gone away, is still very necessary. You need the human element to recognize non-conforming code and functionality, and to question and analyze results. Ours is one of the few independent Quality Assurance departments within an IT software development firm.
While our programmers test some of their own code to maintain high quality standards throughout development, we operate autonomously in the QA department, assuring that we meet stringent standards of professionalism. While there are about 40 automation engineers here, there are also about 100 manual testers who are vital for maintaining quality in the many ad hoc instances where highly specific code can have large ramifications on the functionality of the software product we are creating.
Besides automation tools, in future blogs I will also address the formation of COMAQA.BY, an automation engineering community in the Commonwealth of Independent States as well as the skills and education today’s automation engineers need to be successful today.