Menu

Čo sú používateľské príbehy a kritériá prijatia (príklady)

what is user story acceptance criteria

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Perfektný sprievodca kritériami prijatia používateľských príbehov so scenármi z reálneho života:

V priemysle vývoja softvéru slovo „požiadavka“ definuje, čo je našim cieľom, čo zákazníci presne potrebujú a čo prinúti našu spoločnosť rozšíriť svoje podnikanie.

Či už je to produktová spoločnosť, ktorá vyrába softvérové ​​produkty, alebo servisná spoločnosť, ktorá ponúka služby v rôznych softvérových oblastiach, hlavným základom pre všetky z nich je požiadavka a úspech je definovaný tým, ako dobre sú požiadavky splnené.

Pojem „požiadavka“ má v rôznych projektových metodikách rôzne názvy.

V Vodopád , označuje sa ako „ Doklad o požiadavke / špecifikácii “, V Agilný alebo SCRUM označuje sa ako „Epic“, „Príbeh používateľa“.

Príbeh používateľa a kritériá prijatia

Podľa modelu Waterfall sú dokumenty požiadavky obrovské dokumenty s 200 alebo viac strán, pretože celý produkt je implementovaný v jednej fáze. To však nie je prípad Agile / SCRUM, pretože v týchto metodikách sú uvedené požiadavky na malé funkcionality alebo vlastnosti, pretože produkt sa pripravuje krok za krokom.

V tomto článku som sa pokúsil čo najlepšie zdieľať všetky svoje 4 roky skúseností s prácou s príbehmi používateľov a ich súvisiacimi kritériami prijatia spolu s ľahkými a jednoduchými scenármi v reálnom živote pre lepšie pochopenie.

Najprv navštívme základné veci.

Čo sa dozviete:

Čo je Príbeh používateľa?

Príbeh používateľa je požiadavkou na akúkoľvek funkčnosť alebo funkciu, ktorá je napísaná v jednom alebo dvoch riadkoch a maximálne do 5 riadkov. Príbeh používateľa je zvyčajne najjednoduchšou možnou požiadavkou a týka sa iba jednej funkcie (alebo jednej funkcie).

Najbežnejšie používaný štandardný formát na vytvorenie príbehu používateľa je uvedený nižšie:

Ako

Príklad:

Ako používateľ WhatsApp chcem, aby ikona fotoaparátu v poli na písanie chatu zachytávala a odosielala obrázky, aby som mohla kliknúť a zdieľať svoje obrázky súčasne so všetkými svojimi priateľmi.

Kritérium príbehu používateľa a prijatie

Čo sú to kritériá prijatia?

Kritérium prijatia je súbor prijatých podmienok alebo obchodných pravidiel, ktoré by funkčnosť alebo vlastnosť mali spĺňať a spĺňať, aby ich mohol akceptovať vlastník produktu / zúčastnené strany.

Toto je veľmi dôležitá súčasť dokončovania užívateľských príbehov a produktový vlastník a obchodný analytik by si ho mali preštudovať veľmi precízne, pretože chýbajúce jediné kritérium môže stáť veľa. Toto je jednoduchý očíslovaný zoznam alebo zoznam s odrážkami.

Jeho formát je nasledovný:

„ Vzhľadom na určitý predpoklad, keď urobím nejakú akciu, potom očakávam výsledok “.

prečo je potrebné spustiť program používajúci na vstup testovacie dáta?

Príklad (od vyššie uvedeného príbehu používateľa):

  • Uvažujme, že chatujem s priateľom a mal by som byť schopný zachytiť obrázok.
  • Keď kliknem na obrázok, pred odoslaním by som mal vedieť k obrázku pridať popis.
  • Ak sa vyskytne problém so spustením fotoaparátu môjho telefónu, zobrazí sa chybové hlásenie typu „Fotoaparát sa nepodarilo spustiť“. zodpovedajúcim spôsobom.

Príbeh používateľa teda definuje požiadavku na akúkoľvek funkčnosť alebo funkciu, zatiaľ čo kritériá prijatia definujú „definíciu hotového“ pre príbeh používateľa alebo požiadavku.

Ako QA je veľmi dôležité hlboko porozumieť užívateľskému príbehu a jeho kritériám prijatia, pričom pri „začiatku testovania“ neostáva ani jedna pochybnosť. Poďme ďalej pochopiť, prečo je nesmierne dôležité hlboko sa zaoberať príbehmi používateľov a kritériami prijatia.

Hlboko do príbehov používateľov

Na úvod si najskôr uvedomme dôležitosť „hĺbkovej“ štúdie základnej a základnej veci, t. Príbehy používateľov.

Nasledujúce prípady sú moje vlastné skutočné skúsenosti.

Prípad 1:

Pred 3 rokmi som pracoval na projekte mobilných aplikácií a produktom bola aplikácia, ktorá bola navrhnutá pre doručovateľov.

Boli by ste videli doručovateľa prichádzať k vám domov na doručenie. A majú mobilný telefón, na ktorom vás po doručení požiadajú o podpis. Tento podpis sa odráža na portáli poskytovateľov kuriérskych služieb, ako sú DTDC, FedEx atď.

Poďme si predstaviť, že mobilná aplikácia je práve spustená a jej portály už existujú a sú funkčné.

Problém: Pre spoločnosť Sprint má váš produktový produkt príbeh používateľa pre túto mobilnú aplikáciu, ktorý „Ako správca portálu by som mal byť schopný zobraziť podpis doručiteľa v čase doručenia.“ . Tu sa portál (webová aplikácia) zmení a podľa toho aktualizuje, aby odrážal podpis.

Ako QA musíte overiť, či podpis zachytený v mobilnej aplikácii odráža podľa očakávania portál.

Ak sa pozriete na tento príbeh používateľa, vyzerá to jednoducho, ale je tu skrytá požiadavka, že „Pre historické doručenia neexistovala žiadna funkcia odrazu podpisu, tak čo by sa malo stať, keby si chlapci z portálu prezerali historické doručenia?“ Mali by sa vymazať historické údaje? Mali by sme povoliť zlyhania alebo chyby týchto údajov?

Samozrejme, že vôbec, malo by sa s tým zaobchádzať milostivo.

Riešenie: Keď sa príslušné tabuľky DB aktualizujú a pridajú nový stĺpec pre umiestnenie podpisu, staré údaje by mali mať hodnotu NULL alebo 0, ktorá by sa mala skontrolovať, a mala by sa zobraziť správa „Žiadny podpis neexistuje“.

Môže sa to nazývať ako chyba od produktového vlastníka alebo obchodného analytika, ale musí sa to urobiť. Úspešné zavedenie jednej funkcie, ale niečo spolu s ňou nie je žiaduce. Toto je potrebné urobiť spolu s rovnakým príbehom používateľa a v rovnakom šprinte.

Prípad č

Pred 6 rokmi som pracoval na finančnej aplikácii pre dôchodkové plánovanie (bez BA), ktorá bola globálnou aplikáciou, kde finančníci ako CA, Finance Advisors mohli túto aplikáciu použiť pre rôzne meny na premietnutie investičných plánov, úspor atď. zákazníkom.

Problém: Produktový vlastník vám poskytne Príbeh používateľa „Ako poradca si chcem pozrieť správu môjho zákazníka na základe poskytnutých finančných podrobností“.

Tu boli 2 skryté požiadavky a nazval by som to ako neúplný príbeh, pretože:

do) V prehľadoch by sa mal zohľadňovať denný konverzný kurz meny, a nie historický kurz ako v poslednom prezeranom prehľade a

b) Ak dôjde k zmene meny po zadaní finančných údajov zákazníka, prehľady by sa mali zobrazovať v zmenenej mene.

Riešenie: Predložil som túto obavu priamo na nášho produktového vlastníka a upozornil som ho na to, že obe musia byť urobené čo najskôr. Súhlasil so mnou a vytvoril prednostne 2 rôzne príbehy pre nadchádzajúce šprinty.

Zobrať: Boli zachytené, pretože sme všetci veľmi dobre vedeli o produktoch, ich dizajne, štruktúre atď. Takéto znalosti je možné dosiahnuť iba úplným porozumením produktu, porozumením interoperability modulov a dôkladným preštudovaním užívateľského príbehu, aj keď je to 2 vložky.

Robte si poznámky, aby ste uľahčili prácu, a diskutujte s BA a vývojármi o ich myslení.

Hĺbkový pohľad na kritériá prijatia

Porozumenie vyčerpávajúcich kritérií prijatia a všetkých ostatných podmienok a pravidiel je ešte dôležitejšie ako podhodnotenie príbehu používateľa. Pretože ak je požiadavka neúplná alebo nejasná, je možné ju uplatniť v nasledujúcom šprinte, ale ak chýba kritérium prijatia, samotný príbeh používateľa nemožno zverejniť.

Myslím, že všetci by sme niekedy použili sieťové bankovníctvo a väčšina z nás ho používa každý deň a ja si veľa sťahujem svoje historické výpovede. Ak to pozorne sledujete, máte k dispozícii určité konkrétne možnosti ich sťahovania.

Existuje možnosť zvoliť typ súboru na stiahnutie výpisu. Existuje možnosť zvoliť si, či si chcete stiahnuť iba Kredity / Debit / oboje.

Teraz si predstavte, že produktový vlastník vám poskytne tento príbeh používateľa „Ako zákazník si chcem stiahnuť výpis z účtu, aby som si mohol pozrieť všetky svoje transakcie vykonané za určité obdobie.“

S nasledujúcimi kritériami prijatia:

  • Vzhľadom na to, že sa nachádzam na stránke Stiahnutie historického výpisu, mal by som zvoliť obdobie, za ktoré si chcem výpis stiahnuť.
  • Vzhľadom na to, že sa nachádzam na stránke Stiahnutie historického výpisu, mal by som zvoliť účet, pre ktorý si chcem výpis stiahnuť.
  • Vzhľadom na to, že sa nachádzam na stránke Stiahnutie historického vyhlásenia, by mi nemalo byť umožnené stiahnuť si vyhlásenie k budúcemu dátumu „do“.
  • Vzhľadom na to, že sa nachádzam na stránke sťahovania historických vyhlásení, by mi nemalo byť umožnené zvoliť dátum „od“ o 10 rokov neskôr.
  • Vzhľadom na to, že si stiahnem svoje vyhlásenie, by som mal mať možnosť prehliadať stiahnutý súbor.
  • Vzhľadom na to, že sa nachádzam na stránke Stiahnutie historického vyhlásenia, by som mal mať možnosť stiahnuť si svoje vyhlásenie vo formátoch doc, excel a pdf.

Ak prejdete týmto prijatím, chýbajú tu 3 veci:

  • Názov a formát názvu súboru, ktorý sa má stiahnuť.
  • Aké informácie (názvy stĺpcov) sa majú v súbore zobraziť.
  • V zozname možností môžete zvoliť, aký druh transakcie chce zákazník, t. J. Iba debety alebo iba kredity alebo oboje.

Takéto prípady sa môžu vyskytnúť raz za čas, treba si však dobre prečítať každé kritérium prijatia a pokúsiť sa ho vizualizovať s odkazom na príbeh používateľa. Čím viac budete hlboko študovať podmienky a obchodné pravidlá, tým viac budete mať o tejto funkcii vedomosti.

Chyby nájdené v počiatočnej fáze nestoja nič v porovnaní s cenou v štádiu „testovania“.

Kritériá prijateľnosti

Dôležitosť nájdenia nezrovnalostí v kritériách užívateľského príbehu / prijatia

Vždy je dôležité hlboko sa ponoriť do užívateľských príbehov a kritérií akceptácie v počiatočnej fáze, ešte pred začiatkom vývoja alebo testovania.

Pretože to zahŕňa:

# 1) Strata času:

Ak sa pri vývoji alebo testovaní zistia nezrovnalosti alebo chyby v užívateľskom príbehu / kritériách prijatia, bude treba v zostávajúcom čase šprintu ešte vykonať veľa prepracovania.

Nestáva sa, že aj keby vlastníkovi produktu chýbalo pár vecí, posunú príbeh používateľa do nadchádzajúceho šprintu. 95% šanca je, že požiadajú tím o vykonanie potrebnej implementácie a jej vydanie v rovnakom šprinte.

Preto sa pre tím stáva nočnou morou, pretože musí tráviť čas navyše, prichádzať cez víkendy alebo pracovať neskoro večer. Tomu sa dá vyhnúť štúdiom a diskusiou o užívateľskom príbehu / kritériách prijatia v najskoršej možnej fáze.

# 2) Plytvanie úsilím:

Vývojári a QA musia znova navštíviť implementovaný kód a testovacie prípady. Aktualizácia, pridávanie a odstraňovanie podľa požiadaviek nie je ľahká úloha. Stáva sa to príliš bolestivé, pretože už existuje tlak na včasné dodanie.

V takejto situácii existuje šanca na chyby vo fáze vývoja alebo testovania. Ak narazíte na takúto situáciu, choďte na „DevQA Pairing“. Ako čerešnička na torte nemusí dostať odmenu za prácu navyše.

Nezrovnalosti medzi príbehom používateľa a kritériami prijatia

Záver

Hlboké pochopenie používateľského príbehu a kritérií prijatia je možné dosiahnuť iba tak, že jeho štúdiu venujete nesmierne veľa času.

Na trhu nie je k dispozícii žiadny konkrétny nástroj alebo kurz, ktorý by to za vás mohol urobiť, pretože ide predovšetkým o logické myslenie, skúsenosti a znalosti o produkte.

Aktívna účasť na predbežnom stretnutí, rozhovor s BA, samostatné štúdium vám môže iba pomôcť dosiahnuť to. Čím viac úsilia vynaložíte, tým viac sa budete učiť a rásť.

Či už sú to QA alebo vývojári, všetci musia byť na jednej stránke s príbehmi používateľov a ich kritériami prijatia, až potom je možné úspešne dosiahnuť očakávania zákazníka.

Máte s nami niečo nové, čo by ste chceli zdieľať so svojimi skúsenosťami s prácou s používateľskými príbehmi? Prosím, vyjadrite svoje myšlienky nižšie !!

Odporúčané čítanie

^