— hur man tillämpar processen för att få organisation och lätt att buggen bash Cremona

viktigt: Detta är ett steg för steg för hur man organiserar en bugg bash. Mer om fördelarna med dess användning på QuintoAndar finns i artikeln ”Hur bug bashing ofta och konsekvent förändrade lagets tankesätt mot kvalitet och byggd anslutning på QuintoAndar”.

introduktion

Bug Bash är en testmetodik, ursprungligen definierad av Ron Patton på sin bok Software Testing 2001. Denna metod för testning har varit till hjälp på olika squads på QuintoAndar och som ett resultat har vi skapat en process för att optimera dess tillämpning.

Bug vad?!

Jag hörde först termen bug bash på min rekryteringsintervju på QuintoAndar och det lät bra. Senare letade jag online efter mer information bara för att ta reda på att detta var en ganska spridd praxis, som användes av många företag med en sak gemensamt: en smidig miljö. Bug Bash är en testmetodik som ursprungligen definierades av Ron Patton, 2001. I sin bok ”Software testing” beskriver han bug bash som ett förfarande där alla som är involverade i produktens utvecklingscykel lägger undan sina vanliga dagliga uppgifter och ”pundar på produkten”. Så alla som på något sätt har haft något att säga om produkten — från definition till design; från utveckling till marknadsföring — borde vara i samma rum och testa funktionen på så många sätt som möjligt innan de släpps.

det för teamet — från intressenter till utveckling — närmare varandra för att täcka så många testscenarier som möjligt och därmed minska risken för en defekt release. Med tanke på att detta kan vara ett livskraftigt och värdefullt alternativ till vårt snabba, intensiva arbetstakt började vi långsamt introducera konceptet i truppen, alltid förbättra och anpassa tillvägagångssättet efter funktionens behov.

himlen, är det du?

låter som en dröm men om du någonsin har lett en buggbash vet du förmodligen hur kaotiskt det kan bli att samla så många olika profiler i ett rum: vissa människor väcker tvivel om huruvida det är en bugg eller inte, andra frågar Var man ska rapportera resultaten, andra har problem med att komma åt systemet, alla diskuterar hur man följer upp och prioriterar buggfixar under testning och så vidare. Utan en minimal prep är oddsen att viktiga detaljer kommer att gå vilse mellan frågor och post-its, människor kommer att bli frustrerade för att inte lyssnas på och i slutändan vad som borde vara den mest produktiva tiden att hitta buggar kan visa sig som slöseri med tid för hela laget.

förutom den inneboende komplexiteten att samordna en buggbash, hade vi också utmaningen att tillämpa konceptet på en produkt som erbjuder en komplett affärslösning: från fastighetssökning till hyresadministration. Det betyder back-end och front-end-leveranser genom hela användarupplevelsen. Därför var det här på QuintoAndar absolut nödvändigt att ha en flexibel och anpassningsbar process som kunde passa båda scenarierna.

vi visste att det fanns-och fortfarande är – en stor utmaning framför oss: lär känna hur man applicerar bug bash effektivt i olika sammanhang. Vi behövde en propeller. Det vill säga en smidig process med väsentliga och robusta verktyg för centralisering som var anpassningsbara nog att användas vid olika typer av leveranser validering.

så undrar om ovanstående insikter, vi har skapat en process som fokuserar på att kombinera viktiga punkter för testning tillsammans med viktiga delar av felrapportering, så förenklat som möjligt utan att kompromissa med dess effektivitet.

som nämnts innehåller grunden för en bra buggbash en prep-fas där kvalitetssäkringspersonen ställer in villkoren för testning, vilket ger de tillfälliga testarna verktyg som gör deras testfärdigheter värderade. Det finns tre huvudsteg till en bra uppsättning:

Steg 1: Skapa ett kalkylblad för att centralisera alla resultat

första saker först: vi behöver alla på samma sida. Bokstavligen! När man försöker kartlägga problem är det grundläggande att rapportera allt på ett enda dokument. Detta kan innebära en delad anteckning, ett textdokument, en jätte kartong. Vi bestämde oss för att använda ett kalkylblad där vi också kunde ge visuell vägledning om vad som testades. Detta val var ett samarbete med teamets produktdesigner som beskriver fördelarna med själva designen i artikeln ”produktdesign & Bug bash: hur man validerar gränssnitt och kvalitetssäkrar din leverans från end-to-end”.

ett kalkylblad gör det också enkelt att automatisera processen för att bli mjukare och mer funktionell. I ett bug bash-kalkylblad har vi tre flikar: deltagare, Bug bash, Automatisk rapport.

eftersom Quintoandars slutanvändarapplikationer mestadels är webbaserade måste testning inkludera olika mobila och stationära enheter. Ibland är problemet enhetsrelaterat vilket gör att det är oumbärligt att avslöja det. Så vi skapade fliken ”deltagare”, där varje testare eller deltagare i bug bash matar in information som namn, simulerad användare, webbläsare, enhetsmärke och enhetstyp. Det här är den grundläggande informationen vi behöver för att börja undersöka — eller fixa — problemet. När informationen är klar kan vi fortsätta.

på den andra fliken ”Bug bash” kombinerar vi test-och felrapporteringselementen. En bild av sammanhanget som ska testas i den första kolumnen följs av tre kolumner där testaren matar in testarens namn, en detaljerad beskrivning av problemet som hittats samt en bild av det, om tillämpligt. På det här sättet, om det finns tvivel om rapporten vet vi vem vi ska fråga om det och spara tid. Detta är särskilt värdefullt när vi säkerställer front-end-leveranser eftersom vi kan validera slutprodukten mot den designade layouten. Om Vi validerar back-end-leveranser ersätts front – end-bilden vanligtvis med ett arbetsflöde som förklarar vad som händer på back-end. På så sätt håller vi människor publicerade i sammanhanget även om det inte är synligt testbart. Människor kommer att testa produkten och rapportera alla problem, förbättringar och tvivel på den här fliken. När testtiden är slut kommer teamet att gå igenom de rapporterade problemen, granska och diskutera vad som är vettigt att ingå i fixeringsfasen.

På grund av detta stadium av svårighetsgrad utvärdering och prioritering kommer hela laget att vara medveten om alla problem som hittats och välja de som är relaterade till den utvecklingscykeln för rapportering. Detta kommer att optimera rapporteringsfasen och undvika uppföljningsmöten för att prioritera problemen.

den tredje och sista fliken i kalkylbladet, med namnet ”Automatisk rapport” är nyckeln till att hålla jämna steg med hastigheten på våra processer. Den innehåller ett skript som tar all information från de två sista flikarna och skapar automatiskt en problemrapport på vår Jira-styrelse. Det betyder att ingen information går förlorad i rapporteringsprocessen. Detta förhindrar mycket omarbetning och gör hela processen mer effektiv. Skriptet är anpassningsbart så det är möjligt att lägga till fler fält som ska rapporteras.

en kort video som visar de sista interaktionerna i kalkylbladet. På fliken ” Auto report ”finns en knapp som heter”Skapa”. Ovanför knappen finns användaruppgifter. Därefter kommer användaren åt Skriptredigeraren från Verktyg-menyn och sedan visas ett annat fönster med skriptets detaljer. En snabbsökning genom skriptet och sedan tillbaka till fliken ”Auto report” klickar användaren på ”Skapa” – knappen och skriptet körs.

steg 2: skapa en kontextpresentation

för att vara effektiv bör omfattningen av den produkt som ska testas vara mycket väl definierad för alla som är involverade i testprocessen. Räckvidden bör begränsas till de funktioner som läggs till i det specifika tidsfönstret eller utvecklingscykeln. Ju tydligare människor handlar om omfattningen av den speciella testceremonin, desto mindre får du svara på om det är ett fel eller ett äldre problem. Det är särskilt viktigt att ha denna presentation om intressenter eller utomstående utomstående deltar i testningen, för att de kanske inte har den tydlighet som människor inom själva utvecklingen har.

steg 3: boka ett rum och skicka inbjudningsdagar framåt

ordna ett rum för att passa en stor grupp människor samtidigt som man tänker på människors Kalender är inte alltid så enkelt. Det kan ta lång tid att matcha allas kalender eller ha ett tillräckligt stort rum tillgängligt, så fortsätt. På inbjudan, dela kontextpresentationen tillsammans med Bug bash-kalkylbladet och se till att ha gett tillstånd till alla deltagare. En annan mycket viktig aspekt av bug bashes är tid. Se till att spara minst 1h 30m ( en och en halv timme) för att investera i denna ceremoni. Det kan verka mycket men det är inte när det finns så många olika människor som använder produkten och interagerar för att få en bättre inställning till användarupplevelsen.