Get best of the week

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

Le testeur a de nombreuses opportunités d'améliorer la qualité du produit et de rendre l'équipe plus confortable. L'essentiel est de discuter de tout changement avec l'équipe et de ne mettre en œuvre que ce qui est pratique et utile pour tout le monde.

Je m'appelle Victoria Dezhkina, je suis chargée de tester un certain nombre de produits à la direction Big Data du X5 Retail Group. Dans la dernière partie de l'article, j'ai commencé à parler de la façon dont nous avons changé les processus dans l'équipe produit «Système d'automatisation pour l'approvisionnement d'un réseau de vente au détail». Les lancements de produits étaient constamment retardés pendant plusieurs jours et sortaient souvent bruts. Nous avons modifié l'ordre de calcul du code et de planification des tâches, ce qui nous a permis de raccourcir le cycle de publication de plusieurs jours, mais nous avons encore dû trouver le format optimal pour définir et accepter les tâches, établir des points de test dans le cycle de publication et apprendre à hiérarchiser les problèmes de correction des défauts.



Le format de la formulation et l'acceptation des tâches et des défauts


La méthode de définition de la tâche détermine en grande partie la rapidité et l'exactitude de son exécution. Vous pouvez décrire les tâches de différentes manières, par exemple, en utilisant des user stories qui reflètent les besoins de l'utilisateur final du système. Cela ressemble à ceci: "l'utilisateur veut recevoir un rapport en appuyant sur le bouton vert."

L'inconvénient de cette approche est qu'elle n'explique pas ce qui sera «sous le capot» de cette décision. Les user stories laissent trop de liberté aux développeurs, et parfois cela devient un problème: l'équipe commence à réinventer la roue ou scie quelque chose de trop laborieux. Et étant donné que dans des conditions de développement rapide, il n'y a presque jamais assez de temps pour une documentation complète, avec cette approche, vous obtenez un code cryptique qui complique grandement l'intégration de nouveaux développeurs dans le produit.

Nous avons discuté de plusieurs options de conception pour les tâches et les défauts et opté pour une approche «hybride»: cas d'utilisation + sous-tâches techniques. Le client professionnel écrit le cas d'utilisation, c'est-à-dire décrit les options d'utilisation de la nouvelle fonctionnalité, et l'analyste avec le testeur, sur la base de cela, sont des sous-tâches techniques pour les développeurs. Dans la description de la tâche dans Jira, nous ajoutons le cas d'utilisation à partir duquel elle est faite, ou un cas de test qui vous permet de reproduire l'erreur, tandis que le nom et la description de la tâche principale restent «lisibles par l'homme».

Voyons, par exemple, ce qui se trouve à l'intérieur du défaut avec le nom "L'utilisateur ne comprend pas comment les erreurs qui se produisent lors du choix d'un taux d'achat" sont traitées. La description de la tâche contient:

  • un cas oĂą vous pouvez reproduire l'erreur;
  • rĂ©sultat rĂ©el et attendu;
  • sous-tâches pour le backend et le frontend avec des instructions claires Ă  corriger pour les dĂ©veloppeurs. «Backend: pour cette API, donnez la rĂ©ponse correspondante au frontend» + une matrice d'options montrant quelles rĂ©ponses devraient ĂŞtre dans chacune des situations possibles. "Frontend: pour cette API, en fonction de la rĂ©ponse de l'arrière, Ă©mettez le texte d'erreur correspondant" + matrice d'options.

Lorsque le développeur termine sa sous-tâche, il la ferme simplement. Si toutes les sous-tâches sont fermées, le défaut est renvoyé pour retester. Si des problèmes supplémentaires sont détectés, la sous-tâche correspondante est à nouveau créée.

La règle correspondante pour la description des défauts est obtenue :

  1. Créez une tâche avec une description d'un problème fonctionnel, un cas pour reproduire l'erreur et un lien vers l'historique, lors de la vérification dont un défaut a été trouvé.
  2. . : , , API , use case . , , API, , , , , , .

Nous avons également refusé de former des AC (critères d'acceptation) sur notre produit, car au stade de la planification, nous discutons non seulement de ce que nous développons et testons, mais également de la manière.

Qu'est-ce que cela a donné? Cette approche nous a permis à tout moment de comprendre ce qui n'allait pas avec la fonctionnalité de la part de l'utilisateur, à quel stade le travail sur le défaut et en fonction de la charge à l'arrière et à l'avant différencie les sous-tâches du même défaut de différentes manières.

Par conséquent, même avant le début du développement, toute l'équipe comprend quelle partie de chaque tâche la touchera personnellement et, à la fin, chaque tâche contient des informations: comment elle a été développée, comment elle a été testée, s'il y avait de la documentation dessus et aussi ce qui a été corrigé pendant le processus de développement.

Cette approche n'est utilisée que sur notre produit, car elle s'est avérée être la plus pratique pour nous. D'autres produits de la Direction du Big Data X5 utilisent leurs propres schémas: par exemple, les User stories avec AC.

Il semblerait que notre option ne contribue pas du tout à accélérer le développement, car elle nécessite plus d'étapes pour démarrer. Mais ce n'est pas le cas.

Nous avons organisé le processus afin que les tests soient menés en parallèle avec le développement. Grâce à cela, le développeur ne reste pas inactif pendant que le testeur travaille et localise la tâche autant que possible.De plus, nous voyons toujours quel développeur particulier a travaillé sur la tâche, comment elle a été mise en œuvre - cela nous permet de comprendre à l'avenir lequel des développeurs fera face plus rapidement à de nouveaux problèmes similaires. La logique est simple: moins un développeur fait des choses qui ne sont pas directement liées à l'écriture de code, mieux et la localisation la plus précise d'un défaut permet une réflexion plus approfondie sur les connexions possibles et les problèmes causés par une erreur particulière.

La question peut également se poser de savoir si les règles que nous avons établies dans notre produit n'interfèrent pas avec la formation de normes de test et de développement uniformes au sein du département. En fait non: les règles générales du département déterminent ce que la tâche doit contenir à un certain stade de développement, et nous respectons ces exigences, nous élaborons simplement la tâche à des stades antérieurs.

Moments de test


Nous avons longuement discuté de la question de savoir à quel stade effectuer les tests. Au début, il y avait une idée de vérifier chaque tâche individuelle dans la branche locale, mais avec cette approche, il serait impossible de vérifier comment ces tâches fonctionnent ensemble, et leurs conflits ne seraient révélés qu'au stade de la publication assemblée, quand il est trop tard pour changer quoi que ce soit.

Par conséquent, nous avons convenu de tester chaque tâche séparément, mais sur un banc d'essai. Au début, nous voulions déployer plusieurs tâches à la fois, mais ci-dessus, je vous ai déjà dit quels risques cette idée comporte. Un à la fois beaucoup plus rapide. C'est un effet connu: la réduction du nombre de tâches parallèles ne ralentit pas, mais accélère plutôt le processus. Dans Kanban, par exemple, il existe une limite de travaux en cours (le travail en cours est en cours), ce qui limite le nombre de tâches pouvant être résolues simultanément par chaque rôle.

En conséquence, nous avons établi cinq points où les testeurs sont activement impliqués dans le processus de développement:

  • Au stade de la documentation. Nous veillons Ă  ce qu'il n'y ait aucun problème qui soit en contradiction avec la logique de ce qui a dĂ©jĂ  Ă©tĂ© fait; nous fixons les dĂ©tails de la mise en Ĺ“uvre de chaque tâche.
  • Au stade de la dĂ©finition du problème. Nous discutons avec l'analyste de tous les cas possibles liĂ©s Ă  la tâche et les prenons en compte lors de la formation de la tâche
  • Au stade de la planification. Nous parlons de la manière dont l'implĂ©mentation planifiĂ©e peut s'accrocher aux fonctionnalitĂ©s associĂ©es et des problèmes qu'elle peut entraĂ®ner. Nous coordonnons avec le produit tous les dĂ©fauts critiques et complĂ©tons le sprint.
  • En prĂ©paration de la sortie. Nous vĂ©rifions itĂ©rativement chaque tâche sur un banc de test, et la veille de la sortie prĂ©vue, nous collectons toutes les tâches ensemble et vĂ©rifions sur un banc.
  • Après la sortie. Nous vĂ©rifions le fonctionnement de la version sur la prod.

Au début, quand nous avions des sorties toutes les 2 semaines, le schéma de travail ressemblait à ceci:



Il est devenu (sortie une fois par semaine):



Règles d'interaction du backend - test - connexion frontend


Lorsque de nombreuses données différentes sont envoyées entre le backend et le frontend dans l'API, il n'est pas toujours clair pourquoi elles sont nécessaires et comment elles interagissent. Pour cette raison, des dysfonctionnements peuvent survenir à l'extrémité avant. Par exemple, le numéro de calcul, demande cal, est transféré de l'arrière. En théorie, il s'agit d'un paramètre, mais huit autres champs devraient être «attirés» vers le serveur principal pour effectuer le calcul. Si vous ne les transmettez pas avec le numéro de coût, cette opération ne sera pas effectuée sur le frontal.

Pour éviter de telles situations, nous avons commencé à décrire les paramètres passés, en les indiquant dans les commentaires de la sous-tâche de développement de l'API dans Jira, qui expliquait quelles données le front et le front échangeraient. Nous avons essayé de décrire toutes les API du framework Swagger, mais avec son aide lors de la génération automatique de la documentation, il n'a pas été possible de transmettre au frontend ce que le backend fera exactement avec les paramètres passés. Par conséquent, nous avons convenu que si nous parlons d'un paramètre qui n'est pas simplement écrit au verso, mais utilise d'autres paramètres, il est nécessaire de décrire son objectif dans la tâche.

Nous avons également commencé à contrôler la désignation des variables afin que dans la même API tous les champs soient standardisés. Notre produit se compose de microservices et chacun peut avoir ses propres noms de champs. Dans un champ avec le nom du fournisseur peut être fournisseur, dans un autre - fournisseurID, dans le troisième nom, etc. Lors du transfert de ces données vers un composant du front-end, des difficultés peuvent survenir, nous avons donc examiné tous les paramètres et commencé à standardiser tous les noms de variables. Pour ce faire, nous avons collecté un tableau récapitulatif de toutes les désignations actuelles, un tableau de tous les composants frontaux et des variables qu'ils utilisent (avec lesquelles le développeur frontal a beaucoup aidé) et les a comparés. Désormais, toutes les nouvelles API reçoivent des noms de variables standard et les anciennes API sont corrigées lorsque des tâches surviennent pour leur exécution.

Accélérez la réparation des défauts


Au stade de la définition de la tâche, le client d'entreprise détermine les priorités - il sait mieux quoi et dans quel ordre est nécessaire pour le développement du produit. Mais après le déploiement vers le développement, lorsqu'il y a des tâches pour corriger les défauts, le testeur valide ses priorités.

Parfois, il est urgent de modifier les priorités de ces tâches - par exemple, nous constatons un défaut mineur dans le back-end, sans lequel l'équipe front-end ne peut pas commencer à réparer.

Auparavant, dans de telles situations, nous nous sommes immédiatement adressés aux développeurs et leur avons demandé de modifier la priorité des tâches, mais cela les a distraits. Par conséquent, nous avons convenu que nous ne contacterons qu'à certains moments - après le gel du code, jusqu'à 5 fois par jour. Qu'est-ce que cela a donné? Nous avons cessé de réduire la productivité des développeurs par des appels soudains, nous nous sommes débarrassés des temps d'arrêt et avons augmenté le temps nécessaire à l'analyste pour exécuter les tâches.

De plus, du fait que les tâches n'apparaissent plus spontanément pour les développeurs, nous savons toujours qui a quel type de charge, qui travaillait sur une tâche et pourra y faire face plus rapidement. En conséquence, nous comprenons beaucoup mieux si nous réussirons à préparer la sortie dans les délais ou non.

Ces mesures, combinées à la logique unifiée de déploiement du code sur le développement, la publication et la production, ont permisréduire la période de correction des défauts de 3 jours à 3-4 heures.

résultats


Au cours des 9 mois de travail de notre produit d'automatisation des achats, nous avons réussi à raccourcir le cycle de publication de 2,5 semaines à 1 semaine avec la possibilité d'un déploiement quotidien, augmentant considérablement la stabilité des versions.

Qu'est ce qui a changé:

  1. Nous nous sommes débarrassés de la nécessité de corriger les défauts après le développement, car nous avons poussé ce travail au stade de préparation des tâches au maximum.
  2. Réduction de la période de correction des défauts de 3 jours à 3-4 heures.
  3. Nous avons eu la possibilité de déployer des versions "sur commande". Maintenant, nous pouvons emballer n'importe quel jour, déployer les tâches et le soir, tout sera prêt et débogué.
  4. Nous avons augmenté la transparence des processus pour tous les participants au processus: maintenant, tous les développeurs et testeurs de l'équipe comprennent ce qui se passe en ce moment, qui sont occupés par quelles tâches, combien de temps est nécessaire pour développer et corriger les erreurs, etc.

BONUS: il était possible de réduire le niveau de stress dans l'équipe (j'espère), et grâce au travail coordonné de l'équipe (grâce à la livraison), j'ai pu facilement aller à distance :-) En mettant en œuvre

ces améliorations, nous avons respecté plusieurs règles:

  • Les testeurs et les dĂ©veloppeurs sont dans le mĂŞme bateau (rĂ©pĂ©tez-le comme un mantra!), Donc la première chose qu'un testeur doit faire est de s'entendre avec l'Ă©quipe et de dĂ©couvrir ce qui l'inquiète le plus, d'obtenir son soutien. Mes alliĂ©s et partenaires de l'Ă©quipe Ă©taient le directeur de la distribution et les dĂ©veloppeurs.
  • Il n'y a pas de solution idĂ©ale prĂŞte Ă  l'emploi, et elle doit ĂŞtre recherchĂ©e. Le testeur n'impose ses règles Ă  personne, il s'adapte Ă  l'Ă©quipe et change ses approches avec lui, tout en gardant Ă  l'esprit l'image d'un avenir radieux et en introduisant doucement les mesures pour y parvenir)).
  • Des restrictions et une normalisation trop sĂ©vères ne sont pas une mĂ©thode. Si vous en faites trop, les Ă©quipes peuvent perdre de la flexibilitĂ©.

Les règles d'interaction, qui nous ont aidés à accélérer le développement de ce produit, ne peuvent pas être transférées sous une forme pure à d'autres produits de la Direction - elles sont organisées différemment et les besoins des développeurs là-bas diffèrent. Mais le principe de création de ces règles sera le même: établir l'ordre de calcul du code, trouver les points optimaux pour les tests, documenter le code et l'API.

Parallèlement au travail à l'intérieur des produits, nous développons des règles conçues pour faciliter l'interaction entre les produits, et nous en parlerons dans les documents suivants. Ainsi, à la Direction du Big Data, une stratégie de développement de la qualité des produits se met progressivement en place.

More articles:


All Articles