Nothing is ever perfect on the first try.

Apps are no exception. Most developers have a backlog of bugs waiting to be fixed. But what about bugs that just keep popping up, over and over again?

Don’t worry – you’re not getting deja vu. A bug you see more than once is a “regression.” And there’s a special type of testing that can squash it for good.

You’ve probably already come across regression testing, but in case you haven’t we’ll briefly explain it here.

It can be summarized as a software testing method that uncovers new bugs and/or regressions in an already existing system…

That’s kind of a stale definition – it’s actually much more interesting in practice. Let’s say that you have a bug. Your bug fix process probably goes something like this…

  1. There are a specific set of instructions that created this bug.
  2. You went back and fixed the bug after the quality assurance team caught it.
  3. The new version of the application is released…

    • With regression testing: You use something to “remember” the bug. The next time it pops up – you’re prepared with documentation.
    • Without regression testing: You don’t use anything to “remember” the bug. It shows up again. This time with friends!

 

The bug squashing process (3)

 

In a perfect world, you’d be able to run every testing scenario for every change you made to your code. Practically speaking, that’s just not possible. To save time, you can automate your tests, and run them only in certain scenarios. Generally speaking, a full regression test should only be run if…

  • Something big, like a feature, is being introduced for the first time
  • A critical issue or bug was recently fixed
  • A new version of the application is being released

When you’re short for time or resources, a priority driven test should be run. Some use cases are simply a lower priority than others. Only high risk regressions are given priority.

A high risk regression is a bug that threatens the core function of your application. Testing for these types of bugs is known as a “sanity” test or “smoke test.” Eventually, an automated system should be implemented to save the most amount of time.

 

At this point it’s probably obvious what will happen if you don’t use regression testing. Your team is at risk of releasing buggy code. And really, nobody wants that. Without using this type of testing you will…

  1. Waste your developer’s and tester’s time on recurring, undocumented bugs. When bugs start to regress (and they will) your team will be ill equipped to handle them.
  2. Exceed your budget. Overtime can become very costly when no one knows how to handle a particular bug!
  3. Produce an application that suffers heavily from bug creep. The less you know about your bugs (and the related code), the more they will pop up.

In the end, knowledge really is power when it comes to bugs in your code.

By keeping bugs in your sights (even after they’ve been fixed) they’re less likely to take you and your team by surprise. When a known offender shows up in your code after changes, you’ll know exactly how to handle it quickly and effectively.

Without regression testing, you’ll be left scratching your head trying to remember exactly what it was that caused this the last time. Squashing bugs will never be easier. Good luck!