Test automation is great. Test automation is awesome. Test automation allows you to control your product 24/7. You can load your product with production or production-like data and see how it works. You can emulate any activity or workflow for your product. You can make fancy analytics about the quality of your product and make team performance reports make sense. But I suppose there are more fails then success stories about automation implementation. Why?
Because there are still some risks associated with QA automation implementation. Here I want to talk about these risks, their general solutions, and how we in DataArt address them.
Even the most progressive professional software companies warn their clients about possible defects in software products that would need some testing and fixing. The main requirements for the testing processes are they should save time and money, and should be clear and transparent for the customer. That’s the reason why automated software testing presents itself as the most reliable and effective way of holding all software systems under 24-hour control.
Why should customers prefer automated testing over manual software testing, which has been proven effective over the years? Why should customers rely on machines without souls and brains? Well, for the same reason machines secure houses, build minivans, and record your favorite TV-program, when you are not able to watch it. They perform everything you tell them and never sleep.
In my previous article I wrote about the amazing new features of Visual Studio 2012/Microsoft Test Manager 2012 and mentioned that the guys from Microsoft were going to change the world of QA by making an automation platform that can be used by non-developers (exploratory testing automation, running automated scripts from any place inside manual test run, etc.)
Ok, here is the story. Presenting latest Microsoft product line MS Visual Studio 2012, MS Test Manager 2012 and MS Lab Center 2012, Microsoft Evangelist Brian Keller raised one interesting question. He mentioned that QA Automation and QA itself are living so to speak in different worlds.