— hogyan kell alkalmazni a folyamatot, hogy a szervezet és könnyen a bug Bash Cremona
fontos: ez egy lépésről lépésre, hogyan kell megszervezni egy bug bash. A QuintoAndar használatának előnyeiről bővebben a következő cikkben olvashat:”Hogyan változtatta meg a bug bashing gyakran és következetesen a csapat gondolkodásmódját a minőség felé, és épített kapcsolatot a Quintoandarnál”.
Bevezetés
A Bug Bash egy teszt módszertan, amelyet eredetileg Ron Patton definiált a szoftvertesztelés című könyvében 2001-ben. A tesztelésnek ez a megközelítése hasznos volt a QuintoAndar különböző csapataiban, és ennek eredményeként létrehoztunk egy folyamatot az alkalmazás optimalizálására.
Bug mi?!
a bug bash kifejezést először a QuintoAndar toborzási interjúján hallottam, és jól hangzott. Később online kerestem további információkat, csak hogy megtudjam, hogy ez egy meglehetősen elterjedt gyakorlat, amelyet sok vállalat használ, egy közös dologgal: agilis környezettel. A Bug Bash egy teszt módszertan, amelyet eredetileg Ron Patton, 2001 határozott meg. “Szoftvertesztelés” című könyvében a bug bash-t olyan eljárásként írja le, amelyben a termék fejlesztési ciklusában részt vevő összes ember félreteszi a szokásos napi feladatait és “font a terméken”. Tehát mindenkinek, akinek valamilyen módon beleszólása volt a termékbe — a meghatározástól a tervezésig; a fejlesztéstől a marketingig-ugyanabban a szobában kell lennie, tesztelve a funkciót, a lehető legtöbb módon, mielőtt kiadná.
közelebb hozza a csapatot — az érdekeltektől a fejlesztésig—, hogy a lehető legtöbb tesztforgatókönyvet lefedje, ezáltal csökkentve a hibás kiadás esélyét. Felismerve, hogy ez életképes és értékes alternatívája lehet a gyors, intenzív munkánknak, elkezdtük lassan bevezetni a koncepciót a csapatba, folyamatosan fejlesztve és adaptálva a megközelítést a funkció igényeinek megfelelően.
Mennyország, te vagy az?
úgy hangzik, mint egy álom, de ha valaha is vezettél egy bug bash-t, akkor valószínűleg tudod, milyen kaotikus lehet, hogy olyan sok különböző profilt gyűjtsön össze egy szobában: egyesek kétségeket vetnek fel arról, hogy ez egy hiba-e vagy sem, mások azt kérdezik, hogy hol jelentsék az eredményeket, mások nehezen férnek hozzá a rendszerhez, mindenki megvitatja, hogyan kell nyomon követni és rangsorolni a hibajavításokat tesztelés közben stb. Minimális előkészítés nélkül esély van arra, hogy a fontos részletek elvesznek a kérdések és a post-it között, az emberek csalódottak lesznek, mert nem hallgatnak meg, és végül, mi legyen a legtermékenyebb idő a hibák megtalálása az egész csapat számára időpocsékolásnak bizonyulhat.
a bug bash koordinálásának velejáró bonyolultsága mellett az a kihívás is felmerült, hogy a koncepciót olyan termékre alkalmazzuk, amely teljes üzleti megoldást kínál: az ingatlankereséstől a bérleti adminisztrációig. Ez back-end és front-end termékeket jelent a teljes felhasználói élményben. Ezért itt, Quintoandarban elengedhetetlen volt egy rugalmas és alkalmazkodó folyamat, amely mindkét forgatókönyvnek megfelel.
tudtuk, hogy nagy kihívás áll előttünk — és még mindig az: Ismerkedés a bug bash hatékony alkalmazásával különböző összefüggésekben. Kellett egy propeller. Ez azt jelenti, hogy egy zökkenőmentes folyamat alapvető és robusztus eszközökkel a központosításhoz, amely elég alkalmazkodó volt ahhoz, hogy különböző típusú szállítások érvényesítésére használható legyen.
tehát kíváncsi a fenti felismerések, hoztunk létre egy folyamat középpontjában ötvözi kulcsfontosságú pontjait tesztelés mellett kulcsfontosságú elemei hibajelentés, a lehető legegyszerűbben veszélyeztetése nélkül a hatékonyságot.
mint már említettük, az alapjait egy jó bug bash tartalmaz egy prep fázis, amelyben a minőségbiztosítási személy, beállítja a feltételeket a tesztelés, amely az ideiglenes tesztelők eszközöket, amelyek a vizsgálati készségek értékes. Három fő lépés van a jó beállításhoz:
1. lépés: Hozzon létre egy táblázatot az összes eredmény központosításához
először is: mindenkinek ugyanazon az oldalon kell lennie. Szó szerint! A problémák feltérképezésekor alapvető fontosságú, hogy mindent egyetlen dokumentumon jelentsen. Ez azt jelentheti, hogy megosztott jegyzet, szöveges dokumentum, óriási karton. Úgy döntöttünk, hogy egy táblázatot használunk, amelyben vizuális útmutatást is adhatunk a tesztelésről. Ez a választás a csapat terméktervezőjével való együttműködés volt, aki a “Product Design & Bug bash: hogyan lehet érvényesíteni az interfészeket és a minőséget biztosítani a szállítás végponttól végpontig”című cikkben írja le a tervezés előnyeit.
a táblázat lehetővé teszi a folyamat egyszerű automatizálását, hogy simább és funkcionálisabb legyen. A bug Bash táblázatban három fülünk van: résztvevők, Bug bash, automatikus jelentés.
mivel a QuintoAndar végfelhasználói alkalmazásai többnyire web-alapúak, a tesztelésnek különböző mobil és asztali eszközöket kell tartalmaznia. Néha a probléma az eszközzel kapcsolatos, így a közzététel nélkülözhetetlen. Ezért létrehoztuk a” résztvevők ” fület, amelyben a bug bash minden tesztelője vagy résztvevője olyan információkat ad meg, mint a név, a szimulált felhasználó, a böngésző, az eszköz márkája és az eszköz típusa. Ezek az alapvető információk, amelyekre szükségünk van a probléma kivizsgálásának — vagy kijavításának — megkezdéséhez. Amint ez az információ elkészült, folytathatjuk.
a második “Bug bash” lapon egyesítjük a tesztelési és hibajelentési elemeket. Az első oszlopban a tesztelendő kontextus képét három oszlop követi, ahol a tesztelő megadja a tesztelő nevét, a talált probléma részletes leírását, valamint adott esetben annak képét. Így, ha kétségek merülnek fel a jelentéssel kapcsolatban, tudjuk, ki érdeklődjön róla, és időt takaríthat meg. Ez különösen értékes a front-end szállítások biztosításakor, mivel a végterméket a tervezett elrendezés alapján érvényesíthetjük. Ha a back-end szállítások érvényesítését végezzük, a front-end képet általában egy munkafolyamat váltja fel, amely elmagyarázza, mi történik a back-end-en. Ily módon, az embereket közzétesszük a kontextusban, annak ellenére, hogy nem láthatóan tesztelhető. Az emberek tesztelik a terméket, és jelentik az összes problémát, fejlesztést és kétséget ezen a lapon. Amikor a tesztelési idő lejár, a csapat áttekinti a jelentett problémákat, áttekinti és megvitatja, hogy mi értelme van a rögzítési szakaszba bevonni.
rövid videó a második interakciókészlet megjelenítése a “bug Bash”nevű második lapon. Az első oszlopban, van egy képernyőkép a weboldal egy részéről, amelyet más oszlopok követnek: “ki találta meg ?”, “Probléma címe”, “probléma leírása”, “képernyőkép”és ” jelentés”. A videó azt mutatja, hogy az egyes mezőket gépeléssel töltik ki.
a súlyossági értékelés és a priorizálás ezen szakaszának köszönhetően az egész csapat tisztában lesz az összes talált problémával, és kiválasztja az adott fejlesztési ciklushoz kapcsolódókat a jelentéshez. Ez optimalizálja a jelentési fázist, és elkerüli az ülések nyomon követését a problémák prioritása érdekében.
a táblázat harmadik és utolsó lapja, az “automatikus jelentés” kulcsfontosságú ahhoz, hogy lépést tartsunk folyamataink sebességével. Tartalmaz egy szkriptet, amely az utolsó két lap összes információját veszi, és automatikusan létrehoz egy hibajelentést a Jira táblán. Ez azt jelenti, hogy nincs információ elveszett a jelentési folyamat szakaszában. Ez megakadályozza a sok átdolgozást, és hatékonyabbá teszi az egész folyamatot. A script testreszabható, így lehetséges, hogy adjunk több mezőt kell jelenteni.
táblázat utolsó interakciói. Az ” automatikus jelentés “lapon található egy”Létrehozás” gomb. A gomb felett vannak felhasználói hitelesítő adatok. Ezután a felhasználó hozzáfér Scrip Editor az Eszközök menüből, majd egy másik ablak jelenik meg a szkript részleteit. Egy gyors átkutat a script, majd vissza a” Auto report “fülre, a felhasználó rákattint a” Create ” gombra, és a script kerül végrehajtásra.
2.lépés: Hozzon létre egy kontextus bemutatót
a hatékonyság érdekében a tesztelendő termék mértékét nagyon jól meg kell határozni mindenki számára, aki részt vesz a tesztelési folyamatban. A hatókört az adott időablakban vagy fejlesztési ciklusban hozzáadott funkció(OK) ra kell korlátozni. Minél tisztábbak az emberek az adott tesztünnepség hatóköréről, annál kevésbé fog válaszolni arra, hogy ez hiba vagy örökölt probléma. Különösen fontos, hogy ez az előadás abban az esetben, ha az érdekeltek vagy a csapat kívülállói részt vesznek a tesztelésben, mert nem biztos, hogy tisztában vannak azzal, hogy a fejlesztésen belüli emberek rendelkeznek.
3. lépés: foglaljon szobát és küldjön meghívót nappal előre
rendezzen egy szobát, hogy illeszkedjen egy nagy embercsoporthoz, miközben az emberek naptárát is figyelembe veszi, nem mindig ilyen egyszerű. Hosszú időbe telhet, amíg mindenki naptárához illeszkedik, vagy elég nagy szoba áll rendelkezésre, ezért maradjon előre. A meghívón ossza meg a kontextus bemutatót a bug bash táblázattal együtt, és győződjön meg róla, hogy megadta a szükséges engedélyt minden résztvevőnek. A bug bashes másik nagyon fontos szempontja az idő. Ügyeljen arra, hogy legalább 1 óra 30 percet ( másfél órát) takarítson meg, hogy befektessen ebbe az ünnepségbe. Soknak tűnhet, de nem akkor, ha olyan sok különböző ember használja a terméket, és kölcsönhatásba lép, hogy jobb megközelítést kapjon a felhasználói élményhez.
