Can you imagine making the COVID-19 vaccine available for the general public without properly testing it? That’s right, you can’t – because that would put at risk the lives of billions of people.
In software development, there are no human lives at stake. However, having your project ruined due to inadequate testing can bring significant financial damage to your business and result in job losses.
We’ve often seen cases when clients compromised on software testing as the result of their budget constraints. If you had to eliminate certain types of testing from your process, we’d suggest that you keep regression testing at the very least. Why? Well, as your project progresses, new features will be added inevitably. Regression testing in the Agile process ensures that nothing gets broken with the new code updates and the old product features operate as they’re supposed to.
At UTOR, we perform Agile regression testing to help software teams ship their software updates faster. We’d like to share some of the things that we’ve learned over the years, so here are some things you might be doing wrong in regression testing.
Testing Separate User Stories
Even after a minor software update, your code might seem safe and sound, but your user stories may very well be affected. This means that despite your software operates as it should, the user behavior can be different from the intended.
Adding a new user story can be like playing a house of cards: add one of them, and the others can be negatively impacted by it. You might not be able to tell the difference if you don’t test user stories altogether.
Doing It All Manually
Agile workflow implies using short delivery sprints, meaning that testing occurs periodically, preceding every production release. With more functionality added to the feature list, the number of user stories grows exponentially, adding up to your initial costs for regression testing.
So are you still considering whether you need automation for your regression testing strategy in Agile? The answer lies on the surface.
There are several ways you can go about doing it, using selective, progressive, or complete regression testing – we covered that in our article on the types of regression testing. Consider automating the one that you use on a regular basis!
Although your initial testing time might somewhat increase (since you need to spare some development efforts to automate things), you’ll eventually get to enjoy the full benefits of your automation testing initiative.
Leaving It All for the QA Team
We’ve debated in our previous articles whether software testing needs to be the sole responsibility of the QA team. While different companies tend to have different opinions in this regard, our view is that involving the software development team in the testing process brings lots of benefits.
Developers are the ones who write code: they already know what their code is supposed to do so it’d take them less time to create a corresponding test.
It’s a good practice to ask the development team to assume partial responsibility for the code they produce: that would encourage writing high-quality code with fewer errors in the first place.
Using Outdated Test Cases
Even seasoned testers are known to make this mistake, although this issue has more to deal with the lack of communication.
Test cases describe the expected system’s output and must be updated whenever software requirements change. In the Agile, dynamic environment, everything changes rapidly, and some things naturally can get overlooked sometimes.
Regression testing is an excellent opportunity to review your existing documentation, using important regression test selection criteria to revise your current test cases, or even make new ones.
Introducing Too Many Changes
Regression testing in Agile development is known for its flexibility to adapt to client requirements. However, introducing too many changes within a single sprint might be challenging from the QA perspective: there might be just not enough time to adapt your testing strategy.
Not Using Smoke and Sanity Testing
Regression testing shouldn’t be performed before smoke and sanity testing take place. It might seem like an extra step to take but it’s totally worth it: the main purpose of smoke and sanity testing is to identify broken modules of software so that the QA team doesn’t waste time on that. Here is how it works.
Smoke testing verifies that the most essential software components operate as they should. If the software build works as intended, it’s a green light to proceed to the next stage (which is regression testing). Smoke testing is a “gatekeeper” that prevents the QA team from wasting their time on testing any parts of software that are not ready yet for extensive testing.
Read more: Smoke testing Vs. Regression Testing [Reviewed and Compared]
Sanity testing is usually performed when the QA team inspects the code after bug fixes. The main purpose of this kind of testing is to ensure that all the issues have been successfully resolved. It’s called “sanity” testing as it checks whether there’s certain reasoning behind producing a certain piece of code. For example, if the website isn’t properly optimized for mobile devices, there’s no reason for checking its laptop responsiveness.
Using smoke and sanity testing will significantly optimize your regression testing efforts.
Being Guided by the “Tribal Knowledge”
Risk management teaches us to prioritize software testing, and rightfully so. At times, the QA team can push non-essential testing to the next release so the project can be delivered on schedule (if you take the words of your scrum master for granted).
However, getting in the habit of something like that can backfire eventually. Your testing debt will start increasing, and as a result, you end up having a large backlog of untested functionality. Here is our advice: trust your project documentation (and scrum master!) but use common sense as well.
The Bottom Line
The importance of regression testing in Agile is all about business continuity and the uninterrupted flow of QA services. But one important thing to keep in mind: your Agile regression testing gets as good as the QA team following it. At UTOR, we love Agile! In fact, 99% of our projects are built around the Agile workflow – learn more about our regression testing services!
