Product quality and team organisation
In a Waterfall-like organization, quality is delegated to Testers while Developers build the product on their own. As a result, Testers are the owners of the green light to production. Unfortunately, this leads to a situation where quality depends only on few people while
- Developers may outnumber Testers
- Developers generate unintentionally (hopefully!) a lot of bugs and a lot of them are left over, even when they care about quality [Sandu 2018]
Not only Developers leave some bugs in their artifacts, every actor in the whole Software Development Life Cycle (SDLC) generate them during each activity [Beizer 1994] [Moustier 2019-1]:
The SDLC can be seen as a stack of swiss cheese slices with holes that let bugs go to production [Reason 2006], each slice being a testing opportunity with their own flaws [McConnell 2004] [Moustier 2019-1]:
Moreover, it also appears that a collective approach on testing is much more efficient [Ferguson 01-2017] [Moustier 2019-1]:
These figures lead to a simple conclusion:
“Quality is everyone’s responsibility” - W. Edward Deming
Impact of product quality on the testing maturity
Testing is not something to be done alone and collaboration facilitated by a Ubiquitous Language improves testing efficiency. It also prevents fallacies from cognitive biases [Stevenson 2016] [Moustier 2019-1]. This is notably why 3 Amigos or Example Mapping are so efficient. Moreover, involving everyone in testing should not only cluster people in their own competence silo to limit WIP, this why T-Shape people are so important.
To ease collaboration around testing should also be done with built-in quality [SAFe 2021-26][SAFe 2021-27], notably thanks to testability from the Backlog to every component and knowledge sharing notably through Communities of Practice and more widely a PanTesting approach.
Agilitest’s standpoint on this practice
Since Agilitest is easy to learn because of the #nocode approach [Forsyth 2021], the use of automation testing can be spread to any kind of actor of the SDLC. This reduces the silo effect on automation.
However, automation should not be the only testing strategy to apply. As seen above, different testing techniques should be combined to chase bugs and leave no stone unturned.
To go further
- [Beizer 1994] : Johnson, Mark : « Dr. Boris Beizer on Software Testing : An Interview Part 2 » - The Software QA Quarterly, Summer 1994, 41-45
- [Ferguson 01-2017] : John Ferguson - « Behaviour Driven Development at the heart of any DevOps transformation story » - http://johnfergusonsmart.com/wp-content/uploads/2017/07/bdd-at-the-heart-of-devops.pdf
- [Forsyth 2021] : Alexander Forsyth – JAN 2021 - « Low-Code and No-Code: What’s the Difference and When to Use What? » - https://www.outsystems.com/blog/posts/low-code-vs-no-code/
- [McConnell 2004] : Steve McConnell - « Code Complete - a practical handbook of software construction » - Microsoft Press - 2004 - ISBN 0-7356-1967-0
- [Moustier 2019-1] : Christophe Moustier – JUN 2019 – « Le test en mode agile » - ISBN 978-2-409-01943-2
- [Reason 2006] : James T. Reason - « Revisiting the "Swiss Cheese" Model of Accidents » - Eurocontrol - Oct 2006 - http://www.eurocontrol.int/eec/gallery/content/public/document/eec/report/2006/017_Swiss_Cheese_Model.pdf
- [SAFe 2021-26] : SAFe - FEV 2021 - « Core Values » - https://www.scaledagileframework.com/safe-core-values/
- [SAFe 2021-27] : SAFe - FEV 2021 - « Built-in Quality » - https://www.scaledagileframework.com/built-in-quality/
- [Sandu 2018] : I-A Sandu & Alexandru Salceanu & O Bejenaru - AOU 2018 - “New approach of the Customer Defects per Lines of Code metric in Automotive SW Development applications” - https://www.researchgate.net/publication/328898634_New_approach_of_the_Customer_Defects_per_Lines_of_Code_metric_in_Automotive_SW_Development_applications
- [Stevenson 2016] : John Stevenson - « The Psychology of Software #Testing » - Leanpub - 02/02/2016 - https://leanpub.com/thepsychologyofsoftwaretesting