for enhver solo tester derude anbefaler jeg at lede en regelmæssig bug bash/mob testaktivitet. Det er en aktivitet, du kan køre i slutningen af en sprint/feature dev cyklus. Du inviterer holdet, få nogle snacks / drikkevarer sammen og få alle til at teste i omkring en time.
opsætning
du vil måske sikre dig, at du har en god enhed/bro.ser-dækning ved at sikre, at alle er konfigureret med data/enheder før hånden. Du vil måske også forberede nogle hjælpedokumenter til at hjælpe folk med at komme i gang. Jeg kan godt lide at have et mindmap om dækningsideer forberedt før hånden, så folk har en visuel indikator for, hvad de tester. Jeg kan også oprette en masse testkonti før hånden og distribuere dem til holdet.
Light Bug reporting
du bør tilskynde til letvægts bug reporting;
- måske skriver folk fejl på sticky notes
- Føj fejl til et delt regneark
- eller hæv Jira bugs direkte fra Slack ved hjælp af en /jirio Opret fejlgenvej
fokus skal være på at finde fejl, ikke blive fanget i, hvordan man rapporterer dem. Du kan altid afklare problemer yderligere efter bug bash, hvis du har brug for mere information.
hvad skal man teste i en bug bash
jeg har en 3-trins heuristisk til at beslutte, hvad man skal teste (tænk; guide eller tommelfingerregel):
- hvad har ændret sig for nylig? Ændring introducerer ny risiko. hvilke funktioner er blevet bygget? Hvilken kode er blevet refactored? Hvilke biblioteker er opdateret? Fokuser teamet for at teste disse områder først
- regressionstest. Har en tjekliste med højst et dusin scenarier af kernefunktionalitet (måske omkring registrering, betalinger og de vigtigste ting, folk gør med dit produkt). Bed folk om at overveje disse sager, mens de gør 1), måske bede folk om at sætte Der navn ved siden af en sag, når de tester det, så du kan få en ide om dækning
- hvilken anden test skal/kunne vi gøre? Nogle gange kan det være fornuftigt at lave en pen test bug bash session eller en performance test bash eller en cross bro.ser test bash, men det behøver ikke at ske hver gang
Test i produktion
hvis du kan; test i produktion. Der er ikke noget miljø som det.
men hvis du ikke kan teste i produktion, skal du sørge for, at dit testmiljø er stabilt, dine data er konfigureret, og du har givet dit team anmodningen “Rør ikke undtagen bug bash testing”.
Post Bug Bash
sørg for at takke folk for deres tid, tælle bugs og give kudos til din bedste bug jæger. Test / kvalitet er trods alt et teamansvar. Send en tak e-mail med resultater og pris trofæer. Jeg har uddelt dette trofæ af en næsehorn bug i harpiks på en trofæ base til vores nummer et bug jæger før:
