Avertissement: Ceci est une traduction d'un article . Tous les droits appartiennent à l'auteur de l'article original et à la société Miro.
Je suis ingénieur QA à Miro . Permettez-moi de parler de notre expérience de transfert de tâches de test partiel aux développeurs et de transformation du rôle d'ingénieur de test en QA (assurance qualité).
Tout d'abord brièvement sur notre processus de développement. Nous proposons des versions quotidiennes côté client et 3 à 5 versions hebdomadaires côté serveur. L'équipe compte plus de 60 personnes réparties dans 10 équipes Scrum fonctionnelles.
Je travaille dans l'équipe d'intégration. Nos missions sont:
- Intégration de notre service dans des produits externes
- Intégration de produits externes dans notre service
Par exemple, nous avons intégré Jira . Cartes Jira - représentation visuelle des tâches, il est donc utile de travailler avec des tâches qui n'ouvrent pas du tout Jira.
Comment commence l'expérience
Tout commence par un problème banal. Lorsque quelqu'un de Test Engineers était en arrêt de travail, les performances de l'équipe étaient considérablement dégradées. L'équipe a continué à travailler sur les tâches. Cependant, lorsque le code a été atteint, la tâche de la phase de test a été maintenue. En conséquence, les nouvelles fonctionnalités n'ont pas atteint la production à temps.
Partir en vacances par Test Engineer est une histoire plus complexe. Il / elle doit trouver un autre ingénieur de test prêt à effectuer des tâches supplémentaires et à effectuer le partage des connaissances. Partir en vacances par deux ingénieurs de test en même temps n'est pas un luxe applicable.
Nous avons commencé à réfléchir à la manière de résoudre ce problème. Nous découvrons que la cause profonde est que la phase de test est un goulot d'étranglement. Permettez-moi d'en partager quelques exemples.
Cas 1: Tâche de ping-pong
Il y a moi et développeur. Chacun a ses propres tâches. Les développeurs ont terminé une tâche et m'envoient les tests. Dans la mesure où cette nouvelle tâche a une priorité plus élevée, je l'allume. J'ai trouvé des défauts, les ai remontés dans Jira et j'ai renvoyé la tâche au développeur pour les corrections.
Je reviens aux tâches précédentes. Le développeur revient des tâches en cours à la tâche renvoyée. Après correction, le développeur me renvoie la tâche pour un nouveau test. J'ai retrouvé un défaut et j'ai renvoyé la tâche. Cela pourrait durer longtemps.
En conséquence, le temps cumulé consacré à la tâche augmente en peu de temps et, par conséquent, le temps de mise sur le marché, ce qui est essentiel pour nous en tant qu'entreprise de produits. Il y a peu de raisons d'effort croissant:
- Tâche se déplaçant constamment entre Test Engineer et développeur
- Tâche de passer du temps en attente de l'ingénieur de test ou du développeur
- Le développeur et l'ingénieur de test doivent fréquemment changer de contexte entre les tâches, ce qui entraîne des pertes de temps et d'énergie mentale supplémentaires.
Cas 2: la file d'attente des tâches augmente
Il y a quelques développeurs dans notre équipe Scrum. Ils m'envoient des tâches pour des tests réguliers. Cela forme une file d'attente de tâches que je procède en fonction des priorités.
C'est ainsi que nous travaillons depuis environ un an. Cependant, pendant ce temps, l'entreprise se développe. Le nombre de projets et de développeurs a été augmenté et donc le nombre de tâches à tester. En même temps, j'étais toujours le seul ingénieur de test dans notre équipe Scrum et je n'ai pas pu augmenter mes performances dans le temps. En conséquence, de plus en plus de tâches bloquées dans la file d'attente pour les tests et le processus de ping-pong ont également augmenté le temps d'attente.
Soudain, je suis tombé malade. La livraison de nouvelles fonctionnalités de notre équipe Scrum à la production a été complètement arrêtée.
Quelle équipe devrait faire dans cette situation? Il est possible de demander l'aide d'un ingénieur de test pour une autre équipe. Cependant, un autre ingénieur de test n'est pas dans son contexte et n'a pas obtenu de transfert de connaissances à l'avance, ce qui affectera négativement la qualité et le calendrier des deux équipes.
Le résultat des deux cas dans le même - les équipes dépendent trop des ingénieurs de test:
- La vitesse de l'équipe est limitée par la vitesse de l'ingénieur de test.
- Le nombre de développeurs ne peut pas être augmenté sans l'ajout d'ingénieurs de test, car cela n'a aucun sens d'accélérer le développement si toutes les tâches développées sont bloquées dans la file d'attente pour les tests.
- Pendant que l'ingénieur de test vérifie la tâche après que le développeur ait perdu la responsabilité du développeur pour une qualité diminue.
- Si l'ingénieur de test n'est pas disponible, le processus de livraison souffre.
Ajoutons des ingénieurs de test?
L'idée évidente - augmentons le nombre d'ingénieurs de test. Cela pourrait fonctionner jusqu'à un certain moment: la quantité de tâches augmentera mais il est impossible d'augmenter continuellement le nombre d'ingénieurs de test. Ce sera trop coûteux et inefficace.
Plus efficace est de maintenir la vitesse et la qualité avec les ressources actuelles. C'est pourquoi nous avons décidé de lancer une expérience qui aidera les équipes à créer des fonctionnalités avec une qualité intégrée en assumant les risques et les cas d'angle. Nous avons appelé cette expérience "Transformer le testeur en QA" parce qu'il s'agit de la transformation d'un rôle de testeurs de singes à la recherche de bogues en QA qui influencent consciemment et fournissent la qualité à travers toutes les phases SDLC.
Améliorons les processus de développement
Objectifs de l'expérience:
- Supprimez la dépendance de l'équipe envers les ingénieurs de test qui ne perdent pas en qualité et en temps.
- Améliorez le niveau d'assurance qualité fourni par les AQ et les équipes.
La première étape importante a été de changer l'état d'esprit de l'équipe. Tout était attendu que les ingénieurs de test se soucient exclusivement et soient responsables de la qualité.
Notre idée était que l'ajout d'efforts dans la préparation et la vérification des tâches contribuerait à réduire le nombre d'itérations de ping-pong. Par conséquent, cela permettra de fournir de nouvelles fonctionnalités sur la production en maintenant des niveaux de vitesse et de qualité acceptables ou même de les améliorer.
Mon équipe Scrum et les ingénieurs de test des autres équipes ont créé un nouveau processus. Nous avions travaillé en conséquence sur ce nouveau processus pendant un semestre et nous avons corrigé quelques problèmes pendant cette période et maintenant le processus ressemble à :
- Présentation sur l'énoncé de tâche.
- Solution technique et scénario de test.
- Développement et vérification.
- Relâchez
Énoncé de tâche
Product Owner présente l'énoncé de tâche d'une équipe. L'équipe analyse l'énoncé de tâche pour découvrir les cas d'angle du point de vue technique et du produit. S'il y a des questions qui apparaissent à des fins de clarification ou d'enquête, elles sont suivies comme une tâche distincte avec du temps dédié dans un sprint.
Solution technique
À la suite de l'analyse est une solution technique qui est créée par un ou quelques développeurs. Tous les coéquipiers concernés ainsi que l'AQ doivent l'examiner et en convenir. La solution technique contient le but de la solution, les blocs fonctionnels du produit qui seront affectés et la description des modifications de code prévues.
Une telle solution technique permet de découvrir une solution plus légère et plus appropriée basée sur l'expérience des participants au processus de développement concernés. Ayant une solution technique détaillée, il est plus facile de découvrir et d'éviter les problèmes de blocage, plus facile de procéder à la révision du code.
Voici un exemple de certains blocs dans Technical Solution:
Description de la tâche
De nouvelles entités ou approches sont-elles introduites dans le système?
Si oui, ceux-ci sont décrits et expliquent pourquoi il est impossible de résoudre la tâche avec les approches actuelles.
Les interactions des serveurs au sein d'un cluster changent-elles? De nouveaux rĂ´les de cluster sont-ils introduits?
Le modèle de données change-t-il?
Pour le serveur, il s'agit d'objets et de modèles.
Si le modèle de données est complexe, il peut être représenté par un diagramme UML ou une description textuelle.
L'interaction client-serveur est-elle en train de changer?
Modifie la description. S'il s'agit d'une API, pourrions-nous la publier? N'oubliez pas la gestion des exceptions, c'est-Ă -dire les raisons correctes du journal.
Scénario de test
En parallèle, les développeurs ou QA créent des scénarios de test en supposant des cas d'angle et des points de problème potentiels. S'il est créé par le développeur, le contrôle qualité doit le vérifier sur l'exhaustivité. Si le scénario de test est créé par le contrôle qualité, le développeur doit examiner et confirmer qu'il est clair comment implémenter chaque point. L'équipe évalue également l'exactitude des scénarios de test.
Pour créer et conserver des scénarios de test, nous utilisons HipTest.
Développement et vérification
Le développeur crée un code d'application basé sur la solution technique et en supposant des cas d'angle et des scénarios de test. passer l'examen du code et vérifier la fonctionnalité par rapport aux scénarios de test. Fusionne la branche au maître.
À ce stade, QA prend en charge Developer. Par exemple, aide à la reproduction de cas de test complexes, à la configuration de l'environnement de test, à la réalisation de tests de chargement, à des conseils sur la livraison de grandes fonctionnalités en production.
Libération de la fonctionnalité terminée
Ceci est une dernière étape. Ici, l'équipe peut avoir besoin de fournir des actions avant et après la sortie. Par exemple, activez de nouvelles fonctionnalités pour les utilisateurs bêta.
Un nouveau processus de développement avait exigé des développeurs une implication plus approfondie du processus de test.
Par conséquent, il était important que je, en tant qu'AQ, leur fournisse tous les outils nécessaires et les étudie les principes fondamentaux des tests fonctionnels. En collaboration avec les QA des autres équipes, nous avons compilé une liste de la documentation nécessaire, créé des instructions de test manquantes et mis à jour les éléments existants, y compris non évidents pour les développeurs.
Ensuite, nous avons accordé aux développeurs l'accès à tous les outils de test et environnements de test et avons commencé à exécuter les tests ensemble. Au début, les développeurs ne voulaient pas prendre la responsabilité des résultats des tests car personne ne les vérifiait. C'était inhabituel. Chaque développeur n'avait qu'un scénario de test, une fonctionnalité créée par le développeur et un bouton de fusion. Mais ils se sont adaptés rapidement.
Résultats de l'expérience
Cela fait un an et demi depuis le début de l'expérience. Il y a un graphique du nombre de bugs par semaine. Le nombre de bogues découverts est représenté par la couleur rouge. Le nombre de bogues corrigés est représenté en vert. La ligne jaune est le début de l'expérience.
Il est visible que la ligne rouge reste au même niveau sauf le brochet au début de l'expérience.
Le nombre de bogues n'a pas augmenté et nous avons donc conservé le niveau de qualité actuel.
Parallèlement à ce temps moyen passé sur la tâche a diminué de 2%: 12 heures et 40 minutes avant l'expérience vs 12 heures 25 minutes après. Cela signifie que nous avons réussi à garder la vitesse.
En conséquence, il n'y a plus de forte dépendance vis-à -vis de l'AQ dans une équipe. Si je tombe malade ou si je pars en vacances, l'équipe poursuivra son développement sans perte de vitesse et de qualité.
Envisageons-nous que l'expérience a réussi malgré que la vitesse et la qualité restent les mêmes? Oui, nous le faisons car en même temps, nous avons libéré la capacité d'AQ pour un travail conscient sur le produit et la stratégie d'AQ. Par exemple pour les tests exploratoires, augmenter la couverture des tests fonctionnels et décrire les principes et les règles de création de la documentation de test dans toutes les équipes.
Nous avons également une mentalité d'expérimentation de semences dans d'autres équipes. Par exemple, dans une équipe, le contrôle qualité ne teste plus ce qui est décrit dans la demande d'extraction par le développeur car le développeur peut le vérifier lui-même. dans une autre équipe QA examinant la demande de tirage et teste uniquement les cas d'angle complexes et non évidents.
À quoi faut-il penser avant de lancer une expérience
C'est un chemin complexe et long. Il n'a pas pu être mis en œuvre immédiatement. Cela demande préparation et patience. Cela ne promet pas de gains rapides.
Soyez prêt pour la résistance de l'équipe. Ce n'est pas un moyen de simplement déclarer qu'à partir de maintenant, les développeurs vérifieront la fonctionnalité. Il est important de les préparer à cela, d'élaborer des approches, de décrire les avantages de l'expérience pour l'équipe et le produit.
La perte de vitesse au début est inévitable. Temps pour le transfert de connaissances pour les développeurs, pour la création de documentation manquante et pour les changements dans un processus c'est un investissement.
Il n'y a pas de solution miracle Des processus similaires sont mis en œuvre par exemple dans Atlassian, mais cela ne signifie pas qu'il est possible de le mettre en œuvre dans votre entreprise tel quel.Il est important d'adapter l'expérience à la culture et aux spécificités de l'entreprise.