How Do You Prevent Regression Defects?

I was talking a while ago with a workmate, hearing him complaining by the big number of regression defects he's identifying each time a new build gets to the QA environment.

Let's call him Bob.

And to make things clear from the very beginning, Bob was not complaining by the fact he's finding defects during testing, nor the fact that he needs to carefully test the features, on the contrary, Bob was thrilled by his job and was feeling quite proud that he was the final gate in the delivery process.

Bob was upset that he was finding the same defects he checked and closed weeks before and those bugs kept reappearing with the same behavior. And Bob was starting to question the quality of his job, the trust he's having in his developer workmates and his role in the team.

After talking with Bob several times and encouraging him to reach out to the developers within his team helping him find a solution for his problem, one day I asked Bob the following question:

"Are the developers writing unit and integration tests for the defects they're fixing?"

But Bob didn't quite know and started to dig into GitHub to check the commits with the latest defects fixes and the latest features that were developed and pushed to the master branch. And this is what he found.

For (some of) the new features:

And (some of) the bug fixes:

As you might suppose, the answer to my question came quite easy. No, the developers were not adding unit nor integration tests, at least for several features and bug fixes they pushed to master branch (⚠️ good to be kept in mind that not adding unit and integration tests was not a rule, but happened in several cases).

Before going forward we should all agree upon the following statements:

💡Unit testing improves the quality of the code. Period.

💡Unit testing is good for identifying any potential defects that may have been introduced with the new code.

💡Due to unit testing, defects are found at an early stage, hence it reduces the cost of fixing them.

After finding out those aspects, Bob adopted two approaches. A reactive one and a proactive one.

➡️ Bob asked to be added as a reviewer in the developers' pull requests.

Like said, this was more like a reactive approach, as being the policeman in the team is not always the best thing. But Bob tried to supervise the unit and integration tests creation and sometimes helped the developers in having a better discipline with regards to that, by explaining them why it is so important to have this level of testing too.

It's worth mentioning that the pull requests were not requesting Bob's approval before being merged, it only helped in offering him a better overview of what's getting pushed to the master branch.

➡️ Bob offered himself to assist developers in writing unit and integration tests.

Has started Bob to write unit and integration tests on his own? No. But instead, he offered his support in assisting and discussing with the developers the scenarios he as a tester has thought to test.

Another thing that someone in Bob's situation can do is to share the test cases that you have written to help the developers get better coverage with his/her unit tests. But this is not always working, as requires much more effort from the developers in going through all the test cases etc.

Also, by assisting the developers, you might observe an improvement in the team spirit and in many cases, a stronger developer-tester relationship is being built.

Conclusion:

Every time I'm hearing stories as Bob's one, I'm trying to identify those small details which can have a big impact without creating too much discomfort in the team. Bob's initiatives created some rumors at the beginning, but after a while, the team members understood that quality matters.

And as a fun fact, I had many discussions with Bob since then, but haven't heard anything about the "regression defects reappearing again and again".

Worth mentioning that Bob's team was including four developers and one team lead that has given his support to Bob's initiatives.

Bob's initiatives may not work in all the circumstances, that's why I think is good for you as a tester to maintain a good communication with your teammates and find the solution that suits your context best.

🛎️ If you liked this article, and such as me, you're a fan of prevention rather than treatment, find here another article talking about how we can deal with untested code.

Photo credits: Parvana Praveen