L'équipe est responsable de la qualité du produit

Qualité du produit et organisation de l'équipe

Dans une organisation de type Waterfall, la qualité est déléguée aux testeurs tandis que les développeurs construisent le produit par eux-mêmes. Par conséquent, les testeurs sont les propriétaires du feu vert à la production. Malheureusement, cela conduit à une situation où la qualité ne dépend que de quelques personnes, tandis que les développeurs ne sont pas les seuls. 

• Les développeurs pourraient être plus nombreux que les testeurs 
• Les développeurs génèrent involontairement (espérons-le !) beaucoup de bugs et il en reste beaucoup, même s'ils se soucient de la qualité [Sandu 2018].

Non seulement les développeurs laissent des traces de bugs dans leurs artefacts, mais chaque acteur du cycle de vie du développement logiciel (SDLC) en génère au cours de chaque activité [Beizer 1994] [Moustier 2019-1] :

‍

Le SDLC peut être vu comme une pile de tranches de fromage suisse avec des trous qui permettent à bugs de passer en production [Reason 2006], chaque tranche étant une opportunité de test avec ses propres défauts [McConnell 2004] [Moustier 2019-1] :

Par ailleurs, il apparaît également qu'une approche collective sur les tests est beaucoup plus efficace [Ferguson 01-2017] [Moustier 2019-1] :

Ces chiffres conduisent à une conclusion simple : 

"La qualité est la responsabilité de tous" - W. Edward Deming

Impact de la qualité du produit sur la maturité des tests

Les tests ne sont pas quelque chose à faire seul et la collaboration facilitée par un langage ubiquitaire améliore l'efficacité des tests. Elle permet également d'éviter les erreurs dues aux biais cognitifs [Stevenson 2016] [Moustier 2019-1]. C'est notamment pour cela que 3 Amigos ou Example Mapping sont si efficaces. De plus, impliquer tout le monde dans les tests ne devrait pas seulement regrouper les gens dans leur propre silo de compétences pour limiter le WIP, c'est pourquoi les T-Shape people sont si importants.

Pour faciliter la collaboration autour des tests, il faut également intégrer la qualité [SAFe 2021-26][SAFe 2021-27], notamment grâce à la testabilité du backlog à chaque composant et au partage des connaissances, notamment par le biais des communautés de pratique et, plus largement, d'une approche PanTesting.

Le point de vue d'Agilitest sur cette pratique

Agilitest étant facile à apprendre grâce à l'approche #nocode [Forsyth 2021], l'utilisation des tests d'automatisation peut être étendue à tout type d'acteur du SDLC. Cela réduit l'effet de silo sur l'automatisation.

Cependant, l'automatisation ne doit pas être la seule stratégie de test à appliquer. Comme nous l'avons vu ci-dessus, différentes techniques de test doivent être combinées pour chasser bugs et ne négliger aucune piste.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍