Difference between regression and confirmation testing

Among the various QA terminology which is used for example for web app testing there are such types of testing like Confirmation and Regression testing. To simplify the discussion most of the teams usually avoid the confirmation testing definition or even summarize those types of testing and call such combined process just as "Regression testing" because of similar goals of both those processes. But actually there is a difference here so let's clarify what do these terms mean.

Regression Testing

Regression testing - Is a type of testing which performed by QA after some change was done for the system to make sure that all its old processes (which already exists before recent changes) still works as expected and provide required results. Scope of regression testing is totally depended on project requirements and how big the changes which were done for it. For trivial change you even may avoid such kind of testing but for some massive new feature which may indirectly affect most of already existing ones you will need to dedicate quite big amount of time on regression testing to make sure that everything works as expected before publish on production may be done. How deep the regression testing should be done also differs from project to project and as well depends on severity of change which was done. Sometimes you will need to perform only several sanity checks and in another situation you will need to spent same time on each feature testing as was spent on it when it was just released. The only thing in Regression testing which is consistent is that tests are focused on already existing and not new processes on project. performance - By the way - it's good to have your regression tests to be automatized. It will definitely improve quality of project and save a lot of time for QA team which may be spent on more detailed testing of new features.

Confirmation Testing

Confirmation testing - Is the type of testing which is performed by QA for processes which didn't show the expected results after previous tests so additional change (e.g fix) was done for them. The scope of such testing is in most cases consistent and unchangeable. You should check the changes results by using all the environments, data and inputs which were used when the fixed issue was noticed previously. For clearer example let's take web app testing. You just completed testing of a new feature and noticed some bug. You reported it and later the required fix was done. So now you will require to perform confirmation testing for it to make sure that fix indeed resolved the problem and you may receive the expected result successfully now. And this basically means that regular bug verification process equals to confirmation testing.

Difference - After summarizing all above we may see next differences:

So now you see that there are differences between those terms after all. But then why most of the teams avoid using of such definition during their work?

The thing is that almost all projects currently using the Bug Tracking Systems (e.g. BTS) for their work. And together with it they are using Issue Reports (e.g. bugs). So using of the BTS affect the terminology which is using by QA in such way so that when the time to check the changes (e.g. bug fix) has come the further confirmation testing is called just as bug verification process. Sometimes changes are done without specific issue report. But even in such case QA teams avoid calling the further process as confirmation testing. It because a really good QA team always check not only the original bug flow but also perform additional testing of the surrounding area of fixed place which is contradicts to the consistent scope requirement of confirmation testing and fit better in regression testing definition. So to simplify the discussion instead of saying - Confirmation+Regression testing usually the only regression testing definition is used as confirmation testing in such case is meant by default.

Hope that this article didn't leave any open questions for you and it was interesting to read it. Have a nice day and make good effort in improving the quality of software in the world!