Pour tout testeur solo, je recommande de mener une activité régulière de test de bug bash / mob. C’est une activité que vous pouvez exécuter à la fin d’un cycle de développement sprint/fonctionnalité. Vous invitez l’équipe, prenez des collations / boissons ensemble et faites tester tout le monde pendant environ une heure.
Configuration
Vous pouvez vous assurer d’avoir une bonne couverture de l’appareil / du navigateur en vous assurant que tout le monde est configuré avec les données / appareils à portée de main. Vous voudrez peut-être également préparer des documents d’aide pour aider les gens à démarrer. J’aime avoir une carte mentale sur les idées de couverture préparée à l’avance afin que les gens aient un indicateur visuel de ce qu’ils testent. Je pourrais également créer un tas de comptes de test à l’avance et les distribuer à l’équipe.
Rapports de bogues légers
Vous devriez encourager les rapports de bogues légers;
- peut-être que les gens écrivent des bogues sur des notes autocollantes
- ajoutent des bogues à une feuille de calcul partagée
- ou soulèvent des bogues Jira directement à partir de Slack en utilisant un raccourci /jirio create bug
L’accent devrait être mis sur la recherche de bogues, et non sur la façon de les signaler. Vous pouvez toujours clarifier les problèmes après le bug bash si vous avez besoin de plus d’informations.
Que tester dans un bug bash
J’ai une heuristique en 3 étapes pour décider quoi tester (pensez; guide ou règle empirique):
- qu’est-ce qui a changé récemment? Le changement introduit de nouveaux risques. quelles fonctionnalités ont été construites ? Quel code a été refactorisé ? Quelles bibliothèques ont été mises à jour ? Concentrez l’équipe à tester d’abord ces zones
- Tests de régression. Ayez une liste de contrôle d’au plus une douzaine de scénarios de fonctionnalités de base (peut-être autour de l’enregistrement, des paiements et des principales choses que les gens font avec votre produit). Demandez aux gens de considérer ces cas tout en faisant 1), demandez peut-être aux gens de mettre le nom à côté d’un cas lorsqu’ils le testent afin que vous puissiez avoir une idée de la couverture
- Quels autres tests devrions / pourrions-nous faire? Parfois, il peut être logique de faire une session de test de bogue de test de stylo ou une session de test de performance ou une session de test de navigateur croisé, mais cela ne doit pas se produire à chaque fois que
Test en production
Si vous le pouvez; test en production. Il n’y a pas d’environnement comme ça.
Mais si vous ne pouvez pas tester en production, assurez-vous que votre environnement de test est stable, que vos données sont configurées et que vous avez donné à votre équipe la demande « Ne touchez pas sauf pour les tests de bogues ».
Post Bug Bash
Assurez-vous de remercier les gens pour leur temps, de compter les bugs et de féliciter votre meilleur chasseur de bugs. Les tests / qualité sont une responsabilité d’équipe après tout. Envoyez un e-mail de remerciement avec les résultats et les trophées. J’ai déjà remis ce trophée d’un insecte rhinocéros en résine sur une base de trophée à notre chasseur d’insectes numéro un:
