It is very surprising when you talk to customers who find regression cycles either painful or a drain on their productivity and at times a distraction from critical projects. What comes as a surprise is that most of them have an extremely mature and stable application and testing process. Yet, around regression cycles they scamper to get the entire suite executed and face the dilemma of having to deploy before completing the cycle.
Manual regression testing can be a mundane and boring activity for most test teams! Going through screens repeating the same steps and not finding bugs puts a tester’s concentration levels to the test. It also risks critical bugs escaping through due to the way these suites are structured. Over the years of executing numerous regression cycles I have seen that while automating regression is a great way to address the issue, other factors need to be considered to make regression cycles a cakewalk. I am outlining some of the steps that my teams find useful while automating regression suites
- Find out how many of the existing test cases are automatable
- Find out the coverage gap to identify ideal number of test cases
- Run a test optimization drive (based on scientific methods) to arrive at the optimum number of test cases while ensure maximum coverage
- Do not jump into QTP (explore other low cost options including Selenium)
- Use a test automation framework that enables business users to develop, manage and execute automated regression suites
- Train business users to automate on the fly and use the automation engineer only to maintain.
I acknowledge and understand that one can never achieve 100% test automation but the way I look at it, if you can achieve and significant amount (70-80%) you are going to end up achieving a dramatic reduction in the time taken to execute regression cycles. Eliminating pure testers from this process is also truly empowering your test teams to focus on critical projects.
Hari Raghunathan | AVP | Zen Test Labs