Un QA ne devrait pas être séparé de l’équipe de développement
On voit souvent dans les entreprises les QA totalement dissociées des développeurs-ses.
J’arrive à trouver quelques raisons :
▶ avoir une vision externe sur la qualité de ce qui est produit
▶ permettre une dernière vérification avec un regard neutre
▶ trouver des nouveaux scénarios de tests sans être biaisé et influencé
▶ standardiser les connaissances et processus de validation et de reporting des QA
▶ gérer la capacité de travail d’une seule équipe vis-à-vis de fonctionnalités provenant de plusieurs projets
Cependant, ce format d’organisation génère beaucoup plus d’effets négatifs que positifs !
1️⃣ Des conflits entre les différentes équipes
Le fait d’endosser un rôle de vérification et d’audit sur ce qui est produit par d’autres peut générer de la compétition et des frictions.
Cela est d’autant plus vrai si le reporting des QA manquent de transparence envers l’équipe de développement.
2️⃣ Un délai de livraison accentué En effectuant une validation avec une équipe complètement dissociée, on crée une dépendance qui empêche de passer en livraison continue et qui peut provoquer un goulot d’étranglement.
3️⃣ Des pertes de temps et du travail inutile
On se retrouve à créer de l’inertie avec des échanges asynchrones et des changements de contextes qui viennent perturber la productivité.
Les équipes ne partagent pas le même niveau d’informations et certaines actions peuvent être faits en double : réunion, recueil des besoins, tickets, tests…
4️⃣ Une déresponsabilisation de l’équipe de développement Le fait de tester ce qui est développé d’un côté amène à en faire moins de l’autre. L’équipe initiale, perdant la responsabilité de valider soi-même son travail, finira par accepter et déléguer cette responsabilité.
Amenant une perte de qualité globale du code produit.
𝐏𝐨𝐮𝐫 𝐞́𝐥𝐢𝐦𝐢𝐧𝐞𝐫 𝐜𝐞𝐬 𝐩𝐫𝐨𝐛𝐥𝐞́𝐦𝐚𝐭𝐢𝐪𝐮𝐞𝐬, 𝐥𝐚 𝐬𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐞𝐬𝐭 𝐬𝐢𝐦𝐩𝐥𝐞 : 𝐫𝐚𝐬𝐬𝐞𝐦𝐛𝐥𝐞𝐫 𝐚𝐮 𝐥𝐢𝐞𝐮 𝐝𝐞 𝐝𝐢𝐯𝐢𝐬𝐞𝐫 !
L’équipe qui développe devrait :
▶ maitriser toute la chaîne du développement au déploiement des fonctionnalités, sans dépendances
▶ garder la responsabilité de valider, tester et de gérer la qualité du travail qu’elle produit
Le besoin d’un QA devrait être remonté par l’équipe elle-même et non par la direction.
Et, ce dernier ne devrait pas endosser un rôle d’audit une fois les fonctionnalités “terminés” mais plutôt supporter l’équipe dans la réalisation des typologies de tests manquants durant la phase de développement.
En favorisant la collaboration et intégrant le QA à l’équipe, on peut :
▶ éviter de faire des actions inutilement en double
▶ gagner du temps sur le développement et la livraison des fonctionnalités
▶ avoir une boucle de feeedback beaucoup plus rapide
▶ permettre au QA de mieux contribuer au développement et à la qualité du projet
▶ créer une complémentarité et améliorer les compétences des devs ET des QA
L’intérêt d’un QA n’est pas juste de faire ce que les devs ne font pas, mais de leur donner la possibilité de faire mieux !