Communauté RSS DEV

Qu'est-ce qui empêche encore la QA d'être stratégique ? (Et comment changer la donne)

Le concept de qualité comme responsabilité de tous est bien compris, mais dans la pratique, il reste juste une théorie. Les équipes continuent de déléguer la qualité aux équipes de QA, les développeurs poussent du code sans couverture, et les chefs de produit priorisent la vitesse sur la qualité. Le plus grand obstacle à la qualité n'est pas technique, mais plutôt une mentalité paresseuse et un manque de courage. Les entreprises disent que la qualité est une priorité, mais elles isolent les équipes de QA, et les développeurs disent qu'ils testent, mais laissent 80% de la couverture pour les équipes de QA. La vérité est que tant que les équipes de QA sont considérées comme les "garants de livraison", l'ingénierie continuera à faire des erreurs avec confiance. Trois comportements qui entravent l'évolution sont les équipes de QA comme inspecteurs de code prêt, les développeurs comme personnes de livraison de fonctionnalités, et les chefs de produit comme dispatcheurs de backlog. Chaque rôle doit affronter ses responsabilités de plein fouet, notamment les développeurs qui écrivent du code testable, les leaders techniques qui exigent des tests, et les chefs de produit qui priorisent la qualité sur la vitesse. La structure adéquate pour la qualité existe déjà, mais elle doit être prise au sérieux, et la direction senior est le pilier de la qualité. Le changement peut être difficile, mais le coût de la non-qualité fait plus mal, et la qualité devrait être considérée comme un investissement stratégique, et non comme un coût. En fin de compte, la question est de savoir qui a le courage d'assurer que la qualité est construite chaque jour, dès le premier commit.
favicon
dev.to
What still prevents QA from being strategic? (And how to change the game)
Create attached notes ...