Boutique de bagages: BUgHunting. Comment trouver 200 bugs par jour

Bonjour à tous! Mon nom est Julia et je suis testeur. L'année dernière, je vous ai parlé du Bagelnya - un événement organisé dans notre entreprise pour nettoyer l'arriéré de bogues. Il s'agit d'une option tout à fait viable pour la réduire de manière significative (dans différentes équipes de 10 à 50%) en une seule journée.


Aujourd'hui, je veux vous parler de notre format de printemps de la boutique de bagages - BUgHunting (BUH). Cette fois, nous n'avons pas corrigé de vieux bugs, mais nous en avons cherché de nouveaux et avons proposé des idées de fonctionnalités. Sous la coupe, beaucoup de détails sur l'organisation de ces événements, nos résultats et les commentaires des participants.



Après avoir réfléchi et prescrit les règles, nous avons envoyé une invitation à toutes les chaînes de l'entreprise Slack, dans laquelle il n'y avait aucune restriction:



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


Pourquoi?


Il semblerait que chaque équipe teste ses fonctionnalités. Les utilisateurs nous rapporteront des bogues. Pourquoi même organiser un tel événement?


Nous avions plusieurs objectifs.


  1. Présentez les gars plus près des projets / produits associés .
    Maintenant, dans notre entreprise, tout le monde travaille en équipes distinctes - unités. Ce sont des équipes de conception qui ont vu leur part de la fonctionnalité et ne sont pas toujours pleinement conscientes de ce qui se passe dans d'autres projets.
  2. Présentez-vous simplement vos collègues .
    Nous avons près de 800 employés au bureau de Moscou, tous les collègues ne se connaissent pas en personne.
  3. Améliorez la capacité de rechercher des bogues parmi les développeurs dans leurs produits .
    Nous faisons actuellement la promotion des tests agiles et pompons les gars dans cette direction.
  4. Engagez non seulement des experts techniques dans les tests .
    En plus du département technique, nous avons de nombreux collègues d'autres spécialités qui ont voulu parler davantage des tests, de la manière de rapporter correctement, afin que nous recevions moins de messages au format "Ahhh ... rien ne fonctionne".
  5. Eh bien, bien sûr, trouvez des bugs délicats et non évidents .
    Je voulais aider les équipes à tester de nouvelles fonctionnalités et offrir une opportunité d'examiner les fonctionnalités implémentées sous un angle différent.

Implémentation


Notre journée se composait de plusieurs blocs:


  • briefing;
  • Une courte conférence sur les tests, dans laquelle nous n'avons abordé que les principaux points (objectifs et principes des tests, etc.);
  • section sur les "bonnes manières" lors de l'instauration de bugs (les principes sont bien décrits ici );
  • quatre sessions de test pour des projets avec des scripts de haut niveau; avant chaque session, il y avait une courte conférence introductive sur le projet et la distribution aux équipes;
  • un bref aperçu de l'événement;
  • résumer.

(Nous n'avons pas non plus oublié les pauses entre les sessions et le déjeuner).


Règles de base


  • L'inscription aux épreuves est individuelle , ce qui résout le problème de drainer l'inertie de toute l'équipe si une personne décidait de ne pas y aller.
  • A chaque séance, les participants changent d'équipe . Cela permet aux participants de partir et de venir à tout moment, et vous pouvez également vous familiariser avec un grand nombre de personnes.
  • Des équipes de deux personnes avant chaque session sont formées de manière aléatoire , ce qui s'avère plus dynamique et plus rapide.
  • Des points sont attribués pour les bugs résolus (de 3 à 10) selon la criticité .
  • Aucun point n'est accordé pour les doubles.
  • Les bogues doivent être lancés par un membre de l'équipe conformément à toutes les normes internes.
  • Featurekvesta démarre dans une tâche distincte et participe à une nomination distincte.
  • Le respect de toutes les règles est contrôlé par l'équipe d'audit.


Autres détails


  • Au départ, je voulais faire un événement test «avancé», mais parce que beaucoup de gars des équipes non productives (SMM, avocats, relations publiques) se sont inscrits, j'ai dû simplifier considérablement le contenu et supprimer les cas complexes / spécialisés.
  • En raison du travail des unités de 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 créer des bugs.
  • Pour la notation, nous avons prévu d'utiliser un classement, qui a été mis à jour via les webhooks, mais quelque chose s'est mal passé et, par conséquent, le calcul a dû être fait manuellement.

Lors de l'organisation d'événements, tout le monde se heurte à un râteau et pour vous faciliter la tâche, je décrirai nos problèmes que vous pouvez éviter.


L'un des orateurs est soudain tombé malade et a dû en chercher un nouveau .
J'ai été extrêmement chanceux d'avoir trouvé 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 vous-même pour être prêt à dire le rapport souhaité.


Nous n'avons pas réussi à déployer la fonctionnalité, nous avons dû échanger des blocs .
Afin de ne pas jeter tout le bloc, il est préférable d'avoir un plan de sauvegarde.


Certains utilisateurs de test ont abandonné, j'ai dû en recréer rapidement de nouveaux .
Vérifiez les utilisateurs de test à l'avance ou avez la possibilité de les faire rapidement.


Presque aucun des gars pour qui le format a été simplifié n'est venu .
Vous n'avez pas à traîner quelqu'un de force. Humiliez-vous.
Il existe une option pour prescrire de manière rigide le format de l'événement: «amateur» / «avancé», ou pour préparer deux options à la fois et décider de ce qu'il faut faire.


Points d'organisation utiles:


  • réserver une salle de réunion à l'avance;
  • organiser les tables, ne pas oublier les rallonges et les parasurtenseurs (charger des ordinateurs portables / téléphones pour toute la journée peut ne pas être suffisant);
  • Automatisez le processus de notation;
  • préparer des tableaux de notation;
  • faire 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, indiquez également ce que vous devez apporter avec vous (ordinateurs portables / appareils);
  • parler de l'événement à ses collègues lors d'une démonstration, lors d'un dîner, autour d'une tasse de café;
  • convenir avec les devops de ne pas mettre à jour ou déployer quoi que ce soit ce jour-là;
  • préparer les conférenciers;
  • convenir avec les propriétaires des fonctionnalités et écrire plus de scripts pour les tests;
  • commander des collations (cookies / bonbons) pour des collations;
  • N'oubliez pas de parler du résultat de l'événement.

Résultats


Pendant toute la journée, les gars ont réussi à tester 4 projets et à obtenir 192 bugs (dont 134 sont uniques) et 7 tâches avec des demandes de fonctionnalités. Bien sûr, les propriétaires de projets connaissaient déjà certains de ces bogues. Mais il y a eu des découvertes inattendues.


Tous les participants ont reçu de beaux prix.



Et les gagnants sont des thermos, des badges, des pulls molletonnés.



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


  • le format des séances difficiles était inattendu pour les participants, lorsque le temps est limité et que vous ne pouvez pas y consacrer beaucoup de temps;
  • J'ai réussi à tester le bureau, la version mobile et les applications;
  • regardé de nombreux projets à la fois, il n'y avait pas de temps pour s'ennuyer;
  • rencontré différents collègues, examiné leurs approches de la détection de bogues;
  • senti la douleur des testeurs.

Ce qui peut être amélioré:


  • faire moins de projets et augmenter le temps de session à 1,5 heure;
  • préparer des cadeaux / souvenirs bien à l'avance (parfois la coordination / le paiement dure un mois);
  • détendez-vous et acceptez le fait que quelque chose va mal et qu'il y aura force majeure.

Les avis


image
Anna Bystrikova, administrateur système: «La boutique de bagages est très informative pour moi. J'ai appris le processus de test, ressenti toute la "douleur" des testeurs.
Au début, pendant le processus de test, en tant qu'utilisateur approximatif, vous vérifiez les points principaux: le bouton pousse-t-il, va à la page, la mise en page se déplace-t-elle. Mais plus tard, vous comprenez que vous devez penser de manière non standard et essayer de «casser» l'application. Les testeurs ont un travail difficile, peu de «percer» toute l'interface, vous devez essayer de sortir des sentiers battus et être extrêmement attentif.
Seules des impressions positives ont été laissées, même maintenant, quelque temps après l'événement, je vois comment le travail se fait sur les bugs que j'ai trouvés. C'est cool de se sentir impliqué dans l'amélioration d'un produit ^ _ ^. "

image


Dmitry Seleznev, développeur front-end : «Les tests en mode compétitif motivent fortement la recherche de nouveaux bugs). Il me semble que tout le monde doit essayer de participer à Baghanting. Les tests de recherche 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. "

image


Antonina Tatchuk, rédactrice en chef : «J'ai aimé m'essayer en tant que testeuse. 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 plus sur la hiérarchisation des bogues (par exemple, j'ai l'habitude de rechercher des erreurs grammaticales dans les textes, mais le "poids" d'un tel bogue est très petit; et vice versa, quelque chose qui me semblait peu important s'est avéré être un bogue critique qui a été corrigé tout de suite )
Lors de l'événement, les gars se sont écartés de la théorie des tests. Cela a été utile pour les professionnels non techniques. Quelques jours plus tard, je me suis surpris à penser que j'écrivais à l'appui d'un autre site en utilisant la formule «quoi-quand-quand» et que je décris en détail mes attentes par rapport au site et la réalité. »


Conclusion


Si vous voulez diversifier la vie de l'équipe, regardez la fonctionnalité d'un œil neuf, organisez un mini «Mangez votre propre nourriture pour chien» , alors vous pouvez essayer d'organiser un tel événement, puis nous pourrons en discuter ensemble.


Tous les bons et moins de bugs!

Source: https://habr.com/ru/post/fr453000/


All Articles