J'ai parlé avec des dizaines d'ingénieurs QA de différentes entreprises et chacun d'eux a parlé du fait qu'ils utilisent différents systèmes et outils pour le suivi des bogues. Nous en avons également essayé plusieurs et j'ai décidé de partager la solution à laquelle nous sommes parvenus.
Intro
Je serai banal. Des erreurs apparaissent et sont détectées à différentes étapes du processus de développement. Par conséquent, vous pouvez diviser les bogues en catégories, selon l'heure à laquelle ils ont été détectés:
- Carences . Ce sont les erreurs que les développeurs ont faites en voyant de nouvelles fonctionnalités. De telles erreurs sont détectées lors de la recherche ou des tests d'acceptation de nouvelles fonctionnalités sur les stands de développement des équipes.
- Bugs en régression . Ce sont des défauts qui trouvent des tests de régression manuels ou des tests UI et API automatiques sur le stand pour l'intégration de code.
- Bugs avec une vente . Ce sont des problèmes que les employés ou les clients ont découverts et contacté le support technique.
Où avons-nous commencé, ou Jira
Il y a deux ans, nous avions une équipe dédiée de testeurs qui testait manuellement le produit après avoir intégré le code de toutes les équipes. Jusqu'à présent, le code a été testé par les développeurs sur les stands des développeurs. Les erreurs détectées par les testeurs ont été enregistrées dans l'arriéré de Jira. Les bugs ont été stockés dans un backlog commun et déplacés de sprint en sprint avec d'autres tâches. Chaque sprint a obtenu deux ou trois bugs et les a corrigés, mais la plupart sont restés au bas de l'arriéré:
- L'une des raisons pour lesquelles les bogues sont accumulés dans le backlog est qu'ils n'interfèrent pas avec les utilisateurs. Ces bogues ont une faible priorité et ne seront pas corrigés.
- De plus, si l'entreprise n'a pas de règles claires et compréhensibles pour établir des bogues, les testeurs peuvent ajouter plusieurs fois le même problème car ils n'ont pas pu trouver le rapport de bogue déjà ajouté dans cette liste.
- Une autre raison peut être que des testeurs inexpérimentés participent au projet. C'est une erreur pour les testeurs débutants d'entrer dans le suivi des bogues tous les bogues trouvés pendant le fonctionnement. Les testeurs inexpérimentés considèrent que le but du test est de rechercher des bogues, plutôt que de fournir des informations sur la qualité du produit et de prévenir l'apparition de défauts.
Je vais donner un exemple simple. Lors de la création de rapports dans les champs de saisie de date, la date est remplacée par défaut. Lorsque vous modifiez la date dans la fenêtre contextuelle, vous pouvez à nouveau sélectionner aujourd'hui et le champ de saisie de date sera effacé.
Je soupçonne que pendant toute la durée de vie de notre réseau, personne, à l'exception des testeurs, n'a reproduit cette erreur. De telles erreurs constituent la majorité des bogues qui ne sont pas corrigés.
Avec cette approche, lorsque tous les bogues trouvés sont entrés, certains d'entre eux sont dupliqués et la plupart de ces bogues ne sont pas réparés.
- Les testeurs sont démotivés, car les erreurs qu'ils trouvent ne sont pas corrigées par les développeurs. On a l'impression que le travail n'a pas de sens.
- Il est difficile pour le propriétaire du produit de gérer un backlog avec beaucoup de bugs.
Au revoir Jira, vive Kaiten
Au printemps 2018, nous avons abandonné Jira et déménagé à Kaiten. Le changement d'outils a été causé par des raisons sur lesquelles Andrei Arefiev a écrit dans l'article
«Pourquoi Dodo Pizza a commencé à utiliser Kaiten au lieu d'un tas de Trello et Jira». Après avoir déménagé à Kaiten, notre approche de l'utilisation des bogues n'a pas changé:
- Des imperfections ont été enregistrées sur les tableaux de commande et les développeurs ont décidé indépendamment de les réparer ou non.
- Les bogues qui ont été trouvés dans la régression (il a été effectué par une équipe dédiée de testeurs) ont été réparés dans la branche de publication et n'ont pas publié le code tant que tous les problèmes n'ont pas été résolus. Nous avons décidé qu'il serait plus logique de conserver et de collecter des informations sur ces problèmes dans le canal des testeurs de Slack. Les testeurs ont écrit un message qui contenait une légende, une liste de bogues avec des journaux et les noms des développeurs qui ont entrepris la tâche. Avec l'aide d'emoji, ils ont changé le statut et dans les échanges, ils ont discuté, appliqué des captures d'écran, synchronisé. Ce format convenait aux testeurs. Certains développeurs n'aimaient pas cette méthode, car dans le chat il y avait une autre correspondance en parallèle et ce message montait et n'était pas visible. Nous l'avons réparé, mais cela n'a pas grandement simplifié la vie.
- Les bogues trouvés sur le prod ont été enregistrés dans le backlog, Product Owner, priorisés et sélectionnés ceux que nous allons réparer.
Expérimentez le temps ou pas
Nous avons décidé d'expérimenter avec les formats et avons créé un tableau séparé à Kaiten, sur lequel nous avons conservé les bogues et changé les statuts. Nous avons simplifié l'établissement d'un rapport de bug afin de passer moins de temps. Lors de l'ajout d'une carte à Kaiten, les testeurs ont marqué les développeurs. Une notification leur a été envoyée à ce sujet. Nous avons placé cette carte sur un moniteur accroché dans l'allée près de notre lieu de travail, afin que les développeurs puissent voir les progrès et le processus de test est devenu transparent. Cette pratique n'a pas non plus pris racine, car le principal canal de communication est Slack. Nos développeurs ne vérifient pas souvent le courrier. Par conséquent, cette solution a rapidement cessé de fonctionner et nous sommes retournés à Slack.
Ramenez les fourmis
Après une expérience de carte échouée à Kaiten, certains développeurs étaient toujours contre le format de message dans Slack. Et nous avons commencé à réfléchir à la manière de suivre les bogues de manière lâche et de résoudre les problèmes qui empêchaient les développeurs. À la suite de recherches, je suis tombé sur une application pour Slack, Workast, qui aide à organiser le travail avec les tout-petits directement dans le messager. Nous pensions que cette application vous permettra de gérer le processus de travail avec les bogues de manière plus flexible. Cette application avait ses avantages: changement de statut et affectation aux développeurs en un clic, les tâches terminées étaient masquées et le message ne prenait pas une taille énorme.
Les problèmes résolus ont donc été recherchés dans l'application Todo et les demandes de retour de "fourmis". Une fois la période d'essai de l'application Workast terminée, nous avons décidé de l'abandonner. Parce qu'en utilisant cette application, nous sommes arrivés à la même chose que lorsque nous avons utilisé Jira. Il y avait quelques bogues qui ont erré de régression en régression sur cette liste. Et à chaque itération, il y en avait plus. Peut-être valait-il la peine de finaliser le processus de travail avec cette extension, de l'acheter et de l'utiliser, mais nous ne l'avons pas fait.
Notre moyen idéal pour gérer les bugs maintenant
Fin 2018 - début 2019, un certain nombre de changements ont eu lieu dans notre entreprise qui ont affecté le processus de travail avec les bogues.
Premièrement, nous n'avions pas d'équipe dédiée de testeurs. Tous les testeurs se sont dispersés en équipes de développement, pour renforcer la compétence des équipes de test. Grâce à cela, nous avons commencé à trouver des erreurs plus tôt, avant l'intégration du code de commande.
Deuxièmement, nous avons abandonné les tests de régression manuelle au profit de l'automatique.
Troisièmement, nous avons adopté une «politique zéro bug». Dans l'article "
#zerobugpolicy ou comment nous corrigeons les bugs ",
bevzuk détaille comment nous sélectionnons les bugs que nous corrigeons.
Aujourd'hui, le processus de travail avec les bogues est le suivant:
- Carences . Les testeurs signalent le problème aux analystes ou aux chefs de produit. Ils marchent, montrent, reproduisent, expliquent comment cela affectera les clients et décident s'ils doivent être réparés avant la sortie, ou peuvent être réparés plus tard, ou peut-être que cela ne vaut pas la peine d'être réparé du tout.
- Les bogues dans la régression que les auto-tests ont trouvés sont réparés par l'équipe qui a touché cette partie du système et nous ne publierons pas ce code avant d'avoir résolu le problème. Les testeurs corrigent ces bogues dans un format arbitraire sur le canal de publication de Slack.
- Bugs avec une vente . Ces bogues vont directement aux propriétaires de tâches. Les analystes exécutent des erreurs sur la matrice de priorité du bogue et l'ajoutent au backlog ou le corrigent d'eux-mêmes, accumulant des statistiques de hits sur ce problème.
Résumé
En bref, nous avons essentiellement abandonné le système de suivi des bogues . En utilisant cette approche pour travailler avec les bogues, nous avons résolu plusieurs problèmes:
- Les testeurs ne sont pas contrariés car les erreurs qu'ils trouvent et déclenchent dans le suivi des bogues ne sont pas corrigées.
- Les testeurs ne passent pas de temps sur une institution et une description complète des bugs que personne ne lira même.
- PO est plus facile à gérer le backlog dans lequel il n'y a pas de charge morte.
Je ne veux pas dire que le suivi des bogues est inutile. Les bogues que nous prenons pour travailler sont suivis comme toutes les autres tâches. Mais un système de suivi des bogues n'est pas un attribut de test requis. Il n'a pas besoin d'être utilisé uniquement parce que la plupart des entreprises l'utilisent et est donc habituel dans l'industrie. Vous devez «penser avec votre tête» et essayer des outils pour vos processus et vos besoins. Il est idéal pour nous de travailler sans système de suivi de bogues maintenant. Pendant une demi-année d'un tel travail, nous n'avons jamais pensé à y revenir et à y retrouver tous les bugs.
Et comment le processus de traitement des bogues est-il organisé dans votre entreprise?