Respect the big deal.
Within the course of these magical 4 weeks of complete immersion into web development, a girl’s got to acquire a few good habits. Although, it’s still very early on in my career for me to fully grasp the notion of what is and what isn’t a good habit, I can still wrap my head around the fact that there are processes and tools available to me that will greatly improve my craft. So far, it has become clear that utilizing the process of regression testing is a powerful habit to formulate. Let’s dive deeper.
Regression testing, simply put is the process of testing pieces of your site, software, or app that you have been working on after a new patch has been implemented, to ensure the product is fully functioning, and bug free. So if you think about this from a logical perspective, regression testing makes perfect sense right? The analogy I like to think of when comparing regression testing is that of an architect. If you were building a skyscraper and have just finished completing the monumental foundation that will hold your 30 story high, multi-million dollar building from, would you just go out on a whim and assume the foundation is up to par? or would you go out of your way to test your bedrock and be without a doubt completely sure that it will withstand the rest of the construction? Not a trick question here, and I’m pretty positive we’ll both agree to go with option b. Although this mindset should be a no brainer, unfortunately it’s not a priority for every team.
There are many reasons why regression testing is underestimated and not put into action, but none good enough to be a validation for not taking advantage of this crucial process before the release date. Many teams often complain of the boring, tedious, and time consuming aspect of conducting a regression test. There are a few ways to go about performing a regression test, either you’ll manually do it or set up it up to be an automated process. With automation, there are a few factors that need to be considered and thus can affect the overall conclusion. Factors like, profitability, resources, and constant update to the automation process so it can be up to date with the whole system. The same factors do apply if the manual option is chosen. But the flipside of having an actual human looking at is that it can have a better understanding of where more time should be spent and also be on the lookout of important patters. The preference in either manual or automated process of regression testing is usually the biggest decision, but deciding to do it period will guarantee a successful launch.
As much negative noise as the tech community makes about undergoing the test, it’s pretty evident that the regret factor is always 100% there when this safety net is missing. For example, back in 2012 kickstarter came face to face with this regret when a bug slipped right on by the release date and caused details of unlaunched projects to be made accessible when the API was launched with their new homepage, fully unbeknownst to the engineering team for a full 13 days. Easily avoidable by none other than, a regression test.
At end of the day the two biggest goals of any company, are profitability and happy users. None of which are attainable when your product is full of bugs and end up coming right back to the drawing board if regression testing is not a priority.
So is regression testing a big deal?