Qui est en charge? Comment éliminer le contrôle d'accès et améliorer la qualité

Jonny Steiner, responsable marketing produit

Nous sommes sûrs que vous avez déjà vécu un scénario comme celui-ci : vous vous promenez quelque part en public et tombez sur une personne plus jeune portant un t-shirt de votre groupe préféré. Peut-être que votre première réaction est quelque chose comme ça : « Wow, un t-shirt Nirvana ? Je me demande s'ils connaissent des chansons de Nirvana. Semble familier? Alors félicitations, vous avez un potentiel de contrôle d'accès ! Nous disons potentiel parce qu'en aucun cas vous ne devez aller voir les gens et les griller sur leur droit de porter un t-shirt Nirvana. C'est une leçon de vie fournie gratuitement avec ce billet de blog.

Assez avec les généralités, nous sommes ici pour discuter du contrôle d'accès en ce qui concerne les équipes d'assurance qualité et de test. Dans le monde du développement de logiciels, un Gatekeeper est une personne qui contrôle le moment où un logiciel ou une mise à jour est prêt à entrer en production. Cela signifie que dans ce scénario, le contrôleur d'accès assume l'entière responsabilité de la qualité du logiciel. Souvent, ce rôle est joué par un membre dédié de l'équipe de test ou d'assurance qualité.

Qui Releases le Releases?

Les gens demandent souvent aux testeurs quand ils donnent leur approbation pour release. Les testeurs et les développeurs expriment souvent leur frustration lorsqu'ils ont travaillé sur des projets où l'assurance qualité détenait les clés de la release. Placer ce niveau de responsabilité sur une équipe peut entraîner des conflits et des retards.

À un certain niveau, les équipes de test sont fières de cette désignation car elle place beaucoup de pouvoir entre leurs mains. Cependant, cela soulève la question de savoir pourquoi les équipes d'assurance qualité ou de test doivent approuver un release du tout. Certainement pas d'essayer de prendre un coup de pot à l'AQ ou aux équipes de test. Nous savons tous que lorsqu'elles sont placées dans des conditions difficiles, ces équipes font du mieux qu'elles peuvent avec bonhomie et aplomb.

D'un autre côté, placer les testeurs dans cette position en tant que personnes responsables du dernier mot sur releases met beaucoup de pression sur eux.

Regardons quelques-unes des conséquences négatives d'avoir QA comme gardien :

• Tous les goulots d'étranglement - Les équipes de développement sont généralement composées de cinq personnes, une personne étant désignée comme « testeur ». C'est un calcul assez simple de voir que confier à une seule personne la responsabilité des tests et de la qualité peut conduire aux goulots d'étranglement.
• Porter le poids de la responsabilité - Rendre une personne responsable de releases signifie que les autres membres de l'équipe fonctionneront sous la fausse idée que tous les défauts seront détectés dans QA. Peut-être même pire, cela leur donne également la possibilité de ne pas assumer la responsabilité des bogues qui entrent en production, car ils peuvent simplement le blâmer sur l'assurance qualité.
• Personne n'est parfait, pas même les testeurs - Mieux vaut ne pas baser tout votre release processus sur une personne trouvant TOUTE les bogues. Ils sont humains et vous aussi, et les humains font des erreurs.
• Boucles de rétroaction - Dans le modèle de gardien, lorsqu'un développeur termine sa part dans le processus, ils le remettent au testeur ou à l'assurance qualité, puis passent à leur projet suivant. Cependant, lorsque les commentaires inévitables arrivent en, ils devront revenir en contexte à la fonctionnalité précédente. Cela peut entraîner un gâchis de projets à moitié démarrés et arrêtés.

L'alternative au Gatekeeping est le Gatebreaking

Il existe des moyens d'exécuter des tests qui garantissent que vous release applications de qualité sans avoir besoin de contrôle d'accès. Si vous confiez le travail d'assurance qualité à toute l'équipe de développement, vous les rendrez tous responsables de la qualité. Le QA peut toujours être responsable des tests, mais il y a plus de tests à faire et d'autres membres de l'équipe peuvent aider.

• Les développeurs peuvent couvrir le travail qu'ils font en écrivant leurs propres tests unitaires.
• Les chefs de produit peuvent vérifier les environnements de mise en scène pour s'assurer que les nouvelles fonctionnalités fonctionnent comme elles ont été exécutées.
• DevOps les responsables peuvent utiliser les systèmes CI pour surveiller les tests à mesure que chaque nouveau code est validé.

Vous pouvez commencer à mettre en œuvre cette pratique simplement.

Commencez par une session avant que le travail de développement ne commence sur une nouvelle fonctionnalité. De cette façon, les développeurs et les testeurs peuvent entrer dans le sprint en comprenant ce qu'ils doivent faire pour prouver que le travail a été achevé selon les critères d'acceptation. Le travail étant discuté à l'avance, la charge de travail sera répartie uniformément au sein de l'équipe et les tests d'API étant écrits par les développeurs, l'assurance qualité peut travailler sur l'interface utilisateur et les tests fonctionnels.

Au fur et à mesure que le projet progresse et que l'équipe trouve un problème à résoudre, ils peuvent en discuter entre eux ou entre équipes. Par exemple, si l'AQ découvre un défaut, ils peuvent le signaler aux équipes de développement de produits pour voir s'il s'agit de quelque chose qui nécessite une attention immédiate ou s'il peut attendre.

Mieux encore, à mesure que de plus en plus de personnes s'impliquent dans un projet et participent aux tests, cela conduit à une mentalité de gauche dans laquelle les tests sont effectués le plus tôt possible dans le processus. Personne n'a besoin d'attendre un moment précis pour commencer le test, cela devient simplement un aspect de la routine quotidienne des gens. À long terme, cela devrait aider à minimiser les risques vers la fin du cycle de développement

En fin de compte, cela conduit à plus de tests qui se traduisent par une meilleure couverture car cela permet aux équipes interdisciplinaires de communiquer entre elles plutôt que de rester dans leurs propres équipes cloisonnées. Si les équipes cloisonnées sont un problème dans votre organisation, vous pouvez même en parler avec les propriétaires de produits et les parties prenantes. La promotion de la communication et de la collaboration est extrêmement importante lorsque l'on s'occupe d'une situation de contrôle d'accès.

Les résultats ressembleront alors à ceci :

• Responsabilité partagée – Sans personne responsable, toute l'équipe assume la responsabilité de fournir un logiciel de qualité.
• Adieu les goulots d'étranglement - Ce n'est plus une personne qui teste contre le monde. Avec tout le monde qui teste, les nouvelles versions et applications seront mises en production plus rapidement.
• Resserrement de la boucle de rétroaction – Plus de changement de contexte lorsqu'un défaut est découvert. Les défauts seront découverts et atténués au début du processus, éliminant ainsi tout retard de production.

Le contrôle d'accès dans QA est une relique

Cela arrive encore dans certaines organisations. L'AQ est responsable du projet release et détient les clés du release. Cette pratique néfaste exerce une pression sur les testeurs et conduit à de mauvaises relations entre les équipes cloisonnées car elles travaillent séparément vers un objectif sur lequel elles ne collaborent pas.

Il existe deux principaux scénarios négatifs lors de la pratique du contrôle de l'assurance qualité :

1. Projets retardés – Comme QA bloque certains petits problèmes avant release.
2. Défauts de fabrication – Chaque fois qu'un bogue passe entre les mailles du filet, le QA est le bouc émissaire car il est considéré comme responsable de la qualité globale.

Pour se débarrasser de cette méthode de développement et de test désuète - et franchement anti-collaborative -, les équipes doivent faire en sorte que tout le monde sur le projet travaille sur les tests au fur et à mesure de leur développement, plutôt que de laisser l'assurance qualité être responsable de tout cela. Ils doivent également se déplacer vers la gauche et tester tôt et souvent. Avoir cette compréhension de base aidera les organisations à créer un système où chacun peut faire sa part et la qualité globale de leur releases s'améliorera également.

La qualité en tant qu'objectif et en tant que concept doit être l'un des fondements du flux de travail d'une équipe. Cela doit également être quelque chose auquel participent tous ceux qui sont impliqués dans un projet. Si vous voyez un cloisonnement ou un manque de coopération entre les équipes commencer à apparaître dans votre entreprise, vous devriez en parler avec ceux qui sont en mesure de changer cela. Lorsqu'une équipe d'assurance qualité se concentre sur le contrôle d'accès, la qualité globale de votre application en souffrira, et c'est dommage car le mot est littéralement dans son titre.