regression-testing

8 Simple Ways to build a Regression Pack

regression-testing

Get ready to create a Regression Pack

It’s that time to start thinking about Regression Testing. Many QA Team do not have an adequate Regression Pack to run each time a new release has been deployed though this is a fundamental part of the QA process.

  1. Regression Testing is a fundamental part of the QA lifecycle it ensure that all your hard work during the Integration, Functional and System Testing stages has not gone to waste due to an issue that has been overlooked after a bug fix has been implemented.
  2. Identify areas that are related to the change that is being Implemented. Areas that have had high volume of bugs in the past or that could have reputational or monetary loss to either the business, customer or End User. This could also be customer facing pages, functionality, Customer data information or automated areas such as emails notifications etc. Developer could also advise possible regression areas. This should be run after every Major or small deployment/release to the test Org/Environment.
  3. The best way to build a successful Regression pack is to think about building it right from the start of your project involvement. When scripting or smoke testing as you can get a good feel for the system and how it will all link together.
  4. You can start pulling the tests into a pack when running your Positive and Negative tests also by marking them as part of the regression pack the same can happen for retest of bugs make sure you are making a % of these to be tested as part of the next releases regression pack for at least two or three cycles after this, this will be dependent on resource and deadlines (unfortunately this is a key factor in regression testing being performed). The reason you are doing this is to ensure that the one bug that has been fixed but has not caused more bugs to be release into the System.
  5. Regression packs need to be revisited regularly other wise the size of your regression pack can quickly spiral and end up being much larger than is needed.
  6. You will always have your basic regression tests that can be run on every release but remember that regression packs are constantly changing and that doesn’t always mean increasing in volume it can decrease depending on the result of that iteration and the previous iterations.
  7. Ensure to use the RISK against reputation and monetary LOSS through out the Regression pack building process as you will never be able to get 100% regression testing coverage.
  8. Always allow time in your regression pack to go in and do some exploratory regression as this is vital in finding them buried bugs that may not be found in the day to day processing these are the ones that will catch you out in the end, because if an end user can get around a process be sure that they will.