Why are you still holding on to manual testing? Has the experience of an automation failing been so expensive? Or are you avoiding it because you don’t want to experience the former? The reasons for avoiding are many. I also agree they are legitimate ones. Some of the major ones include:
Traditional a.k.a script based test automation are complex. All thanks to the need to ‘code’! Whether it is RFT, QTP, Selenium or any other test automation tool a tester needs to learn a scripting language specific to the automation tool, apply development practices to create a script of a manually tested test case. What if you could still automate without having your testing teams code scripts?
Test automation is expensive
Right from investing in automation tools to right resources who know the native language of the tool to make it work – traditional test automation requires huge amount of investment. Tool license to user ratio is 1:1 which implies even if you add one more test automation expert to your team, you have to purchase an additional license. What if you could share test automation tool licenses within your team?
Yes, script based test automation calls for programmers. Often more than expected, good programmers come at a price. This increases the cost to automate. Don’t forget to include the costs of hiring and retaining these resources. Scripting also isolates the whole testing exercise from the other team members ( manual testers and subject matter experts). This is not intentional but a side effect of test automation. What if all levels of experience, domain and technical knowledge collaborate in test case creation?
Traditional test automation means scripting. To write scripts, test, and make them work requires considerable time. And time means more cost, literally. What if you could shorten this time and still ensure automation?
Even though the aforementioned reasons are real, have you ever thought what you are missing out on? Have you ever thought about:
Incomplete test coverage
The pressure of time-to-market pushes your testing team to not regress 100%.
Even if you decide to manually regress for 100% test coverage, imagine how much time would you save if you would automate regression? Imagine how fast you can hit the market? Imagine the first mover advantage?
Even though to err is human, testing world can’t use this as an excuse for a bug that gets noticed by the client. Manual regression has the potential to become mundane which can result in unidentified bugs.
This not only encapsulates resource cost, tool cost, infrastructure cost but cost the of increased time to market, the unidentified bugs due to lack of 100 % regression or just sheer boredom. These are all costs and opportunities you can’t condone.
Manual testing is absolutely essential. Test automation cannot replace manual testing. If testing is means to build high quality software, then test automation is a means to mean. You would agree, it is one of the effective strategies to build optimum software testing process. But the dilemma continues…
One one hand lies to cost of developing, maintaining and operating test automation. And on the other hand lies of the cost of increased time to market and the unidentified bugs due to lack of 100 % manual regression. What would you choose?
What if I propose to decrease the cost of automation and still offer all the benefits of test automation? What if you could still automate without having your testing teams code scripts? What if you could share test automation tool licenses within your team? What if all levels of experience, domain and technical knowledge collaborate in test case creation? What if you could shorten the time to automate and still ensure 100% automation? What if you could regress for 100% test coverage?
Would you still automate or not?