Co je uživatelský příběh a kritéria přijetí (příklady)

Příklad:

Jako uživatel WhatsApp chci, aby ikona fotoaparátu v poli pro psaní chatu zachytila ​​a odeslala obrázky, abych mohl klikat a sdílet své obrázky současně se všemi svými přáteli.

Co jsou kritéria přijetí?

Kritériem přijetí je soubor přijatých podmínek nebo obchodních pravidel, které by funkce nebo funkce měly splňovat a splňovat, aby byly přijaty vlastníkem produktu / zúčastněnými stranami.

Toto je velmi důležitá součást dokončení příběhu uživatele a produktový vlastník a obchodní analytik by si jej měli velmi pečlivě prostudovat, protože chybějící jediné kritérium může stát hodně. Toto je jednoduchý očíslovaný seznam nebo seznam s odrážkami.

Jeho formát je následující:

' Vzhledem k určitým podmínkám, když udělám nějakou akci, očekávám výsledek “.

nejlepší optimalizační software pro Windows 10

Příklad (příběh uživatele výše):

• Uvažujme, že chatuji s přítelem a měl bych být schopen zachytit obrázek.
• Když kliknu na obrázek, měl bych být schopen k obrázku přidat titulek před jeho odesláním.
• Pokud se při spouštění fotoaparátu v telefonu vyskytne problém, zobrazí se chybová zpráva jako „Fotoaparát nelze spustit“. odpovídajícím způsobem.

Příběh uživatele tedy definuje požadavek na jakoukoli funkčnost nebo funkci, zatímco kritéria přijetí definují „definici provedeného“ pro příběh uživatele nebo požadavek.

Jako QA je velmi důležité důkladně porozumět příběhu uživatele a jeho kritériím přijetí, aniž by při „zahájení testování“ zůstala jen jedna pochybnost. V dalším kroku pochopme, proč je nesmírně důležité hlouběji se zabývat příběhy uživatelů a kritérii přijetí.

Hlouběji do příběhů uživatelů

Nejprve pochopme důležitost „hloubkové“ studie základní a základní věci, tj. Uživatelské příběhy.

Následující případy jsou moje vlastní skutečné zkušenosti.

Případ č. 1:

Před 3 roky jsem pracoval na projektu mobilní aplikace a produktem byla aplikace, která byla navržena pro doručovatele.

Viděli byste doručovatele přicházet k vám domů k dodání. A mají mobilní telefon, na kterém vás po doručení požádají o podpis. Tento podpis se odráží na portálu poskytovatelů kurýrních služeb, jako jsou DTDC, FedEx atd.

Představme si, že mobilní aplikace je právě spuštěna a její portály již existují a jsou aktivní.

Problém: Pro Sprint má váš vlastník produktu uživatelský příběh pro tuto mobilní aplikaci „Jako správce portálu bych měl být schopen zobrazit podpis, který si doručovatel vzal v době doručení.“ . Zde se portál (webová aplikace) změní a odpovídajícím způsobem aktualizuje, aby odrážel podpis.

Jako QA musíte ověřit, zda se podpis zachycený v mobilní aplikaci odráží podle očekávání na portálu.

Pokud se podíváte na tento uživatelský příběh, vypadá to jednoduše, ale je zde skrytý požadavek, že „U historických dodávek neexistovala žádná funkce odrazu podpisu, tak co by se mělo stát, kdyby si kluci portálu prohlíželi historické dodávky?“ Měla by být vymazána historická data? Měli bychom u těchto dat povolit selhání nebo chyby?

Samozřejmě vůbec, mělo by se s tím zacházet laskavě.

Řešení: Když se příslušné tabulky DB aktualizují a přidají nový sloupec pro umístění podpisu, měla by stará data mít hodnotu NULL nebo 0, která by měla být zkontrolována, a měla by se zobrazit zpráva „Žádný podpis neexistuje“.

To lze nazvat jako chybějící produktový vlastník nebo obchodní analytik, ale je třeba to udělat. Úspěšná implementace jedné funkce, ale zlomení něčeho spolu s ní není zákazníky žádoucí. To je třeba udělat spolu se stejným příběhem uživatele a ve stejném sprintu.

Případ č. 2

Před 6 lety jsem pracoval na finanční aplikaci pro plánování odchodu do důchodu (bez BA), což byla globální aplikace, kde ji finančníci jako CA, Finance Advisors mohli použít pro různé měny k promítnutí investičních plánů, úspor atd. velké období svým zákazníkům.

Problém: Vlastník produktu vám poskytne uživatelský příběh 'Jako poradce chci zobrazit zprávu mého zákazníka na základě poskytnutých finančních údajů.'

Tady byly 2 skryté požadavky a nazval bych to jako neúplný příběh, protože:

na) Přehledy by měly brát v úvahu denní směnný kurz měny, nikoli historický kurz jako v posledním zobrazeném přehledu a

b) Pokud se měna po zadání finančních údajů zákazníka změní, měly by se přehledy zobrazovat ve změněné měně.

Řešení: Tuto obavu jsem vznesl přímo u našeho vlastníka produktu a uvědomil jsem si, že obojí je třeba provést co nejdříve. Souhlasil se mnou a vytvořil přednostně 2 různé příběhy pro nadcházející sprinty.

Odnést: Byly zachyceny, protože jsme si všichni byli velmi dobře vědomi produktů, jejich designu, struktury atd. Takových znalostí lze dosáhnout pouze úplným pochopením produktu, porozuměním interoperability modulů a důkladným prostudováním příběhu uživatele, i když je to 2 vložka.

Dělejte si poznámky, které vám usnadní věci, a diskutujte s BA a vývojáři o jejich myšlení.

Podrobný pohled na kritéria přijetí

Pochopit kritéria přijetí a všechny ostatní podmínky a pravidla vyčerpávajícím způsobem je ještě důležitější než podceňovat příběh uživatele. Protože pokud je požadavek neúplný nebo vágní, lze jej převzít v příštím sprintu, ale pokud chybí kritérium přijetí, samotný příběh uživatele nelze zveřejnit.

Myslím, že bychom v určitém okamžiku všichni používali síťové bankovnictví a většina z nás jej používá každý den a já si hodně stahuji svá historická prohlášení. Pokud to pozorně sledujete, máte k dispozici určité konkrétní možnosti pro jejich stažení.

Existuje možnost vybrat typ souboru pro stažení výpisu. Existuje možnost zvolit, zda chcete stáhnout pouze kredity / debet / obojí.

Nyní si představte, že vám produktový vlastník poskytne tento uživatelský příběh „Jako zákazník si chci stáhnout výpis z účtu, abych mohl zobrazit všechny své transakce provedené za určité období.“

S následujícími kritérii přijetí:

• Vzhledem k tomu, že jsem na stránce Stáhnout historický výpis, měl bych vybrat období, za které si chci výpis stáhnout.
• Vzhledem k tomu, že jsem na stránce Stáhnout historický výpis, měl bych vybrat účet, pro který si chci výpis stáhnout.
• Vzhledem k tomu, že jsem na stránce Stáhnout historické prohlášení, nemělo by mi být umožněno stáhnout si prohlášení pro budoucí datum „do“.
• Vzhledem k tomu, že jsem na stránce Stáhnout historické prohlášení, nemělo by mi být dovoleno vybrat datum „Od“ o 10 let později.
• Vzhledem k tomu, že stáhnu své prohlášení, měl bych být schopen zobrazit stažený soubor.
• Vzhledem k tomu, že jsem na stránce Stáhnout historické prohlášení, měl bych být schopen stáhnout své prohlášení ve formátech doc, excel a pdf.

Pokud projdete tímto přijetím, chybí zde 3 věci:

• Název a formát názvu souboru, který bude stažen.
• Jaké informace (názvy sloupců) se mají v souboru zobrazit.
• V seznamu možností můžete vybrat, jaký druh transakce zákazník chce, tj. Pouze debety nebo pouze kredity nebo obojí.

Takové případy se mohou stát jednou za čas, ale přesto si dobře prostudujte všechna kritéria přijetí a pokuste se je vizualizovat s odkazem na příběh uživatele. Čím více budete hluboce studovat podmínky a obchodní pravidla, tím více budou vaše znalosti o této funkci.

Chyby nalezené v počáteční fázi nestojí nic ve srovnání s náklady ve fázi „testování“.

Důležitost zjištění nesrovnalostí v kritériích uživatelského příběhu / přijetí

Vždy je důležité důkladně se ponořit do uživatelských příběhů a kritérií přijetí v rané fázi ještě před zahájením vývoje nebo testování.

Protože to zahrnuje:

# 1) Ztráta času:

Pokud se při vývoji nebo testování objeví nesrovnalosti nebo chyby v uživatelském příběhu / kritériích přijetí, bude třeba ve zbývajícím čase sprintu provést hodně přepracování.

Nestává se, že i kdyby produktový vlastník zmeškal několik věcí, posunou příběh uživatele do nadcházejícího sprintu. 95% šance, že požádají tým, aby provedl nezbytnou implementaci a vydal ji ve stejném sprintu.

Proto se pro tým stává noční můrou, protože musí trávit více času, chodit o víkendech nebo pracovat pozdě v noci. Tomu se lze vyhnout studiem a diskusí o uživatelském příběhu / kritériích přijetí v nejbližší možné fázi.

# 2) Ztráta úsilí:

Vývojáři a QA musí znovu navštívit implementovaný kód a testovací případy znovu. Aktualizace, přidávání a odebírání podle požadavků není snadný úkol. Stává se to příliš bolestivé, protože již existuje tlak na včasné doručení.

V takové situaci existuje šance na chyby ve fázi vývoje nebo testování. Pokud narazíte na takovou situaci, jděte na ‚DevQA Pairing '. Jako třešničku na dortu možná nedostanete náhradu za práci navíc.

Závěr

Hlubokého porozumění Příběhu uživatele a kritériím přijetí lze dosáhnout pouze tím, že jeho studiu věnujete nesmírný čas.

Na trhu není k dispozici žádný konkrétní nástroj nebo kurz, který by to pro vás mohl udělat, protože jde o logické myšlení, zkušenosti a znalosti o produktu.

Aktivní účast na schůzce s předběžným plánem, rozhovor s BA, studium na vlastní pěst vám k tomu může jen pomoci. Čím více úsilí vynaložíte, tím více se naučíte a budete růst.

Ať už jde o QA nebo vývojáře, každý musí být na stejné stránce o uživatelských příbězích a jejich kritériích přijetí, teprve poté lze úspěšně dosáhnout očekávání zákazníka.

Máte s námi něco nového o svých zkušenostech s prací s uživatelskými příběhy? Prosím, vyjádřete své myšlenky níže !!

Doporučené čtení

• MongoDB Vytváření uživatelů a přiřazování rolí s příklady
• Ukázková šablona pro protokol o přejímce s příklady
• Ověření uživatele v MongoDB
• Parametrizace dat JMeter pomocí uživatelem definovaných proměnných
• Oprávnění Unix: Oprávnění k souborům v Unixu s příklady
• Co je to přejímací testování (kompletní průvodce)
• Co je Uživatelská přejímací zkouška (UAT): Kompletní průvodce
• Výukový program Python DateTime s příklady