Regression testing, one of the most important yet neglected Testing type. Why? Because we are bored of it. Why bored? Because we do it incorrectly or don’t follow the best practices. Most of the time it results into wasted efforts – repeated testing without any qualitative results. Have you ever tried to revamp your regression approach? Or to actually work on the challenges faced? Most of us ignore regression testing – it can be taken care by automation. But even automation isn’t useful if other best practices are not followed. It just adds up to your wasted efforts. Let’s see why regression testing is important, the challenges faced and what can be done about it, i.e. the best practices.

What is Regression Testing and why it’s important?

Ever heard of the ‘functions’ concept in the programming world? No? Say you are building a payment platform where the most common functionality would be ‘Initiate Payment’. Every other functional flow will need a payment to be initiated first. What do you do? Program it in every other functional flow? No, right? Just create a function called ‘Initiate Payment’ and use it in all different workflows. Seems logical, right?

Now we are testing this Payment platform. All test cases have been executed, defects logged, fixed, retested and closed. The platform is successfully deployed for end-users.

User A initiates a payment type A successfully but gets an error when initiating the other payment type B. What the heck! User A reports the issue and decides to opt for another platform instead.

During analysis it is observed that a similar defect was raised for payment type A. Huff! At least we have a defect raised. But it was fixed, retested & closed. And it was for Payment type A, no such defect was raised for Payment type B – it was working perfectly fine.

What do you think had happened?

Yeah! A defect was raised for Payment type A but during debugging it was identified that there is a bug in the common function ‘Initiate Payment’. So the bug was fixed and retested for Payment A (for which the defect was reported). What everybody missed is that the same function was being used in other payment type’s initiation flow as well. The fix worked for Payment type A but not for Payment type B (say there was an additional mandatory field here).

Whose fault is it?

Definitely developer, right? Haha! Congratulations! You are half-right 🙂 Software delivery is a collaborative effort from the development and testing team. A successful delivery requires both development and testing to go hand-in-hand. Hope you got the point 😉 It’s as good a miss from the Test team as from the developer. After all, Test team act as the ‘Quality Gate’ to sign-off the final build for Go-live.

How this could have been avoided?

A comprehensive Regression Testing. How? Because the sole purpose of Regression Testing is to find the ‘Side-effects’. Yeah! The side-effects of any changes to the build – be it an enhancement, defect fixes, infrastructure change, change requests, optimization, or any kind of code addition/deletion/modification. Functional Testing and Defect retesting focus on the requirements and defect fixes, but what if the code changes have had a side effect on the existing working functionality? Whenever developers change or modify their code, even a small tweak can have unexpected consequences, as in the case above…That’s where Regression Testing comes into picture!

Regression Testing

Regression testingis a type of testing that is carried out to make sure that any changes to the software product didn’t result in any additional defects (side-effects) in the existing functionality that was working perfectly fine earlier. In other words – to identify the defects in related functionalities that creep in after the code changes to an already tested functionality.

As you might have guessed, Regression testing is usually performed at the end of functional testing cycle when all the required changes and defect fixes have been completed and no further change is expected.

The catch in Regression Testing

There is one catch here though – many a times even after completing the regression tests there might be a case that a related defect is encountered by the end-user in the production environment. Any idea why? Yeah! Because though important, still Regression testing is one of the most neglected concept in Software Testing. It is not given its share of due importance – proper planning, impact analysis, Test case prioritization, Automation, etc. We will have a close look at each of these Regression Testing challenges and corresponding Best practices in our future articles….

Any technology or tool is worthless unless it is being used by ‘some’ organization somewhere. It all starts from organizations adopting the new technology or a tool and then it gets popular slowly. In that sense QA Job Descriptions are a great source of current technology, i.e. practical tech. being used by IT organizations. Be it Selenium, Protractor, Appium, API tools, Big Data Testing, etc. Everything is embedded in the QA Job descriptions, you just need to mine some data 😉 But don’t worry. Continuing on our “JD Talks” series – we mine hundreds of QA Job descriptions to come up with latest tools, technology, languages and concepts. Let’s see what the fourth set of JDs talk about…

Once upon a time we had a finicky client manager with no understanding of testing logic. He just wanted us [a team of 4] to execute thousands of test cases in a week, that too maintaining quality. Is it possible in any real-world? No, right? There was a tiff between the Test Manager and Client Manager and that’s when I got the real-time exposure to Risk-based Testing, a win-win idea!

Regression Testing is really important, but I have some comments regarding the example you have given.
1. The problem was detected in payment type A during debugging while in while in in payment type B you didn’t detect the defect. First of all I would like to emphasise that debagging is not testing there is a big difference between the two activities and you should know it. That’s the reason that you didn’t detect defects in payment type B.
2. In your case Regression Testing will not help to uncover the hiden defect because the Regression Testing will execute over the test cases you you already done first time.
2. So before going to Regression Testing you should improve your testing process starting from planning, Test strategy,Trceability between requirements to testing, test purpose/goal, test design and …

Are you a Manual Tester? A Test Lead? Good in people’s management? Or Planning? Whatever! You still need to know the basics of programming and automation tool. You need not be a framework-developer, but every organization now wants a Software Tester who knows both functional test + automation scripting!

The Defect Severity (Technical) - In simple words, how severe is the defect for the application’s quality? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right?

The Defect Priority (Business) - In simple words, what is the precedence, importance or urgency to fix a defect? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right? But how many of us really click the ‘Help’ link? Business usage statistics show less than 2%. Now what do you think should be the urgency to fix a defect that impacts just the 2% of the end-users? Yeah! Not ‘High’ obviously. There would be other urgent defects to fix prior to this. Defect Priority defines the order in which defects should be fixed, i.e. its impact to the end-users, the business perspective.

About STS

Software Testing Studio is an attempt to share some incredible knowledge from industry leaders & experts, which should be helpful for anybody to start his/her career in ‘Software Testing’ or to progress it further. Apart from the technical nitty-gritties, one can also find some intellectual posts by industry experts sharing their Wisdom.