Salut Je m'appelle Alyona Isakova, je suis un testeur de premier plan chez Avito et je veux vous parler de mon expérience dans l'introduction des tests Agile à l'équipe. Lorsque j'ai lu des articles sur les tests Agile et l'ATDD disponibles en russe, j'ai eu l'impression que je n'étais "pas à la mode", "pas sur Agile". Il semblait que c'était une sorte de structure complexe qui nécessitait l'inclusion de développeurs, et avant qu'elle ne soit appliquée, je devais encore "labourer et labourer".

Pendant un certain temps, j'ai vécu avec cette idée, écrit une liste de contrôle des tâches lors de la définition des tâches, rassemblé les réunions de la «fonctionnalité-équipe», auxquelles PM, QA, Frontend et Backend ont été invités à discuter des nuances de la tâche avant la mise en œuvre.

Ceux qui comprennent de quoi ils parlent ont déjà remarqué le problème, n'est-ce pas?

Si vous cherchez sur Google ce que sont les «tests agiles», vous pouvez trouver des suggestions pour suivre des cours, quelques articles avec des vues sur l'approche et la définition sur Wikipedia:

"Les tests agiles sont une pratique de test de logiciels qui suit les principes du développement de logiciels agiles. Les tests agiles impliquent tous les membres d'une équipe agile interfonctionnelle, avec une expertise spéciale apportée par des testeurs pour garantir la fourniture de la valeur commerciale souhaitée par le client à intervalles fréquents, en travaillant à un rythme durable. La spécification par l'exemple est utilisée pour saisir des exemples de comportements souhaités et indésirables et guider le codage. "

Je ne sais pas pour vous, mais je n’ai pas fini de lire cette définition la première fois, j’ai été attaqué par le désir. En fait, tout n'est pas si sec. L'essentiel est que le test Agile est une telle approche du processus de test, dans lequel le testeur est beaucoup plus impliqué dans les premières étapes de la tâche et moins (ou complètement absent) dans ce dernier, contrairement à l'approche Waterfall.

Comment était organisé notre flux de tâches

Il vaut la peine de dire qu'au départ, notre équipe a travaillé sur le SCRUM rigoureux, désolé pour l'expression, qui va évidemment bien avec les tests Agile, vous pouvez dire que cela implique cela.

1. Déclaration du client (supposons PM)

A ce stade, la formulation du problème pour nous a été réalisée selon le schéma User Story, Critères d'acceptation, Cas d'utilisation. Une telle déclaration, évidemment Agile, n'est pas accidentelle - c'est un mérite de ma collègue de l'unité, qui a déjà introduit les tests Agile dans son équipe. Pourquoi je ne pouvais pas simplement emprunter l'expérience d'une équipe voisine, je vous le dirai plus loin dans l'article.

2. Examen de l'énoncé du problème par le testeur

À ce stade, la tâche a été vérifiée pour son caractère unique, sa cohérence et son utilité. Dans mon cas, j'ai également ajouté l'élément «tests» ici, qui décrivait des cas de test supplémentaires (par exemple, négatifs), qui n'étaient pas appropriés pour écrire dans le format de cas d'utilisation. À ce moment-là, je ne savais pas vraiment comment utiliser les critères d'acceptation, j'ai donc juste essayé de donner au développeur le maximum de données pour mes futures vérifications.

3. Discussion de la tâche par toutes les personnes intéressées ou «équipe spéciale»

L'étape a été réalisée selon les besoins. Si après l'examen, le testeur a décidé que la tâche était claire et que des discussions supplémentaires n'étaient pas nécessaires, nous sommes passés au quatrième paragraphe.

Si l'étape était nécessaire, lors de la réunion, une clarté a été faite sur les exigences, un travail supplémentaire. Souvent, la tâche était décomposée, les conditions de test étaient discutées lors du fonctionnement indépendant du frontend et du backend.

4. La tâche a suivi dans un carnet de commandes, a été planifiée, exécutée, déployée et a apporté des avantages et du bonheur

Il semble que tout ne soit pas si mal, mais il y a quelque chose à améliorer: au moins, vous pouvez supprimer quelques étapes supplémentaires, car nous ne comprenons pas pourquoi elles le sont.

Ce qui a été fait pour s'améliorer

Sentant un désir insatiable de s'améliorer, le développeur et moi avons réussi une master class interne sur les tests Agile. Il s'est avéré que pour se conformer pleinement à l'approche, l'équipe n'a qu'à changer la terminologie et serrer un peu les vis de notre vélo personnalisé.
Présenter la démarche, observer les équipes dans lesquelles elle existe déjà, ne suffit pas, il faut un bloc de connaissances et une étape de sensibilisation, qui dans mon cas ont été données par une master class. Un énorme avantage était le fait que nous avons suivi une formation avec le développeur, ce que je conseille vivement à tout le monde, il est difficile de surestimer son aide. Vous deux (testeur et développeur) êtes un minimum nécessaire et suffisant pour commencer à mettre en œuvre l'approche. De plus, chaque équipe et produit est individuel, afin d'affiner cette méthode par vous-même, vous devez au moins essayer.

Par exemple, dans une équipe voisine, il existe une expérience dans l'utilisation utile des tests unitaires avec une description préliminaire dans un outil pour stocker les cas de test et l'automatisation ultérieure. Notre équipe a décidé de déterminer d'abord la vérification nécessaire conceptuellement, de l'automatiser, puis de sélectionner automatiquement les cas du code dans un outil de stockage. Vous pouvez avoir votre propre façon d'interagir.

Je ne déclare pas que sans événement spécial, il est impossible d'introduire une approche, en aucun cas. Mais vous devez prendre le temps de comprendre, de motiver l'équipe et de commencer à changer et à changer. Soyez prêt à ce que tout le monde n'accepte pas immédiatement l'augmentation du temps consacré à la tâche à bras ouverts, j'ai eu de la chance à cet égard.

Que lire sur ce sujet

«Tests agiles. Cours de formation pour toute l'équipe », Janet Gregory et Lisa Crispin. Le livre a récemment été publié en traduction russe et est disponible sur Ozone.

Qu'est-ce qui a changé exactement

1. Lors de nos réunions pour clarifier l'arriéré (PBR), je suis devenu comme un excellent élève ennuyeux demandant tout et tout: "Que se passera-t-il si le service tiers tombe en panne?", "Que se passera-t-il si nous retournons null, pas 0?", "A pourquoi appelons-nous cela, et pas là-bas? "," Et si nous n'obtenons pas toutes les données? "," Et si la planète est capturée par des dinosaures rebelles? " Je plaisante, seulement des questions importantes, pas de «null» et de «0».
   Au fil du temps, les gars ont réalisé que dans une telle discussion, plusieurs cas non comptabilisés à l'avance sont nés qu'ils peuvent maintenant prévoir. Auparavant, des questions comme «Que se passe-t-il si tout s'effondre?» Je me suis demandé dans la phase de test, et maintenant dans la phase de réglage.
2. Au lieu de l'élément «Tests» dans les tâches, nous écrivons «Critères d'acceptation» en détail et consciemment, et déterminons également le nombre et les niveaux des futurs autotests.
   Pour être honnête, il vaut la peine de dire que dans 100% des cas, nous ne connaissons pas les niveaux des autotests à l'avance. Il y a des moments où nous ne pouvons techniquement pas faire cela ou cela prend plus de temps que nous avons à la réunion. Dans la pratique, il n'est souvent pas possible d'agir de façon spectaculaire. Et cela est permis - quelque chose viendra avec le temps.
3. Les articles «Examen de l'énoncé du problème par le testeur» et «équipe de fonctionnalités» que nous ne menons pas actuellement. Nous résolvons tous les problèmes lors des réunions PBR, car toutes les personnes nécessaires sont déjà là et les critères d'acceptation sont discutés dans le processus.
4. Le testeur est ajouté au code de révision du test unitaire pour confirmer qu'il y a suffisamment de contrôles.
5. Au lieu des tests de fonctionnalité habituels, à la fin du processus de développement, des autotests (à tous les niveaux) sont exécutés et seuls des tests de recherche sont effectués.
   Idéalement, bien sûr, les tests ne devraient pas être là du tout, mais dans notre pratique, nous avons constaté que lorsque vous apportez des modifications à un produit développé par de nombreuses équipes, il est plus facile et plus correct d'ajouter des tests de recherche.

Quelles difficultés avez-vous rencontrées?

1. Qu'est-ce qu'un test unitaire

Nous sommes confrontés au fait que nous, QA, ne comprenons pas ce que les tests unitaires testent et ne leur faisons donc pas confiance, et en hommage à notre vigilance, nous écrivons des tests à un niveau supérieur et avec un talon de frappe "pour automatiser, vous ne pouvez pas avoir pitié".

Comme décidé:
Nous, avec notre développeur agile (merci et sa patience), nous nous sommes assis dans le coin, et pendant une heure, il m'a expliqué du doigt ce que sont les tests unitaires, ce avec quoi ils mangent et pourquoi ils ne peuvent pas encore vérifier "cette merde". À la suite de nos souffrances, un incroyable programme de services est né: ils l'ont dessiné de telle manière qu'ils ont eux-mêmes compris.

Une flèche sélectionnée - un voyage - un contrôle dans le test unitaire

En conséquence, après quelques mois, j'écris moi-même quelques tests unitaires et supprime les contrôles redondants aux niveaux supérieurs. Bien sûr, c'est principalement du copier-coller, mais conscient!

Peut-être que vous comprenez déjà bien l'essence des tests unitaires et que vous n'avez pas à passer du temps sur cet élément, mais sinon, sous-autorisez votre développeur dans un environnement calme et attaquez-le avec des questions.

2. Dans l'implémentation actuelle, tous les tests ne peuvent pas être omis sans modifications

Comme décidé:
Suppression des jeux de données inutiles des tests e2e en augmentant le nombre de tests unitaires.
Nous avons déjà révisé les tests unitaires qui ont été mis en œuvre, nous avons noté quels contrôles nous attendons d'eux. Après cela, comme on pouvait s'y attendre, il s'est avéré que nous manquions certains contrôles.
Après avoir déterminé quoi et à quel niveau nous voulons, nous fixons des tâches pour l'avenir.
Après avoir suivi une formation sur ce qui existe déjà, nous avons repris l'application réelle de l'approche et commencé à rédiger des vérifications sur les méthodes qui ne sont pas encore disponibles. C'était déjà plus difficile.

Conclusions

• La particularité de cette approche est qu'elle est naturelle et résulte de choses telles que: «transmettre de la valeur à l'utilisateur», «réduire l'AQ manuelle», «fournir une couverture». Comment exactement vous ferez cela est une autre question, mais cette approche a quelque chose à vous offrir et vous suggère les clés principales à utiliser pour vous simplifier la vie et ne rien perdre.
  Par exemple, les «pratiques de test agiles» sont des outils prêts à l'emploi pour l'application, et les «valeurs» et les «principes» sont ce que le testeur d'une personne en bonne santé comprend, mais cela vaut la peine de les répéter à vous-même et à votre équipe, car je sais par expérience : ils sont souvent relégués à l'arrière-plan en mode haute charge.

  
  

• L'essentiel de la méthodologie ATDD est qu'avant de faire quelque chose, vous devez trouver un critère pour le travail effectué et un critère pour que le travail soit fait correctement. En gros, l'approche détermine la période à laquelle vous êtes d'accord avec l'équipe. Le reste va de pair avec la pièce.

  
  

Par exemple, vous vous rendez compte que dans vos conditions, vous ne pouvez pas distinguer la couche d'intégration des tests - c'est correct. Commencez par les premières étapes de la démarche: notez les critères d'acceptation, définissez les tests et leurs niveaux, créez une tâche pour un avenir meilleur. L'étape la plus utile ici est la définition des contrôles à l'avance, à partir de vos questions méticuleuses au stade de la définition de la tâche - le résultat positif le plus rapide qui prouvera à votre équipe que vous ne perdez pas son temps.

• En général, l'approche du test Agile et les valeurs, principes et pratiques qui y sont proposés découlent de choses assez évidentes, comme l'a dit mon professeur préféré en algèbre supérieure: "Mais ici, il est nécessaire d'appliquer le bon sens." Cela vaut la peine d'être suivi, et pas seulement dans les tests.

Une fois, au milieu d'une discussion, l'équipe et moi avons réalisé que nous écrivions des chèques sur trop de conditions, ce qui nous a amenés à la question: «Appelons-nous la méthode exactement sur ce paramètre?» Il s'est avéré que la formulation du problème peut être fondamentalement simplifiée en appelant l'essence elle-même, et non la logique au-dessus du niveau. Autrement dit, les conditions lorsque nous avons une entité dépendante, mais il n'y a pas d'entité elle-même, elle n'existe pas. Cela nous a facilité la vie.

Par la façon de déterminer le niveau du cas de test, il s'agit d'un holivar distinct, lorsque vous commencez à ressentir de la douleur, essayez de consulter la littérature. Et rappelez-vous que la pratique doit être appliquée là où elle résout vraiment le problème, où elle facilite la vie. Bonne chance et bonne chance!