for noen solo tester der ute anbefaler jeg å lede en vanlig bug bash / mob testing aktivitet. Det er en aktivitet du kan kjøre på slutten av en sprint / funksjon dev syklus. Du inviterer laget, får litt snacks / drikkevarer sammen og får alle til å teste i rundt en time.
Oppsett
du vil kanskje sørge for at du har god enhet/nettleser dekning ved å sikre at alle er satt opp med data/enheter før hånd. Du vil kanskje også forberede noen hjelpedokumenter for å hjelpe folk med å komme i gang. Jeg liker å ha en mindmap på dekning ideer forberedt før hånd slik at folk har en visuell indikator på hva de tester. Jeg kan også lage en haug med testkontoer før hånden og distribuere dem til laget.
Lys Feilrapportering
du bør oppmuntre til lett feilrapportering;
- kanskje folk skriver feil på klistrelapper
- legg til feil i et delt regneark
- eller hev Jira-feil direkte fra Slack ved hjelp av en /jirio create bug shortcut
fokuset bør være på å finne feil, ikke bli fanget opp i hvordan du rapporterer dem. Du kan alltid avklare problemer videre etter bug bash hvis du trenger mer informasjon.
hva du skal teste i en bug bash
jeg har en 3-trinns heuristisk for å bestemme hva du skal teste (tenk; guide eller tommelfingerregel):
- hva har endret seg nylig? Endring medfører ny risiko. hvilke funksjoner er bygget? Hvilken kode har blitt refactored? Hvilke biblioteker har blitt oppdatert? Fokuser teamet for å teste disse områdene først
- Regresjonstesting. Ha en sjekkliste over maksimalt et dusin scenarier av kjernefunksjonalitet (kanskje rundt registrering, betalinger og de viktigste tingene folk gjør med produktet ditt). Be folk om å vurdere disse sakene mens du gjør 1), kanskje be folk om å sette det navn ved siden av et tilfelle når de tester det slik at du kan få en ide om dekning
- Hvilken annen testing skal/kan vi gjøre? Noen ganger kan det være fornuftig å gjøre en penn test bug bash økt eller en ytelsestesting bash eller en cross browser test bash, men det trenger ikke å skje hver gang
Test I Produksjon
hvis du kan; test i produksjon. Det er ikke noe miljø som det.
Men hvis du ikke kan teste i produksjon, må du kontrollere at testmiljøet ditt er stabilt, dataene dine er satt opp Og du har gitt laget ditt» Ikke Rør unntatt bug bash testing » forespørsel.
Post Bug Bash
Sørg for å takke folk for sin tid, telle opp feilene og gi kudos til din beste bug hunter. Testing / Kvalitet er tross alt et teamansvar. Send ut en takk e-post med resultater og tildele trofeer. Jeg har delt ut dette trofeet av en rhino bug i harpiks på en trophy base til vår number one bug hunter før:
