Automation is a mantra in testing. Anyone associated with software development wants more test automation, but it’s often misunderstood. People who do test automation know how difficult it can be. But some people do not understand that automation is code, and that it needs to have architecture and design just like production code. They do not understand that it needs code review, and especially ongoing maintenance, which can be more expensive than maintenance of the production code. These misunderstandings about automation in addition to misunderstandings about testing in general, make test automation a political problem as much as it is a software problem.
In this issue, just as with last year’s September issue, test automation is the focus. As we know, test tools have always lagged development tools. At the same time, as software development lifecycles speed up and faster testing is needed, there is an ever greater need for test automation. As the business has grown more aware of these facts, the test automation tool market has rapidly grown. Today, most ALM tools (which we’ve written about here) include test automation tools or an ability to easily integrate test automation tools as normal practice. But remember the old saying “a fool with a tool is still a fool.” Tools will not solve your test automation problems. Great test design, architecture, great data design, and knowledgeable testers along with a great tool will get you started.
One of the most profound findings from the automation section of our 2010 Global Testing Survey is that 1/3 of respondents did 100% manual regression testing. What kind of confidence will you have from that? It is difficult for product teams to fully realize what a risk this is. If they did realize, I think many more companies would make the investment in staff, training, methodology and tools to make automation as important as their production code. The risk is that high.
Test automation is more complicated today. Most test teams today have to support far more platforms than ever in addition to traditional platform combinations, additional browser combinations, matrices of client/server combinations, and now multiple mobile platforms . Supporting a large suite of automated tests is hard enough. Supporting multiple tools due to inabilities for many tools to work across platforms, browsers and especially mobile devices makes an exponential nightmare. At this point, mobile automation can be so problematic for traditional teams we devoted an issue entirely to automating tests for mobile devices in December 2012.
In this issue, Karthik KK gives recommendations for organizing your automation code; LogiGear CTO Hans Buwalda addresses misconceptions about test automation; Randall Rice shows us why automation is not automatic; Amol Kher, Wello CTO, discusses the challenges his Netflix testing team faced when implementing their mobile application; LogiGear, Halliburton and Simco collaborate on a case study to show how to leverage test automation to increase the efficiency of distributed teams; Jonathan Khol urges testing teams to use games to make testing more engaging, productive and fun; and finally, Tad Anderson reviews the book Experiences of Test Automation by Dorothy Graham and Mark Fewster.
As always, we at LogiGear Magazine hope you find useful information to help in your test efforts. Automate more!
