Bonjour à tous ! Je m'appelle Julia et je suis testeur. L'année dernière, je vous ai parlé de Bugathon — un événement organisé dans notre entreprise pour nettoyer le backlog des bugs. C'est un moyen tout à fait viable de le réduire de manière significative (de 10 à 50 % selon les équipes) en une seule journée.

Aujourd'hui, je veux vous parler de notre format printanier de Bugathon — BUgHunting (BUH). Cette fois, nous n'avons pas corrigé d'anciens bugs, mais nous avons recherché de nouveaux et proposé des idées pour des fonctionnalités. Plus de détails sur l'organisation de tels événements, nos résultats et les retours des participants se trouvent en dessous.

Après avoir réfléchi et rédigé un règlement, nous avons envoyé une invitation sur tous les canaux de Slack de l'entreprise, sans aucune restriction :

Au final, environ 30 personnes se sont inscrites — des développeurs et des non-spécialistes techniques. Nous avons bloqué une journée entière pour l'événement, réservé une grande salle de réunion et organisé les déjeuners sur place grâce à la cantine de l'entreprise.

Pourquoi ?

On pourrait penser que chaque équipe teste sa propre fonctionnalité. Les utilisateurs nous signalent les bugs. Pourquoi organiser un tel événement ?

Nous avions plusieurs objectifs.

1. Faire connaître aux participants les projets/produits connexes de plus près.
   Actuellement, tous nos employés travaillent dans des équipes séparées — des unités. Ce sont des groupes projet qui développent leur partie de la fonctionnalité et ne sont pas toujours pleinement informés de ce qui se passe dans d'autres projets.
2. Tout simplement faire connaître les collègues entre eux.
   Nous avons presque 800 employés dans notre bureau de Moscou, tous les collègues ne se connaissent pas forcément.
3. Améliorer les compétences de recherche de bugs des développeurs dans leurs produits.
   Nous promouvons actuellement le Test Agile et formons les équipes dans ce domaine.
4. Attirer à la testation non seulement des spécialistes techniques.
   En dehors du département technique, nous avons beaucoup de collègues d'autres spécialités qui souhaitaient en savoir plus sur les tests, sur la façon de signaler correctement les bugs afin que nous recevions moins de messages du type « Aaaa… ça ne fonctionne pas ».
5. Et bien sûr, trouver des bugs astucieux et non évidents.
   Nous voulions aider les équipes à tester de nouvelles fonctionnalités et donner la possibilité de voir la fonctionnalité implémentée sous un autre angle.

Mise en œuvre

Notre journée était composée de plusieurs blocs :

• briefing ;
• une brève présentation sur le test, où nous avons seulement abordé les points principaux (objectifs et principes du test, etc.) ;
• section sur les « règles de bonne conduite » lors de la création de bugs (ici les principes sont bien décrits) ;
• quatre sessions de test sur des projets avec des scénarios décrits de manière générale ; avant chaque session, il y avait une brève présentation du projet et une répartition en équipes ;
• un sondage rapide sur l'événement ;
• bilan final.

(Nous n'avons pas oublié de parler des pauses entre les sessions et du déjeuner).

Règles principales

• L'inscription aux événements est individuelle, ce qui résout le problème du départ en masse de toute l'équipe si une personne décide de ne pas venir.
• À chaque session, les participants changent d'équipe. Cela permet aux participants d'entrer et de sortir à tout moment, et de rencontrer plus de personnes.
• Commandes deux personnes avant chaque session sont formées de manière aléatoire, ce qui rend le processus plus dynamique et plus rapide.
• Des points sont attribués pour les bugs enregistrés (de 3 à 10) selon leur criticité.
• Les doublons ne rapportent pas de points.
• Les bugs doivent être enregistrés par un membre de l'équipe selon toutes les normes internes.
• Les demandes de fonctionnalités sont créées dans une tâche séparée et participent à une nomination distincte.
• L'équipe d'audit veille au respect de toutes les règles.

D'autres détails

• Au départ, nous avions prévu de faire un événement « avancé » sur le test, mais comme assez de personnes des équipes non-produits (SMM, avocats, RP) se sont inscrites, il a fallu simplifier le contenu et éliminer les cas complexes/professionnels.
• En raison du travail des unités dans Jira sur différents projets avec leurs workflows, nous avons spécialement créé un projet séparé, où nous avons configuré un modèle pour l'enregistrement des bugs.
• Pour le comptage des points, nous avions prévu d'utiliser un leaderboard qui se met à jour via des webhooks, mais quelque chose n'a pas fonctionné et au final, le comptage a dû être fait manuellement.

Chaque fois que vous organisez des événements, vous tombez sur des pièges et pour vous faciliter un peu la tâche, je vais décrire nos problèmes que vous pourrez éviter.

Un des intervenants est tombé malade à la dernière minute et nous avons dû chercher un remplaçant.
J'ai eu de la chance de trouver un remplaçant dans la même équipe à 9 heures du matin). Mais il vaut mieux ne pas compter sur la chance et avoir un plan B. Ou être prêt à faire la présentation vous-même.

Nous n'avons pas eu le temps de lancer la fonctionnalité, il a donc fallu échanger les blocs..
Pour ne pas jeter tout un bloc, il vaut mieux avoir un plan de secours.

Une partie des utilisateurs test a abandonné, il a fallu rapidement en recréer de nouveaux..
Vérifiez à l'avance les utilisateurs test ou ayez la possibilité de les créer rapidement.

Presque personne des gars pour qui nous avons simplifié le format n'est venu..
Il ne faut forcer personne. Acceptez la situation.
Il est possible de définir fermement le format de l'événement : « amateur » / « avancé », ou de préparer directement deux options et de décider en fonction des faits quel format adopter.

Points organisationnels utiles :

• réservez la salle de réunion à l'avance ;
• organisez les tables, n'oubliez pas les rallonges et les multiprises (la recharge des ordinateurs portables / téléphones pour toute la journée peut ne pas suffire) ;
• automatiser le processus de comptage des points ;
• préparez des tableaux de classement ;
• élaborez des documents imprimés avec les identifiants et mots de passe des utilisateurs test, un guide pour travailler avec Jira, des scénarios ;
• n'oubliez pas d'envoyer des rappels une semaine avant l'événement, en précisant également ce qu'il faut apporter (ordinateurs / appareils) ;
• parlez de l'événement à vos collègues lors des démonstrations, aux déjeuners, autour d'un café ;
• convenez avec les devops de ne rien mettre à jour ni déployer ce jour-là ;
• préparez les intervenants ;
• convenez avec les responsables des fonctionnalités et établissez autant de scénarios de test que possible ;
• commanditez des en-cas savoureux (biscuits / bonbons) pour les collations ;
• n'oubliez pas de faire un retour sur l'événement.

Résultats

Pendant toute la journée, les participants ont pu tester 4 projets et découvrir 192 bugs (dont 134 uniques) et 7 tâches avec des demandes de fonctionnalités. Bien sûr, une partie de ces bugs était déjà connue des propriétaires des projets. Mais il y a eu aussi des trouvailles inattendues.

Tous les participants ont reçu des prix sucrés.

Et les gagnants — des thermos, des badges, des sweats.

Ce qui s'est avéré intéressant :

• pour les participants, le format des sessions rigoureuses, où le temps est limité et où il n'est pas possible de perdre trop de temps à réfléchir, était inattendu ;
• il a été possible de tester la version desktop, la version mobile et les applications ;
• nous avons regardé de nombreux projets à la fois, il n'y avait pas de temps pour s'ennuyer ;
• nous avons rencontré différents collègues, avons vu leurs approches en matière de création de bugs ;
• nous avons ressenti toute la douleur des testeurs.

Ce qui peut être amélioré :

• réduire le nombre de projets et augmenter la durée des sessions à 1,5 heures.
• préparer des cadeaux/souvenirs longtemps à l'avance (parfois l'accord/le paiement s'étale sur un mois);
• se détendre et accepter que quelque chose ne se passe pas comme prévu et qu'il y aura des imprévus.

Avis

Anna Bystrikova, administratrice système : « La Bugathon est très instructive pour moi. J'ai appris le processus de test, j'ai ressenti toute la « douleur » des testeurs.
Au début, dans le processus de test, en tant qu'utilisateur moyen, vous vérifiez les points principaux : est-ce que le bouton fonctionne, est-ce que ça redirige vers la page, est-ce que la mise en page est correcte. Mais plus tard, vous comprenez qu'il faut penser de manière plus originale et essayer de « casser » l'application. Le travail des testeurs n'est pas simple, il ne s'agit pas seulement de passer en revue l'interface, il faut essayer de penser en dehors des sentiers battus et être extrêmement attentif.
Les impressions sont uniquement positives, même maintenant, après un certain temps écoulé depuis l'événement, je vois comment le travail est mené sur les bogues que j'ai trouvés. C'est génial de se sentir impliqué dans l'amélioration du produit ^_^ ».

Dmitri Seleznev, développeur front-end: « Le test en mode compétitif motive beaucoup à trouver plus de bogues). Je pense que tout le monde devrait essayer de participer à un Bug Hunting. Le test exploratoire permet de trouver des cas qui ne sont pas décrits dans le plan de test. De plus, les personnes qui ne connaissent pas le projet peuvent donner des retours sur la convivialité du service ».

Antonina Tatchouk, rédactrice en chef: « J'ai aimé essayer d'être testeur. C'est un style de travail complètement différent. Vous essayez de casser le système au lieu de vous amuser avec. Nous avons toujours eu la possibilité de poser des questions à des collègues sur les tests. J'ai appris davantage sur la priorisation des bogues (par exemple, j'avais l'habitude de chercher des erreurs grammaticales dans les textes, mais le « poids » d'un tel bogue est très faible ; et à l'inverse, quelque chose qui m'a semblé peu important s'est finalement avéré être un bogue critique qui a été corrigé immédiatement).
Lors de l'événement, les gars ont fourni un résumé théorique sur les tests. C'était utile pour les non-spécialistes techniques. Et quelques jours plus tard, je me suis surprise à écrire au support d'un autre site avec la formule « quoi-où-quand » et à décrire en détail mes attentes vis-à-vis du site et la réalité ».

Conclusion

Si vous souhaitez diversifier la vie de l'équipe, avoir un regard frais sur la fonctionnalité, organiser un mini «Mange ta propre nourriture pour chiens», vous pouvez essayer d'organiser un tel événement, puis nous pourrons en discuter ensemble.

Je souhaite à tous le meilleur et moins de bugs !

Source : habr.com