Menu

Existuje nějaká hranice pro zahájení a zastavení role QA ve Scrumu?

is there any start stop boundary qa s role scrum

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Co je role QA ve Scrumu: Scrum aktivity pro testery

Tento článek není jen výukovým programem o některých procesech nebo metodách nebo návodech, jak pracovat jako QA. Jedná se spíše o článek, ve kterém se chci podělit o své vlastní zkušenosti s prací jako Senior QA ve SCRUM.

Můj předchozí CTO to vždycky říkal „Se svobodou přichází odpovědnost“. Pokud máte svobodu dělat svou práci svým způsobem, pak jste vy a jen vy sami zodpovědní za vaši práci nebo úkoly nebo činnosti.

O tom je Scrum !! Dovolte mi, abych vám dal základní představu o Scrumu, jak budeme pokračovat dále.

Role QA ve skrumáži

Co se naučíte:

Přehled Scrumu

Scrum je podmnožinou souboru agilní metodologie a je lehký rámec procesu, který je široce používán.

Scrum nám pomáhá udržovat spokojenost zákazníků tím, že jim dává produkt v malých modulech, a také udržuje zákazníky vědomi toho, že jejich často se měnící požadavky mohou aktivity zpomalit. Vydání jsou krátká a pracuje se podle kapacity zúčastněného týmu, a proto je pravděpodobnost selhání nebo nešťastných zákazníků do značné míry snížena.

Na druhou stranu jsou požadavky (v tomto případě Uživatelské příběhy) finalizovány před spuštěním Sprintu, aby nedocházelo k přepracování, což má za následek zpožděný nebo neúspěšný Sprint (výjimky jsou vždy k dispozici).

Ale největší výzvou pro QA je, že rozpětí vydání je krátké, Sprint je většinou 15denní cyklus. Dodání „bezplatného“ produktu s chybou maximálně za 4–5 dní (bez nutnosti vývoje) proto vyžaduje hodně úsilí a chytrého myšlení.

Jsem QA svého týmu:

Skrumáž

Ach ano, jsem QA svého týmu a jsem důležitým hráčem mého týmu. Proč?? Protože zákazníci, BA, Scrum Master a všichni ostatní mají nejasnosti ohledně kvality, vzhledu a chování aplikace nebo produktu.

Ve Scrumu, protože trvání sprintu je krátké, musí QA fungovat chytře, a proto je velmi důležité, aby se QA zapojila hned od začátku. Jsou chvíle, kdy QA může hrát roli vlastníka Proxy produktu, když objednávka není k dispozici, a tak pomáhá BA s vytvořením scénářů / případů testování akceptačních kritérií.

Vývojáři také přistupují k QA v době, kdy čelí problémům s funkčností nebo obchodními pravidly. Ve Scrumu se zaměřujeme pouze na hladké a úspěšné vydání Sprintu a nejde o to, že „Moje práce“ nebo „Vaše práce“ podají pomocnou ruku, když vás váš tým požádá o pomoc.

Při propojení týmu Scrum hrají zdravé vztahy mezi členy týmu velmi zásadní roli a jako QA byste měli být velmi opatrní při komunikaci svého názoru na příběhy uživatelů, které testujete. Vaše komunikace by měla být o uživatelském příběhu nebo funkčnosti, nikoli o osobě, která na tom pracovala.

Ve Scrumu není QA hodnocena ani oceňována kvůli počtu chyb, které zjistí, ale také kvůli tomu, jak interaguje s týmem, pomáhá týmu a motivuje tým i v obtížných dobách.

Kromě testování úkolů sprintu se psaní testovacích plánů / testovacích případů / dokumentů k vydání také snaží zapojit více, protože doba vydání Sprintu je krátká a cíl je pro všechny stejný „Úspěšně dodávat fungující produkt bez chyb tím, že si navzájem pomáháme“.

QA je zapojena téměř do všech činností prováděných ve sprintu a technicky neexistuje hranice pro zahájení nebo ukončení aktivit QA. Na rozdíl od tradičního modelu Waterfall, kde se QA omezuje pouze na testování vydání, má QA mnohem více povinností. Navrhoval bych tedy vyzkoušet a provést více z následujících činností.

Činnosti, které je třeba sledovat

Níže je uvedeno několik aktivit, které bych doporučil sledovat jako QA ve Scrumu.

qa vs qc v testování softwaru

# 1) Dwell Deeper:

Tím mám na mysli, že až budou příběhy uživatelů a jejich kritéria přijatelnosti připraveny, důkladně si je prostudujte a zamyslete se hlouběji nad závislostmi, skrytými výsledky a pokud existuje lepší způsob, jak to udělat.

Komunikujte o tom a spolupracujte s BA a vývojovým týmem, protože se může stát, že o tom také nemysleli. Sdílejte své nápady a zjištění s týmem.

Pokud zjistíte, že existují skryté překážky nebo negativní dopady, jejich zvednutí pomocí Scrum Master a vývojářů jim poskytne čas na přemýšlení a odpovídající jednání. Tato aktivita ve Scrumu se stává velmi kritickou, když je projekt rozsáhlý a když jsou v týmech rozložené moduly.

Nyní při studiu závislostí je pro QA velmi důležitý dopad a dokonce o něm informuje vývojový tým. Chcete-li to provést, diskutujte s QA ostatních týmů a přijímejte od nich vstupy.

# 2) Zapojte se do odhadů:

Obvyklou praxí je zahrnutí QA do odhadů, ale mnohokrát kvůli malému sprintu nemusí být QA požádáno o odhad pro testování úkolů a ponechání 3/4/5 dnů na testovací práci.

Nikdy to nepřijímejte. Zvyšte hlas, pokud musíte, ale ujistěte se, že poskytujete odhad testování, který by měl zahrnovat čas, který potřebujete pro každou práci.

Může zahrnovat čas na výzkum, čas na nastavení, čas na sběr historických dat atd., Ale musí být přísný a konkrétní ohledně času potřebného k provedení testovacích činností a má tyto časové hodnoty přidány do příběhu uživatele spolu s vývojovými úkoly čas .

To je velmi důležité, protože pokud se pokusíte vykonat svou práci ve stanoveném čase a pokud nejste schopni dokončit práci, budete za selhání zodpovědní pouze vy. Když se přidá čas QA, Scrum Master, PO si bude vědoma příslušných aktivit QA a množství požadovaného času.

# 3) Párování QA Dev:

V ideálním případě jsou ve Scrumu předány uživatelské příběhy Sprint k testování po dokončení vývoje a jakmile je testování dev provedeno, ale problém je v tom, že v době, kdy je předán QA k testování sotva 4–5 dní k ukázce nebo recenzi zůstanou.

Nyní, pokud jako QA zjistíte dokonce 4 blokátory nebo funkční selhání, budete muset pracovat pozdě v noci nebo o víkendu, abyste splnili datum vydání, protože bude třeba provést funkční testování, regrese atd. Vypadá to jako tradiční model vodopádu, což není nejlepší způsob, ve Scrumu je to nejchytřejší způsob 'Spíše než vadám zabránit vadám'.

Proto je řešením provést párování QA dev a provést základní kolo testování na nastavení dev, jakmile jsou vývojáři připraveni na příběhy ještě před oficiálním vydáním pro testování.

Následující kritéria lze vzít v úvahu při provádění BVT v nastavení dev pro příběhy uživatelů:

  • Kritéria přijetí pro každý příběh uživatele: BVT příběhů uživatelů v souladu s kritérii přijetí.
  • Nedůvěra v vývojáře: Někdy si vývojáři nejsou jisti některými implementacemi, a proto o těchto implementacích diskutují a dělají BVT pro ty, kteří mají stejné nastavení dev.
  • Závislosti / Testování dopadu: BVT závislostí nebo dopadu na / jiných modulů nových implementací.
  • Testování jednotky: Udělejte BVT s vývojářem testů jednotek, které vytvořili, v případě potřeby jim pomozte přidat nebo aktualizovat testy jednotek.

To pomůže při snižování počtu chyb tam a zpět, ušetří každému čas, protože před vydáním do QA je většina havarujících nebo funkčních chyb již opravena. Nezapomeňte tyto defekty ve svých nástrojích zaznamenat před kontrolou sprintu a nechat je přesunout do stavu „uzavřeno“.

Párování QA Dev

# 4) QA na bílé tabuli:

Vždy jsem osobně vyzýval svůj tým, aby zahrnul úkoly QA na tabuli White Scrum, včetně chyb. To pomáhá Scrum Masteru zjistit stav QA příběhu uživatele pouhým pohledem na tabuli.

Ne. chyb v seznamu Úkoly, chyby v seznamu Probíhá, aktivity QA v seznamu Úkoly, Probíhá a Hotovo mluví samy za sebe. Považuji za opravdu bolestivé, když se někdo ptá na stav testování jednotlivých příběhů pro Sprint, protože musím věnovat více času tomu, abych odstranil svůj stav z kompilace nástrojů a ukázal jim nebo vytvořil e-mail.

Jednoduše dávám přednost tomu, abych dotyčnou osobu nasměroval na Scrum Board a nechal ji, aby si to udělala sama. Upřednostňujte jasnou vynikající barvu pro stisky QA Sticky.

QA na bílé tabuli

# 5) Dokumentace:

To je jedna z nevýhod nebo nevýhod Scrumu, že kvůli malé velikosti Sprintu není mnoho času na dokumentaci a nikdy jsem neviděl technického spisovatele v týmu Scrum. Scrum Master / BA nemusí a nemusí vždy aktualizovat dokumenty o informacích o produktu.

Problém nastane, pokud se přidají noví členové, nebo v nejhorším případě, pokud se změní obchodní pravidla, funkce a jak je sledovat, protože hledat informace v uživatelských příbězích „Hotovo“ bude jako hledat jehlu v kupce sena.

Řešením je mít ve sprintu vytvořenou samostatnou úlohu, kdykoli je to možné (většinou v době nečinnosti nebo když je pracovní zátěž mnohem menší) pro dokumentaci, abyste mohli dokumenty zkontrolovat a aktualizovat nebo je aktualizovat pomocí Scrum Master nebo BA.

QA je správná osoba, která vám pomůže s aktualizací dokumentů, protože vy jste ten, kdo testuje, ověřuje příběhy uživatelů a zná funkce dovnitř a ven. Udělejte to sami, pokud není BA a pokud je váš Scrum Master zaneprázdněn aktualizací.

# 6) Kontrola sprintu / Ukázka sprintu:

Většinou se stane, že QA je ten, kdo je vybrán, aby dal demonstraci PO a zúčastněným stranám. ale pokud nepřesvědčíte svého Scrum Master, aby tak učinil. QA je správná osoba, která předvede demo, protože otestoval příběh uživatele dovnitř a ven.

QA může předvést z obchodního hlediska, protože zná funkce, toky a obchodní pravidla. Dobře se připravte na ukázku a pokuste se odpovědět na každou otázku, kterou má organizace producentů a zúčastněné strany. To vám pomůže, abyste se pro ně stali kontaktním místem při absenci Scrum Master a BA.

# 7) Chovejte se jako BA:

To není běžný úkol a od QA se to ani neočekává, ale pokuste se dostat do této role, když je hodena šance, protože QA je nejlepší osoba, která má být BA. Zkuste se například zamyslet a představit si, zda lze toky, funkce nebo obchodní pravidla upravit způsobem, který bude přínosem pro zákazníka.

Přemýšlejte a hledejte aktuální trendy v uživatelském rozhraní, vzhled a chování aplikace a způsob, jakým ji lze beatifikovat, učinit ji uživatelsky přívětivější atd. Pokud je tým zaseknutý nějakým problémem, zapojte se a zkuste dát jednoduchou a řešení. To posílí vaši roli a bude faktorem, který přispěje k vašemu kariérnímu růstu.

Šance přicházejí při voláních s PO, když se diskutuje o některých problémech, nebo při revizi / ukázce, kde můžete dát návrhy.

Závěr

Scrum je velmi odlišná metodika od běžné metody Waterfall a Scrum Master je zprostředkovatel. Proto od něj neočekávejte, že pro vás definuje vaše aktivity.

Ve Scrumu neexistuje žádná hranice začátku a konce role QA. QA musí a musí být zapojena do každé činnosti od samého začátku až do konce, od předběžného plánování až po kontrolu / ukázku sprintu a musí se účastnit všech činností.

To pomůže porozumět produktu nebo aplikaci, protože (jak jsem již řekl) není při práci ve Scrumu k dispozici žádná řádná dokumentace. Očekává se od vás, že budete zodpovědní, motivovaní a aktivní. Proto nečekejte, až někdo přijde a řekne vám, co a jak máte dělat.

Měli byste sami podniknout iniciativy, všemožně pomáhat týmu, udržovat zdravý vztah, sledovat aktuální věci v týmu a hlavně mít jasno ve svých úkolech v daném sprintu.

Tady nejsou žádní manažeři, kteří by vás sledovali nebo sledovali vaše aktivity. Buďte vždy připraveni s pomocnou rukou pro svůj tým a získáte ty nejlepší příležitosti.

Neváhejte vyjádřit své myšlenky / návrhy k tomuto informativnímu článku v sekci komentáře níže.

Doporučené čtení

^