Prevent bugs

Avoiding bugs in testing

The third principle of testing is called "Test early" [Radid 2018-3]. When attempting to apply this strategy in an extreme way, then practices are put in place to prevent bugs from appearing rather than having to write tests and run them to check if bugs have appeared.

This practice is stated in the "Agile Testing Manifesto" [Laing 2016] and is in line with the old adage "Prevention is better than cure".

This can be achieved by integrating quality from the design stage as proposed by SAFe's "Built-in Quality" value [SAFe 2021-26]. However, this prevention approach requires a certain knowledge of the impacts of an element once it is put into production: one avoids touching the embers if one knows in advance that they will burn!

This knowledge can be acquired by reading or by experience acquired in the field, as proposed by the practice of "Gemba" sessions, which can be implemented by the presence of T-Shape collaborators in the team or X-Team type teams. These configurations are theorised by the notions of "Double Loop Learning" [Argyris 1977] [Moustier 2020] and "Panarchy", the concrete implementation of which involves the automation of observables.

Application to test maturity

In terms of bug prevention, the first posture advocated by Extreme Programming [Beck 2000] and SAFe [SAFe 2021-27] is to start with testing. This posture led Kent Beck to develop TDD, which found its counterpart for User Stories with ATDD.

Other practices linked to the code also help to avoid the appearance of bugs, such as pair programming or even mob programming, or defensive programming, which consists of systematically checking for invalid ranges of parameter values when a function or web service is called, with an appropriate warning mechanism to indicate that the calling module clearly contains an error.

One can also think of the implementation of technical mechanisms that avoid doing anything at the earliest, whether it is:

• with a Linter [Promyze 2021] which indicates to the developer a bug in his editor while he is writing the code
• or during compilation or even continuous integration where blocking criteria will stop the delivery process

or any other automatic checks that allow the implementation of a "Poka Yoke" that blocks the progress of the product by highlighting the identified error.

All these practices can be grouped together in the Software Craftsmanship approach [McBreen 2002] [Martin 2008] [Moustier 2019-1] [Moustier 2020] [Kokaina 2019] with techniques such as refactoring [Fowler 1999] to make the code more maintainable.

Still in a strategy where one prefers to prevent bugs rather than check for them, one can also introduce group ideation techniques such as "3 Amigos" or "Event Storming" [Brandolini 2019] which allow the technical people to understand the particular situations to be taken into account by reducing ambiguities, and more globally, the notion of testability and "Pantesting" [Moustier 2020] to allow the whole system to integrate this quality both in the system that generates the product and in the product itself.

The strategy of preventing bugs before they appear can also be applied once the solution is in production, this is called Shift Right Testing. It consists of identifying a bug that is already present before it is detected by users: not seen, not taken! This approach is obviously more complex to implement, but it contributes to customer satisfaction, which is the primary objective of quality [ISO9000 2005].

Agilitest's position on preventing bugs

Agilitest can be part of an ATDD-type approach. However, this tool cannot be the only way to prevent bugs. Indeed, with such an approach, the test pyramid would end up pointing downwards [Craske 2020] to form what is called an "ice cream cone". Agilitest should be combined with other testing techniques, for example following the Emmental slices model [Reason 2006] [Moustier 2019-1] [Moustier 2020].

‍

To discover the whole set of practices, click here.

‍