— het toepassen van het proces om de organisatie en gemakkelijk aan de bug bash cremona
belangrijk: dit is een stap voor stap hoe u een bug bash organiseert. Meer over de voordelen van het gebruik bij QuintoAndar is te vinden in het artikel “Hoe bug bashing vaak en consequent de teammindset veranderde in de richting van kwaliteit en gebouwde verbinding bij QuintoAndar”.
introductie
Bug Bash is een testmethode, oorspronkelijk gedefinieerd door Ron Patton op zijn boek Software Testing in 2001. Deze benadering van testen is nuttig geweest op verschillende teams bij QuintoAndar en als gevolg daarvan hebben we een proces gecreëerd om de toepassing ervan te optimaliseren.
Bug wat?!
Ik hoorde voor het eerst de term bug bash op mijn recruiting interview bij QuintoAndar en het klonk goed. Later was ik online op zoek naar meer informatie om erachter te komen dat dit een wijdverbreide praktijk was, gebruikt door veel bedrijven met één ding gemeen: een agile omgeving. Bug Bash is een testmethode oorspronkelijk gedefinieerd door Ron Patton, 2001. In zijn boek “Software testing” beschrijft hij bug bash als een procedure waarbij alle mensen die betrokken zijn bij de ontwikkelingscyclus van het product, opzij zetten hun normale dagelijkse taken en “pond op het product”. Dus, iedereen die op de een of andere manier iets te zeggen heeft gehad over het product — van definitie tot ontwerp; van ontwikkeling tot marketing — moet in dezelfde kamer zijn, het testen van de functie, op zoveel mogelijk manieren voordat het vrij te geven.
Het brengt het team — van stakeholders tot ontwikkeling-dichter bij elkaar om zo veel mogelijk testscenario ‘ s te behandelen en daardoor de kans op een defecte release te verkleinen. Erkennend dat dit een levensvatbaar en waardevol alternatief zou kunnen zijn voor ons snelle, intense werktempo, begonnen we het concept langzaam in de ploeg te introduceren, waarbij we de aanpak altijd verbeterden en aanpasten aan de behoeften van de functie.
hemel, ben jij dat?
klinkt als een droom, maar als je ooit een bug bash hebt geleid, Weet je waarschijnlijk hoe chaotisch het kan worden om zoveel verschillende profielen in een kamer te verzamelen: sommige mensen die twijfels hebben over het feit of het een bug is of niet, anderen die vragen waar ze de bevindingen moeten rapporteren, anderen die problemen hebben met toegang tot het systeem, iedereen die discussieert over het opvolgen en prioriteren van bug fixes tijdens het testen, enzovoort. Zonder een minimale prep, is de kans groot dat belangrijke details verloren gaan tussen vragen en post-its, zullen mensen gefrustreerd raken omdat er niet naar geluisterd wordt en, uiteindelijk, wat de meest productieve tijd zou moeten zijn het vinden van bugs kan blijken als een verspilling van tijd voor het hele team.
naast de inherente complexiteit van het coördineren van een bug bash, hadden we ook de uitdaging om het concept toe te passen op een product dat een complete zakelijke oplossing biedt: van zoeken naar onroerend goed tot verhuurbeheer. Dat betekent back-end en front-end deliverables gedurende de hele gebruikerservaring. Daarom was het hier bij QuintoAndar noodzakelijk om een flexibel en aanpasbaar proces te hebben dat geschikt was voor beide scenario ‘ s.
We wisten dat er nog een grote uitdaging voor ons lag en is: om te weten hoe je de bug bash effectief toe te passen in verschillende contexten. We hadden een propeller nodig. Betekenis, een soepel proces met essentiële en robuuste tools voor centralisatie die aanpasbaar genoeg was om te worden gebruikt op verschillende soorten leveringen’ validatie.
omdat we ons afvragen wat de bovenstaande realisaties zijn, hebben we een proces gecreëerd dat gericht is op het combineren van belangrijke testpunten samen met belangrijke elementen van bug reporting, zo vereenvoudigd mogelijk zonder afbreuk te doen aan de efficiëntie.
zoals gezegd, de grondbeginselen voor een goede bug bash omvat een prep fase waarin de persoon voor kwaliteitsborging, stelt de voorwaarden voor het testen, het verstrekken van de tijdelijke testers met tools die hun testvaardigheden gewaardeerd. Er zijn drie belangrijke stappen voor een goede set-up:
Stap 1: Maak een spreadsheet om alle bevindingen te centraliseren
eerste dingen eerst: we hebben iedereen op dezelfde pagina nodig. Letterlijk! Bij het in kaart brengen van problemen is het van fundamenteel belang om alles op één enkel document te rapporteren. Dit kan een gedeelde notitie betekenen, een tekstdoc, een gigantisch karton. We besloten om een spreadsheet te gebruiken waarin we ook wat visuele begeleiding konden geven van wat werd getest. Deze keuze was een samenwerking met de productontwerper van het team, die de voordelen voor het ontwerp zelf beschrijft in het artikel “Product Design & Bug bash: hoe interfaces te valideren en kwaliteit uw levering van end-to-end te verzekeren”.
met een spreadsheet kan het proces ook eenvoudig worden geautomatiseerd om soepeler en functioneler te zijn. In een bug bash-spreadsheet hebben we drie tabbladen: deelnemers, Bug bash, automatisch rapport.
omdat QuintoAndar ‘ s eindgebruikerstoepassingen meestal webgebaseerd zijn, moeten verschillende mobiele en desktopapparaten worden getest. Soms is het probleem apparaat-gerelateerde waardoor de openbaarmaking ervan onmisbaar. Dus hebben we het tabblad “deelnemers” gemaakt, waarin elke tester of deelnemer van de bug bash informatie invoert zoals naam, gesimuleerde gebruiker, browser, apparaatmerk en apparaattype. Dit zijn de basisgegevens die we nodig hebben om het probleem te onderzoeken of op te lossen. Zodra die informatie is voltooid, kunnen we doorgaan.
op het tweede tabblad “Bug bash” combineren we de test-en bugrapportage-elementen. Een beeld van de te testen context in de eerste kolom wordt gevolgd door drie kolommen waarin de tester de naam van de tester invoert, een gedetailleerde beschrijving van het gevonden probleem en, indien van toepassing, een afbeelding ervan. Op deze manier, als er twijfels over het verslag weten we wie te informeren over het en tijd te besparen. Dit is vooral waardevol bij het verzekeren van front-end leveringen, omdat we het eindproduct kunnen valideren tegen de ontworpen lay-out. Als we back-end leveringen valideren, wordt de front-end image meestal vervangen door een workflow waarin wordt uitgelegd wat er gebeurt op de back-end. Op deze manier houden we mensen op de hoogte van de context, ook al is het niet zichtbaar te testen. Mensen zullen het product testen en alle problemen, verbeteringen en twijfels op dit tabblad rapporteren. Wanneer de testtijd voorbij is, zal het team de gerapporteerde problemen bespreken, beoordelen en bespreken wat zinvol is om in de bevestigingsfase te worden opgenomen.
vanwege deze fase van beoordeling van de ernst en prioritering zal het hele team op de hoogte zijn van alle gevonden problemen en zal het de problemen selecteren die verband houden met die ontwikkelingscyclus om te rapporteren. Dit zal de rapporteringsfase optimaliseren en follow-upbijeenkomsten vermijden om de problemen te prioriteren.
het derde en laatste tabblad op de spreadsheet, genaamd “Automatic report” is de sleutel om de snelheid van onze processen bij te houden. Het bevat een script dat alle informatie van de laatste twee tabbladen neemt en automatisch een probleemrapport maakt op ons Jira bord. Dit betekent dat er geen informatie verloren gaat over de fase van het rapportageproces. Dit voorkomt veel nabewerking en maakt het hele proces veel efficiënter. Het script is aanpasbaar, zodat het mogelijk is om meer velden toe te voegen om te worden gerapporteerd.
Stap 2: Maak een contextpresentatie
om effectief te zijn, moet de omvang van het te testen product zeer goed gedefinieerd zijn voor iedereen die bij het testproces betrokken is. De reikwijdte moet worden beperkt tot de functie(s) toegevoegd in dat bepaalde tijdvenster of ontwikkelingscyclus. Hoe duidelijker mensen zijn over de omvang van die specifieke test ceremonie, hoe minder je krijgt om te antwoorden of dat is een bug of erfenis probleem. Het is vooral belangrijk om deze presentatie te hebben in het geval stakeholders of team buitenstaanders deelnemen aan de tests, omdat ze misschien niet de duidelijkheid hebben die mensen binnen de ontwikkeling zelf hebben.
Stap 3: Boek een kamer en stuur uitnodigingsdagen vooruit
Schik een kamer om bij een grote groep mensen te passen, terwijl het ook niet altijd zo eenvoudig is om op de agenda van mensen te letten. Het kan lang duren om aan ieders agenda te voldoen of een kamer beschikbaar te hebben die groot genoeg is, dus blijf voor. Deel op de uitnodiging de contextpresentatie samen met de bug bash-spreadsheet en zorg ervoor dat u alle deelnemers de benodigde toestemming hebt gegeven. Een ander zeer belangrijk aspect van bug bashes is de tijd. Zorg ervoor dat u minstens 1 uur 30m ( anderhalf uur) overhoudt om in deze ceremonie te investeren. Het lijkt misschien veel, maar het is niet wanneer er zo veel verschillende mensen met behulp van het product en interactie om een betere benadering van de gebruikerservaring te krijgen.
