2. www.qamentor.com
Introduction
As a vital component of a healthy and error-free release, regression testing is necessary to ensure that
existing modules or processes were not adversely affected by recent changes. In 2012, Kickstarter
introduced a new API to their web application. On release, it allowed unauthorized access to 70,000 of
their client’s projects. The error was found quickly and access was limited to just 48 unauthorized people,
but the lesson was still evident. It appeared that while testing was done on the API, regression testing of
the entire application was not completed and led to a loss of data integrity.
But, just how much regression testing is appropriate?
Running the entire suite of tests - that could number in the many thousands - is prohibitively expensive
and time consuming for every single release. At QA Mentor, we believe that while performing a full
regression is appropriate at least once a year and for any large, involved releases, a more focused
regressions is suitable for regular releases. The testing execution scope is reduced in order to also
reduce the cost and time necessary to test. If the regression test selection strategy is logical and sound, a
team can provide more than adequate coverage without wasting time. The goal is to spend as little time
as possible regression testing without decreasing the likelihood that issues will be detected.
Timely, thorough, and cost-effective regression test execution requires a sound regression strategy. QA
Mentor recommends a five-phased approach towards regression testing.
Phase 1 – Impact Analysis
The first step in any testing strategy should be to
assess the scope and impact of any changes
made. Generally this means meeting with the
development team to discuss all of the bug fixes
or applications enhancements and their potential
impact to the existing functionality. During this
impact analysis, work should be done with the
development team to isolate modules or
functional areas that were not affected by the
changes in any way. Once the unaffected areas
are eliminated from the regression plan, focus
can be placed on the areas that do need tested
and to what extend they require it.
Phase 2 – Test Repository Review & Update
The next step is tackling the regression test repository. Some tests may be obsolete due to the changes
and those should be identified and removed. Any changes to the remaining tests should be completed
along with adding any necessary new ones. This maintenance at each release will save much time later
one and help make future test cycles more accurate and effective.

3. www.qamentor.com
Once the regression suite has been
updated, test selection begins.
Testers should take a risk-based
approach to selecting the
appropriate test cases for each of
the following three regression
phases and take care to avoid
duplicate tests and multiple
negative scenarios. This risk-based
approach is aided by the impact
analysis in Phase 1.
Phase 3 – Focused Regression
This phase of the regression focuses on the specific functionality around the new or modified code. QA
Mentor recommends regression testing affected areas in tandem with the functional testing of the new
or modified functionality. By dividing the testers into two teams – one that tests the new functionality
and one that regresses the existing functionality – the regression testing isn’t done as the last step.
Starting regression earlier in the cycle allows for issues to be found and fixed much sooner and makes
the process more efficient.
Phase 4 – Expanded Regression
This phase incorporates tests for functional areas not directly related to the changes, but potentially
affected by them. Executed preferably when there’s a code freeze, the expanded regression phases is
best done using an automation tool. Very often, however, this isn’t possible so a manual execution is
perfectly fine. All areas identified in the impact analysis and risk assessment should be fully exercised in
this phase.
Phase 5 – New Release Functional Regression
Due to the testing done previously and defects found and fixed, this last phase is a performed as an extra
precaution. QA Mentor recommends selecting at least 30% of any newly added functional test cases for
this mini-regression at the end of the testing cycle. This final step is aimed at finding defects that may
have been overlooked during the find and fix periods at the beginning and also offers the opportunity of
a higher level of confidence in the final product.
With this five-phase methodology, you can reduce regression testing costs by reducing the time it takes
to test, and without reducing quality as a result.

4. www.qamentor.com
QA Mentor’s Recommended Quick Tips for Regression:
 Create an organized library of tests
 Review test library frequently
 Remove redundant or outdated tests each test cycle
 Periodically clean test repository and get rid of less effective tests
 Archive tests that are consistently passed
 Focus on function, not design
 Make large and small changes to test data to check test accuracy
 Automate
Final Notes
In the end, is a full regression worth it? On occasion - for large, involved releases, or periodically to
double check the accuracy of your focused regression logic, yes. But for normal, regular releases and
bug fixes, QA Mentor doesn’t think so. Performing a more focused regression will save you time and
money without sacrificing quality. If your team would like to learn more about QA Mentor’s regression
testing methodology or need help implementing it, please contact us!
About the Author
The author, Ruslan Desyatnikov, is the CEO & President of QA Mentor. After working as the
Global Head of Testing at Citi, Ruslan created QA Mentor to fill the gap he has witnessed in QA
service providers during his near 20 years in QA. With Ruslan’s guidance, unique services
and methodologies were developed at QA Mentor to aid clients in their QA difficulties while still
offering a high ROI. Ruslan offers monthly seminars aimed at imparting his extensive testing
knowledge that can be applied to start-ups as well as large companies.
About QA Mentor
QA Mentor is independent software testing company and top provider of 37 different Quality
Assurance testing types, with 24 different services – several of which are not found at any
other company. With a global presence in 8 different countries, a staff of 100, and a pool of
over 1500 crowdsourced testers, QA Mentor uses an effective and unique combination of
onshore and offshore resources to keep costs low for our clients. QA Mentor aims to bring
quality to the forefront of software development and become the central figure in Quality
Assurance with an active QA community full of engaging discussions and resources.
QA Mentor, Inc. United States
1441 Broadway, 3rd Floor,
New York, NY 10018.
Toll Free: 1-800-622-2602
Manhattan Office: 1-212-960-3812
Brooklyn Office: 1-718-606-7086
New Jersey Office: 1-201-918-4616
Email: contact_US@qamentor.com
Web: www.qamentor.com
All content & information presented in the White Paper is the exclusive property of QA Mentor, Inc. The content & information contained here is
correct at the time of publishing. No material from white paper may be copied, modified, reproduced, republished, uploaded, transmitted,
posted or distributed in any form without prior written permission from QA Mentor. Unauthorized use of the content & information appearing
here may violate copyright, trademark and other applicable laws, and could result in legal actions.
Copyright © 2014 QA Mentor, Inc.