Home
Updates! What's New?
Got Questions? Get Answers!
QA Overview What is QA?
QA Employment Jobs
Testing Portfolios
Testing Services
Free Consultation
QA Training Become a Tester!
QA Course List
Testers The QA Elite
The Beta Tester
The Game Tester
The Software Tester
Testing SQA Glossary
Types of Testing
QA Metrics
Forms & Templates
Etc... About Us
Contact Me
Privacy Policy

E-mail Address

First Name (optional)

Then

Don't worry -- your e-mail address is totally secure.
I promise to use it only to send you SQA the Right Way!.

Subscribe To Successful Quality Assurance
XML RSS
Add to Google
Add to My Yahoo!
Add to My MSN
Subscribe with Bloglines
 

Regression Testing Process

Regression testing is where many QA teams get sloppy. Entering the bug is not enough. Accurate validation or rejection of a fix is just as important. Sloppy work creates risk and cost money.

Once the engineering team implements a fix and assigns a bug back to QA, the crucial work of fix verification is undertaken. It is imperative that this testing be at least as accurate, if not more, than the original testing.

The fix may be all that was needed. It may be effective and complete. But that is not always the case.

Some “fixes” do not work at all. Some code changes create other bugs. It is a critical task for the QA team to be able to know with certainty if a bug is actually fixed or not.

On many QA teams, this is a task that is not given it’s just due. Once fixes are implemented, many QA testers spend only minimal attention and effort checking to discover whether the fix is adequate or not.

This kind of ad-hoc re-testing often results in bugs that are not truly fixed becoming closed. Why? Because the tester did not properly validate or reject the fix.

Under the best circumstances these mistakes are caught in a later build prior to release. If that does not happen, then the consumer is the one that discovers the mistake. That always hurts a company’s brand.

Other mistakes in bug regression create more work for other members of the development team. If you have taken any of the other courses offered on this site, you know how important it is to avoid that.

The worst mistake made in bug regression is that of a critical show-stopping bug not being regressed properly. If one of these gets closed without an adequate fix, the consumer pays the price, the company pays the price, and once what has happened is discovered, the QA team pays the price.

It is too common for fixes to not be adequately tested. Or when they are tested, the work is done so poorly that it creates work for the rest of the development team.

These issues are preventable. There is no reason for any QA team to perform bug regression in any less than a perfect manner. Everything you need is laid out in front of you. Less than perfect results shows that a QA team is not professional.

What can be done? Easy. You create a simple, straightforward process that your entire team understands and buys into. You use these 5 Steps to Bug Regression to create repeatable success.

Each action and every step you need to follow in laid out for you. I detail all you need to do to master the 5 Steps to Bug Regression. And it doesn’t end there.

Once you complete this 5 Steps to Bug Regression course, continue on to 5 Most Common Bug Regression Mistakes. So, not only do you get a course that shows you how to perform regression testing like a professional, I also give you the most frequent, debilitating mistakes to which QA testers fall prey.


Quality in a service or product is not what you put into it. It is what the customer gets out of it.
~Peter Drucker



Leave Regression Testing Process and go to Successful Quality Assurance Home


footer for regression testing page