Ce este povestea utilizatorului și criteriile de acceptare (exemple)

Exemplu:

În calitate de utilizator WhatsApp, vreau o pictogramă a camerei în caseta de scris chat pentru a captura și trimite imagini, astfel încât să pot face clic și să împărtășesc fotografiile simultan cu toți prietenii mei.

Ce este un criteriu de acceptare?

Un criteriu de acceptare este un set de condiții sau reguli comerciale acceptate pe care funcționalitatea sau caracteristica ar trebui să le îndeplinească și să le îndeplinească, pentru a fi acceptate de către proprietarul / părțile interesate de produs.

Aceasta este o parte foarte importantă a completării poveștii utilizatorului și ar trebui studiată de către proprietarul de produs și analistul de afaceri foarte meticulos, deoarece lipsa unui singur criteriu poate costa foarte mult. Aceasta este o listă simplă numerotată sau cu marcatori.

Formatul său este după cum urmează:

' Având în vedere unele condiții prealabile atunci când fac o acțiune, atunci mă aștept la rezultat ”.

cel mai bun software de recuperare a hard diskului extern

Exemplu (w.r.t până la povestea utilizatorului de mai sus):

• Să luăm în considerare faptul că vorbesc cu un prieten și ar trebui să pot realiza o fotografie.
• Când dau clic pe o imagine, ar trebui să pot adăuga o legendă la imagine înainte de ao trimite.
• Dacă există o problemă la pornirea camerei telefonului meu, un mesaj de eroare de genul „Camera nu a putut fi pornită”. etc., ar trebui să fie afișate în consecință.

Prin urmare, povestea utilizatorului definește cerința pentru orice funcționalitate sau caracteristică, în timp ce criteriile de acceptare definesc „Definiția faptului” pentru povestea utilizatorului sau cerința.

În calitate de QA, este foarte important să înțelegeți profund povestea utilizatorului și criteriile sale de acceptare, fără să rămână nici măcar o singură îndoială la „începutul testării”. Mergând mai departe, să înțelegem de ce este extrem de important să săpăm „adânc” în poveștile utilizatorilor și în criteriile de acceptare.

Adâncind în poveștile utilizatorilor

Pentru început, să înțelegem mai întâi importanța unui studiu „aprofundat” al unui lucru de bază și fundamental, adică Povești de utilizatori.

Următoarele cazuri sunt propriile mele experiențe reale.

Cazul 1:

Înainte de 3 ani, lucram la un proiect de aplicații mobile, iar produsul era o aplicație concepută pentru persoanele care livrează.

Ați fi văzut o persoană de livrare venind la dumneavoastră pentru livrare. Și au un telefon mobil pe care vă cer să vă dați semnătura după livrare. Această semnătură se reflectă pe portalul furnizorilor de servicii de curierat precum DTDC, FedEx etc.

Să ne imaginăm că aplicația mobilă tocmai a fost lansată și portalurile lor sunt deja existente și în vigoare.

Problemă: Pentru un Sprint proprietarul produsului dvs. are o poveste de utilizator pentru această aplicație mobilă care „În calitate de administrator al portalului, ar trebui să pot vedea semnătura luată de persoana care livrează la momentul livrării” . Aici portalul (aplicația web) este modificat și actualizat corespunzător pentru a reflecta semnătura.

În calitate de QA, trebuie să verificați dacă semnătura capturată în aplicația mobilă reflectă așa cum era de așteptat în portal.

Dacă te uiți la această poveste a utilizatorului, pare simplă, dar există o cerință ascunsă aici: „Pentru livrările istorice, nu a existat funcționalitatea de reflectare a semnăturii, deci ce ar trebui să se întâmple dacă băieții din portal văd livrările istorice?” Ar trebui șterse datele istorice? Ar trebui să permitem blocări sau erori pentru astfel de date?

Desigur, deloc, acest lucru ar trebui tratat cu grație.

Soluţie: Când tabelele DB respective sunt actualizate pentru a adăuga o nouă coloană pentru locația Semnăturii, datele vechi ar trebui să aibă o valoare NULL sau 0 care ar trebui verificată și ar trebui afișat un mesaj care să indice „Nu există semnătură”.

Acest lucru poate fi numit lipsă de la proprietarul de produs sau analistul de afaceri, dar acest lucru trebuie făcut. Implementarea cu succes a unei caracteristici, dar clienții nu doresc să spargă ceva împreună cu aceasta. Acest lucru trebuie făcut împreună cu aceeași poveste de utilizator și în același sprint.

Cazul nr. 2

În urmă cu 6 ani, lucram la o cerere de finanțare pentru planificarea pensionării (fără BA), care era o aplicație globală în care oamenii din Finanțe, cum ar fi CA, consilierii în finanțe, o puteau folosi pentru diferite monede pentru a proiecta planurile de investiții, economiile etc. perioadă mare pentru clienții lor.

Problemă: Proprietarul produsului vă oferă o poveste de utilizator care „În calitate de consilier, vreau să vizualizez raportul clientului meu pe baza detaliilor financiare furnizate”.

Aici existau 2 cerințe ascunse și aș numi-o ca pe o poveste incompletă, deoarece:

la) Rapoartele ar trebui să ia în considerare rata zilnică de conversie a monedei și nu cea istorică, ca în ultimul raport vizualizat și

b) Dacă moneda este schimbată după furnizarea detaliilor financiare ale clientului, rapoartele ar trebui să apară în moneda modificată.

Soluţie: Am ridicat această îngrijorare direct la proprietarul nostru de produs și l-am conștientizat că ambele trebuie să fie făcute cât mai curând posibil. El a fost de acord cu mine și a creat cu prioritate 2 povești diferite pentru sprint-urile viitoare.

La pachet: Acestea au fost surprinse deoarece toți am fost foarte conștienți de produse, designul, structura lor etc. Astfel de cunoștințe pot fi obținute doar prin înțelegerea completă a produsului, prin înțelegerea interoperabilității modulelor și prin studierea temeinică a utilizatorului, chiar dacă este un 2 liner.

Faceți note pentru a ușura lucrurile și discutați cu BA și dezvoltatorii despre gândirea lor.

O privire aprofundată asupra criteriilor de acceptare

Înțelegerea exhaustivă a criteriilor de acceptare și a tuturor celorlalte condiții și reguli este chiar mai importantă decât subevaluarea unei povești a utilizatorului. Deoarece dacă o cerință este incompletă sau vagă, aceasta poate fi preluată în sprintul următor, dar dacă un criteriu de acceptare este omis, atunci povestea utilizatorului în sine nu poate fi lansată.

Cred că am fi folosit cu toții un serviciu bancar net la un moment dat și majoritatea dintre noi îl folosim în fiecare zi și descarc mult declarațiile mele istorice. Dacă îl observați cu atenție, există anumite opțiuni specifice disponibile pentru descărcarea acestora.

Există o opțiune pentru a selecta tipul de fișier pentru descărcarea extrasului dvs. Există o opțiune de a alege dacă doriți să descărcați numai creditele / debitul / ambele.

Acum imaginați-vă că proprietarul produsului vă oferă această poveste de utilizator „În calitate de client, vreau să descarc extrasul de cont pentru a putea vedea toate tranzacțiile efectuate pentru o anumită perioadă”.

Cu următoarele criterii de acceptare:

• Având în vedere că sunt pe pagina Descărcare declarație istorică, ar trebui să selectez perioada pentru care doresc să descarc declarația.
• Având în vedere că sunt pe pagina Descărcați declarația istorică, ar trebui să selectez contul pentru care doresc să descărc extrasul.
• Având în vedere că sunt pe pagina Descărcare declarații istorice, nu ar trebui să am permisiunea de a descărca declarația pentru data viitoare „Până la”.
• Având în vedere că mă aflu pe pagina Declarație istorică, nu ar trebui să îmi fie permis să selectez data „De la” cu 10 ani mai târziu în trecut.
• Având în vedere că descarc declarația mea, ar trebui să pot vizualiza fișierul descărcat.
• Având în vedere că sunt pe pagina Descărcare declarații istorice, ar trebui să pot descărca declarația mea în format doc, excel și pdf.

Dacă treceți prin această acceptare, aici lipsesc 3 lucruri:

• Numele și formatul numelui fișierului care va fi descărcat.
• Ce informații (nume coloane) trebuie afișate în fișier.
• Lista de opțiuni pentru a selecta ce tip de tranzacție dorește clientul, adică numai debite sau numai credite sau ambele.

Astfel de cazuri se pot întâmpla din când în când, totuși studiați bine despre fiecare criteriu de acceptare și încercați să-l vizualizați cu referire la povestea utilizatorului. Cu cât veți studia mai profund despre condiții și reguli de afaceri, cu atât mai multe vor fi cunoștințele dvs. despre caracteristică.

Bugurile găsite în etapa inițială nu costă nimic în comparație cu ceea ce ar putea costa în etapa de „testare”.

Importanța găsirii discrepanțelor în povestea utilizatorului / criteriile de acceptare

Este întotdeauna important să faceți o scufundare profundă în poveștile utilizatorilor și criteriile de acceptare într-o etapă incipientă chiar înainte de începerea dezvoltării sau testării.

Pentru că implică:

# 1) Pierderea timpului:

Dacă discrepanțele sau greșelile din povestea utilizatorului / criteriile de acceptare se găsesc atunci când se desfășoară dezvoltarea sau se desfășoară testarea, atunci poate fi necesar să se facă o mulțime de lucrări în timpul rămas sprint.

Nu se întâmplă ca, chiar dacă Proprietarul produsului a ratat câteva lucruri, să mute povestea utilizatorului la sprintul care urmează. 95% sunt șanse să solicite echipei să realizeze implementarea necesară și să o lanseze în același sprint.

Prin urmare, devine un coșmar pentru echipă, deoarece trebuie să petreacă timp suplimentar, să vină în weekend sau să lucreze noaptea târziu. Acest lucru poate fi evitat studiind și discutând povestea utilizatorului / criteriile de acceptare în cea mai timpurie etapă posibilă.

# 2) Risipa de eforturi:

Dezvoltatorii și QA trebuie să revizuiască codul implementat și să testeze din nou cazurile. Actualizarea, adăugarea și eliminarea conform cerințelor nu este o sarcină ușoară. Devine prea dureros, deoarece există deja o presiune pentru a livra la timp.

Într-o astfel de situație, există șanse de greșeli în etapa de dezvoltare sau testare. Dacă întâlniți o astfel de situație, alegeți „DevQA Pairing”. Ca cireasă de pe tort, este posibil să nu primiți o compensație pentru munca suplimentară.

Concluzie

Înțelegerea profundă a User Story și criteriile de acceptare pot fi realizate numai petrecând un timp imens în studierea acesteia.

Nu există un instrument sau curs specific disponibil pe piață pentru a face acest lucru pentru dvs., deoarece este vorba despre gândire logică, experiență și cunoștințe despre produs.

Participarea activă la întâlnirea de pre-plan, discuția cu BA, studierea pe cont propriu vă poate ajuta doar să realizați acest lucru. Cu cât depui mai multe eforturi, cu atât înveți și crești mai mult.

Fie că este vorba de asigurări de calitate sau de dezvoltatori, toată lumea trebuie să fie pe aceeași pagină despre poveștile utilizatorilor și criteriile lor de acceptare, numai atunci așteptările clientului pot fi atinse cu succes.

Aveți ceva nou de împărtășit cu noi despre experiențele dvs. despre lucrul cu User Stories? Vă rog să vă exprimați gândurile mai jos !!

Lectură recomandată

• MongoDB Creează utilizator și atribuie roluri cu exemple
• Exemplu de șablon pentru raportul testului de acceptare cu exemple
• Autentificare utilizator în MongoDB
• Parametrizarea datelor JMeter folosind variabile definite de utilizator
• Permisiuni Unix: Permisiuni de fișiere în Unix cu exemple
• Ce este testarea acceptării (Un ghid complet)
• Ce este testul de acceptare a utilizatorului (UAT): un ghid complet
• Tutorial Python DateTime cu exemple