Što je korisnička priča i kriteriji prihvaćanja (primjeri)

Primjer:

Kao korisnik WhatsAppa, želim ikonu kamere u okviru za pisanje chata za snimanje i slanje slika kako bih mogao istovremeno kliktati i dijeliti svoje slike sa svim svojim prijateljima.

Što su kriteriji prihvaćanja?

Kriterij prihvaćanja skup je prihvaćenih uvjeta ili poslovnih pravila koje funkcionalnost ili značajka trebaju zadovoljiti i ispuniti kako bi ih vlasnik / dionici prihvatio.

Ovo je vrlo važan dio dovršavanja korisničke priče i vlasnik proizvoda i poslovni analitičar trebao bi ga vrlo pažljivo proučiti jer propuštanje jednog kriterija može puno koštati. Ovo je jednostavan numerirani ili nabrajan popis.

Njegov je oblik sljedeći:

' S obzirom na neki preduvjet kad nešto poduzmem, onda očekujem rezultat '.

kako dodati elemente niza u javi

Primjer (w.r.t do gornje korisničke priče):

• Uzmimo u obzir da razgovaram s prijateljem i trebao bih moći snimiti sliku.
• Kad kliknem na sliku, trebao bih moći dodati naslov na sliku prije slanja.
• Ako postoji problem s pokretanjem kamere mog telefona, pojavljuje se poruka o pogrešci poput 'Kamera se ne može pokrenuti'. itd., treba prikazati u skladu s tim.

Stoga Korisnička priča definira zahtjev za bilo kojom funkcionalnošću ili značajkom, dok Kriteriji prihvaćanja definiraju 'Definiciju gotovog' za korisničku priču ili zahtjev.

Kao osiguranje kvalitete vrlo je važno duboko razumjeti korisničku priču i njezine kriterije prihvaćanja, a da niti jedna dvojba ne ostane na „početku testiranja“. Krenimo dalje, shvatimo zašto je izuzetno važno kopati se duboko u korisničke priče i kriterije prihvaćanja.

Kopajući duboko u korisničke priče

Za početak, prvo shvatimo važnost ‘dubinskog’ proučavanja osnovne i temeljne stvari, tj. Korisničke priče.

Sljedeći su slučajevi moja vlastita stvarna iskustva.

Slučaj # 1:

Prije tri godine radio sam na projektu mobilne aplikacije, a proizvod je bio aplikacija namijenjena dostavljačima.

Vidjeli biste da dostavljač dolazi kod vas na dostavu. I oni imaju mobitel na kojem od vas traže da date svoj potpis nakon isporuke. Ovaj se potpis odražava na portalu pružatelja kurirskih usluga poput DTDC-a, FedExa itd.

Zamislimo da je mobilna aplikacija tek pokrenuta, a njihovi portali već postoje i postoje.

Problem: Za Sprint vaš vlasnik proizvoda ima korisničku priču za ovu mobilnu aplikaciju koja 'Kao administrator portala, trebao bih moći vidjeti potpis koji je dostavljač preuzeo u trenutku isporuke' . Ovdje se portal (web aplikacija) mijenja i ažurira u skladu s tim da odražava potpis.

Kao QA morate provjeriti odražava li se potpis zabilježen u mobilnoj aplikaciji kako se očekuje na portalu.

Ako pogledate ovu korisničku priču, izgleda jednostavno, ali ovdje postoji skriveni zahtjev da 'Za povijesne isporuke nije postojala funkcija odražavanja potpisa, pa što bi se trebalo dogoditi ako momci s portala gledaju povijesne isporuke?' Treba li izbrisati povijesne podatke? Trebamo li dopustiti padove ili pogreške za takve podatke?

Naravno, nikako, s tim bi se trebalo postupati ljubazno.

Riješenje: Kada se odgovarajuće DB tablice ažuriraju kako bi se dodao novi stupac za mjesto Potpis, stari podaci trebali bi imati vrijednost NULL ili 0 što bi trebalo provjeriti i prikazati poruku u kojoj stoji 'Nema potpisa'.

To se može nazvati propustom vlasnika proizvoda ili poslovnog analitičara, ali to mora biti učinjeno. Uspješna implementacija jedne značajke, ali razbijanje nečega zajedno s njom nije poželjno za kupce. To treba učiniti zajedno s istom korisničkom pričom i istim sprintom.

Slučaj # 2

Prije 6 godina radio sam na aplikaciji za financiranje mirovinskog planiranja (bez BA) koja je bila globalna aplikacija u kojoj su ljudi iz financija poput CA-a, savjetnika za financije mogli koristiti za različite valute za projektiranje investicijskih planova, štednje itd. Tijekom više od veliko razdoblje za svoje kupce.

Problem: Vlasnik proizvoda daje vam korisničku priču koja „Kao savjetnik želim pregledati izvješće svog kupca na temelju pruženih financijskih detalja“.

Ovdje su postojala 2 skrivena zahtjeva i nazvao bih to nepotpunom pričom jer:

do) Izvješća trebaju uzimati u obzir dnevni tečaj pretvorbe valuta, a ne povijesni kao u posljednjem pregledanom izvješću i

b) Ako se valuta promijeni nakon pružanja financijskih podataka kupca, izvješća bi se trebala prikazivati ​​u promijenjenoj valuti.

Riješenje: Ovu zabrinutost izravno sam iznio s našim vlasnikom proizvoda i obavijestio ga da oboje treba obaviti što prije. Složio se sa mnom i stvorio 2 različite priče za nadolazeće sprinteve s prioritetom.

Oduzeti: Oni su uhvaćeni jer smo svi bili vrlo dobro upoznati s proizvodima, njihovim dizajnom, strukturom itd. Takvo se znanje može postići samo cjelovitim razumijevanjem proizvoda, razumijevanjem međusobne operativnosti modula i temeljitim proučavanjem korisničke priče, čak i ako je to slučaj 2 obloge.

Pravite bilješke kako biste olakšali stvari i razgovarajte s BA-ima i programerima o njihovom razmišljanju.

Dubinski uvid u kriterije prihvaćanja

Iscrpno razumijevanje kriterija prihvaćanja i svih ostalih uvjeta i pravila još je važnije od razumijevanja korisničke priče. Jer ako je zahtjev nepotpun ili nejasan, može se poduzeti u sljedećem sprintu, ali ako se propusti kriterij prihvaćanja, tada se sama korisnička priča ne može objaviti.

Pretpostavljam da bismo svi u nekom trenutku koristili mrežno bankarstvo i većina nas koristi ga svaki dan, a ja često preuzimam svoje povijesne izjave. Ako ga pažljivo promatrate, dostupne su određene posebne mogućnosti za njihovo preuzimanje.

Postoji mogućnost odabira vrste datoteke za preuzimanje vaše izjave. Postoji mogućnost odabira želite li preuzeti samo Kredite / Debit / oba.

Sada zamislite da vam Vlasnik proizvoda daje ovu korisničku priču „Kao kupac želim preuzeti izvod svog računa kako bih mogao pregledati sve svoje transakcije izvršene za određeno razdoblje“.

Sa sljedećim kriterijima prihvaćanja:

• S obzirom da se nalazim na stranici Preuzimanje povijesne izjave, trebao bih odabrati razdoblje za koje želim preuzeti izjavu.
• S obzirom da se nalazim na stranici Preuzimanje povijesne izjave, trebao bih odabrati račun za koji želim preuzeti izjavu.
• S obzirom da se nalazim na stranici Preuzimanje povijesne izjave, ne bi mi trebalo biti dopušteno da preuzmem izjavu za budući datum „Do“.
• S obzirom na to da se nalazim na stranici Preuzimanje povijesne izjave, ne bi mi trebalo biti dopušteno da odaberem datum 'Od' prije 10 godina u prošlosti.
• S obzirom na to da preuzimam izjavu, trebao bih moći pregledati preuzetu datoteku.
• S obzirom da se nalazim na stranici Preuzimanje povijesne izjave, trebao bih moći preuzeti izjavu u formatima doc, excel i pdf.

Ako prođete kroz ovo prihvaćanje, ovdje nedostaju 3 stvari:

• Naziv i format naziva datoteke koja će se preuzeti.
• Koji se podaci (nazivi stupaca) trebaju prikazati u datoteci.
• Popis opcija za odabir vrste transakcije koju kupac želi, tj. Samo terećenja ili samo krediti ili oboje.

Takvi se slučajevi mogu dogoditi povremeno, no ipak dobro proučite svaki kriterij prihvaćanja i pokušajte ga vizualizirati s pozivom na korisničku priču. Što više duboko proučite uvjete i pravila poslovanja, to će više biti i vašeg znanja o značajci.

Greške pronađene u početnoj fazi ne koštaju ništa u usporedbi s onim što bi mogle koštati u fazi 'testiranja'.

Važnost pronalaženja odstupanja u korisničkoj priči / kriterijima prihvaćanja

Uvijek je važno duboko zaroniti u korisničke priče i kriterije prihvaćanja u ranoj fazi čak i prije nego što razvoj ili testiranje započnu.

Budući da uključuje:

# 1) Gubljenje vremena:

Ako se utvrde odstupanja ili pogreške u korisničkoj priči / kriterijima prihvaćanja tijekom razvoja ili testiranja, tada će u preostalom vremenu sprinta trebati obaviti puno prerade.

Ne događa se da će čak i ako je vlasnik proizvoda propustio nekoliko stvari, premjestiti korisničku priču na nadolazeći sprint. 95% šanse je da od ekipe zatraže da izvrši potrebnu implementaciju i pusti je u istom sprintu.

Stoga to postaje noćna mora za tim jer moraju provoditi dodatno vrijeme, dolaziti vikendom ili raditi kasno navečer. To se može izbjeći proučavanjem i raspravom o korisničkoj priči / kriterijima prihvaćanja u najranijoj mogućoj fazi.

# 2) Gubljenje napora:

Programeri i QA moraju ponovno posjetiti implementirani kod i ponovo testirati slučajeve. Ažuriranje, dodavanje i uklanjanje prema zahtjevu nije lak zadatak. Postaje previše bolno jer već postoji pritisak da se isporuči na vrijeme.

U takvoj situaciji postoje šanse za pogreške u fazi razvoja ili ispitivanja. Ako naiđete na takvu situaciju, odaberite 'DevQA uparivanje'. Kao šlag na torti, možda nećete dobiti naknadu za dodatni rad.

Zaključak

Dubinsko razumijevanje korisničke priče i kriteriji prihvaćanja mogu se postići samo trošenjem ogromnog vremena na njezino proučavanje.

Na tržištu nema dostupnog određenog alata ili tečaja koji bi to učinio umjesto vas, jer se ovdje radi o logičnom razmišljanju, iskustvu i znanju o proizvodu.

Aktivno sudjelovanje na sastancima prije planiranja, razgovor s BA, samostalno studiranje mogu vam samo pomoći da to postignete. Što više napora uložite, više učite i rastete.

Bilo da je riječ o QA-u ili programerima, svi moraju biti na istoj stranici o korisničkim pričama i njihovim kriterijima prihvaćanja, samo se tada uspješno mogu ostvariti očekivanja kupca.

Imate li nešto novo s nama o svojim iskustvima u radu s korisničkim pričama? Iznesite svoje misli u nastavku !!

Preporučena literatura

• MongoDB Stvori korisnika i dodijeli uloge s primjerima
• Uzorak predloška za izvješće o ispitivanju prihvaćanja s primjerima
• Autentifikacija korisnika u MongoDB
• JMeter parametalizacija podataka korištenjem korisnički definiranih varijabli
• Dopuštenja za Unix: Dozvole za datoteke u Unixu s primjerima
• Što je ispitivanje prihvaćenosti (cjelovit vodič)
• Što je ispitivanje prihvaćenosti korisnika (UAT): cjelovit vodič
• Python DateTime Vodič s primjerima