— hvordan man anvender processen til at bringe organisation og let til fejlen bash Cremona
Vigtigt: Dette er et trin for trin af, hvordan man organiserer en bug bash. Mere om fordelene ved dets anvendelse på Kvintoandar kan findes i artiklen “Hvordan bug bashing ofte og konsekvent ændrede teamets tankegang mod kvalitet og bygget forbindelse på Kvintoandar”.
introduktion
Bug Bash er en testmetode, oprindeligt defineret af Ron Patton på hans Bogprogramtest i 2001. Denne tilgang til test har været nyttig på forskellige hold på Kvintoandar, og som et resultat har vi oprettet en proces for at optimere dens anvendelse.
Bug hvad?!
Jeg hørte først udtrykket bug bash på min rekrutteringssamtale hos Kvintoandar, og det lød godt. Senere, Jeg søgte online efter mere information kun for at finde ud af, at dette var en ret spredt praksis, brugt af mange virksomheder med en ting til fælles: et smidigt miljø. Bug Bash er en testmetode, der oprindeligt blev defineret af Ron Patton, 2001. I sin bog “testing” beskriver han bug bash som en procedure, hvor alle mennesker, der er involveret i produktets udviklingscyklus, lægger deres regelmæssige daglige opgaver til side og “pund på produktet”. Så alle, der på en eller anden måde har haft indflydelse på produktet — fra definition til design; fra udvikling til markedsføring — skal være i samme rum og teste funktionen på så mange måder som muligt, før de frigives.
det bringer teamet — fra interessenter til udvikling — tættere sammen for at dække så mange testscenarier som muligt og dermed reducere chancerne for en defekt frigivelse. Da vi erkendte, at dette kunne være et levedygtigt og værdifuldt alternativ til vores hurtige, intense arbejdstempo, begyndte vi langsomt at introducere konceptet i truppen og altid forbedre og tilpasse tilgangen i henhold til funktionens behov.
himlen, er det dig?
lyder som en drøm, men hvis du nogensinde har ført en bug bash, ved du sikkert, hvor kaotisk det kan komme til at samle så mange forskellige profiler i et rum: nogle mennesker rejser tvivl om, hvorvidt det er en fejl eller ej, andre spørger, hvor de skal rapportere resultaterne, andre har problemer med at få adgang til systemet, alle diskuterer, hvordan man følger op og prioriterer fejlrettelser under test og så videre. Uden en minimal prep, odds er, at vigtige detaljer vil gå tabt mellem spørgsmål og post-its, folk bliver frustrerede over ikke at blive lyttet til og, ultimativt, hvad der skal være den mest produktive tid at finde fejl kan vise sig som spild af tid for hele holdet.
ud over den iboende kompleksitet ved at koordinere en bug bash havde vi også udfordringen med at anvende konceptet på et produkt, der tilbyder en komplet forretningsløsning: fra ejendomssøgning til udlejningsadministration. Det betyder back-end og front-end leverancer gennem hele brugeroplevelsen. Derfor var det vigtigt at have en fleksibel og tilpasningsdygtig proces, der kunne passe til begge scenarier.
Vi vidste, at der var — og stadig er — en stor udfordring foran os: Lær at vide, hvordan man anvender bug bash effektivt i forskellige sammenhænge. Vi havde brug for en propel. Betydning, en jævn proces med vigtige og robuste værktøjer til centralisering, der var tilpasningsdygtige nok til at blive brugt på forskellige former for leverancevalidering.
så undrer vi os over ovenstående erkendelser, vi har oprettet en proces med fokus på at kombinere nøglepunkter for test sammen med nøgleelementer i fejlrapportering, så forenklet som muligt uden at gå på kompromis med dens effektivitet.
som nævnt indeholder fundamentet for en god bug bash en prep-fase, hvor kvalitetssikringspersonen opstiller betingelserne for testning og giver de midlertidige testere værktøjer, der gør deres testfærdigheder værdsat. Der er tre hovedtrin til en god opsætning:
Trin 1: Opret et regneark for at centralisere alle fund
første ting først: Vi har brug for alle på samme side. Bogstaveligt talt! Når man prøver at kortlægge problemer, er det grundlæggende at rapportere alt på et enkelt dokument. Dette kan betyde en delt note, en tekst doc, en kæmpe pap. Vi besluttede at bruge et regneark, hvor vi også kunne give en visuel vejledning af, hvad der blev testet. Dette valg var et samarbejde med holdets produktdesigner, der beskriver fordelene ved selve designet i artiklen “produktdesign & Bug bash: sådan valideres grænseflader og kvalitetssikrer din levering fra ende til ende”.
et regneark tillader også, at processen let kan automatiseres for at være glattere og mere funktionel. I et bug bash-regneark har vi tre faner: deltagere, Bug bash, automatisk rapport.
da slutbrugerapplikationer for det meste er internetbaserede, skal Test omfatte forskellige mobile og stationære enheder. Nogle gange er problemet enhedsrelateret, hvilket gør dets offentliggørelse uundværlig. Så vi oprettede fanen “deltagere”, hvor hver tester eller deltager i bug bash indtaster oplysninger som navn, simuleret bruger, bro.ser, enhedsmærke og enhedstype. Dette er de grundlæggende oplysninger, vi har brug for for at begynde at undersøge — eller løse — problemet. Når disse oplysninger er afsluttet, kan vi fortsætte.
på den anden fane “Bug bash” kombinerer vi test-og fejlrapporteringselementerne. Et billede af den kontekst, der skal testes i den første kolonne, efterfølges af tre kolonner, hvor testeren indtaster testerens navn, en detaljeret beskrivelse af det fundne problem samt et billede af det, hvis relevant. På denne måde, hvis der er tvivl om rapporten, ved vi, hvem vi skal spørge om det og spare tid. Dette er især værdifuldt, når vi sikrer front-end-leverancer, fordi vi kan validere det endelige produkt mod det designede layout. Hvis vi validerer back – end-leverancer, erstattes front-end-billedet normalt med en arbejdsgang, der forklarer, hvad der sker på back-end. På denne måde holder vi folk opdateret om konteksten, selvom det ikke er synligt testbart. Folk vil teste produktet og rapportere alle problemer, forbedringer og tvivl på denne fane. Når testtiden er udløbet, holdet gennemgår de rapporterede problemer, gennemgå og diskutere, hvad der giver mening at blive inkluderet i fikseringsfasen.
På grund af denne fase af alvorlighedsevaluering og prioritering vil hele teamet være opmærksom på alle fundne problemer og vælge dem, der er relateret til den udviklingscyklus til rapportering. Dette vil optimere rapporteringsfasen og undgå opfølgningsmøder for at prioritere problemerne.
den tredje og sidste fane på regnearket, der hedder “automatisk rapport”, er nøglen til at holde trit med hastigheden på vores processer. Den indeholder et script, der tager alle oplysninger fra de sidste to faner og opretter automatisk et problem rapport på vores Jira bord. Det betyder, ingen oplysninger tabt på rapporteringsprocessen fase. Dette forhindrer en masse omarbejdning og gør hele processen mere effektiv. Scriptet kan tilpasses, så det er muligt at tilføje flere felter, der skal rapporteres.
Trin 2: Opret en kontekstpræsentation
for at være effektiv skal omfanget af det produkt, der skal testes, være meget veldefineret for alle involverede i testprocessen. Anvendelsesområdet bør begrænses til de(n) funktion (er), der er tilføjet i det pågældende tidsvindue eller udviklingscyklus. Jo klarere folk handler om omfanget af den pågældende testceremoni, jo mindre får du svar på, om det er et fejl-eller arvsproblem. Det er især vigtigt at have denne præsentation, hvis interessenter eller hold udenforstående deltager i testen, fordi de måske ikke har den klarhed, som folk inden for selve udviklingen har.
Trin 3: Book et værelse og send invitationsdage forude
Arranger et rum, der passer til en stor gruppe mennesker, mens det også ikke er så enkelt at passe på folks kalender. Det kan tage lang tid at matche alles kalender eller have et stort nok værelse til rådighed, så hold dig foran. På invitationen skal du dele kontekstpræsentationen sammen med bug bash-regnearket og sørge for at have givet den nødvendige tilladelse til alle deltagere. Et andet meget vigtigt aspekt af bug bashes er tid. Sørg for at spare mindst 1 time 30m ( en og en halv time) for at investere i denne ceremoni. Det kan virke meget, men det er ikke, når der er så mange forskellige mennesker, der bruger produktet og interagerer for at få en bedre tilgang til brugeroplevelsen.
