Get best of the week

Comment organiser les tests afin d'accélérer et de stabiliser les versions des produits. Partie 1

Si le travail d'équipe n'est pas convenu, des collisions se produiront constamment entre les participants au processus individuel et des équipes entières, et les produits ou microservices de l'entreprise au sein du même produit interféreront les uns avec les autres en utilisant des ressources et une infrastructure communes. Il en résultera des pannes permanentes, des conflits et des ralentissements. Des rejets rapides et prévisibles dans de telles conditions seront inaccessibles.

Je m'appelle Victoria Dezhkina, je suis engagée dans les tests au sein du département de développement et maintenance des produits big data X5 Retail Group. Je vais vous dire comment nous avons modifié le processus de test dans l'une de nos équipes produits afin d'accélérer la préparation des versions de près de moitié et de soulager l'équipe de stress. Maintenant, nous introduisons cette approche pour tester dans d'autres produits de l'entreprise.



La Direction Big Data du X5 Retail Group développe actuellement 13 produits, dont 4 dans le département de monétisation, où les produits sont orientés vers le marché étranger, et toute erreur, qu'il s'agisse d'un défaut d'un produit ou d'une fonctionnalité tardivement publiée, a un effet économique et conduit à la perte de clients . En fait, ce sont des équipes internes qui gagnent sur le marché étranger et respectent les règles des petites entreprises au sein d'une grande entreprise.

Tous nos produits varient considérablement dans leurs objectifs et nécessitent donc différentes approches de développement et de test, mais ils ont beaucoup en commun: ils utilisent la même infrastructure (Kubernetes, Greenplum, serveurs de test), et les développeurs de différentes équipes de produits se remplacent parfois pendant un certain temps les vacances.

Dans une telle situation, le rôle des accords augmente fortement: si une partie de l'équipe ne sait pas ce que fait l'autre, et que chaque équipe a ses propres règles, des problèmes surgiront inévitablement.

Par exemple, deux produits utilisent la même infrastructure de test de charge, et les deux doivent de toute urgence effectuer des tests. Sans s'informer mutuellement, ils le font en même temps, par conséquent, ils obtiennent de faux résultats, parce que le SGBD s'est "posé", et à cause de qui ce n'est pas clair. Ils voulaient gagner du temps dans les négociations, en conséquence, ils ont perdu beaucoup de temps sans résultat.
La perte de données n'est pas exclue. Supposons que l'un des produits occupe un serveur de test gratuit sans en avertir qui que ce soit. Officiellement, le matériel est considéré comme gratuit, donc un autre produit y pénètre et efface accidentellement toutes les données de test du premier. Bien sûr, ce ne sont pas des données utilisateur, mais simplement des tests, mais un cas assez désagréable.

Il se peut qu'il n'y ait tout simplement pas assez de travailleurs si le travail n'est pas planifié à l'avance. Par exemple, les tests de résistance de notre Direction fonctionnent désormais dans un format de service, c'est-à-dire que nous sélectionnons le spécialiste approprié pour les équipes sur demande. Si plusieurs équipes, sans prévenir à l'avance, viennent exiger des tests de charge en une journée, il se peut que le nombre de testeurs soit insuffisant.

Il semble que la solution la plus simple dans une telle situation soit d'établir des règles uniformes d'interaction pour tous les produits. Mais le problème est que tous les produits sont différents. Certains d'entre eux sont destinés à des utilisateurs internes, c'est-à-dire des spécialistes d'autres départements de l'entreprise, par exemple des services de tarification ou d'étude de la demande. L'autre partie est développée pour les utilisateurs externes - par exemple, pour les fournisseurs. Ces produits ont des logiques architecturales et des critères de qualité complètement différents.

Les produits à différents stades de préparation n'acceptent pas non plus la même approche: au début, lorsque le produit teste des idées, la priorité est de comprendre la fonctionnalité pour l'utilisateur et l'absence de menaces pour la sécurité de l'entreprise. Lorsqu'un produit est pris en charge, d'autres exigences sont prioritaires: la commodité pour l'utilisateur, la stabilité des fonctionnalités existantes, la rapidité de réponse aux défauts et la pleine conformité avec la politique de sécurité de l'entreprise.

Ces deux facteurs - un travail conjoint sur le même territoire et des caractéristiques de produit uniques - nous imposent la tâche: développer des règles qui permettent aux équipes de ne pas interférer les unes avec les autres, mais en même temps ne lieront pas les testeurs et les développeurs des mains et des piedset ils ne réduiront pas le développement de différents produits à un seul modèle, piratant tous les avantages de l'agilité et d'une approche produit dans l'œuf.

Je vais dire quelques mots sur les raisons pour lesquelles les testeurs jouent un rôle de premier plan dans la création de normes d'interaction au sein des équipes produit. Le fait est que, en raison des spécificités de notre travail, nous voyons l'ensemble du produit, tandis que les développeurs se concentrent généralement sur une petite zone. Nous sommes les premiers à remarquer des problèmes et à leur proposer des solutions, mais la solution finale est élaborée avec les développeurs.

Nous avons déjà écrit comment ce travail collectif se déroule : au stade initial, il faut littéralement composer un seul dictionnaire pour ne pas se confondre en termes. Mais c'est seulement le début. Ensuite, nous devons nous mettre d'accord sur une masse de nuances très différentes.

Je vais vous expliquer comment cela s'est produit sur l'exemple de l'un de nos produits - un système d'automatisation des achats pour un réseau de distribution. Sa tâche est d'assurer le fonctionnement de tous les processus depuis le moment où le magasin a besoin de certains produits jusqu'au moment où il les reçoit.

Quels processus ont changé dans notre produit


Lorsque nous sommes arrivés au produit, les versions devaient être publiées toutes les 2 semaines, mais elles étaient presque toujours en retard pendant quelques jours, et le jour de la sortie signifiait toujours que nous resterions définitivement au travail et jusqu'à la dernière, nous stabiliserions la version existante. Il fallait changer quelque chose.

Il est important de noter que le changement est une cause courante. Quel que soit leur initiateur, le testeur ou les développeurs eux-mêmes, ils ne peuvent le faire sans le consentement de toute l'équipe et de puissants alliés. Tout changement doit être discuté par toute l'équipe afin de collecter autant d'idées que possible et de ne pas rater les risques éventuels. Le responsable de la livraison et du produit de notre produit et avant moi a systématiquement travaillé à l'amélioration des processus tant du côté technique que du produit. Ayant rejoint l'équipe, j'ai examiné le processus du côté des tests et ensemble, nous avons réfléchi à une «stratégie de changement» convenue. Le premier point était un changement dans la disposition du code.

Disposition du code


La procédure de calcul est l'une des principales «difficultés» du développement d'équipe, et il y a ici des problèmes très différents. Par exemple, une équipe n'a qu'une seule branche avec un code et la correction d'erreurs ne s'arrête pas là. Ou il existe plusieurs branches, mais des tâches avec des fonctionnalités qui se chevauchent peuvent apparaître en même temps dans l'environnement de test.Par conséquent, les testeurs ne pourront pas localiser le défaut ni vérifier certaines des nouvelles fonctions bloquées par le défaut de l'une des tâches. Et à propos des développeurs désespérés qui ne considèrent pas que c'est quelque chose de mauvais de réparer rapidement les petites choses sur la prod sans en avertir les autres, je ne dirai généralement rien.

Pour éviter tout cela, nous devions déterminer le nombre de branches et d'environnements, ainsi que convenir de la procédure à suivre pour tester le code.

Le moyen le plus simple serait de diviser le processus en deux branches avec du code "propre" et "sale". Mais nous devions remplir de nombreuses conditions:

  • « », « »
  • ,
  • .

Nous avons passé 2 heures à discuter d'un nouveau schéma de travail et sommes arrivés à ce qui suit: nous démarrons trois branches, deux d'entre elles (release et master) seront en code propre. Dans le «maître» est la version actuelle du produit, dans la «version» - des fonctionnalités qui sont prêtes à être déployées. En Dev, les tests ont lieu, voici les tâches prêtes pour le test, le développement a lieu localement. Le déploiement dans chaque branche s'effectue en accord avec le testeur. La voici:



qu'est-ce que cela nous a donné en termes de tests:

  • Le temps de test pour chaque tâche individuellement a été réduit de 20%. Il n'était plus nécessaire de recommencer la vérification, si une nouvelle tâche se déployait au test sans avertissement, de nouvelles tâches ne bloquaient pas la vérification de celles déjà effectuées et le temps de localisation des défauts s'accélérait.
  • Au jour prévu pour la correction de la version, 1 à 2 tâches n'étaient toujours pas contrôlées au lieu de 4 (c'est-à-dire que le temps de les vérifier était réduit de moitié).
  • Le temps pour les tests d'intégration et les tests de libération des candidats a été réduit de 6 heures à 2 (en comptant le nouveau test).
  • Le nombre de défauts trouvés au stade de la libération a diminué. Auparavant, sur la première version, nous en avions trouvé plus de 10, mais maintenant pas plus de 4. Le temps de nouveau test a diminué de 2 heures.
  • Il était possible de poursuivre le développement parallèlement aux tests.

Le temps total que nous avons consacré aux tests, retardant le déploiement de la prod, a été réduit de 8 heures. Seulement 2 heures de discussion sur un nouveau plan de travail avec l'équipe - et a réussi à économiser une journée entière de travail, qui était auparavant passée toutes les deux semaines. Pas mal?

Mais les problèmes sont restés.

  • , .
  • - , , .
  • .
  • , .

Conclusion: nous avons continué à nous attarder sur le travail le jour de la sortie.

Nous nous sommes à nouveau réunis. Une partie des problèmes a été résolue en affinant le processus de développement et en ajoutant CI:



Nous avons mis en place un déploiement automatique sur tous les environnements pendant près d'un mois, mais cela a donné une accélération de près de 2 jours ouvrables. L'équipe y travaille depuis longtemps, le responsable de la distribution et les développeurs eux-mêmes s'y sont engagés, mais jusqu'à présent, ils n'ont pas réussi à réaliser deux choses: pour que le déploiement dans tous les environnements soit uniforme et qu'en même temps le contrôle de version soit préservé. Le déploiement automatique a soit violé le principe principal du test «à tout moment, le testeur doit savoir ce qui se trouve dans chaque environnement», soit a ralenti les développeurs qui ne pouvaient pas terminer le développement de la tâche sans l'autorisation de déployer le test.

Il s'agit d'un dilemme difficile. Ignorez le premier principe et au lieu d'accélérer, vous obtenez une forte diminution de la prévisibilité des versions et des tâches dégonflées par erreur. Par exemple, si un défaut est déjà corrigé en conjonction avec une «tâche propre», alors lors du déploiement d'une tâche fixe, il rattrapera certainement la défectueuse. Par conséquent, vous devrez soit attendre la correction du défaut de la tâche associée, reporter la date de sortie, soit corriger à nouveau le défaut déjà résolu.

Le déploiement automatique n'est pas une personne, vous ne serez pas d'accord avec lui. Par conséquent, nous avons résolu le problème avec les erreurs restantes d'une manière différente - une approche spéciale de la planification, puis en ajoutant un autre stand.

Planification du développement et des tests


Initialement, lors de la planification, l'équipe et moi avons discuté de la clarté de la tâche pour les développeurs, du temps qu'il faudrait et de la pertinence du sprint. Le testeur a estimé la durée du test.

Dans le même temps, nous n'avons pas du tout discuté des erreurs qui pourraient se produire: nous ne les avions pas prévues à l'avance et ne les avons pas incluses dans la liste des tâches possibles. Par conséquent, lorsque ces cas sont sortis pendant le processus de test, ils ont été ajoutés en tant que tâche distincte, ils ont eu besoin de temps pour travailler et ont augmenté le volume de publication, et parfois ils n'ont été trouvés que dans le candidat à la version, au stade du test de tâche conjoint, reportant le déploiement indéfiniment. Nous nous sommes réunis pour trois personnes - un testeur, une livraison et un produit, et avons pensé à un nouveau schéma d'interaction.

Maintenant, nous prononçons toutes les erreurs possibles avant de commencer le développement. Il m'a fallu devenir un étudiant ennuyeux qui, au stade de la planification, demande tout et tout: «Que se passera-t-il si le service tiers tombe en panne?», «Et si nous obtenons la nullité, mais pas 0?», «Et si nous n'obtenons pas toutes les données? "," Et si les Pechenegs attaquent? " et ainsi de suite, mais maintenant nous étions prêts à tout.

Nous avons également commencé à parler de la façon dont nous mettrons en œuvre telle ou telle tâche et comment nous la testerons. Cela nous a permis de réduire l'initiative (l'invention de toutes sortes de vélos, par exemple) et a permis à chaque membre de l'équipe de comprendre ce que faisaient ses collègues. Cela nous a d'ailleurs permis d'abandonner les critères d'acceptation (AC).

Pour éviter que la discussion dans le nouveau format ne devienne trop lourde, nous avons commencé à le faire non pas 2 semaines à l'avance, mais pendant une semaine.

La nouvelle disposition du code et la planification des tâches n'étaient que les premières étapes. Dans la prochaine partie de l'article, qui sera publié demain, je parlerai en détail de la façon dont nous avons modifié toute une série de processus dans l'équipe:

  • Le format de définition et d'acceptation des tâches et des défauts: ils ont laissé des user stories pour l'hybride «cas d'utilisation + tâche technique» qui nous convient le mieux.
  • Moment du test: 5 points ont été définis dans le cycle de sortie au cours duquel les testeurs contrôlent activement le processus de création du produit.
  • Les règles d'interaction entre la connexion backend - testing - frontend: nous avons développé un schéma qui nous a permis de vérifier toutes les données transmises entre le backend et le frontend.
  • Accélération du travail de correction des défauts: règles établies sur la façon de prioriser les tâches de débogage afin de ne pas distraire à nouveau les développeurs.

Ces mesures nous ont permis de raccourcir le cycle de publication de 2,5 semaines à 1. L'augmentation de la vitesse peut sembler faible, mais le principal résultat est que nos versions sont devenues plus stables et prévisibles - nous avons eu la possibilité de déployer des versions "sur commande": nous pouvons nous réunir n'importe quel jour, déployez les tâches et le soir, tout sera prêt et débogué.

More articles:


All Articles