A Good Software Testing Process Should Effectively Prevent the Recurrence of the Same Defects in New Releases

Take an Engineering Mindset towards your E2E Testing.

A repost of my past article on Medium in 2024.
(boosted: high-quality, selected by Medium curators)

Today, my daughter discovered that one of the LinkedIn email updates she received was evidently incorrect.

The subject line still contains {:replace_token}. Clearly, the LinkedIn testing team missed one scenario to test.

This article in no way questions a software giant’s testing capability. This can happen to any company; certainly, my own apps had it (but I implemented a process; see below). Human beings make mistakes. We cannot totally prevent defects in software (developers produce them, and testers miss some). However, if a software team (along with its customers) encounters the same defect recurring now and then (in different builds), it is wrong.

A well-established testing process within a software company should effectively prevent the recurrence of the same defects in future releases. This is easy to understand. For instance, despite the inevitability of aviation accidents could happen, we feel safe when flying. Why? Because we have faith in the engineering process, particularly the rigorous quality assurance (QA) procedures in place. In the event of a plane-fault-related incident, airlines and aircraft manufacturers diligently investigate the cause, ensuring transparency throughout. Any fixes implemented must meet the stringent standards set by aviation authorities before the affected plane can resume flight. This epitomizes the essence of engineering.

In the software world, sadly, those engineering measures are hardly implemented.

How would I solve a case like this?