Booster la productivité : un guide pour la mise en œuvre d'un nouveau rôle d'assurance qualité pour des versions plus rapides

Salut!

Je suis ravi de partager comment j'ai réussi à améliorer notre flux de versions de 20 % grâce à la mise en œuvre d'un rôle d'AQ système.

Étant donné que mon entreprise est une entreprise de produits typique, les équipes ne sont pas divisées par produit mais par composants. Grâce à cela, d'une part, nous avons réussi à former des équipes puissantes avec des "détenteurs" de connaissances. Mais d'un autre côté, les rôles au sein des unités sont relativement isolés et les différents ensembles de compétences techniques et d'expertise imposent leurs limites. Par exemple, j'ai parfois besoin de déplacer un testeur de l'équipe backend vers le frontend ou vice versa.

Cela a conduit au fait qu'il y avait une question d'orchestration efficace au sein des équipes d'assurance qualité et de gestion de l'interaction entre les équipes. Ce qui, bien sûr, a finalement affecté le flux de publication.

Flux de publication avant les modifications

Avant les modifications, notre flux de publication ressemblait à ceci :

1. Une spécification des exigences commerciales (BRS) est un document qui décrit les besoins, les attentes et les spécifications détaillées d'une fonctionnalité, d'un système, d'un produit ou d'un projet spécifique au sein d'une entreprise. Il sert de pont entre les parties prenantes de l'entreprise et les équipes de développement ou de mise en œuvre, garantissant une compréhension claire de ce qui doit être réalisé et de la manière dont il s'aligne sur les objectifs commerciaux globaux. Il doit contenir des scénarios détaillés qui décrivent comment les utilisateurs interagiront avec la fonctionnalité. Le Feature Owner (FO) est chargé de formuler les exigences commerciales.
2. Une spécification des exigences logicielles (SRS) est un document complet qui décrit la description détaillée de ce qu'un système logiciel est censé accomplir. Par exemple, comment et quelles commandes interagissent, par quel protocole et quelles données seront transmises. Si l'équipe travaillant sur la fonctionnalité utilise une interface graphique, le SRS doit inclure les mises en page de la fonctionnalité en cours de développement. L'architecte de fonctionnalité est responsable de l'écriture du SRS.
3. Plan d'action qualité (PAQ) - un ensemble de cas qu'un propriétaire de fonctionnalité vérifie avant d'accepter une fonctionnalité. Une fois les documents décrits, nous procédons à l'implémentation de la fonctionnalité. Lorsque la première équipe a fini de développer et de tester sa partie de la fonctionnalité, elle est transférée à la deuxième équipe. La deuxième équipe effectue l'intégration/le développement/les tests et le transmet à l'unité suivante. Et ainsi de suite jusqu'à ce que toutes les équipes de composants participant au développement des fonctionnalités passent par ce flux. FO valide la fonctionnalité, et elle est envoyée à la version.

Problèmes de flux de libération

Donc, tout semble aller bien - documents, demandes, cas d'acceptation. Cependant, nous avons rencontré les difficultés suivantes dans ce processus :

Problèmes de la part de QA:

• Les tests d'exigences ne commencent qu'après le développement. Les tâches qui ont déjà été mises en œuvre par les développeurs, ainsi que leurs exigences, sont transmises à l'équipe QA. Mais, comme nous le savons, il peut y avoir des erreurs dans les exigences.
• Trouver l'équipe responsable d'un bogue prend un peu de temps car il n'est pas toujours clair quels cas ont déjà été testés par d'autres équipes.
• Aucune réutilisation des artefacts de test. Dans le cadre du test d'une fonctionnalité, les équipes d'assurance qualité préparent des ensembles de données de test similaires. Mais en raison de l'isolement et de la spécialisation étroite des équipes, elles ne pouvaient pas se transmettre ces données entre elles.

Problèmes de la part de FO :

• En raison des nombreuses fonctionnalités, l'écriture de QAP prend beaucoup de temps.
• La validation de la fonctionnalité intervient après le développement par toutes les équipes. Dans notre cas, cela allonge considérablement le flux de publication en raison de nombreux problèmes d'intégration.
• La préparation de l'environnement de test est également précise du fait de la complexité du produit et du volume d'intégrations entre les équipes. Différentes équipes testent leurs composants simultanément, ce qui augmente les risques de brassage, de modification ou de suppression de données.

Contrôle qualité système dans le flux de publication mis à jour

Pour faciliter une interaction efficace entre les équipes d'assurance qualité et réduire le flux de publication, nous avons introduit le rôle de l'assurance qualité du système.

Cela a permis d'alléger la charge de travail sous la forme d'écriture de cas d'acceptation avec FO et d'accélérer l'écriture de scénarios de test, d'introduire des tests intermédiaires du composant de fonctionnalité avant de le transmettre à l'équipe suivante, et également de déplacer le travail fastidieux de préparation du test. environnement à l'AQ du système, en tenant compte de toutes les nuances et exigences des équipes pour les intégrations et les données de test.

System QA est devenu un lien entre les exigences techniques et commerciales pour chaque fonctionnalité et le produit dans son ensemble.

Intégration pour le système QA

Pour comprendre l'intégralité du cycle de publication, les AQ système doivent comprendre le fonctionnement d'un cycle de publication spécifique dans chaque équipe. L'intégration dure généralement environ trois mois, car le système QA passe 2 à 3 semaines dans chaque équipe, comprenant leurs cycles de publication spécifiques.

Résultats du nouveau processus

• Nous testons actuellement les exigences BRS/SRS des propriétaires de fonctionnalités et des architectes. La détection précoce des bogues entraîne des économies de coûts pour l'entreprise.

• Nous avons établi un espace QA inter-équipes, où des artefacts de test sont attachés à chaque fonctionnalité - exigences commerciales, exigences techniques, cas d'acceptation, cas d'autres équipes, données de test. Cela a considérablement aidé toutes les équipes d'assurance qualité à être dans un contexte unique et à réutiliser efficacement les données.

• Accélération du processus de localisation des bugs car le système QA dispose d'ensembles de cas de test de toutes les équipes.

• Étant donné que l'assurance qualité du système rédige des cas d'acceptation pour chaque équipe, il s'agit d'un excellent indice pour accélérer et améliorer la qualité des tests.

• Le processus d'intégration est devenu indolore puisque la fonctionnalité est validée par des cas d'acceptation après chaque commande.

• Après avoir retiré une partie importante de la charge du FO, l'acceptation des fonctionnalités et la préparation d'un stand d'intégration avec des données de test se sont accélérées.

  
  

Dans l'ensemble, nous avons accéléré le flux de publication de 15 à 20 % et réduit de près de moitié le nombre de bogues d'intégration, car nous les détectons désormais à la fois au stade de la rédaction des exigences BRS et SRS et lors des intégrations d'équipe dans le cadre du développement de fonctionnalités.

Tests heureux et productifs !