Taking Possession of Your Regression: Web Regressions & The Bottom Line
You’ve probably heard of the age old saying “if you’re not progressing, you’re regressing”.
If your childhood was anything like mine this particular gem might have been dropped on you by an irate coach in the heat of a soccer scrimmage or by a particularly resigned orchestral conductor as he looked around and reminded you to practice the viola more. Or if you’re really like me, you may have heard this line not too long ago while eating brunch in NYC with friends and asking them if they knew what “website regression testing” is. To be completely honest, unless you were in the cafe with me in early August the last scenario probably doesn’t apply to you, but I can assure you if you’ve ever accessed a website (such as the one you’re reading this piece from), wherever you may be reading this from, regressions do apply. Website “regressions”, ambiguous as they may sound, can affect anything from your website experience, to your time and bottom line.
At this point, if you’re a website owner or overseer and are interested in learning about regressions and your bottom line or what I talk about during brunch, but you’re not well-versed in “developer talk”, don’t worry- this post will walk you through the important stuff while breaking down the technical words. In this article we’ll cover:
- What regressions are
- How regressions happen
- Why we care about regressions
Regressions: What the heck are they?
Regressions are a type of software bug. They happen when the program or code that tells a website how to look and behave has been disrupted or changed in a way that adversely affects existing site features. In simple words, regressions result in a website exhibiting unintended or abnormal behaviors due to a change in coding.
Regressions: When am I most susceptible to them?
A regression can occur when an alteration is made in source code. This can happen in numerous ways, most notably when someone changes the code because they want to change website features. When the code is modified, if the new modified code is not a strong healthy code the website becomes vulnerable to regressions. If all of this “code” stuff is making you dizzy think of code as DNA, and what you see on a website as a an object with DNA, such as a banana. Now when a code is modified, really great, cool things can happen- but if the new code is weak or faulty, bad things (regressions) can happen. Looking at the fruit analogy, if you take a banana and you change its sequences you can make really tasty, large bananas. However, much like adding weak code to a website if you add in a DNA splice to the banana that is not healthy, or is not strong, the results would not be so desirable.
A regression can also occur when an existing code is added to, and new features are added to software. The reasoning behind this is just that when new code is added, it can negatively affect the pre-existing code. This can happen in two ways: 1- the new code does not mesh well with the pre-existing code, or 2- the new code breaks up the pre-existing code. For the first reason, going back to the banana example, imagine if a healthy DNA strand were added to make the fruit’s growth impervious to cold weather. Though this sounds like it could be a good thing, adding the new DNA to the existing banana DNA could result in bad things (think: too many banana growers leading to market oversaturation, too much competition, and lots of rotting bananas). Just like the banana if new healthy code is added to good preexisting code it does not mean the culmination of the good codes is guaranteed to also be good. The second reason that adding existing code can result in regressions (even if it is good code) is that it could break up pre-existing code. Think of the fruit analogy again, and think of how bananas are bananas because of the unique DNA sequence it possesses. If the DNA sequence that makes up bananas is altered too much, even if the alterations are meant to be good it would change the fruit too much, making it into something else which would not be the intended goal.
Regressions: Pssh! Why should I care?
Simply and in short, site regressions will cost you. If you decide to fix it (something you really ought to be doing to have a site up in full capacity) it’s going to cost you time and money. In terms of time, if you find that your site has a regression, the time needed to run tests for the regression, locate the regression, determine what exactly the issue is, and then fix the regression is going to add up and cost you. In terms of money, if you decide to go the route of having regression work outsourced, it is going to cost you money to pay for services rendered. In terms of time and money, no matter which route you take, both are spent; outsourcing takes time and even if you keep things in house, the time your in-house team takes to deal with regressions hits on opportunity costs and eats away at their time to do other work. Since we all know time is money, keeping things in-house will cost too.
If you decide you’re going to take a risk and do nothing a regression is still going to cost you. Because the regression affects the way a website behaves, it puts you at a loss of full site function, translating to a very likely loss of site usability, traffic, and engagement- ultimately affecting conversion rates, leads, and your company’s bottom line.
Regressions: We Recap
By now we’ve covered regressions and their importance by touching on the following points:
- What regressions are: alterations in code that negatively affect a website
- How regressions happen: through changing or adding to code
- Why we care about regressions: there are time, money, & opportunity costs involved with regressions
If you found this article helpful and are now thirsting to learn about code testing and review, or if your thirst wasn’t quite quenched by this overview of regressions and you are looking for a more “practical applications” type post of regressions and black box testing, be sure to tune into our post on code review.
This article was originally posted by Maggie Newberg on our Isovera blog.
