Salut tout le monde! Je m'appelle Yulia et je suis testeuse. L'année dernière, je vous ai parlé Bagodelnia - un événement organisé dans notre entreprise pour nettoyer l'arriéré de bugs. C’est une option tout à fait viable pour la réduire significativement (de 10 à 50 % dans différentes équipes) en une seule journée.

Aujourd'hui, je veux vous parler de notre format Bagodelny de printemps - BUgHunting (BUH). Cette fois, nous n’avons pas corrigé les anciens bugs, mais nous en avons recherché de nouveaux et proposé des idées de fonctionnalités. Sous la coupe se trouvent de nombreux détails sur l'organisation de tels événements, nos résultats et les commentaires des participants.

Après avoir réfléchi et rédigé la réglementation, nous avons envoyé une invitation à tous les canaux de Slack d'entreprise, qui ne contenait aucune restriction :

En conséquence, environ 30 personnes se sont inscrites - à la fois des développeurs et des spécialistes non techniques. Nous avons consacré une journée de travail entière à l'événement, réservé une grande salle de réunion et organisé des déjeuners à la cantine du bureau.

Pourquoi?

Il semblerait que chaque équipe teste sa fonctionnalité. Les utilisateurs nous signalent des bugs. Pourquoi même organiser un tel événement ?

Nous avions plusieurs objectifs.

1. Présentez les gars plus près des projets/produits connexes.
   Désormais, dans notre entreprise, tout le monde travaille dans des équipes distinctes - des unités. Il s'agit d'équipes de projet qui travaillent sur leur propre partie des fonctionnalités et ne sont pas toujours pleinement conscientes de ce qui se passe dans d'autres projets.
2. Présentez simplement vos collègues les uns aux autres.
   Nous avons près de 800 employés dans notre bureau de Moscou ; tous les collègues ne se connaissent pas de vue.
3. Améliorer la capacité des développeurs à trouver des bugs dans leurs produits.
   Nous promouvons désormais les tests agiles et formons les gars dans cette direction.
4. Impliquer plus que de simples spécialistes techniques dans les tests.
   En plus du service technique, nous avons de nombreux collègues d'autres spécialités qui voulaient parler davantage des tests, de la façon de signaler correctement un bug afin que nous recevions moins de messages du type « Ahhh... rien ne fonctionne ».
5. Et bien sûr, trouvez des bugs délicats et peu évidents.
   Je souhaitais aider les équipes à tester de nouvelles fonctionnalités et leur donner l'opportunité d'appréhender les fonctionnalités implémentées sous un angle différent.

exécution

Notre journée s'est composée de plusieurs blocs :

• Compte rendu;
• une courte conférence sur les tests, dans laquelle nous n'avons abordé que les points principaux (buts et principes des tests, etc.) ;
• section sur les « règles de bonnes manières » lors de l'introduction de bugs (ici les principes sont bien décrits) ;
• quatre sessions de tests pour les projets avec des scénarios décrits de haut niveau ; avant chaque séance, il y avait une courte conférence d'introduction au projet et à la répartition en équipes ;
• brève enquête sur l'événement ;
• résumer.

(Nous n’avons pas non plus oublié les pauses entre les séances et le déjeuner).

Les règles fondamentales

• L'inscription aux événements est individuelle, ce qui résout le problème de l'épuisement de toute l'équipe à cause de l'inertie si une personne décide de ne pas y aller.
• Les participants changent d'équipe à chaque session. Cela permet aux participants d’aller et venir à tout moment et vous pouvez également rencontrer plus de personnes.
• Команды deux personnes avant chaque séance se forment au hasard, cela le rend plus dynamique et plus rapide.
• Pour les bugs introduits, vous êtes récompensé points (de 3 à 10) selon la criticité.
• Aucun point n'est attribué pour les doublons.
• Les bogues doivent être classés par un membre de l’équipe conformément à toutes les normes internes.
• Les demandes de fonctionnalités sont créées dans une tâche distincte et participent à une nomination distincte.
• L'équipe d'audit contrôle le respect de toutes les règles.

Autres détails

• Au départ, je voulais faire une épreuve de test « avancé », mais... Beaucoup de gars d'équipes non produit se sont inscrits (SMM, avocats, relations publiques), nous avons dû grandement simplifier le contenu et supprimer les cas complexes/profilés.
• En raison du travail des unités dans Jira dans différents projets, selon notre flux, nous avons spécialement créé un projet séparé dans lequel nous avons mis en place un modèle pour introduire les bugs.
• Pour calculer les points, ils prévoyaient d'utiliser un classement mis à jour via des webhooks, mais quelque chose s'est mal passé et le calcul a finalement dû être effectué manuellement.

Tout le monde a des ennuis lors de l'organisation d'événements, et pour vous faciliter la tâche, je vais décrire nos problèmes que vous pouvez éviter.

L'un des intervenants est tombé subitement malade et a dû en trouver un nouveau..
J'ai eu beaucoup de chance de trouver un remplaçant de la même équipe à 9 heures du matin). Mais il vaut mieux ne pas compter sur la chance et avoir une pièce de rechange. Ou soyez prêt à fournir vous-même le rapport nécessaire.

Nous n'avons pas eu le temps de déployer la fonctionnalité, nous avons dû échanger les blocs.
Pour éviter de jeter un bloc entier, mieux vaut avoir un plan de secours.

Certains utilisateurs de test ont été abandonnés, nous avons dû en recréer rapidement de nouveaux.
Recoupez les tests des utilisateurs à l’avance ou soyez en mesure de les faire rapidement.

Presque aucun des gars pour qui le format a été simplifié n'est venu.
Il n’est pas nécessaire de forcer qui que ce soit à traîner qui que ce soit. Humiliez-vous.
Il existe la possibilité de prescrire strictement le format de l'événement : « amateur »/« avancé », ou de préparer deux options à la fois et de décider laquelle organiser après coup.

Points d'organisation utiles :

• réserver une réunion à l'avance;
• disposez les tables, n'oubliez pas les rallonges et les parasurtenseurs (charger les ordinateurs portables/téléphones peut ne pas suffire pour toute la journée) ;
• automatiser le processus de notation ;
• préparer des tableaux de classement ;
• rédiger des documents papier avec les identifiants et les mots de passe des utilisateurs de test, des instructions pour travailler avec Jira, des scripts ;
• N’oubliez pas d’envoyer des rappels une semaine avant l’événement et d’indiquer également ce que vous devez emporter avec vous (ordinateurs portables/appareils) ;
• parlez de l'événement à vos collègues lors d'une démonstration, lors de déjeuners, autour d'une tasse de café ;
• accepter avec les développeurs de ne pas mettre à jour ou déployer quoi que ce soit ce jour-là ;
• préparer les conférenciers ;
• négocier avec les propriétaires de fonctionnalités et rédiger davantage de scénarios de test ;
• commander des friandises (biscuits/bonbons) pour les collations ;
• n'oubliez pas de nous faire part des résultats de l'événement.

résultats

Au cours de toute la journée, les gars ont réussi à tester 4 projets et à créer 192 bugs (dont 134 uniques) et 7 problèmes avec des demandes de fonctionnalités. Bien entendu, les propriétaires du projet connaissaient déjà certains de ces bugs. Mais il y a eu aussi des découvertes inattendues.

Tous les participants ont reçu de jolis prix.

Et les gagnants sont des thermos, des badges, des sweat-shirts.

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

• les participants ont trouvé inattendu le format des séances difficiles, où le temps est limité et où l'on ne peut pas passer beaucoup de temps à réfléchir ;
• réussi à tester la version de bureau, la version mobile et les applications ;
• nous avons regardé plusieurs projets à la fois, nous n'avions pas le temps de nous ennuyer ;
• rencontré différents collègues, examiné leurs approches en matière d'introduction de bugs ;
• ressenti toute la douleur des testeurs.

Ce qui peut être amélioré :

• faire moins de projets et augmenter la durée de la session à 1,5 heure ;
• préparer les cadeaux/souvenirs longtemps à l’avance (parfois l’approbation/le paiement prend un mois) ;
• détendez-vous et acceptez que quelque chose ne se passera pas comme prévu et qu’il y aura un cas de force majeure.

Avis clients

Anna Bystrikova, administrateur système : « L'hospice est pour moi très éducatif. J'ai appris le processus de test et j'ai ressenti toute la « douleur » des testeurs.
Dans un premier temps, pendant le processus de test, en tant qu'utilisateur exemplaire, vous vérifiez les points principaux : si le bouton clique, s'il accède à la page, si la mise en page s'est déplacée. Mais plus tard, vous réalisez que vous devez sortir des sentiers battus et essayer de « casser » l’application. Les testeurs ont un travail difficile ; il ne suffit pas de « fouiller » partout dans l’interface ; il faut essayer de sortir des sentiers battus et être extrêmement attentif.
Les impressions n'étaient que positives, même maintenant, quelque temps après l'événement, je vois comment le travail est effectué sur les bugs que j'ai trouvés. C'est formidable de se sentir impliqué dans l'amélioration du produit ^_^.

Dmitry Seleznev, développeur front-end: « Tester en mode compétitif nous motive grandement à trouver plus de bugs). Il me semble que tout le monde devrait essayer de participer au Baghunting. Les tests exploratoires vous permettent de trouver les cas qui ne sont pas décrits dans le plan de test. De plus, les personnes qui ne connaissent pas le projet peuvent donner leur avis sur la commodité du service.

Antonina Tatchuk, rédactrice en chef: « J’ai aimé m’essayer en tant que testeur. C'est un style de travail complètement différent. Vous essayez de briser le système, pas de vous lier d'amitié avec lui. Nous avons toujours eu l’occasion de poser des questions à nos collègues sur les tests. J'ai appris davantage sur la priorisation des bugs (par exemple, j'ai l'habitude de rechercher des erreurs grammaticales dans les textes, mais le « poids » d'un tel bug est très faible ; et vice versa, quelque chose qui ne me semblait pas très important a fini par être un bug critique, qui a été immédiatement corrigé).
Lors de l'événement, les gars ont donné un résumé de la théorie des tests. Cela était utile pour les personnes non techniques. Et quelques jours plus tard, je me suis surpris à penser que j'écrivais pour soutenir un autre site en utilisant la formule « quoi-où-quand » et en décrivant en détail mes attentes par rapport au site et à la réalité.

Conclusion

Si vous souhaitez diversifier la vie de votre équipe, porter un nouveau regard sur les fonctionnalités, aménager un mini "Mangez votre propre nourriture pour chien", vous pourrez alors essayer d'organiser un tel événement, puis nous pourrons en discuter ensemble.

Tout le meilleur et moins de bugs !

Source: habr.com