Get best of the week

Comment améliorer les performances des équipes agiles grâce aux tests

Le développement agile vise à fournir de nouvelles fonctionnalités rapidement et avec la bonne fréquence, assurant un flux constant de changements. Une approche flexible permet à l'équipe de garder un rythme élevé, mais pour cette raison, la qualité du code et la stabilité du produit souffrent souvent. Comment résoudre ce problème sans enfoncer l'équipe dans un cadre serré et sans le priver des avantages des méthodes agiles? L'aide vient des testeurs. Je m'appelle Denis Dubovoi, je dirige le département de test de la direction Big Data de X5 Retail Group, et dans cet article je vais vous dire comment l'apparition de testeurs a contribué à améliorer la qualité de nos développeurs.



Élaborer des règles grâce aux tests


Les équipes agiles négligent souvent la qualité. Cela est dû en partie au fait que les méthodologies de test traditionnelles ne rentrent pas dans un contexte «flexible», en partie à cause de la priorité de la vitesse sur la qualité. La tâche principale de l'équipe agile est de mettre en œuvre rapidement les fonctions dont un client professionnel a besoin. Cela est particulièrement vrai au stade de la formation d'un produit, lorsque sa fonctionnalité est déterminée littéralement par essais et erreurs, et les développeurs doivent reconstruire rapidement le produit pour les demandes actuelles. Dans une telle situation, l'équipe décide souvent de cette façon: nous appellerons le testeur plus tard, lorsque nous ferons le MVP / première version de travail / nous apprendrons le Zen - car il ne comprend tout simplement pas comment organiser des tests flexibles. Il en résulte souvent des perturbations dans les délais de livraison, des erreurs sur la démo et, pire que tout, dans l'environnement PROM.

Dans notre cas, la situation était très similaire: le département de développement de produits Big Data du X5 Retail Group existe depuis 2 ans, et au début la qualité des produits n'était maintenue que par les développeurs eux-mêmes - il n'y avait pas de rôle de spécialiste QA dédié, et le département de test et le premier testeur du produit sont apparus. il y a seulement un an, lorsque les produits avaient déjà commencé.

Aujourd'hui, le département de test compte déjà 15 personnes: 11 testeurs accompagnent les produits en équipe, deux personnes développent la direction des tests de charge et deux autres - la direction de l'automatisation des tests. Dans de nombreuses équipes de produits, les testeurs sont devenus un catalyseur de changements importants: leur arrivée a rationalisé le processus de développement et amélioré la stabilité des versions. Pour ce faire, nous avons connecté des testeurs à des équipes déjà actives selon le schéma suivant:

1. Plongez dans le processus


À la première étape, nous devons comprendre comment l'équipe travaille maintenant, comment les rôles y sont répartis et comment les informations sont échangées. Le testeur commence à aider aux tests, plus sous forme de "contrôle de qualité", évaluant simultanément la maturité de l'équipe et les processus dans l'équipe - pour cela, il existe une petite "carte thermique" de la maturité, dont un exemple peut être vu ci-dessous. Vous pouvez y voir comment différentes directions sont développées (développement, tests, DG, DevOps, support) dans chacun de nos produits.


Carte de chaleur de maturité

Les testeurs collectent l'évaluation de la maturité des processus avec les développeurs, évaluant l'ensemble des pratiques technologiques et méthodologiques utilisées par l'équipe. En conséquence, nous pouvons voir sur la carte thermique quoi et dans quel domaine il est possible d'améliorer - par exemple, pour développer la pratique des tests unitaires en développement ou pour automatiser les contrôles API dans les tests - pour chaque étape de la vie d'un produit (prototype, pilote, industriel), son propre ensemble de pratiques est recommandé.

2. Nous faisons des recommandations d'amélioration




Après avoir compris comment vit l'équipe, vous pouvez réfléchir aux premières recommandations pour améliorer son travail. Ici, nous adhérons à la logique suivante: les testeurs ne sont pas une fonction dédiée responsable d'un domaine spécifique, nous faisons partie de l'équipe et pouvons influencer l'ensemble du processus. Afin de faciliter le lancement des améliorations, nous commençons par les choses de base:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • Nous fixons les étapes de sprint et l'un des points critiques - le point «gel de code».

Nous avons examiné les étapes avant les tests et un peu les tests eux-mêmes, mais il y a aussi une partie technique avec la maintenance des bancs de test et le travail avec les données de test et une partie industrielle avec le support produit. Les testeurs sont en quelque sorte impliqués à toutes ces étapes - nous essayons de former des spécialistes en forme de T qui voient l'ensemble du processus de production, et pas seulement leur fonction immédiate.

3. Nous présentons nos améliorations aux chefs d'équipe et aux parties prenantes, en nous concentrant sur les problèmes que ces améliorations permettront de résoudre


Le processus sera plus facile si vous obtenez le soutien de l'équipe. Il est important de «vendre» votre idée, pour montrer quel profit vos modifications proposées apporteront. Par exemple, les critères d'acceptation que nous avons mentionnés ci-dessus peuvent ressembler à du travail supplémentaire pour l'analyste, mais lorsque l'équipe comprend les gains de temps qu'elle recevra - et cela de quelques heures à quelques jours, ce qui peut prendre pour affiner la tâche - cela rend l'amélioration beaucoup plus facile.

Dans certains cas, vous pouvez agir par l'intermédiaire du propriétaire du produit. Par exemple, le produit manque de surveillance (par exemple, technique, avec des journaux et de beaux graphiques) et il n'y a pas de temps à configurer, car ce n'est pas une tâche de produit. Dans ce cas, vous pouvez contacter le produit et expliquer exactement quels avantages il retirera de la surveillance (il ne deviendra pas plus stable immédiatement, mais la vitesse de localisation du problème augmentera) et lui demander d'allouer des ressources pour cela.
Parallèlement à la standardisation du travail dans les équipes de produits, des approches de test sont en cours de développement pour garantir la qualité des produits, par exemple, évaluer et préparer les volumes requis de données de test, développer un modèle de test, former des points pour une future automatisation, etc.

Il y a toujours une chance que l'équipe n'accepte pas les modifications proposées, même si elles vous semblent raisonnables. Dans chaque cas, il est nécessaire de formuler vos propres approches et de rechercher un moyen de persuasion individuel. Les produits sont très différents et les approches qui fonctionnent dans un produit ne fonctionnent pas du tout dans un autre.

De nombreuses équipes sont convaincues qu'elles sont capables d'organiser leur travail elles-mêmes, et cela est parfois vrai. Il y a eu des cas où notre participation se résumait à recommander les principaux points de vérification, puis l'équipe a parfaitement mis tout en œuvre au niveau du code, et nous sommes restés à proximité, toujours prêts à aider. Mais le plus souvent, cela se passe différemment: notre employé vient dans l'équipe et les développeurs commencent en plaisantant à «pleurer» des défauts trouvés par le testeur, se réjouissant que les défauts aient été trouvés avant la démo ou la version industrielle.

Qu'est ce qui a changé


Les changements dans les équipes produits se sont déroulés différemment et ont affecté différents aspects du processus. Dans l'une des équipes, les tests sont d'abord devenus un goulot d'étranglement: cela a pris du temps, et tout le monde n'a pas compris ce qui se passait à ce stade. À titre expérimental, nous avons connecté les développeurs à l'exécution de tests, grâce auxquels ils ont pu expérimenter le travail des testeurs et même voir le produit dans son ensemble - pas une fonction distincte de la création d'un rapport, par exemple, mais tout le chemin depuis l'autorisation de l'utilisateur dans le produit et la conduite des opérations commerciales jusqu'à la fin - le déchargement rapport. Nous avons donc renforcé l'implication de toute l'équipe, rendu le processus de test transparent et montré l'importance de cette action, et la pratique décrite ci-dessus est devenue régulière.

Dans un autre produit, le cycle de publication a changé avec notre aide. Initialement, il a été convenu que les résultats du sprint seraient testés vendredi après-midi et lundi, le produit avait déjà atteint le client. La toute fin de vendredi et seulement le début de lundi sont restés pour tester et corriger les erreurs critiques, et en conséquence, la nouvelle version est souvent sortie «brute» ou les développeurs ont dû corriger d'urgence des bogues le week-end. Après quelques quarts de livraison difficiles, l'équipe a toujours reporté la livraison du sprint à mercredi (n'a pas réduit la durée du sprint, mais a simplement décalé le calendrier de deux jours). Maintenant, l'équipe a le temps de vérifier et de corriger la livraison dans une atmosphère détendue.



La décision finale, de changer ou non, appartient à l'équipe: c'est elle qui est responsable du produit et de sa production, c'est pourquoi elle choisit l'option la plus pratique pour elle. Le but de notre travail n'est pas d'imposer nos approches aux programmeurs, mais de donner un maximum d'informations sur les risques possibles et de proposer des améliorations et actions adaptées au produit.

Ce que notre service d'essais a réussi à faire au cours de la dernière année:

  • Des tests fonctionnels réguliers sont apparus dans 7 produits du département Big Data du X5 Retail Group, 2 d'entre eux ont atteint des versions stables en PROM sans commentaires critiques. Organisation de tests réguliers de charge de 3 produits.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

Les changements sont toujours complexes, mais ils sont nécessaires si nous recherchons nos produits. Et ce sont les testeurs qui peuvent apporter une contribution significative à la qualité des produits.
Dans les articles suivants, mes collègues et moi parlerons de la façon dont nous testons des produits spécifiques, du choix d'une stratégie de test, des outils (par exemple, l'édition Allure Enterprise - un outil pratique pour gérer les tests, les rapports et même la gestion des autotests), et comment mettre en œuvre des tests automatisés dans pipeline et quelles options de développement que nous voyons (Test Driven Development, si vous y pensez, ce n'est qu'une des options possibles).

More articles:


All Articles