Regression defects can be the most frustrating thing in the software world.
If you don’t know what that means, exactly, or you don’t have direct experience with it, let me set the stage for you. Your team has been working on a software release for months. It’s been something of a grind, and you’ve had to cut a few corners to go live by your deadline, but you’re going to ship on time. Sure, you anticipate some glitches, but at least you didn’t fail to deliver.
You ship the software and, sure enough, reports of glitches do come in. And, as you anticipated, these have to do with the new functionality you developed. Er, some of them do, anyway.
But there are a bunch of other problems besides. And these don’t seem to have anything to do with what you shipped. Users are reporting bugs in things that have always worked since the day you’ve developed them. And they’re understandably not happy about this.
These are regression defects.
Get TestRail FREE for 30 days!
What Are Regression Defects?
To get a little more formal about the definition, regression defects occur when a change you make to the software actually creates a problem. This is different than shipping new, buggy functionality. The new stuff never worked and you just missed it in testing. Regression defects mean you’ve broken something.
This makes conceptual sense when you consider the definition of regression. Through your actions, the software has actually regressed — vis a vis that particular behavior, it’s worse than it was before you modified it.
Make no mistake. Sooner or later, you will encounter a regression defect in any piece of non-trivial software. But if you find yourself buried in an avalanche of them every time you ship software, something is wrong.
Let’s look at how to fix that situation if you find yourself in it.
1. First, Slow Down and Plan for Delays
If you’re experiencing a lot of regression defects, you have almost certainly incurred a sizable technical debt in your codebase. (More on that shortly.) This means that you’ve got a software quality problem on your hand — a software quality problem that is going to slow you down.
When you’re in this situation, you’re going to experience slowdown. Features that once took days to implement are probably taking weeks and later they’re going to take months. The software’s internal complexity is growing faster than its feature list.
You need to slow down your development and plan for delays in the future. The delays are going to happen whether you plan for them or not, so you might as well be strategic.
2. Do a Tech Debt Assessment
Now that you’ve adjusted your expectations, you need to figure out how bad things are. How much technical debt do you have?
You incur technical debt when you take shortcuts. The team implements global variables or slapdash design in order to meet a deadline or effect some short-term outcome. They then wind up repaying this debt with “interest” as these decisions make future features more difficult and risky to implement.
When you’re drowning in regression defects, you need to stop and take stock of just how bad the technical debt is. You can ask your team for an inventory, or you can leverage static analysis tools or outside experts. But whatever route you go, get a handle on how bad your problem is. Then make plans to pay down your debt alongside any implementation of new features.
3. Implement a Regression Testing Plan
So far we’ve looked at a project (expectation) management approach and a code-focused one. The QA group can help as well, though. If you don’t already have a regression test plan, then you should make one.
While it’s true that code problems create regression defects, that doesn’t mean that you’re powerless to catch them before users do. A robust regression testing plan can help. And that can easily be the province of the QA group.
Ideally, you could automate such a plan with scripts or record/playback technology. But even creating a script for manual execution can help. The idea? You want to run existing functionality of your application through the paces before each roll to production — not just the stuff most recently added.
When you do this, you’re going to catch a good chunk of the regression defects that might otherwise escape. And, while this doesn’t address the root cause, it does surface the problem earlier and with less embarrassment.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
4. Train and Implement Unit Testing in the Dev Group
There is another form of testing that you can leverage. And this one does address the root problem. I’m talking about having the developers implement automated unit testing.
Unit tests are extremely granular tests of application functionality. Software developers write these and execute them, and one of their main purposes is the early detection of regression issues. With a strong unit test suite in place, you’re going to have thousands of tests that run regularly to check that existing functionality continues to behave as intended.
While not a silver bullet for regression defects, a unit test suite might be the closest thing there is.
As with anything, however, there is a cost. Codebases with lots of technical debt resist unit tests. And, if your group isn’t used to writing them that just compounds the problem. So it isn’t as simple as just saying “start writing unit tests.” You need to invest in both training and initial effort to get a test suite up to snuff.
5. Change the Culture — Defects are Not Inevitable
I’ll conclude with more of a philosophical item, and it has to do with your outlook and culture. When you’re swimming in regression defects, it’s easy to think of that as normal. You get used to thousands of open issues in JIRA and spending weeks in firefighting mode after each release.
But life doesn’t have to look like this. In fact, it shouldn’t look like this.
Defects are not inevitable. Oh, don’t get me wrong — you’re never going to have a situation where things don’t go wrong. But there are groups and organizations for whom a defect is an unusual occurrence and a source of consternation and embarrassment. They react to a defect report with “wow, I’m so sorry about that — that’s unacceptable” rather than “yeah, but what are you gonna do?”
Start by making this outlook shift, and the rest of these points will follow. When defects are unacceptable, you’re going to slow down, assess your tech debt, and developer prevention plans both in dev and QA. And when you do all of this, you’ll find yourself in a virtuous circle — one that does not include frustrating regression defects.
This is a guest post by Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.
Test Automation – Anywhere, Anytime
