Je travaille comme ingénieur QA chez
Miro . Je vais vous parler de notre expérience de transfert aux développeurs d'une partie des tâches de test et de transformation du rôle du testeur en rôle d'AQ (assurance qualité).
Tout d'abord, brièvement sur notre processus de développement. Nous avons des versions quotidiennes du client et 3 à 5 versions du serveur par semaine. L'équipe de développement compte plus de 60 personnes réparties en 10 équipes de mêlée fonctionnelles.
Je travaille dans l'équipe d'intégration, dont la tâche est d'intégrer notre service dans des produits externes et d'intégrer des produits externes dans notre service. Par exemple, nous avons
intégré le traqueur de tâches Jira . Cartes Jira - un affichage visuel des tâches que vous pouvez facilement travailler sur le tableau sans entrer dans Jira.
Comment l'expérience a-t-elle commencé?
Tout a commencé avec un problème banal. Lorsque l'un des testeurs est allé sur la liste de maladie, les performances de l'équipe ont été considérablement réduites. L'équipe a continué à travailler sur les tâches, mais le code a atteint la phase de test et la tâche s'est arrêtée. En conséquence, la nouvelle fonctionnalité n'a pas atteint la production à temps.
Le départ du testeur en vacances est une autre histoire. Il doit trouver à l'avance l'un des testeurs qui est prêt à prendre ses tâches en plus de la sienne, à accepter, à s'immerger dans les tâches. Deux testeurs partent en vacances en même temps, c'est un luxe inadmissible.
Nous avons commencé à réfléchir à la manière de résoudre le problème, et nous avons réalisé que le vrai problème est que le col étroit des processus de développement est en train de tester. Je vais vous montrer un exemple de plusieurs histoires.
La première histoire: restauration sans fin des tâches
Il y a aussi un développeur. Chacun a ses propres tâches. Le développeur a terminé l'une des tâches et me l'a donné pour test. Comme cette tâche a une priorité plus élevée que les miennes, je passe à celle-ci. Je trouve des bugs, je récupère tout dans Jira et je le redonne au développeur pour révision.
Je reviens aux tâches qui ont dû être reportées. Le développeur passe de nouvelles tâches à la tâche que j'ai renvoyée. Il corrige les bugs et me renvoie pour les tests. Je trouve de nouveau des bogues et je renvoie à nouveau la tâche. Ce processus peut durer très longtemps.
En conséquence, le temps total de travail sur la tâche augmente plusieurs fois, suivi par l'augmentation du délai de mise sur le marché, ce qui est essentiel pour nous en tant qu'entreprise alimentaire. Il y a plusieurs raisons pour augmenter le temps consacré à la tâche:
- La tâche évolue constamment entre le développement et les tests.
- La tâche est inactive en attendant un testeur ou un développeur.
- Le développeur et le testeur doivent basculer régulièrement entre les tâches, ce qui nécessite du temps et de l'énergie supplémentaires.
La deuxième histoire: une gamme croissante de tâches
Notre équipe Scrum compte plusieurs développeurs. Ils me soumettent régulièrement leurs tâches pour des tests. Une file d'attente de formulaires de tâches pour lesquels je m'engage, en fonction des priorités.
Nous avons donc travaillé environ un an, mais pendant cette période, l'entreprise a connu une croissance importante: le nombre de projets et de développeurs a augmenté, et donc le nombre de tâches à tester. En même temps, j'étais toujours le seul testeur de notre équipe et je n'ai pas pu multiplier ma vitesse. En conséquence, de plus en plus de tâches s'accumulaient dans la file d'attente de test et le processus de transfert des tâches entre le développeur et le testeur augmentait le temps d'attente.
Soudain, je suis tombé malade. La livraison de nouvelles fonctionnalités de notre équipe de production a complètement cessé. Que doit faire une équipe dans une telle situation? Vous pouvez demander l'aide du testeur à une autre équipe. Mais, avec un degré de probabilité élevé, il ne sera pas plongé dans nos spécificités, ce qui affectera négativement la qualité et le timing des deux équipes.
La conclusion des deux histoires est la même - les équipes dépendent trop du testeur:
- Les performances de toute l'équipe sont limitées par les performances du testeur.
- Le nombre de développeurs ne peut être augmenté sans augmenter le nombre de testeurs.
- Une augmentation de la vitesse de développement n'a aucun sens si toutes les tâches tombent dans la file d'attente pour les tests.
- Alors que le travail du développeur est vérifié par le testeur, le sens de responsabilité du développeur pour la qualité est réduit.
- S'il n'y a pas de testeur, le processus de sortie de nouvelles fonctionnalités en souffre.
Augmentons le personnel des testeurs?
La pensée la plus évidente est d'augmenter le nombre de testeurs. Cela fonctionnera, mais seulement jusqu'à un certain point: le nombre de tâches augmentera constamment et il est impossible d'augmenter infiniment le nombre de testeurs - à un moment donné, cela deviendra coûteux et inefficace.
Fedor Ovchinnikov , PDG de Dodo Pizza,
a bien écrit sur le sujet des problèmes de «réflexion sur les ressources» (ne pouvez-vous pas résoudre le problème? Embaucher un autre employé).
Il est beaucoup plus efficace de maintenir la vitesse et la qualité du développement dans les limites des ressources actuelles. Par conséquent, nous avons décidé de lancer une expérience qui aidera les équipes à créer des fonctionnalités immédiatement, en tenant compte de tous les risques et des situations frontalières. Ils l'ont appelé Transformer tester en QA, car il s'agit de la transformation de l'un des rôles dans l'équipe: d'un testeur de singe, identifiant les erreurs par le développeur, à un ingénieur QA qui garantit consciemment la qualité à toutes les étapes du processus de développement.
Améliorons les processus de développement
Objectifs de l'expérience:
- Pour supprimer la dépendance de l'équipe vis-à-vis des testeurs, mais sans perte de qualité et de temps.
- Améliorez l'assurance qualité des ingénieurs QA en équipe.
La première étape a été de changer la façon de penser de l'équipe. Tout le monde est habitué au fait que le testeur est responsable de la qualité de l'équipe.
Notre hypothèse était que l'augmentation du temps de préparation et de test des tâches aiderait à réduire le nombre d'itérations dans le travail sur une tâche. Ceci, à son tour, permettra d'apporter de nouvelles fonctionnalités à la production sans perte de vitesse et de niveau de qualité, et peut-être plus rapidement et avec une meilleure qualité.
En collaboration avec l'équipe et avec des testeurs d'autres équipes, nous avons développé un nouveau schéma de travail. Pendant six mois, au fur et à mesure que l'équipe y travaille, nous avons pris en compte les difficultés et les problèmes qui se sont posés en cours de route, et aujourd'hui cela ressemble à ceci:
- Présentation de la production.
- Solution technique et scénario de test.
- Développement et vérification.
- Relâchez
Énoncé du problème
Le Product Owner présente l'énoncé du problème à l'équipe. L'équipe analyse la formulation afin d'identifier les situations limites du côté technique et produit. S'il y a des questions qui doivent être approfondies - une tâche distincte est définie, pour laquelle du temps est alloué dans le sprint.
Solution technique
Le résultat de l'analyse de la formulation du problème est une solution technique, qui est un ou plusieurs développeurs. Tous les employés concernés de l'entreprise, y compris l'AQ, doivent connaître et accepter la solution technique. La solution technique décrit le problème que nous résolvons, les blocs fonctionnels du produit qui seront affectés et le plan proposé pour apporter des modifications au code.
Cette solution vous permet d'identifier une solution plus simple et meilleure basée sur l'expérience des participants concernés dans le processus de développement. Avoir une description technique détaillée à portée de main - il est plus facile de voir et d'éviter les problèmes de blocage, il est plus facile de procéder à une révision du code.
Voici un exemple de quelques blocs d'une solution technique:
Description de la tâche
De nouvelles entités ou approches sont-elles ajoutées au système?
Dans l'affirmative, elles sont décrites et expliquées pourquoi il est impossible de résoudre le problème dans le cadre des approches existantes.
L'interaction du serveur change-t-elle au sein du cluster? De nouveaux rôles de cluster sont-ils ajoutés?
Le modèle de données change-t-il?
Pour le serveur, nous parlons d'objets et de modèles.
Si le modèle de données est complexe, vous pouvez le présenter sous la forme d'un diagramme UML ou sous forme de description textuelle.
L'interaction entre le client et le serveur est-elle en train de changer?
Description des changements. S'il s'agit d'une API, peut-elle être donnée à des utilisateurs externes? N'oubliez pas la gestion des erreurs - c.-à-d. indiquez la raison correcte.
Scénario de test
Parallèlement à cela, le développeur ou QA établit un scénario de test qui prend en compte tous les endroits possibles où des problèmes se sont produits. Si le développeur fait cela, il donnera nécessairement le script à QA, qui le vérifie pour être complet et suffisant. Si le script est QA, le développeur doit confirmer qu'il comprend comment chacun de ses éléments peut être complété. L'équipe évalue également l'exactitude du script.
Pour la compilation et le stockage de scripts, nous utilisons HipTest.
Développement et validation
Le développeur commence à écrire du code basé sur une solution technique et en tenant compte de toutes les situations possibles décrites dans la documentation de test. Passe un examen du code et vérifie le code par rapport aux scénarios de test. Produit une fusion dans le maître.
À ce stade, QA fournit le support nécessaire au développeur. Par exemple, il aide à jouer des cas complexes, à configurer un environnement de test, à effectuer des tests de charge et suggère les nuances possibles de la sortie de grandes fonctionnalités en production.
Sortie de la fonctionnalité prête
Ceci est la dernière étape. Ici, l'équipe peut être tenue d'effectuer des actions pré \ post-publication, par exemple, l'inclusion de nouvelles fonctionnalités pour les utilisateurs bêta.
Documentation et outils
Le nouveau schéma de travail exigeait des développeurs une plus grande immersion dans le processus de test. Par conséquent, en tant qu'AQ, il était important pour moi de leur fournir tous les outils nécessaires et d'enseigner les bases des tests fonctionnels. En collaboration avec le QA d'autres équipes, nous avons dressé une liste de la documentation nécessaire, créé les instructions de test manquantes et finalisé celles existantes en tenant compte de choses qui n'étaient pas évidentes pour les développeurs.
Ensuite, nous avons donné aux développeurs l'accès à tous les outils de test et à tous les environnements de test et avons commencé à effectuer des tests communs. Au début, les développeurs ne voulaient pas prendre la responsabilité des résultats des tests, car personne d'autre n'a vérifié quoi que ce soit pour eux, c'était inhabituel pour eux. Chaque développeur n'avait qu'un script de test, les fonctionnalités qu'il avait développées et le bouton Fusionner. Mais progressivement, ils s'y sont habitués.
Résultats de l'expérience
Six mois se sont écoulés depuis le début de l'expérience. Le graphique affiche les statistiques du nombre de bugs par semaine dans notre équipe. La couleur rouge indique le nombre de tous les bogues trouvés par l'équipe, le vert - le nombre de bogues corrigés.
On peut voir que le niveau de la ligne rouge est resté au même niveau, à l'exception de la rafale au début de l'expérience. Il n'y a plus de bogues, ce qui signifie que nous avons maintenu le niveau de qualité actuel.
Dans le même temps, le temps moyen de travail sur les tâches n'a diminué que de 2%: avant le début de l'expérience, il était de 12 heures 40 minutes, après - 12 heures 25 minutes. Nous avons donc pu maintenir la vitesse actuelle de travail sur les tâches.
En conséquence, notre équipe n'a plus une forte dépendance à l'AQ. Si je tombe malade ou que je pars en vacances, l'équipe continuera de travailler sans perte de vitesse et de qualité.
Estimons-nous que l'expérience a réussi, malgré le fait que les indicateurs de temps et de qualité sont restés les mêmes? Oui, nous le pensons, car nous avons maintenu la vitesse et la qualité du travail et libéré du temps d'AQ pour un travail plus conscient sur la qualité des produits et les processus de développement. Par exemple, pour effectuer des tests de recherche, augmenter la couverture des tests fonctionnels et décrire les principes et les règles de développement de la documentation des tests dans toutes les équipes.
Dans d'autres équipes, nous avons semé le germe de l'expérience. Par exemple, dans l'une des commandes, QA ne teste plus ce qui est décrit par le développeur dans la demande d'extraction, car le développeur peut le voir par lui-même. Dans une autre équipe, QA analyse les modifications de demande et vérifie uniquement les cas complexes et non évidents.
Choses à retenir avant de commencer une expérience
Il s'agit d'une expérience complexe et longue. Il n'est pas mis en œuvre d'un simple clic, vous devez vous y préparer soigneusement et ne pas attendre des résultats rapides.
Soyez prêt pour la négativité de l'équipe. Vous ne pouvez pas simplement le prendre et dire que maintenant les développeurs testent la fonctionnalité. Il faut les préparer à cela, développer des approches, expliquer la valeur de l'expérience pour l'équipe et le produit.
La perte de vitesse au départ est inévitable. Il faut du temps pour former les développeurs, écrire la documentation manquante et reconstruire les processus, ce qui devra être donné à l'expérience.
Il n'y a pas de solution toute faite. Des processus similaires sont implémentés, par exemple,
dans Atlassian , mais cela ne signifie pas que vous pourrez également les implémenter tels quels. L'adaptation à la culture de l'entreprise et aux spécificités des équipes est importante.