div>
— Comment appliquer le processus pour apporter une organisation et une facilité au bug bash cremona
Important: Ceci est une étape par étape de la façon d’organiser un bug bash. Vous trouverez plus d’informations sur les avantages de son utilisation chez QuintoAndar dans l’article « Comment le bug bashing a fréquemment et systématiquement changé l’état d’esprit de l’équipe vers la qualité et la connexion établie chez QuintoAndar ».
Introduction
Bug Bash est une méthodologie de test, définie à l’origine par Ron Patton dans son livre Software Testing en 2001. Cette approche des tests a été utile sur différentes équipes de QuintoAndar et, par conséquent, nous avons créé un processus pour optimiser son application.
Bug quoi?!
J’ai d’abord entendu le terme bug bash lors de mon entretien de recrutement à QuintoAndar et cela sonnait bien. Plus tard, j’ai cherché en ligne plus d’informations pour découvrir que c’était une pratique assez répandue, utilisée par de nombreuses entreprises avec un point commun: un environnement agile. Bug Bash est une méthodologie de test définie à l’origine par Ron Patton, 2001. Dans son livre « Software testing », il décrit bug bash comme une procédure où toutes les personnes impliquées dans le cycle de développement du produit, mettent de côté leurs tâches quotidiennes régulières et « pilonnent le produit ». Ainsi, tous ceux qui ont d’une manière ou d’une autre eu leur mot à dire sur le produit — de la définition à la conception; du développement à la commercialisation — devraient être dans la même pièce, tester la fonctionnalité, de toutes les manières possibles avant de la publier.
Il rapproche l’équipe — des parties prenantes au développement – pour couvrir autant de scénarios de test que possible et, par conséquent, réduire les risques d’une version défectueuse. Reconnaissant que cela pouvait être une alternative viable et précieuse à notre rythme de travail rapide et intense, nous avons commencé à introduire lentement le concept dans l’équipe, en améliorant et en adaptant toujours l’approche en fonction des besoins de la fonctionnalité.
Ciel, c’est toi ?
Cela ressemble à un rêve mais si vous avez déjà mené une foire aux bogues, vous savez probablement à quel point il peut être chaotique de rassembler autant de profils différents dans une pièce: certaines personnes doutent qu’il s’agisse d’un bogue ou non, d’autres demandent où rapporter les résultats, d’autres ont du mal à accéder au système, tout le monde discute de la façon de suivre et de prioriser les corrections de bogues lors des tests, etc. Sans une préparation minimale, il y a de fortes chances que des détails importants soient perdus entre les questions et les post-its, que les gens soient frustrés de ne pas être écoutés et, en fin de compte, quel devrait être le temps le plus productif pour trouver des bugs peut se révéler une perte de temps pour toute l’équipe.
En plus de la complexité inhérente à la coordination d’un bug bash, nous avons également eu le défi d’appliquer le concept sur un produit qui offre une solution commerciale complète: de la recherche de biens à l’administration de la location. Cela signifie des livrables back-end et front-end tout au long de l’expérience utilisateur. Par conséquent, chez QuintoAndar, il était impératif de disposer d’un processus flexible et adaptable pouvant convenir aux deux scénarios.
Nous savions qu’il y avait — et qu’il y avait encore — un grand défi devant nous: apprendre à appliquer efficacement le bug bash dans différents contextes. Il nous fallait une hélice. C’est-à-dire un processus fluide avec des outils essentiels et robustes de centralisation suffisamment adaptables pour être utilisés sur différents types de validation de livraisons.
Alors, en nous interrogeant sur les réalisations ci-dessus, nous avons créé un processus axé sur la combinaison de points clés de test et d’éléments clés de reporting de bogues, aussi simplifiés que possible sans compromettre son efficacité.
Comme mentionné, les principes fondamentaux d’un bon bug bash comprennent une phase de préparation au cours de laquelle le responsable de l’assurance qualité, met en place les conditions de test, fournissant aux testeurs temporaires des outils qui valorisent leurs compétences de test. Il y a trois étapes principales pour une bonne configuration:
Étape 1: Créez une feuille de calcul pour centraliser tous les résultats
Tout d’abord: nous avons besoin de tout le monde sur la même page. Littéralement! Lorsque vous essayez de cartographier les problèmes, il est fondamental de tout rapporter sur un seul document. Cela pourrait signifier une note partagée, un document de texte, un carton géant. Nous avons décidé d’utiliser une feuille de calcul dans laquelle nous pourrions également donner des conseils visuels sur ce qui était testé. Ce choix était une collaboration avec le concepteur produit de l’équipe qui décrit les avantages pour le Design lui-même dans l’article « Product Design &Bug bash: comment valider les interfaces et assurer la qualité de votre livraison de bout en bout ».
Une feuille de calcul permet également d’automatiser facilement le processus pour être plus fluide et plus fonctionnel. Dans une feuille de calcul bug bash, nous avons trois onglets: Participants, Bug bash, Rapport automatique.
Comme les applications utilisateur final de QuintoAndar sont principalement basées sur le Web, les tests doivent inclure différents appareils mobiles et de bureau. Parfois, le problème est lié à l’appareil, ce qui rend sa divulgation indispensable. Nous avons donc créé l’onglet « Participants », dans lequel chaque testeur ou participant du bug bash saisit des informations telles que le nom, l’utilisateur simulé, le navigateur, la marque et le type d’appareil. Ce sont les informations de base dont nous avons besoin pour commencer à enquêter — ou à résoudre — le problème. Une fois ces informations complétées, nous pouvons continuer.
Dans le deuxième onglet « Bug bash », nous combinons les éléments de test et de rapport de bogues. Une image du contexte à tester dans la première colonne est suivie de trois colonnes où le testeur entre le nom du testeur, une description détaillée du problème trouvé ainsi qu’une image de celui-ci, le cas échéant. De cette façon, s’il y a des doutes sur le rapport, nous savons qui s’enquérir à ce sujet et gagner du temps. Ceci est particulièrement utile pour assurer des livraisons frontales car nous pouvons valider le produit final par rapport à la mise en page conçue. Si nous validons les livraisons back-end, l’image frontale est généralement remplacée par un flux de travail expliquant ce qui se passe sur le back-end. De cette façon, nous tenons les gens au courant du contexte même s’il n’est pas visiblement testable. Les gens testeront le produit et rapporteront tous les problèmes, améliorations et doutes sur cet onglet. Lorsque le temps de test est écoulé, l’équipe passe en revue les problèmes signalés, examine et discute de ce qui est logique à inclure dans la phase de correction.
En raison de cette étape d’évaluation de la gravité et de la hiérarchisation, toute l’équipe sera au courant de tous les problèmes détectés et sélectionnera ceux liés à ce cycle de développement pour le reporting. Cela optimisera la phase de reporting et évitera les réunions de suivi pour hiérarchiser les problèmes.
Le troisième et dernier onglet de la feuille de calcul, nommé « Rapport automatique », est essentiel pour suivre la vitesse de nos processus. Il contient un script qui prend toutes les informations des deux derniers onglets et crée automatiquement un rapport de problème sur notre tableau Jira. Cela signifie qu’aucune information n’a été perdue sur la phase du processus de déclaration. Cela évite beaucoup de retouches et rend l’ensemble du processus beaucoup plus efficace. Le script est personnalisable, il est donc possible d’ajouter d’autres champs à signaler.
Étape 2: Créer une présentation contextuelle
Pour être efficace, l’étendue du produit à tester doit être très bien définie pour toutes les personnes impliquées dans le processus de test. La portée devrait être limitée à la ou aux fonctionnalités ajoutées dans cette fenêtre temporelle ou ce cycle de développement particulier. Plus les gens sont clairs sur la portée de cette cérémonie de test particulière, moins vous aurez à répondre s’il s’agit d’un bug ou d’un problème hérité. Il est particulièrement important d’avoir cette présentation au cas où des parties prenantes ou des membres de l’escouade participeraient aux tests, car ils pourraient ne pas avoir la clarté que les personnes à l’intérieur du développement lui-même ont.
Étape 3: Réservez une chambre et envoyez les jours d’invitation à l’avance
Organiser une chambre pour accueillir un grand groupe de personnes tout en veillant au calendrier des gens n’est pas toujours aussi simple. Cela peut prendre beaucoup de temps pour correspondre au calendrier de tout le monde ou avoir une salle assez grande disponible, alors restez en tête. Sur l’invitation, partagez la présentation contextuelle avec la feuille de calcul bug bash et assurez-vous d’avoir donné l’autorisation nécessaire à tous les participants. Un autre aspect très important des attaques de bogues est le temps. Assurez-vous de ménager au moins 1h 30m (une heure et demie) pour investir dans cette cérémonie. Cela peut sembler beaucoup, mais ce n’est pas le cas lorsqu’il y a tant de personnes différentes qui utilisent le produit et interagissent pour obtenir une meilleure approche de l’expérience utilisateur.
