— Jak aplikovat proces aby organizace a snadné bug bash cremona

důležité: toto je krok za krokem, jak uspořádat chybu bash. Více o výhodách jeho použití v QuintoAndar lze nalézt v článku „Jak bug napadání často a důsledně změnil tým myšlení směrem ke kvalitě a vestavěné připojení na QuintoAndar“.

Úvod

Bug Bash je testovací metodika, kterou původně definoval Ron Patton ve své knize testování softwaru v roce 2001. Tento přístup k testování byl užitečný na různých jednotkách v Quintoandaru a v důsledku toho jsme vytvořili proces optimalizace jeho aplikace.

chyba co?!

poprvé jsem slyšel termín bug bash na můj nábor rozhovor na QuintoAndar a znělo to dobře. Později jsem online hledal další informace, abych zjistil, že se jedná o poměrně rozšířenou praxi, kterou používá mnoho společností s jednou společnou věcí: agilní prostředí. Bug Bash je testovací metodika původně definovaná Ronem Pattonem z roku 2001. Ve své knize „testování softwaru“ popisuje bug bash jako postup, kdy všichni lidé zapojení do vývojového cyklu produktu odložili své pravidelné každodenní úkoly a „bušili na produkt“. Takže každý, kdo nějak měl slovo o produktu – od definice k designu; od vývoje k marketingu-by měl být ve stejné místnosti, testování funkce, v mnoha způsoby, jak je to možné před uvolněním.

přibližuje tým-od zúčastněných stran po vývoj-tak, aby pokryl co nejvíce testovacích scénářů, a tím snížil šance na vadné uvolnění. Uznávajíce, že by to mohlo být životaschopné a cenná alternativa k naší rychlé, intenzivní tempo práce, jsme se začali pomalu zavést koncept do družstva, vždy zlepšení a přizpůsobení přístupu podle funkce je potřebuje.

nebe, jsi to ty?

Zní to jako sen, ale pokud jste někdy vedl bug bash, asi víte, jak chaotické, to může shromáždit tolik různých profily v místnosti: někteří lidé pochybnosti o tom, zda to je chyba nebo ne, jiní se ptají, kde se podává zprávy o zjištěních, jiní mají potíže s přístupem k systému, každý diskutovat o tom, jak sledovat a upřednostnit opravy chyb při testování, a tak dále. Bez minimální prep, šance jsou, že důležité informace budou ztraceny mezi otázky a post-jeho, lidi budou frustrovaní za to, že poslouchal, a nakonec, co by mělo být nejvíce produktivní čas zjištění chyby mohou se ukáže jako ztráta času pro celý tým.

kromě vnitřní složitosti koordinace bug bash, jsme také měli napadnout použití koncepce na produkt, který nabízí kompletní obchodní řešení: z majetku vyhledávání pro pronájem správy. To znamená, že back-end a front-end výstupy v celém uživatelském prostředí. Proto zde v Quintoandaru bylo nezbytné mít flexibilní a přizpůsobivý proces, který by vyhovoval oběma scénářům.

věděli jsme, že nás čeká — a stále je-velká výzva: seznámení se s tím, jak efektivně aplikovat bug bash v různých kontextech. Potřebovali jsme vrtuli. To znamená hladký proces s nezbytnými a robustními nástroji pro centralizaci, který byl dostatečně přizpůsobivý pro použití při ověřování různých druhů dodávek.

zajímá vás, k o nad realizací, jsme vytvořili proces, zaměřený na kombinace klíčových bodů testování spolu s klíčovými prvky hlášení chyb, jako zjednodušené, jak je to možné, aniž by byla ohrožena jeho účinnost.

Jak již bylo zmíněno, základy pro dobrý bug bash zahrnuje přípravnou fázi, ve které se zajištění kvality osoba, stanoví podmínky pro testování, poskytování dočasné testery s nástroji, které jejich testování dovedností oceňují. Existují tři hlavní kroky k dobrému nastavení:

Krok 1: vytvořte tabulku pro centralizaci všech zjištění

popořádku: potřebujeme všechny na stejné stránce. Doslova! Při pokusu o mapování problémů je zásadní hlásit vše na jednom dokumentu. To by mohlo znamenat sdílenou poznámku, textový dokument, obří karton. Rozhodli jsme se použít tabulku, ve které bychom mohli také poskytnout nějaké vizuální pokyny o tom, co bylo testováno. Tato volba byla spolupráce s týmem je produktový designér, který popisuje výhody pro Design sám v článku „Product Design & Bug bash: jak ověřit rozhraní a kvalitě zajistit si dodávku od end-to-end“.

tabulka také umožňuje, aby byl proces snadno automatizován, aby byl plynulejší a funkčnější. V tabulce bug bash máme tři karty: účastníci, Bug bash, automatická zpráva.

protože aplikace koncového uživatele QuintoAndar jsou většinou webové, musí testování zahrnovat různá mobilní a stolní zařízení. Někdy je problém související se zařízením, takže jeho zveřejnění je nepostradatelné. Vytvořili jsme tedy kartu „účastníci“, ve které každý tester nebo účastník chyby Bash zadává informace, jako je jméno, simulovaný uživatel, prohlížeč, značka zařízení a typ zařízení. Toto jsou základní informace, které musíme začít vyšetřovat — nebo opravit-problém. Jakmile budou tyto informace dokončeny, můžeme pokračovat.

na druhé záložce „Bug bash“ kombinujeme prvky testování a hlášení chyb. Po obrázku kontextu, který má být testován v prvním sloupci, následují tři sloupce, kde tester zadá jméno testeru, podrobný popis zjištěného problému a případně jeho obrázek. Tímto způsobem, pokud existují pochybnosti o zprávě, víme, koho se na ni zeptat a ušetřit čas. To je zvláště cenné při zajišťování front-end dodávek, protože můžeme ověřit konečný produkt proti navrženému rozvržení. Pokud jsme ověření back-end dodávky, front-end obraz je obvykle nahrazen workflow vysvětlit, co se děje na back-end. Tímto způsobem udržujeme lidi v kontextu, i když není viditelně testovatelný. Lidé budou testovat produkt a hlásit všechny problémy, vylepšení a pochybnosti na této kartě. Po uplynutí doby testování tým projde nahlášené problémy, přezkoumá a diskutuje o tom, co má smysl zahrnout do fáze fixace.

Vzhledem k této fázi závažnosti hodnocení a stanovení priorit, celý tým bude vědom všech problémů, nalézt a vybrat ty, týkající se, že vývojový cyklus pro podávání zpráv. Tím se optimalizuje fáze podávání zpráv a zabrání se následným schůzkám, aby se problémy upřednostňovaly.

třetí a poslední karta v tabulce s názvem „automatická zpráva“ je klíčem k udržení kroku s rychlostí našich procesů. Obsahuje skript, který vezme všechny informace z posledních dvou karet a automaticky vytvoří zprávu o problému na naší desce Jira. To znamená, že ve fázi procesu podávání zpráv nebyly ztraceny žádné informace. Tím se zabrání velkému přepracování a celý proces je tak efektivnější. Skript je přizpůsobitelný, takže je možné přidat další pole, které mají být hlášeny.

Krok 2: Vytvoření kontextu prezentace

být efektivní, rozsah produktů, které mají být testovány, by měl být velmi dobře definovaný, aby všechny zúčastněné v procesu testování. Rozsah by měl být omezen na vlastnosti přidané v daném časovém okně nebo vývojovém cyklu. Čím jasnější lidé jsou o rozsahu tohoto konkrétního testovacího ceremoniálu, tím méně dostanete odpověď, zda se jedná o chybu nebo starší problém. Je obzvláště důležité mít tuto prezentaci v případě, že se testování účastní zúčastněné strany nebo outsideři týmu, protože nemusí mít jasnost, kterou mají lidé uvnitř samotného vývoje.

Krok 3: Rezervovat pokoj a poslat pozvánku dny dopředu,

Zařídit pokoj, aby se vešly velké skupiny lidí a zároveň staral lidový kalendář není vždy tak jednoduché. Může to trvat dlouho, než se přizpůsobí kalendáři každého nebo bude mít k dispozici dostatečně velký prostor, takže zůstaňte napřed. Na pozvánce sdílejte kontextovou prezentaci spolu s tabulkou bug bash a ujistěte se, že jste udělili potřebné povolení všem účastníkům. Dalším velmi důležitým aspektem brouků je čas. Nezapomeňte investovat do tohoto obřadu alespoň 1h 30m ( jeden a půl hodiny). Může se to zdát hodně, ale není to, když existuje tolik různých lidí, kteří produkt používají a interagují, aby získali lepší přístup k uživatelské zkušenosti.