för alla solo tester där ute rekommenderar jag att leda en vanlig bug bash/mob testning aktivitet. Det är en aktivitet du kan köra i slutet av en sprint/feature dev-cykel. Du bjuder in teamet, får lite snacks / drycker tillsammans och får alla att testa i ungefär en timme.
Setup
du kanske vill se till att du har bra enhet/webbläsare täckning genom att se till att alla är inställda med data/enheter innan handen. Du kanske också vill förbereda några hjälpdokument för att hjälpa människor att komma igång. Jag gillar att ha en mindmap på täckningsideer förberedda före handen så att människor har en visuell indikator på vad de testar. Jag kan också skapa en massa testkonton före handen och distribuera dem till laget.
Light Bug reporting
du bör uppmuntra lätt felrapportering;
- kanske människor skriver buggar på klisterlappar
- Lägg till buggar i ett delat kalkylblad
- eller höja Jira buggar direkt från Slack med hjälp av en /jirio skapa bugg genväg
fokus bör vara på att hitta buggar, inte fastna i hur man rapporterar dem. Du kan alltid klargöra frågor ytterligare efter bug bash om du behöver mer information.
vad ska man testa i en bugg bash
jag har en 3-stegs heuristisk för att bestämma vad man ska testa (tänk; guide eller tumregel):
- vad har förändrats nyligen? Förändring innebär nya risker. vilka funktioner har byggts? Vilken kod har refactored? Vilka bibliotek har uppdaterats? Fokusera teamet för att testa dessa områden först
- regressionstestning. Ha en checklista med högst ett dussin scenarier av kärnfunktionalitet (kanske kring registrering, betalningar och de viktigaste sakerna som folk gör med din produkt). Be folk att överväga dessa fall medan de gör 1), kanske be folk att sätta det namn bredvid ett fall när de testar det så att du kan få en uppfattning om täckning
- vilken annan testning ska/kan vi göra? Ibland kan det vara meningsfullt att göra en pen test bug bash session eller en prestandatestning bash eller en cross browser test bash men det behöver inte hända varje gång
Test i produktion
om du kan; test i produktion. Det finns ingen miljö som gillar det.
men om du inte kan testa i produktion, se till att din testmiljö är stabil, dina data är inställda och du har gett ditt team ”rör inte förutom bug bash testing” begäran.
Post Bug Bash
se till att tacka människor för sin tid, räkna upp buggarna och ge kudos till din bästa buggjägare. Testning / kvalitet är trots allt ett teamansvar. Skicka ut ett tack-e-postmeddelande med resultat och prisutdelningar. Jag har delat ut denna pokal av en noshörning bug i harts på en pokal bas till vår Nummer ett bug hunter innan:
