Regression testing
August 25, 2020
What’s the difference between regression testing and debugging?
What are they, and when do you need them?
.jpeg){kind=avatar}
Sometimes it can feel like software and app development teams live in a world of their own. They have their unique ways of working, a distinct culture, and even their own language. Technical business users like Salesforce administrators, who often work in the space between IT teams and everyday team members, have the challenging task of serving as something of a translator between the groups. But learning a new language is difficult. While most learners are able to nail down vocabulary, they often still struggle with the nuances of different terms and expressions.
And in the software world, early- or mid-career Salesforce admins—who may not have had a ton of exposure to the mysterious ways of software development teams—might confuse more technical terms or use them interchangeably when they shouldn’t. That’s especially true when they’re talking about debugging and regression testing. While many people think they’re completely synonymous terms, they’re actually two distinct parts of the same process. Here’s a look at what they really mean, how to use them properly, and the roles they play in your daily responsibilities for making sure your Salesforce apps work as expected.
In the fast-paced world of software development, things break. Low-code apps, like those from Salesforce, make it easier for developers and non-developers alike to configure and launch applications. But they also increase the likelihood of simple mistakes that can lead to big problems.
Debugging is the process of fixing those mistakes. Think of it as sort of like proofreading an essay for spelling and grammar mistakes or re-calculating a balance sheet when the numbers don’t add up. Usually it’s something like a weird sentence fragment or a misplaced decimal that throws your whole project off-kilter. In software development, those mistakes might be something like a missing parenthesis or an extra space in a line of code. But unlike proofreading or reconciling a budget, debugging is an intensely time-consuming process that can take up to 75% of a developer’s productive time because it requires digging around log files and poring over tens of thousands of lines of code for hours, searching for what seems like a needle in a haystack.
With the rise of low-code apps, the process of debugging is increasingly handled by administrators, analysts, and other non-developers. While the where and how of debugging low-code apps is different (admins often have to scour configuration settings or rows of Data Loader CSVs to find a missing character or incorrect ID), the process is no less time intensive than debugging traditional software. The most important thing to remember is that debugging only happens after the application or software fails to execute properly, like how you’d take your car to the mechanic after the “check engine” light comes on rather than before.
Conversely, regression testing helps confirm that a recent configuration update or new deployment won’t adversely affect existing functionality, processes, and workflows of a system before it’s released. That means it’s more like a preventive checkup appointment with your doctor to make sure everything’s okay rather than going for a visit when you’re sick or know something’s not right.
This is an important step for all app development teams, but it’s also especially important for Salesforce administrators to understand and command because Salesforce issues three major releases every year that affect all Salesforce customers and users. Some teams continue to regression test manually, but quickly realize they have to run the same tests repeatedly, which gets increasingly more difficult as their use of the Salesforce platform and integrated low-code apps gets more complex. Plus, they might still overlook important warning signs of an impending problem.
Fortunately, regression testing can be automated. Automating regression testing unburdens teams of tedious, boring, and time-consuming testing and frees them up to pursue higher-value business tasks without sacrificing the quality or performance of their apps. More importantly, automated regression tests can be reused across every app configuration, helping your team detect potential problems before they occur and ensuring that changes in a new release won’t negatively impact or reverse a previous feature or fix.
The software and app development space is full of jargon and sometimes confusing language. It’s imperative that Salesforce admins and other business users distinguish between those terms to make sure they’re allocating time, resources, and energy to the right activities and ensure their Salesforce apps perform at their peak consistently. Learn more about regression testing in this free webinar or schedule your free, personalized demo today.
Sometimes it can feel like software and app development teams live in a world of their own. They have their unique ways of working, a distinct culture, and even their own language. Technical business users like Salesforce administrators, who often work in the space between IT teams and everyday team members, have the challenging task of serving as something of a translator between the groups. But learning a new language is difficult. While most learners are able to nail down vocabulary, they often still struggle with the nuances of different terms and expressions.
And in the software world, early- or mid-career Salesforce admins—who may not have had a ton of exposure to the mysterious ways of software development teams—might confuse more technical terms or use them interchangeably when they shouldn’t. That’s especially true when they’re talking about debugging and regression testing. While many people think they’re completely synonymous terms, they’re actually two distinct parts of the same process. Here’s a look at what they really mean, how to use them properly, and the roles they play in your daily responsibilities for making sure your Salesforce apps work as expected.
In the fast-paced world of software development, things break. Low-code apps, like those from Salesforce, make it easier for developers and non-developers alike to configure and launch applications. But they also increase the likelihood of simple mistakes that can lead to big problems.
Debugging is the process of fixing those mistakes. Think of it as sort of like proofreading an essay for spelling and grammar mistakes or re-calculating a balance sheet when the numbers don’t add up. Usually it’s something like a weird sentence fragment or a misplaced decimal that throws your whole project off-kilter. In software development, those mistakes might be something like a missing parenthesis or an extra space in a line of code. But unlike proofreading or reconciling a budget, debugging is an intensely time-consuming process that can take up to 75% of a developer’s productive time because it requires digging around log files and poring over tens of thousands of lines of code for hours, searching for what seems like a needle in a haystack.
With the rise of low-code apps, the process of debugging is increasingly handled by administrators, analysts, and other non-developers. While the where and how of debugging low-code apps is different (admins often have to scour configuration settings or rows of Data Loader CSVs to find a missing character or incorrect ID), the process is no less time intensive than debugging traditional software. The most important thing to remember is that debugging only happens after the application or software fails to execute properly, like how you’d take your car to the mechanic after the “check engine” light comes on rather than before.
Conversely, regression testing helps confirm that a recent configuration update or new deployment won’t adversely affect existing functionality, processes, and workflows of a system before it’s released. That means it’s more like a preventive checkup appointment with your doctor to make sure everything’s okay rather than going for a visit when you’re sick or know something’s not right.
This is an important step for all app development teams, but it’s also especially important for Salesforce administrators to understand and command because Salesforce issues three major releases every year that affect all Salesforce customers and users. Some teams continue to regression test manually, but quickly realize they have to run the same tests repeatedly, which gets increasingly more difficult as their use of the Salesforce platform and integrated low-code apps gets more complex. Plus, they might still overlook important warning signs of an impending problem.
Fortunately, regression testing can be automated. Automating regression testing unburdens teams of tedious, boring, and time-consuming testing and frees them up to pursue higher-value business tasks without sacrificing the quality or performance of their apps. More importantly, automated regression tests can be reused across every app configuration, helping your team detect potential problems before they occur and ensuring that changes in a new release won’t negatively impact or reverse a previous feature or fix.
The software and app development space is full of jargon and sometimes confusing language. It’s imperative that Salesforce admins and other business users distinguish between those terms to make sure they’re allocating time, resources, and energy to the right activities and ensure their Salesforce apps perform at their peak consistently. Learn more about regression testing in this free webinar or schedule your free, personalized demo today.
.png)