Without a doubt, regression testing is a time consuming endeavor. Necessary, but time consuming. Just how much regression is necessary? When a new patch is completed, do you really need to perform a full regression each and every time?

This is a tricky question – most likely you do not, but sometimes you do. So how do you know when you do and when you don’t? Unfortunately, there’s not a simple answer to that question. The answer lies in the application under test, the patch or bug fixes, and even how long it’s been since you’ve done a full regression.

If the application under test isn’t too complication and doesn’t have a lot of moving parts, so to speak, then a full regression wouldn’t be warranted too often. If however, your application is highly complication, requires numerous calculations, relies on input from multiple sources, and is a high profile or secure application, then full regressions may be needed more often.

Aside from those considerations, you should always consider the patch or bug fixes that were done. How many different parts of the application did the patch touch? How many pages were touched? Modules? These kind of questions may need to be answered by the developers who did the work, so you should talk to them about the changes they made. Did they touch a stored procedure that’s used all over the application? Or did they just modify a single line of code on a single page? Understanding the extent of the changes made will help you to determine if a full regression is warranted.

Another consideration is the length of time since the last full regression. If you’ve been doing focused regressions for months, patch after patch, it may be time to do a full regression. A good habit to have is to set up a schedule to perform full regressions on a regular basis (every month, every quarter, etc) regardless of the amount of types of patches done. And of course, doing full regressions at any other time it’s deemed necessary. This kind of schedule will help you keep your application as bug free as possible, and keep your testers from wasting time doing full regressions for every single code change.