Kaj je uporabniška zgodba in merila sprejemljivosti (primeri)

Primer:

Kot uporabnik WhatsAppa želim v polju za pisanje klepeta ikono fotoaparata za zajemanje in pošiljanje slik, tako da lahko svoje slike hkrati kliknem in dam v skupno rabo z vsemi prijatelji.

Kaj so merila sprejemljivosti?

Kriterij sprejemljivosti je sklop sprejetih pogojev ali poslovnih pravil, ki jih mora funkcionalnost ali funkcija izpolnjevati in izpolnjevati, da jih lahko sprejme lastnik izdelka / deležniki.

To je zelo pomemben del dokončanja uporabniške zgodbe, zato bi ga lastnik izdelka in poslovni analitik moral zelo natančno preučiti, ker lahko manjkanje enega samega merila stane veliko. To je preprost oštevilčen ali označen seznam.

Njegova oblika je naslednja:

' Glede na predpogoj, ko nekaj ukrepam, pričakujem rezultat '.

vprašanja o intervjuju za spletne storitve za milo in počitek

Primer (w.r.t do zgoraj uporabniške zgodbe):

• Upoštevajmo, da klepetam s prijateljem in bi moral biti sposoben zajeti sliko.
• Ko kliknem sliko, bi ji lahko pred pošiljanjem dodal napis.
• Če je pri zagonu fotoaparata telefona nekaj težav, se prikaže sporočilo o napaki, na primer »Fotoaparata ni bilo mogoče zagnati«. itd., je treba ustrezno prikazati.

Zato uporabniška zgodba opredeljuje zahtevo za katero koli funkcionalnost ali funkcijo, medtem ko merila sprejemljivosti določajo 'opredelitev opravljenega' za uporabniško zgodbo ali zahtevo.

Kot QA je zelo pomembno, da uporabniško zgodbo in njena merila za sprejem razumemo globoko, niti en dvom ne ostane na 'začetku testiranja'. Ko gremo naprej, bomo razumeli, zakaj je izjemno pomembno, da se poglobimo v zgodbe uporabnikov in merila sprejemljivosti.

Poglobite se v uporabniške zgodbe

Za začetek najprej razumemo pomen ‘poglobljene’ študije osnovne in temeljne stvari, tj. Zgodbe uporabnikov.

Naslednji primeri so moje resnične izkušnje.

Primer 1:

Pred tremi leti sem delal na projektu mobilne aplikacije, izdelek pa je bil namenjen dostavljavcem.

Videli bi dostavljavca, ki bi prišel k vam na dostavo. In imajo mobilni telefon, na katerem vas prosijo, da podate svoj podpis po dostavi. Ta podpis se odraža na portalu ponudnikov kurirskih storitev, kot so DTDC, FedEx itd.

Predstavljajmo si, da je mobilna aplikacija pravkar zagnana in njihovi portali že obstajajo in delujejo.

Težava: Za Sprint ima vaš lastnik izdelka uporabniško zgodbo za to mobilno aplikacijo, ki 'Kot skrbnik portala bi moral imeti vpogled v podpis, ki ga je prevzela dostavljalka ob dostavi' . Tu se portal (spletna aplikacija) ustrezno spremeni in posodobi, da odraža podpis.

Kot QA morate preveriti, ali podpis, zajet v mobilni aplikaciji, odraža pričakovano na portalu.

Če pogledate to uporabniško zgodbo, je videti preprosto, vendar je tu skrita zahteva, da 'Za zgodovinske dostave ni bilo funkcije odseva podpisov, kaj naj se zgodi, če si fantje s portala ogledajo zgodovinske dostave?' Ali je treba zgodovinske podatke izbrisati? Ali bi morali dovoliti zrušitve ali napake za take podatke?

Seveda sploh ne, s tem bi morali ravnati milostno.

Rešitev: Ko se ustrezne tabele DB posodobijo, da se doda nov stolpec za lokacijo podpisa, morajo imeti stari podatki vrednost NULL ali 0, ki jo je treba preveriti in prikazati sporočilo z napisom „Podpis ne obstaja“.

To lahko lastnik izdelka ali poslovni analitik zamudite, vendar je to treba storiti. Kupci ne želijo, da bi eno funkcijo uspešno uvedli, a nekaj skupaj zlomili. To je treba storiti skupaj z isto uporabniško zgodbo in v istem sprintu.

Primer # 2

Pred 6 leti sem delal na aplikaciji za financiranje pokojninskega načrtovanja (brez BA), ki je bila globalna aplikacija, kjer so jo ljudje iz financ, na primer CA, Finance Advisors, lahko uporabljali za različne valute za načrtovanje naložbenih načrtov, prihrankov itd. veliko časa za svoje stranke.

Težava: Lastnik izdelka vam da uporabniško zgodbo, ki 'Kot svetovalec si želim ogledati poročilo svoje stranke na podlagi posredovanih finančnih podrobnosti.'

Tu sta bili dve skriti zahtevi in ​​temu bi rekel nepopolno zgodbo, ker:

do) Poročila morajo upoštevati dnevni menjalni tečaj in ne zgodovinskega, kot je bilo v zadnjem ogledu poročila in

b) Če se valuta spremeni po navedbi strankinih finančnih podrobnosti, morajo biti poročila prikazana v spremenjeni valuti.

Rešitev: To skrb sem izrazil neposredno pri našem lastniku izdelka in ga opozoril, da je treba oboje storiti čim prej. Strinjal se je z mano in prednostno ustvaril 2 različni zgodbi za prihajajoče šprinte.

Odnesi: Ti so bili ujeti, ker smo se vsi dobro zavedali izdelkov, njihove zasnove, strukture itd. Takšno znanje lahko dosežemo samo s popolnim razumevanjem izdelka, razumevanjem medsebojne uporabnosti modulov in temeljitim preučevanjem uporabniške zgodbe, tudi če je 2 podloga.

Naredite si zapiske, da boste stvari olajšali, in se z BA-ji in razvijalci pogovorite o njihovem razmišljanju.

Poglobljen pogled na merila sprejemljivosti

Razumevanje meril sprejemljivosti in vseh drugih pogojev in pravil je celo pomembnejše od razumevanja uporabniške zgodbe. Ker če je zahteva nepopolna ali nejasna, jo je mogoče uporabiti v naslednjem šprintu, če pa je kriterij sprejemljivosti zgrešen, uporabniške zgodbe same ni mogoče objaviti.

Mislim, da bi vsi nekoč uporabljali neto bančništvo, večina pa ga uporablja vsak dan in veliko prenašam svoje zgodovinske izjave. Če ga natančno opazujete, so na voljo nekatere posebne možnosti za njihov prenos.

Obstaja možnost, da izberete vrsto datoteke za prenos izjave. Obstaja možnost, da izberete, ali želite prenesti samo dobroimetje / bremenitev / oboje.

Zdaj pa si predstavljajte, da vam lastnik izdelka predstavi to uporabniško zgodbo 'Kot stranka želim prenesti izpisek računa, da si lahko ogledam vse transakcije, opravljene za določeno obdobje'.

Z naslednjimi merili sprejemljivosti:

• Glede na to, da sem na strani Prenos zgodovinske izjave, bi moral izbrati obdobje, za katero želim prenesti izjavo.
• Glede na to, da sem na strani Prenos zgodovinske izjave, bi moral izbrati račun, za katerega želim prenesti izjavo.
• Glede na to, da sem na strani Prenos zgodovinske izjave, ne bi smel dovoliti, da prenesem izjavo za prihodnji datum »Do«.
• Glede na to, da sem na strani za prenos zgodovinske izjave, ne bi smel izbrati datuma »Od«, preteklega 10 let.
• Glede na to, da prenesem izjavo, bi si lahko ogledal preneseno datoteko.
• Glede na to, da sem na strani Prenos zgodovinske izjave, bi lahko prenesel izjavo v oblikah doc, excel in pdf.

Če greste skozi to sprejemanje, tukaj manjkajo 3 stvari:

• Ime in oblika imena datoteke, ki bo prenesena.
• Katere informacije (imena stolpcev) bodo prikazane v datoteki.
• Seznam možnosti za izbiro vrste transakcije, ki jo želi stranka, tj. Samo bremenitve ali samo dobropisi ali oboje.

Takšni primeri se lahko občasno pojavijo, vendar vseeno dobro preučite vsa merila sprejemljivosti in jih poskusite vizualizirati glede na zgodbo uporabnika. Bolj ko boste globoko preučevali pogoje in poslovna pravila, bolj bo vaše znanje o funkciji.

Napake, najdene v začetni fazi, ne stanejo nič v primerjavi s stroški, ki bi jih lahko stali v fazi 'testiranja'.

Pomen odkrivanja neskladij v uporabniški zgodbi / merilih sprejemljivosti

Vedno je pomembno, da se zgodbe uporabnikov in merila sprejemljivosti poglobijo že v zgodnji fazi, še preden se začne razvoj ali testiranje.

Ker vključuje:

# 1) Zapravljanje časa:

Če se med razvojem ali preizkušanjem odkrijejo odstopanja ali napake v uporabniški zgodbi / merilih sprejemljivosti, bo v preostalem času sprinta morda treba veliko predelati.

Ne zgodi se, da bo lastnik izdelka, tudi če je nekaj stvari zamudil, uporabniško zgodbo premaknil na prihajajoči sprint. 95% možnosti je, da od ekipe zahtevajo, da opravi potrebno izvedbo in jo sprosti v istem sprintu.

Zato postane ekipa nočna mora, saj morajo preživljati dodaten čas, prihajati ob vikendih ali delati pozno zvečer. Temu se je mogoče izogniti s čimprejšnjim proučevanjem in razpravljanjem o uporabniški zgodbi / merilih sprejemljivosti.

# 2) Zapravljanje prizadevanj:

Razvijalci in QA morajo znova pregledati implementirano kodo in znova preizkusiti primere. Posodabljanje, dodajanje in odstranjevanje po zahtevah ni lahka naloga. Postane preveč boleče, saj že obstaja pritisk, ki ga je treba pravočasno dostaviti.

V takšnih razmerah obstaja verjetnost napak v fazi razvoja ali testiranja. Če naletite na takšno situacijo, izberite 'DevQA Pairing'. Kot češnja na torti morda ne boste dobili nadomestila za dodatno delo.

Zaključek

Poglobljeno razumevanje uporabniške zgodbe in kriterijev sprejetja je mogoče doseči le tako, da se za njeno preučevanje porabi ogromen čas.

Na trgu ni na voljo nobenega posebnega orodja ali tečaja, ki bi to naredil namesto vas, saj gre predvsem za logično razmišljanje, izkušnje in znanje o izdelku.

Aktivno sodelovanje na sestankih pred načrtovanjem, pogovor z univerzitetnim študentom, samostojno učenje vam lahko samo pomagajo doseči to. Več truda vložite, več se učite in rastete.

Naj bodo to skrbniki kakovosti ali razvijalci, vsi morajo biti na isti strani o uporabniških zgodbah in njihovih merilih sprejemljivosti, le tako je mogoče uspešno doseči pričakovanja kupca.

Ali želite z nami deliti nekaj novega o svojih izkušnjah pri delu z uporabniškimi zgodbami? Prosimo, izrazite svoje misli spodaj !!

Priporočeno branje

• MongoDB Ustvari uporabnika in dodeli vloge s primeri
• Vzorčna predloga za poročilo o preizkusu sprejemljivosti s primeri
• Preverjanje pristnosti uporabnika v MongoDB
• Parametriranje podatkov JMeter z uporabniško določenimi spremenljivkami
• Dovoljenja Unixa: Dovoljenja datotek v Unixu s primeri
• Kaj je sprejemno testiranje (popoln vodnik)
• Kaj je testiranje sprejemljivosti uporabnika (UAT): popoln vodnik
• Vadnica Python DateTime s primeri