Fitting In Regression Testing by Shifting QA Left

In the QA field, ensuring a quality product through our testing is a great responsibility. But being in QA comes with great power to make that happen—you just have to be willing to try.

A few years back, I joined a software startup as their first QA intern. I was thrown right into the mix, testing software apps with real test cases and defect tracking.

We were testing every button, filter, click, and navigation. I even listed all the test items in a spreadsheetand started testing them one by one to ensure their quality. If I found any issue, I would go straight to that feature’s particular developer and inform them so we could get it worked out.

During that period, the team had back-to-backsoftware releases to production. We were pressed for time, so I was constantly doing QA activities. I completed the first test execution cycle and reported the identified issues and test results. After the developers fixed the issues, I retested the feature to confirm the fix and closed the defects, and our software product went live.

It was nerve-wracking and invigorating at the same time. Software is being released to production on my call: “Yes, we are good to go live!” That is the day I realized QA has power. 

After one release, the next release to production was scheduled for a day or two later, and within that brief period I planned and designed more test cases. Throughout the test execution I identified and reported issues to get fixed. After the bug fixes, I retested and closed the defects, just like in the last production release. But this release was nothing like the previous one. 

The day after we published the changes to production, we had a meeting to demonstrate the new changes to stakeholders. I was self-assured about my testing, so I wasn’t worried. The session started with a basic overview of the system, and then the presenter started the demo. From that run-through, everyone in the room identified a few defects, one of which was critical. The stakeholders were nice enough to understand and did not create any issue for me, but I was astounded.

I had been so confident in my testing. What happened?

The Great Regression

I didn’t identify those defects because I didn’t know at the time that changes to some parts of the software could also affect the unchanged parts of the system.

Changes to code can come with degradation in the quality of the software, known as regression. Sometimes, fixing one area of the software will break something in another area due to dependencies and other connections.

To detect whether defects have been introduced in seemingly unchanged areas of the system, we need to perform regression testing—executing certain test cases again to confirm that a change has not adversely affected other existing features. 

I went to the team and raised the regression issues in our software product. I suggested that we plan regression testing prior to any production release, but there were a few hurdles. 

The major obstacle was time. We did not have time to schedule a regression testing cycle prior to every production release.

I revisited my previous testing timeline and analyzed how much time was being spent planning, designing test cases, and setting up the bug tracker. Less time was given to test execution. Instead of planning, designing, and discussing, I should be running tests on the actual product.

That’s when I realized that I had to divide my pre-testing time, testing time, and post-testing time. I proposed to the team that we exclude planning and designing from our testing timeline by doing these activities before official testing began.

Shifting QA Left

To do that, I had to be involved as QA in the earlier phases of product development. 

I needed to be there when the stakeholders were explaining the business needs, software requirements, functional specifications, and every other detail related to the software product that I am supposed to test. I told developers that any change being made to the software code should be shared with me as well, because it really helps to know exactly what has been altered and why.

I figured these changes to start shifting QA left in the software development lifecycle were what I needed to plan my regression test coverage prior to every production release. Our project manager valued the honesty and agreed to give this experiment a trial run so we could observe the outcome.

A week passed, and prior to the production release, I executed my regression test cases. Sure enough, they identified some defects to report, which significantly helped the software product quality. 

As time went by after this demonstrated success, our team got to the point where no build was being deployed to production without going through the regression testing cycle. Everyone on the team understood that with every new change made to software comes regression in the software code. 

Being a QA analyst is a power and a responsibility. It’s not just about doing what we’re asked to do, but also questioning why we are doing it. If something is not right or can be improved upon, then it is our responsibility to refine and enhance our testing and other quality assurance activities.

I would like to encourage new testers or aspiring QA engineers to examine what you’re doing, ask questions about what you don’t understand, and strive to discover if your processes can be improved. The quality of your product will thank you for it.