div>

Viktig: Dette er en trinnvis for å organisere en bug bash. Mer om fordelene ved bruk På QuintoAndar finner du i artikkelen «Hvordan bug bashing ofte og konsekvent endret teamet tankesett mot kvalitet og bygget tilkobling På QuintoAndar».Bug Bash Er en testmetodikk, opprinnelig definert Av Ron Patton på sin bok Software Testing i 2001. Denne tilnærmingen til testing har vært nyttig på forskjellige squads På QuintoAndar, og som et resultat har vi laget en prosess for å optimalisere applikasjonen.

Feil hva?!

jeg hørte først begrepet bug bash på rekrutteringsintervjuet Mitt På QuintoAndar, og det hørtes bra ut. Senere var jeg på nettet og søkte etter mer informasjon bare for å finne ut at dette var en ganske spredt praksis, brukt av mange selskaper med en ting til felles: et smidig miljø. Bug Bash er en testmetodikk opprinnelig definert Av Ron Patton, 2001. I sin bok «Software testing» beskriver han bug bash som en prosedyre der alle som er involvert i produktets utviklingssyklus, legger til side sine vanlige daglige oppgaver og «pund på produktet». Så, alle som på en eller annen måte har hatt noe å si på produktet – fra definisjon til design; fra utvikling til markedsføring-bør være i samme rom, teste funksjonen, på så mange måter som mulig før du slipper den.Det bringer teamet — fra interessenter til utvikling-tettere sammen for å dekke så mange testscenarier som mulig, og dermed redusere sjansene for en defekt utgivelse. Da vi innså at dette kunne være et levedyktig og verdifullt alternativ til vårt raske, intense tempo i arbeidet, begynte vi sakte å introdusere konseptet i troppen, og alltid forbedre og tilpasse tilnærmingen i henhold til funksjonens behov.

Himmelen, Er det deg?

Høres ut som en drøm, Men hvis du noen gang har ledet en feil bash, vet du sikkert hvor kaotisk det kan komme til å samle så mange forskjellige profiler i et rom: noen mennesker som tviler på om det er en feil eller ikke, andre spør hvor du skal rapportere funnene, andre har problemer med å få tilgang til systemet, alle diskuterer hvordan man følger opp og prioriterer feilrettinger under testing og så videre. Uten en minimal prep, oddsen er at viktige detaljer kommer til å gå tapt i mellom spørsmål og post-its, folk vil bli frustrert for ikke å bli lyttet til og, til slutt, hva som bør være den mest produktive tid å finne bugs kan vise seg som bortkastet tid for hele laget.

i tillegg til den iboende kompleksiteten ved å koordinere en bug bash, hadde vi også utfordringen med å bruke konseptet på et produkt som tilbyr en komplett forretningsløsning: fra eiendomssøking til utleieadministrasjon. Det betyr back-end og front-end leveranser gjennom hele brukeropplevelsen. Derfor, her På QuintoAndar, var det viktig å ha en fleksibel og tilpasningsdyktig prosess som kunne passe begge scenarier.

Vi visste at det var — og fortsatt er — en stor utfordring foran oss: bli kjent med hvordan du bruker bug bash effektivt i ulike sammenhenger. Vi trengte en propell. Dette betyr en smidig prosess med viktige og robuste verktøy for sentralisering som var tilpasningsdyktig nok til å brukes på validering av ulike typer leveranser.

så lurer på om de ovennevnte erkjennelser, vi har laget en prosess som fokuserer på å kombinere viktige punkter for testing sammen med viktige elementer i feilrapportering, så forenklet som mulig uten at effektiviteten.som nevnt inkluderer grunnleggende for en god bug bash en prep-fase der kvalitetssikringspersonen setter opp betingelsene for testing, og gir de midlertidige testerne verktøy som gjør deres testferdigheter verdsatt. Det er tre hovedtrinn til en god oppsett:

Trinn 1: Lag et regneark for å sentralisere alle funn

Første ting først: vi trenger alle på samme side. Bokstavelig talt! Når du prøver å kartlegge problemer, er det grunnleggende å rapportere alt på ett enkelt dokument. Dette kan bety et delt notat, et tekstdokument, en gigantisk papp. Vi bestemte oss for å bruke et regneark der vi også kunne gi litt visuell veiledning om hva som ble testet. Dette valget var et samarbeid med teamets produktdesigner som beskriver fordelene for Selve Designet i artikkelen » Produktdesign & Bug bash: hvordan validere grensesnitt og kvalitetssikre leveransen fra ende til ende».

et regneark gjør det også enkelt å automatisere prosessen slik at den blir jevnere og mer funksjonell. I en bug bash regneark, har vi tre faner: Deltakere, Bug bash, Automatisk rapport.

En kort video som viser interaksjoner på et regneark. Det er tre faner i regnearket, og de første interaksjonene er på den første kategorien, kalt «Deltakere». Seks kolonner («Hvem tester», «Kontakt med produktet», «Simulert bruker», «Enhetstype», «Enhetsmerke» og «Nettleser») er felt en om gangen ved å velge et alternativ fra rullegardinmenyene.

Siden Quintoandars sluttbrukerapplikasjoner hovedsakelig er webbaserte, må testing inkludere forskjellige mobile og stasjonære enheter. Noen ganger problemet er enhetsrelatert gjør sin avsløring uunnværlig. Så vi opprettet» Deltakere » – fanen, hvor hver tester eller deltaker av bug bash legger inn informasjon som navn, simulert bruker, nettleser, enhetsmerke og enhetstype. Dette er den grunnleggende informasjonen vi trenger for å begynne å undersøke — eller fikse-problemet. Når denne informasjonen er fullført, kan vi fortsette.

på den andre kategorien «Bug bash» kombinerer vi test-og feilrapporteringselementene. Et bilde av konteksten som skal testes i den første kolonnen, etterfølges av tre kolonner hvor testeren legger inn testerens navn, en detaljert beskrivelse av problemet som er funnet, samt et bilde av det, hvis det er aktuelt. På denne måten, hvis det er tvil om rapporten, vet vi hvem som skal spørre om det og spare tid. Dette er spesielt verdifullt når vi sikrer front-end-leveranser fordi vi kan validere sluttproduktet mot designet layout. Hvis vi validerer back-end-leveranser, erstattes front-end-bildet vanligvis med en arbeidsflyt som forklarer hva som skjer på back-end. På denne måten holder vi folk lagt ut på konteksten, selv om det ikke er synlig testbar. Folk vil teste produktet og rapportere alle problemer, forbedringer og tvil på denne kategorien. Når testtiden er ute, vil teamet gå over de rapporterte problemene, gjennomgå og diskutere hva som er fornuftig å bli inkludert i fikseringsfasen.

En kort video viser det andre interaksjonssettet i den andre kategorien som heter»bug bash». På den første kolonnen er det et skjermbilde av en del av nettstedet etterfulgt av andre kolonner som heter » Hvem fant det ?», «Problemtittel»,» Problembeskrivelse»,» Skjermbilde «og»Rapport». Videoen viser hvert felt fylles ved å skrive.

På grunn av dette stadiet av alvorlighetsgrad evaluering og prioritering, vil hele teamet være klar over alle problemer funnet og velge de som er relatert til den utviklingssyklusen for rapportering. Dette vil optimalisere rapporteringsfasen og unngå oppfølgingsmøter for å prioritere problemene.

den tredje og siste fanen i regnearket, kalt «Automatisk rapport», er nøkkelen til å holde tritt med hastigheten på prosessene våre. Den inneholder et skript som tar all informasjon fra de to siste kategoriene og oppretter automatisk en problemrapport på Vår jira bord. Dette betyr at ingen informasjon går tapt i rapporteringsprosessen. Dette forhindrer mye omarbeiding og gjør hele prosessen mer effektiv. Skriptet er passelig, så det er mulig å legge til flere felt som skal rapporteres.

En kort video som viser de siste interaksjonene i regnearket. I kategorien» Auto report «er det en knapp som heter «Create». Over knappen er det brukerlegitimasjon. Deretter får brukeren Tilgang Til Scrip Editor fra Verktøy-menyen, og deretter vises et annet vindu med skriptets detaljer. En rask skanning gjennom skriptet og deretter tilbake til» Auto report «- fanen, klikker brukeren på» Create » – knappen og skriptet utføres.

Trinn 2: Lag en kontekstpresentasjon

for å være effektiv bør omfanget av produktet som skal testes være svært godt definert for alle som er involvert i testprosessen. Omfanget bør begrenses til funksjonen (e) som er lagt til i det aktuelle tidsvinduet eller utviklingssyklusen. Jo klarere folk handler om omfanget av den aktuelle testseremonien, desto mindre får du svar på om det er et feil-eller arvsproblem. Det er spesielt viktig å ha denne presentasjonen i tilfelle interessenter eller troppen utenforstående deltar i testing, fordi de ikke kan ha klarhet at folk inne utviklingen selv har.

Trinn 3: Bestill et rom og send invitasjon dager fremover

Ordne et rom for å passe en stor gruppe mennesker, samtidig som det ikke alltid er så enkelt å tenke på folks kalender. Det kan ta lang tid å matche alles kalender eller ha et stort nok rom tilgjengelig, så vær fremover. På invitasjonen, dele kontekst presentasjon sammen med bug bash regneark og sørg for å ha gitt tillatelse til alle deltakerne. Et annet svært viktig aspekt av bug bashes er tid. Sørg for å spare minst 1t 30m (en og en halv time) for å investere i denne seremonien. Det kan virke mye, men det er ikke når det er så mange forskjellige mennesker som bruker produktet og samhandler for å få en bedre tilnærming til brukeropplevelsen.