Co je to Uživatelská Příběh a Přejímací Kritéria (Příklady)

Ideální Příručka pro Uživatele Příběh Kritéria Přijatelnosti s scénáře v reálném životě:

V odvětví Vývoje Softwaru, slovo „Požadavkem“ definuje, co je naším cílem, co zákazníci přesně potřebujete a to, co bude naše společnost zvýšit své podnikání.

ať už je to produkt společnosti, která je software, produkty nebo služby společnosti, která nabízí služby v různých softwarových oblastech, hlavní základna pro všechny z nich je požadavek, a úspěch je definován tím, jak dobře jsou splněny požadavky.,

termín „požadavek“ má různá jména v různých metodikách projektu.

ve vodopádu se označuje jako „dokument požadavku/SPECIFIKACE“, v Agile nebo SCRUM se označuje jako „Epic“, „User Story“.

pod Vodopádovým modelem jsou dokumenty požadavků obrovské dokumenty o 200 nebo více stránkách, protože celý produkt je implementován v jedné fázi. Ale to není případ Agile / SCRUM, protože v těchto metodikách jsou uvedeny požadavky na malé funkce nebo funkce,protože produkt je připraven krok za krokem.,

V tomto článku, snažil jsem se moje nejlepší, aby sdílet všechny mé 4 roky zkušeností na práci s Uživatelské příběhy a jejich Kritéria Přijatelnosti spolu s snadné a jednoduché real-life scénáře, pro vaše lepší pochopení.

pojďme nejprve znovu navštívit základy.

co je to příběh uživatele?

uživatelský příběh je požadavek na jakoukoli funkci nebo funkci, která je zapsána v jednom nebo dvou řádcích a max až 5 řádků. Uživatelský příběh je obvykle nejjednodušší možný požadavek a je asi jedna a pouze jedna funkce (nebo jedna funkce).,

nejčastěji Se používá standardní formát pro Uživatele, Příběh stvoření je uvedeno níže:

Jako <role uživatele/zákazníka, Chci, aby < cíl dosáhnout> takže můžu <důvod, proč cíle>.

Příklad:

Jako uživatel WhatsApp, chci ikonu fotoaparátu v chatu psát box zachytit a posílat obrázky tak, že mohu kliknout a sdílet své obrázky současně se všemi přáteli.

jaká jsou kritéria pro přijetí?,

kritériem pro přijetí je soubor přijatých podmínek nebo obchodních pravidel, které by funkčnost nebo funkce měla splňovat a splňovat, aby je přijal vlastník/zúčastněné strany produktu.

Jedná se o velmi důležitou součást dokončení uživatelského příběhu a měl by být velmi pečlivě studován vlastníkem produktu a obchodním analytikem, protože chybějící jediné kritérium může stát hodně. Jedná se o jednoduchý číslovaný nebo odrážkový seznam.

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

„Vzhledem k tomu, podmínku, když udělám nějakou akci, pak očekávám, že výsledek“.

příklad (w.r.,t k výše uvedenému uživatelskému příběhu):

• Vezměme si, ž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 přidat titulek k obrázku před jeho odesláním.
• pokud se vyskytne nějaký problém se spuštěním fotoaparátu v telefonu, nelze spustit chybovou zprávu jako „fotoaparát“. atd., by měly být uvedeny odpovídajícím způsobem.

proto uživatelský příběh definuje požadavek na jakoukoli funkci nebo funkci, zatímco kritéria pro přijetí definuje „definici Hotovo“ pro příběh uživatele nebo požadavek.,

jako QA je velmi důležité pochopit příběh uživatele a jeho akceptační kritéria hluboce, aniž by na „začátku testování“ zůstala ani jediná pochybnost. Kupředu pojďme pochopit, proč je nesmírně důležité kopat „hluboko“ v uživatelských příbězích a kritériích přijetí.

kopání hluboko do uživatelských příběhů

nejprve pochopíme důležitost „hloubkové“ studie základní a základní věci, tj.

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

Case #1:

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

viděli byste doručovatele, který přichází na vaše místo k dodání. A mají mobilní telefon, na kterém vás požádají, abyste po doručení dali svůj 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 jejich portály jsou již existující a nahoru.,

Problém: Pro Sprint váš vlastník Produktu má uživatel příběh pro tento mobilní aplikaci, která „Jako Portál Admin, měl bych být schopen zobrazit podpis přijatá dodávka osoba v době dodání“. Zde je portál (webová aplikace) změněn a odpovídajícím způsobem aktualizován, 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.,

Když se podíváte na tento příběh uživatele, to vypadá jednoduše, ale je skrytý požadavek tady, že „Pro historické dodávky, tam byl žádný podpis reflexe funkčnosti, tak co by se stalo, kdyby portálu chlapi zobrazit historické dodávky?“Měly by být historické údaje vymazány? Měli bychom povolit chyby nebo chyby pro taková data?

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

Řešení: Když příslušné DB tabulky jsou aktualizovány přidat nový sloupec pro Podpis, umístění, stará data by měla mít hodnotu NULL, nebo hodnotu 0, které by měly být kontrolovány a zpráva ‚Žádný podpis existuje, by měl být zobrazen.

to lze nazvat jako slečna od vlastníka produktu nebo obchodního analytika, ale to musí být provedeno. Implementace jedné funkce úspěšně, ale lámání něco spolu s ním není žádoucí ze strany zákazníků. To je třeba provést spolu se stejným uživatelským příběhem a ve stejném sprintu.,

#2

před 6 lety, jsem pracoval na Plánování odchodu do Důchodu Financí Aplikace (bez BA), který byl globální aplikace, kde Financování lidi, jako CA, Finanční Poradci mohli použít pro různé měny k projektu investiční plány, úspory, atd., po dlouhou dobu svým zákazníkům.

problém: majitel produktu vám poskytne uživatelský příběh, který“jako poradce chci zobrazit zprávu svého zákazníka na základě poskytnutých finančních údajů“.,

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

a] zprávy by měly zvážit denní směnný kurz a není historický, jak v poslední zobrazenou zprávu a

b] v Případě, že měna je změněn po zadání zákazníka, finanční údaje, zprávy by měly ukázat ve změnila měnu.

řešení: tuto obavu jsem vznesl přímo u našeho vlastníka produktu a uvědomil jsem si, že obě tyto věci musí být provedeny co nejdříve. Souhlasil se mnou a vytvořil 2 různé příběhy pro nadcházející sprinty s prioritou.,

Take Away: ty byly chyceny, protože jsme si všichni byli velmi dobře vědomi produktů,jejich designu, struktury atd. Takovou znalostí může být dosaženo pouze tím, že rozumí produkt zcela, pochopení interoperability modulů a studiem uživatelská příběh důkladně, i když je to 2 vložky.

dělat si poznámky, aby se věci jednodušší a diskutovat s BA a vývojáři o jejich myšlení.,

podrobný pohled na kritéria přijetí

pochopení kritérií přijetí a všech ostatních podmínek& pravidla jsou ještě důležitější než podceňování příběhu uživatele. Protože pokud je požadavek neúplný nebo vágní, může být přijat v příštím sprintu, ale pokud chybí kritérium přijetí, nemůže být samotný uživatelský příběh propuštěn.

myslím, že bychom všichni v určitém okamžiku použili čisté bankovnictví a většina z nás ho používá každý den a hodně Stahuji svá Historická prohlášení., Pokud je pečlivě sledujete, existují určité konkrétní možnosti, jak je stáhnout.

existuje možnost vybrat typ souboru pro stažení vašeho prohlášení. K dispozici je možnost vybrat si, zda chcete stáhnout pouze Kredity / debet / obojí.

nyní si představte, že majitel produktu vám dává tento uživatelský příběh „jako zákazník si chci stáhnout výpis z účtu, abych si mohl prohlédnout všechny své transakce provedené za určité období“.,

S následující Akceptační Kritéria:

• Vzhledem k tomu, že jsem na Stáhnout Historické Prohlášení Stránce, bych měla vybrat období, pro které chci stáhnout prohlášení.
• vzhledem k tomu, že jsem na stránce historické prohlášení ke stažení, měl bych vybrat účet, pro který chci stáhnout prohlášení.
• vzhledem k tomu, že jsem na stránce historických prohlášení ke stažení, neměl bych mít možnost Stáhnout prohlášení pro budoucí datum „To“.,
• vzhledem k tomu, že jsem na stránce historických prohlášení ke stažení, neměl bych mít možnost vybrat si datum “ od “ 10 let za minulostí.
• vzhledem k tomu, že Stahuji své prohlášení, měl bych být schopen zobrazit stažený soubor.
• vzhledem k tomu, že jsem na stránce historických prohlášení ke stažení, měl bych si 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.
• seznam možností pro výběr toho, jaký druh transakce zákazník chce, tj. pouze debety nebo pouze kredity nebo obojí.

k takovým případům může dojít jednou za čas, nicméně stále dobře studujte o jednotlivých kritériích přijetí a pokuste se je vizualizovat s odkazem na příběh uživatele. Čím více budete studovat hluboce o podmínkách a obchodních pravidel, tím více bude vaše znalosti o funkci.

chyby nalezené v počáteční fázi nestojí nic ve srovnání s tím, co to může stát ve fázi „testování“.,

význam nalezení nesrovnalostí v kritériích pro příběh uživatele / přijetí

vždy je důležité provést hluboký ponor v uživatelských příbězích a kritériích přijetí v rané fázi ještě před zahájením vývoje nebo testování.

Protože to zahrnuje:

#1) Plýtvání Času:

Pokud se nesrovnalosti nebo chyby v uživatelském příběh/kritéria přijatelnosti jsou nalezeny, kdy je vývoj nebo testování se děje, pak hodně přepracovat, může být potřeba udělat ve zbývajících sprint času.,

nestane se, že i když majitel produktu vynechal několik věcí, přesune uživatelský příběh do nadcházejícího sprintu. 95% je pravděpodobné, že požádají tým, aby provedl potřebnou implementaci a uvolnil ji ve stejném sprintu.

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

# 2) plýtvání úsilí:

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

v takové situaci existuje šance na chyby ve fázi vývoje nebo testování. Pokud narazíte na takovou situaci, jděte na „párování DevQA“. Jako třešnička na dortu nemusíte dostat náhradu za práci navíc.

závěr

hluboké pochopení uživatelských příběhových a akceptačních kritérií lze dosáhnout pouze tím, že strávíte obrovský čas studiem.,

Neexistuje žádný konkrétní nástroj nebo kurz na trhu k dispozici, aby to pro vás, protože to je všechno o logické myšlení, zkušenosti a znalosti o produktu.

účast na Předplánovém setkání aktivně, mluvení s BA, studium na vlastní pěst vám může pomoci pouze k dosažení tohoto cíle. Čím více úsilí dáte, tím více se učíte a rostete.

Být to QA, nebo vývojáři, všichni musí být na stejné stránce o uživateli příběhy a jejich kritéria přijatelnosti, teprve pak očekávání zákazníka může být úspěšně dosaženo.,

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!!