is there any start stop boundary qa s role scrum
Čo je rola QA v Scrume: Scrum aktivity pre testerov
Tento článok nie je len výučbou niektorých procesov alebo metód alebo návodmi, ako pracovať ako QA. Ide skôr o článok, v ktorom sa chcem podeliť o svoje vlastné skúsenosti s prácou ako Senior QA v SCRUM.
Môj predchádzajúci CTO to vždy hovorieval „So slobodou prichádza zodpovednosť.“ Ak máte slobodu vykonávať svoju prácu týmto spôsobom, ste za svoju prácu alebo úlohy alebo činnosti zodpovední iba vy.
To je to, o čom je Scrum !! Dovoľte mi, aby som vám dal základnú predstavu o Scrume, ako pokračujeme ďalej.
Čo sa dozviete:
Prehľad Scrumu
Scrum je podmnožinou súboru agilná metodológia a je ľahký procesný rámec, ktorý sa široko používa.
Scrum nám pomáha udržiavať spokojnosť zákazníkov tým, že im dáva produkt v malých moduloch, a tiež informuje zákazníka, že jeho často sa meniace požiadavky môžu spomaliť aktivity. Vydania sú krátke a pracuje sa na kapacitách zúčastneného tímu, takže šance na zlyhania alebo nešťastných zákazníkov sú do značnej miery znížené.
Na druhej strane, požiadavky (v tomto prípade Používateľské príbehy) sú finalizované pred spustením Sprintu, aby sa zabránilo prepracovaniu, čo vedie k oneskorenému alebo neúspešnému Sprintu (výnimky tu vždy sú).
Ale najväčšou výzvou pre QA je to, že rozpätie vydania je krátke, Sprint je väčšinou 15-dňový cyklus. Preto doručenie „bezplatného“ produktu s chybou maximálne za 4 až 5 dní (bez času potrebného na vývoj) vyžaduje veľa úsilia a inteligentného myslenia.
Som QA svojho tímu:
Ach áno, som QA svojho tímu a som dôležitým hráčom môjho tímu. Prečo? Pretože zákazníci, BA, Scrum Master a všetci ostatní majú pochybnosti o kvalite, vzhľade a výkone aplikácie alebo produktu.
Pretože v šprinte je krátke trvanie šprintu, musí QA vystupovať inteligentne a preto je veľmi dôležité, aby sa QA zapojila hneď od začiatku. Sú chvíle, keď QA môže hrať úlohu vlastníka Proxy produktu, keď objednávka nie je k dispozícii, čo pomáha BA pri vytváraní testovacích scenárov / prípadov akceptácie kritérií.
Vývojári tiež pristupujú k QA v čase, keď čelia problémom s funkčnosťou alebo obchodnými pravidlami. V Scrume sa pozornosť zameriava iba na hladké a úspešné vydanie Sprintu. Nejde o to, aby „Moja práca“ alebo „Vaša práca“ podali pomocnú ruku, keď vás váš tím požiada o pomoc.
pl sql rozhovor s vývojárom otázky a odpovede
Pri spájaní tímov Scrum zohrávajú zdravé vzťahy medzi členmi tímu veľmi dôležitú úlohu a keďže ste QA, mali by ste byť pri komunikácii svojho názoru na príbehy používateľov, ktoré testujete, veľmi opatrní. Vaša komunikácia by mala byť o užívateľskom príbehu alebo funkčnosti, a nie o osobe, ktorá na tom pracovala.
V spoločnosti Scrum nie je QA posudzovaná ani oceňovaná za počet zistených chýb, ale ani za to, ako interaguje s tímom, pomáha tímu a motivuje ho aj v zložitých obdobiach.
Okrem testovania úloh sprintu sa písanie testovacích plánov / testovacích prípadov / dokumentov vydania tiež snaží zahrnúť viac, pretože doba vydania sprintu je krátka a cieľ je pre všetkých rovnaký „Úspešne doručiť funkčný produkt bez chýb tým, že si navzájom pomôžeme“.
QA je zapojená do takmer všetkých aktivít vykonávaných v šprinte a technicky neexistuje hranica pre začatie alebo zastavenie QA aktivít. Na rozdiel od tradičného modelu Waterfall, kde sa QA obmedzuje iba na testovanie vydania, má QA oveľa viac povinností. Navrhoval by som teda vyskúšať a vykonať viac z nasledujúcich činností.
Činnosti, ktoré treba sledovať
Ďalej je uvedených niekoľko aktivít, ktoré by som vám podľa odporúčaní mal ako QA v Scrume dodržiavať.
# 1) Prebývajte hlbšie:
Chcem tým povedať, že keď budú príbehy používateľov a ich kritériá prijatia pripravené, dôkladne si ich preštudujte a premyslite si hlbšie závislosti, skryté výsledky a či existuje lepší spôsob, ako to urobiť.
Komunikujte o tom a spolupracujte s BA a vývojovým tímom, pretože sa môže stať, že na to tiež nemuseli myslieť. Podeľte sa s tímom o svoje nápady a zistenia.
Ak zistíte, že existujú skryté prekážky alebo negatívne dopady, potom ich zvýšenie pomocou Scrum Master a vývojárov im poskytne čas na premýšľanie a zodpovedajúce konanie. Táto aktivita v programe Scrum sa stáva veľmi kritickou, ak je projekt rozsiahly a keď sú v tímoch rozložené moduly.
Pri štúdiu závislostí je teraz pre QA veľmi dôležitý vplyv, ktorý si dokonca uvedomuje aj vývojový tím. Za týmto účelom prediskutujte s QA ostatných tímov a vezmite si od nich podnety.
# 2) Zúčastnite sa odhadov:
Obvyklou praxou je zapojiť QA do odhadov, ale kvôli malému šprintu sa QA nemusí často vyžadovať odhad pre testovanie úloh a na testovacie práce im ostane 3/4/5 dní.
Toto nikdy neakceptujte. Ak musíte, zvýšte hlas, ale uistite sa, že poskytujete odhad testovania, ktorý by mal zahŕňať čas, ktorý potrebujete na každú prácu.
Môže zahŕňať čas na výskum, čas na nastavenia, čas na zber historických údajov atď., Ale musí byť strohý a konkrétny v čase potrebnom na vykonanie testovacích aktivít a musí mať tieto časové hodnoty pridané k príbehu používateľa spolu s časmi vývojových úloh. .
Je to veľmi dôležité, pretože ak sa pokúsite urobiť svoju prácu v stanovenom čase a ak nemôžete dokončiť prácu, za zlyhanie budete zodpovední iba vy. Keď sa pridá čas QA, Scrum Master, PO si bude vedomý zapojených aktivít QA a množstva požadovaného času.
# 3) Párovanie QA Dev:
V ideálnom prípade sú v aplikácii Scrum používateľské príbehy Sprintu odovzdané na testovanie po dokončení vývoja a po vykonaní vývojárskeho testovania. Problém však je, že v čase, keď je odovzdaný QA na testovanie, sotva 4 až 5 dní na ukážku alebo preskúmanie zostane.
Teraz, ak ako QA zistíte dokonca 4 blokátory alebo funkčné poruchy, budete musieť pracovať neskoro večer alebo cez víkend, aby ste splnili dátum vydania, pretože bude potrebné vykonať funkčné testovanie, regresie atď. Zdá sa to ako tradičný model vodopádu, čo nie je najlepší spôsob, ako v Scrum „Predchádzajte skôr chybám, ako ich hľadajte“.
Preto je riešením vykonať párovanie QA dev a vykonať základné kolo testovania nastavenia dev, akonáhle sú vývojári pripravení na príbehy ešte pred oficiálnym vydaním na testovanie.
Nasledujúce kritériá môžu byť brané do úvahy pri vytváraní BVT pri nastavovaní dev pre užívateľské príbehy:
- Kritériá prijatia pre každý príbeh používateľa: BVT príbehov používateľov v súlade s kritériami prijatia.
- Nedôvera vývojárom: Niekedy si vývojári nie sú istí niektorými implementáciami, a preto o týchto implementáciách diskutujú a robia BVT pre tých, ktorí majú rovnaké nastavenie vývojára.
- Závislosti / nárazové testovanie: BVT závislostí alebo dopadu na / ostatných modulov nových implementácií.
- Testovanie jednotky: Vykonajte BVT s vývojárom Unit testov, ktoré vytvorili, v prípade potreby im pomôžte pridaním alebo aktualizáciou unit testov.
Pomôže to pri znižovaní množstva chýb, ušetrí každému čas, pretože pred vydaním na QA je väčšina zlyhaní alebo funkčných chýb už opravená. Nezabudnite tieto chyby vo svojich nástrojoch zaznamenať pred kontrolou sprintu a nechať ich presunúť do stavu „zatvorené“.
# 4) QA na Bielej tabuli:
Vždy som osobne povzbudzoval svoj tím, aby zahrnul úlohy QA na dosku White Scrum vrátane tiež chýb. Toto pomáha Scrum Masteru zistiť stav QA užívateľského príbehu jednoduchým pohľadom na dosku.
Č. chýb v zozname Úlohy, chyby v zozname Prebieha, aktivity QA v zozname Úlohy, Prebieha a Hotovo hovoria samy za seba. Považujem za skutočne bolestivé, keď sa niekto pýta na stav testovania jednotlivých príbehov pre Sprint, pretože musím venovať viac času tomu, aby som vyňal svoj stav z kompilácie nástrojov a ukázal im alebo vypracoval e-mail.
Jednoducho dávam prednosť tomu, aby som osobu nasmeroval na Scrum Board a nechal ju, aby si to urobila sama. Uprednostňujte žiarivú vynikajúcu farbu pre pásky QA Sticky.
# 5) Dokumentácia:
Toto je jedna z nevýhod alebo nevýhod Scrumu, že kvôli malým rozmerom Sprintu nie je veľa času na dokumentáciu a nikdy som nevidel technického spisovateľa v tíme Scrum. Scrum Master / BA nemusí a vždy aktualizuje dokumenty o informáciách o produkte.
Problém nastane, ak sa pridajú noví členovia, alebo v najhoršom prípade, ak sa zmenia obchodné pravidlá, funkcionality a spôsob ich sledovania, pretože hľadanie informácií v používateľských príbehoch „Hotovo“ bude ako hľadanie ihly v kope sena.
Riešením je nechať si vytvoriť samostatnú úlohu v šprinte, kedykoľvek je to možné (väčšinou v časoch stagnácie alebo keď je pracovná záťaž veľmi nízka) pre dokumentáciu, aby ste mohli dokumenty skontrolovať a aktualizovať alebo ich aktualizovať pomocou Scrum Master alebo BA.
QA je správna osoba, ktorá pomáha pri aktualizácii dokumentov, pretože vy ste ten, kto testuje, overuje príbehy používateľov a pozná funkčnosť dovnútra a von. Urobte to sami, ak neexistuje BA a ak je váš Scrum Master zaneprázdnený aktualizáciami.
# 6) Sprint Review / Sprint Demo:
Väčšinou sa stáva, že QA je ten, kto je vybraný na predloženie ukážky PO a zainteresovaným stranám. ale ak nie, presvedčte svojho Scrum Master, aby tak urobil. QA je správna osoba, ktorá dá demonštráciu, keď testuje užívateľský príbeh dovnútra a von.
QA môže demonštrovať z obchodného hľadiska, pretože pozná funkcie, toky a obchodné pravidlá. Pripravte sa na ukážku a pokúste sa odpovedať na každú otázku, ktorú má PO a zainteresované strany. To vám pomôže stať sa ich kontaktným bodom v prípade absencie Scrum Master a BA.
# 7) Správajte sa ako BA:
Toto nie je bežná úloha, ani sa to od QA neočakáva, ale pokúste sa dostať do tejto role, keď sa vrhne šanca, pretože QA je najlepší človek na získanie titulu BA. Skúste napríklad premýšľať a predstaviť si, či je možné toky, funkcionality alebo obchodné pravidlá upraviť spôsobom, ktorý bude prospešný pre zákazníka.
Premýšľajte a hľadajte súčasné trendy v používateľskom rozhraní, vzhľad a dojem z aplikácie a možnosti, ako ju možno beatifikovať, dosiahnuť, aby bola užívateľsky príjemnejšia atď. Ak sa tím zasekne v nejakom probléme, zapojte sa a pokúste sa poskytnúť jednoduchý a inteligentný Riešenie. To podporí vašu rolu a bude faktorom, ktorý prispeje k vášmu kariérnemu rastu.
Šance prichádzajú pri hovoroch s PO, keď sa diskutuje o nejakých problémoch, alebo pri revízii / ukážke, kde môžete poskytnúť návrhy.
Záver
Scrum je veľmi odlišná metodológia od bežnej Waterfallovej metódy a Scrum Master je sprostredkovateľom. Neočakávajte od neho, že za vás definuje vaše aktivity.
V Scrume neexistuje žiadna hranica začiatku a konca úlohy QA. QA musí byť a musí byť zapojená do každej činnosti od samého začiatku do konca, od predbežného plánovania až po kontrolu / ukážku šprintu a musí sa zúčastňovať na všetkých činnostiach.
To pomôže porozumieť produktu alebo aplikácii, pretože (ako som už povedal) pri práci v Scrume nie je k dispozícii správna dokumentácia. Očakáva sa od vás zodpovednosť, motivácia a proaktívnosť. Preto nečakajte, kým niekto príde a povie vám, čo alebo ako máte robiť.
Mali by ste sa chopiť iniciatívy sami, všemožne pomáhať tímu, udržiavať zdravý vzťah, mať prehľad o prebiehajúcich veciach v tíme a hlavne mať jasno vo svojich úlohách v danom šprinte.
Tu nie sú žiadni manažéri, ktorí by vás sledovali alebo sledovali vaše aktivity. Buďte vždy pripravení s pomocnou rukou pre svoj tím a získate maximum príležitostí.
Neváhajte a vyjadrite svoje názory a návrhy týkajúce sa tohto informatívneho článku v sekcii komentárov nižšie.
Odporúčané čítanie
- Úloha obchodných analytikov v SCRUM a prečo je QA najlepšia pre túto úlohu?
- Online kvíz o Agile Scrum: Otestujte si svoje znalosti o Agile Scrum
- Inštalácia aplikácie na zariadenie a spustenie testovania z Eclipse
- Kanban vs Scrum vs Agile: Podrobné porovnanie s cieľom nájsť rozdiely
- Ako poskytovať softvérové funkcie vysokej hodnoty v krátkom časovom období pomocou agilného procesu skrumáže
- Agilný manifest: Pochopenie agilných hodnôt a zásad
- Porucha triafania do skrumáže: Ako je to organizované v nastavení skrumáže
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]