Why Do I Need Regression Testing?

Regression Testing
If you are asking this question, then this writing is especially dedicated to you.

Regression Testing can become one of the most critical elements of your test artifacts and can prove to be the most preventative of all measures you can take in your organization.

Many quality organizations will publish that regression testing is part of their testing life cycle and a core ingredient in their test cases before moving deliverables to production. But how strong is the regression test suite in your organization? How well are you monitoring your test suite to maintain relevance?

The challenge of organizations today is to ensure each business area supported has a robust, detailed and highly covered test suite for regression.

Whether you are a mature testing organization or just getting started, below are some needed steps to ensuring you have a quality regression test suite for each business area you support:

  • Understand your business area. This includes working with business partners and stakeholders to ensure each subset of the business area supported is documented and tracked by the team. Leverage subject matter experts (SMEs) from not only the testing organization, but also the business and development teams.
  • Create, validate and maintain the artifacts. Simply documenting various integration points and subsets of business areas is not the only goal. It is important that, as new releases, updates and changes are rolled out, the suite is revisited and artifacts are updated to maintain the accurate and detailed picture of the business area.
  • Understand the test cases required to build high coverage for the business area. It is important that you review this with the business stakeholders, development and testing teams to ensure agreement and collaboration between the teams. Creating test cases builds the framework for future savings as the test cases are created once in order to be used many times down the road.
  • Build the test suite in priority order. Teams are able to quickly define which subsets of a business area are the most critical to the organization. Based on this prioritization, the test suites must be built in this order. NOTE: Do not confuse “prioritization” with “risk.” Risk-based Testing does not apply to regression prioritization. After a regression test suite is built, teams may find not all regression test cases can be run at times, and a risk based approach must be followed. When this occurs, regression prioritization should be based on the importance of the test cases and whether these cases can detect and identify possible defects in the product.
  • Just Start It! Nike had an extremely popular ad campaign in 1988 that carried the slogan, “Just Do It!” For regression test suites, the goal is to “Just Start It!” How you can apply this theory is to begin immediately using regression test suites the moment the first test cases are delivered. Begin experimenting with the test cases, building a lessons learned document, validating with the stakeholders that the quality of the test cases are mapped to the expected results. This ensures that the organization begins benefiting early from the initial regression efforts.

Now what?

It’s been said that “A mother’s job is never complete.” The same applies with regression. Maintaining test cases and integrating the many deliverables from the organization into the regression test suites will be a constant task. However, following a disciplined approach to coordinating with the development, testing and release teams will pay huge dividends in return.

After you determine the organization has a firm grip on regression, you can evolve the goals for regression further. A few things you can target to grow the organization include the following:

  • Automating the Regression Test Suite – the benefits of automation are tremendous. The value of automating the manual test cases is found when you realize the speed at which you can execute the automated regression test cases versus running them manually. Additionally, automation reduces the risk of human error that is more likely in a manual regression-test execution. While the term “regression” implies the test suite will be run many times over a given period, it is always important that the team evaluate the frequency of execution for the manual test cases before automating. The lower the frequency of execution, the less valuable that automating the regression test suite will be.
  • Integration – once you have a detailed, highly covered regression test suite and a disciplined approach to maintaining the suite, another area you could evaluate is integrating upcoming projects and deliverables to reduce the number of test cases required to deliver system integration testing. Integrating with these teams allows you to leverage the regression suite in areas where new test cases, in the past, may have been created to accomplish a validation that can already be accomplished with the existing test suite. Also, the earlier the regression team is involved in the building of new test cases required for new deliverables, the earlier the regression test suite can be updated to contain the new required test cases.

If you don’t have a regression test suite today, or the one you have currently is of low coverage or is outdated and not maintained, I challenge you to spend some time with your business area and build the test suite to perfection. You will not regret time spent to reduce the risk of releasing defects into production. And you will find that your stakeholders will recognize and appreciate these efforts, as well as willingly participate in helping ensure this critical part of a testing organization is maintained.

Mike LylesMike Lyles is a Sr. QA Leader with over 21 years of IT experience, gaining exposure through all aspects of IT in various roles – tech support, software developer, PMO, development manager, and, ultimately, testing/QA. He has led various aspects of testing: functional testing, Test Environments, SCM, Test Data Management, Performance Testing, Test Automation, and Service Virtualization. In his current role, reporting to the VP of QA, he is responsible for defining and implementing tools, processes, and methodologies to support the QA teams for Functional, Regression, Infrastructure, Test Automation, and Performance. Mike is an international/keynote speaker at multiple conferences, and is regularly published in testing publications and magazines. Mike’s passion to help others improve and grow in the field of testing, leadership, and management is his key motivation.

Come see Mike’s sessions this Spring at STPCon in San Diego. Mike will lead a workshop – Metrics: Tell A Story Not A Number and session just for new and experienced speakers – STPCon Presenter Mentoring: Speaker Invitation and Orientation.