— näin prosessi tuo organisaation ja helpon bug bash Cremona

tärkeää: tämä on vaihe vaiheelta, miten bug bash järjestetään. Lisää sen käytön eduista Quintoandarissa löytyy artikkelista ”Kuinka vikojen hakkaaminen usein ja johdonmukaisesti muutti tiimin ajattelutapaa kohti laatua ja rakensi yhteyden Quintoandarissa”.

Johdanto

Bug Bash on testimenetelmä, jonka Ron Patton määritteli alun perin kirjassaan Software Testing vuonna 2001. Tämä testausmenetelmä on ollut hyödyllinen Quintoandarin eri joukkueissa, ja sen seurauksena olemme luoneet prosessin optimoidaksemme sen soveltamisen.

Bug mitä?!

kuulin Quintoandarin rekrytointihaastattelussa ensi kertaa termin bug bash ja se kuulosti hyvältä. Myöhemmin etsin netistä lisää tietoa vain huomatakseni, että kyseessä oli varsin laajalle levinnyt käytäntö, jota käyttävät monet yritykset, joilla on yksi yhteinen asia: ketterä ympäristö. Bug Bash on alun perin Ron Pattonin vuonna 2001 määrittelemä Testimenetelmä. Kirjassaan ” Software testing ”hän kuvailee bug bashia menetelmäksi, jossa kaikki tuotteen kehityskaareen osallistuvat ihmiset laittavat syrjään säännölliset päivittäiset tehtävänsä ja”puntaroivat tuotetta”. Joten jokaisen, jolla on ollut sananvaltaa tuotteeseen — määrittelystä suunnitteluun, kehityksestä markkinointiin — pitäisi olla samassa huoneessa testaamassa ominaisuutta mahdollisimman monella tavalla ennen sen julkaisemista.

se tuo työryhmän — sidosryhmistä kehitykseen — lähemmäksi toisiaan kattaakseen mahdollisimman monta testiskenaariota ja vähentääkseen siten virheellisen julkaisun mahdollisuutta. Tunnustaen, että tämä voisi olla toteuttamiskelpoinen ja arvokas vaihtoehto nopealle, intensiiviselle työtahdillemme, aloimme hitaasti ottaa konseptin käyttöön ryhmässä, aina parantaen ja mukauttaen lähestymistapaa ominaisuuden tarpeiden mukaan.

taivas, oletko se sinä?

kuulostaa unelta, mutta jos olet joskus johtanut bug bashia, luultavasti tiedät kuinka kaoottiseksi voi tulla kerätä niin monia erilaisia profiileja huoneeseen: jotkut ihmiset herättävät epäilyksiä siitä, onko kyseessä vika vai ei, toiset kysyvät, mistä raportoida havainnot, toisilla on vaikeuksia päästä järjestelmään, kaikki keskustelevat siitä, miten seurata ja priorisoida vikakorjauksia testauksen aikana ja niin edelleen. Ilman minimaalinen prep, kertoimet ovat, että tärkeät tiedot ovat menossa menetetään välillä kysymyksiä ja post-it, ihmiset turhautuvat ei kuunneltu ja lopulta, mitä pitäisi olla tuottavin aika löytää vikoja voi osoittautua ajanhukkaa koko joukkue.

bug Bashin koordinoinnin luontaisen monimutkaisuuden lisäksi haasteena oli myös konseptin soveltaminen tuotteeseen, joka tarjoaa täydellisen liiketoimintaratkaisun: kiinteistöhausta vuokrahallintoon. Tämä tarkoittaa back-end-ja front-end-suoritteita koko käyttökokemuksen ajan. Siksi täällä Quintoandarissa oli välttämätöntä saada joustava ja mukautuva prosessi, joka sopisi molempiin skenaarioihin.

tiesimme, että edessä on — ja on edelleen — iso haaste: oppia soveltamaan bug bash tehokkaasti eri yhteyksissä. Tarvitsimme potkurin. Merkitys, sujuva prosessi, jossa on olennaiset ja vankat keskittämistyökalut, jotka ovat riittävän muunneltavia erilaisten toimitusten validointiin.

edellä mainittuja oivalluksia miettien olemme luoneet prosessin, joka keskittyy testauksen avainkohtien ja vikailmoituksen keskeisten elementtien yhdistämiseen, mahdollisimman yksinkertaistettuna sen tehokkuudesta tinkimättä.

kuten mainittua, hyvän bugin Bashin perusteisiin kuuluu preppausvaihe, jossa laadunvarmistaja laatii testauksen edellytykset ja tarjoaa väliaikaisille testaajille työkaluja, joiden avulla heidän testaustaitojaan arvostetaan. Hyvään asetelmaan on kolme päävaihetta:

Vaihe 1: Luo taulukkolaskenta, johon keskitetään kaikki havainnot

First things first: Tarvitsemme kaikki samalle sivulle. Kirjaimellisesti! Kun ongelmia yritetään kartoittaa, on olennaista raportoida kaikki yhdellä asiakirjalla. Tämä voi tarkoittaa yhteistä lappua, tekstilookia, jättimäistä pahvia. Päätimme käyttää laskentataulukkoa, jossa voisimme antaa myös visuaalista ohjausta siitä, mitä testattiin. Valinta tehtiin yhteistyössä tiimin tuotesuunnittelijan kanssa, joka kuvaa itse suunnittelun hyötyjä artikkelissa ”Product Design & Bug Bash: how to validate interfaces and quality Assur the delivery from end-to-end”.

taulukkolaskennan avulla prosessi voidaan myös automatisoida helposti sujuvammaksi ja toimivammaksi. Bug bash taulukkolaskenta, meillä on kolme välilehdet: osallistujat, Bug bash, Automaattinen raportti.

koska Quintoandarin loppukäyttäjäsovellukset ovat pääosin web-pohjaisia, testauksessa tulee olla mukana erilaisia mobiili-ja työpöytälaitteita. Joskus ongelmana on laitteeseen liittyvä sen paljastaminen välttämättömäksi. Joten loimme ”osallistujat” välilehti, jossa jokainen testaaja tai osallistuja bug bash syöttää tietoja, kuten nimi, simuloitu käyttäjä, selain, laitteen tuotemerkin ja Laitetyyppi. Nämä ovat perustiedot, joita tarvitsemme, jotta voimme alkaa tutkia — tai korjata — ongelmaa. Kun tieto on saatu valmiiksi, voimme jatkaa.

toisessa välilehdessä ”Bug bash” yhdistämme testaus-ja vikailmoituselementit. Testattavan asiayhteyden kuva ensimmäisessä sarakkeessa seuraa kolme saraketta, joihin testaaja syöttää testaajan nimen, yksityiskohtaisen kuvauksen havaitusta ongelmasta sekä tarvittaessa kuvan siitä. Näin, jos mietintöön liittyy epäilyksiä, tiedämme, keneltä sitä kannattaa tiedustella ja säästää aikaa. Tämä on erityisen arvokasta front-end-toimitusten varmistamisessa, koska voimme validoida lopputuotteen suunniteltua ulkoasua vastaan. Jos validoimme back-end-toimituksia, etupään kuva korvataan yleensä työnkululla, jossa selitetään, mitä takapäässä tapahtuu. Näin pidämme ihmiset ajan tasalla asiayhteydestä, vaikka se ei ole näkyvästi testattavissa. Ihmiset testaavat tuotetta ja raportoivat kaikista ongelmista, parannuksista ja epäilyistä tällä välilehdellä. Kun testausaika on päättynyt, tiimi käy raportoidut asiat läpi, käy läpi ja keskustelee siitä, mitä on järkevää ottaa mukaan korjausvaiheeseen.

tämän vaikeusasteen arvioinnin ja priorisoinnin vuoksi koko tiimi on tietoinen kaikista löydetyistä asioista ja valitsee raportoitavaksi kyseiseen kehityssykliin liittyvät asiat. Näin optimoidaan raportointivaihe ja vältetään seurantakokoukset ongelmien priorisoimiseksi.

taulukkolaskennan kolmas ja viimeinen välilehti, nimeltään ”Automaattinen raportti”, on avain prosessiemme nopeuteen. Se sisältää komentosarjan, joka ottaa kaikki tiedot kahdesta viimeisestä välilehdestä ja luo automaattisesti ongelmaraportin jira-laudallemme. Tämä tarkoittaa, että raportointivaiheessa ei menetetä tietoja. Tämä estää paljon uudelleenkäsittelyä ja tekee koko prosessista paljon tehokkaampaa. Skripti on muokattavissa, joten on mahdollista lisätä lisää raportoitavia kenttiä.

Step 2: Create a context presentation

to be effective, the extent of the product to be investigated to everyone involving process. Soveltamisala olisi rajattava kyseiseen aikaikkunaan tai kehityssykliin lisättyihin piirteisiin. Mitä selkeämmät ihmiset ovat kyseisen testiseremonian laajuudesta, sitä vähemmän saat vastata, onko kyseessä bugi vai perintöongelma. On erityisen tärkeää saada tämä esitys, jos sidosryhmät tai joukkue ulkopuoliset osallistuvat testaukseen, koska heillä ei ehkä ole selkeyttä, että ihmiset sisällä itse kehitys on.

Vaihe 3: Varaa huone ja lähetä kutsupäivät eteenpäin

Järjestä huone, johon mahtuu suuri joukko ihmisiä, mutta samalla ihmisten kalenterin hoitaminen ei ole aina niin yksinkertaista. Se voi kestää kauan vastaamaan kaikkien kalenterin tai on tarpeeksi iso huone käytettävissä, joten pysy edellä. Jaa kutsussa kontekstiesitys yhdessä bug bash-laskentataulukon kanssa ja varmista, että olet antanut tarvittavan luvan kaikille osallistujille. Toinen erittäin tärkeä näkökohta bug bashes on aika. Varmista säästää vähintään 1h 30m ( puolitoista tuntia) investoida tähän seremoniaan. Se voi tuntua paljolta, mutta se ei ole, kun on niin paljon erilaisia ihmisiä, jotka käyttävät tuotetta ja ovat vuorovaikutuksessa saadakseen paremman lähestymistavan käyttökokemukseen.