timp de citire: 7 minute

succesul oricărui proiect depinde de capacitatea unei echipe de dezvoltare de a satisface nevoile clientului. Comunicarea dintre client și echipa de dezvoltare joacă un rol vital în livrarea unei soluții care se potrivește cerințelor de produs și de piață., Problemele apar dacă clienții își explică prea vag nevoile și echipa nu poate înțelege cerințele clare și, în cele din urmă, problema de afaceri din spatele lor. Imaginați-vă că cereți echipei dvs. să permită utilizatorilor să caute un produs într-o librărie online pe categorii. Vă așteptați să aveți o interfață clară cu linkurile de categorii pentru a face clic pe ele (de exemplu, fantezie, non-ficțiune, istoric etc.).) După două săptămâni de dezvoltare, primiți o caracteristică a barei de căutare în care utilizatorii trebuie să tasteze categoria de care sunt interesați, în loc să navigheze categoriile pre-listate., Deși acest lucru funcționează, obiectivul dvs. inițial a fost să expuneți toate categoriile disponibile și să permiteți utilizatorilor să exploreze în continuare.acest lucru este atunci când documentația software de înaltă calitate ar putea ajuta la evitarea problemei. Poveștile utilizatorilor și criteriile de acceptare (AC) ca principalele formate ale cerințelor de documentare. O poveste de utilizator este o descriere în limbaj natural a unei caracteristici. De obicei este însoțită de criterii de acceptare.

criteriile de acceptare (AC) sunt condițiile pe care un produs software trebuie să le îndeplinească pentru a fi acceptat de un utilizator, un client sau alt sistem., Acestea sunt unice pentru fiecare poveste de utilizator și definesc comportamentul caracteristicilor din perspectiva utilizatorului final. Criteriile de acceptare bine scrise ajută la evitarea rezultatelor neașteptate la sfârșitul unei etape de dezvoltare și asigură că toate părțile interesate și utilizatorii sunt mulțumiți de ceea ce obțin.

criteriile de Acceptare sunt cele mai mici la nivel de cerințe funcționale

criterii de Acceptare scopuri principale

Clarificarea cerințele părților implicate este un nivel înalt scop. Pentru a face scopurile AC mai clare, să le rupe în jos.,

detalizarea domeniului de aplicare a caracteristicilor. AC definesc limitele poveștilor utilizatorilor. Acestea oferă detalii precise despre funcționalitate care ajută echipa să înțeleagă dacă povestea este finalizată și funcționează conform așteptărilor.

descriind scenarii negative. Yor AC poate solicita sistemului să recunoască intrările de parole nesigure și să împiedice un utilizator să continue. Formatul de parolă nevalid este un exemplu de așa-numit scenariu negativ atunci când un utilizator face intrări nevalide sau se comportă în mod neașteptat. AC defini aceste scenarii și să explice modul în care sistemul trebuie să reacționeze asupra lor.

setarea comunicării., Criteriile de acceptare sincronizează viziunile clientului și ale echipei de dezvoltare. Acestea se asigură că toată lumea are o înțelegere comună a cerințelor: dezvoltatorii știu exact ce fel de comportament trebuie să demonstreze caracteristica, în timp ce părțile interesate și clientul înțeleg ce se așteaptă de la caracteristică.

optimizarea testelor de acceptare. AC sunt baza testării de acceptare a povestirii utilizatorului. Fiecare criteriu de acceptare trebuie să fie testabil independent și, prin urmare, să aibă scenarii clare de trecere sau eșec. Ele pot fi, de asemenea, utilizate pentru a verifica povestea prin teste automate.

estimarea caracteristicilor., Criteriile de acceptare specifică exact ce trebuie dezvoltat de echipă. Odată ce echipa are cerințe precise, ei pot împărți poveștile utilizatorilor în sarcini care pot fi estimate corect.

criterii de acceptare tipuri și structuri

AC pot fi scrise în diferite formate. Există două cele mai comune, și cea de-a treia opțiune este să elaboreze propriul format:

• scenariu-orientate (Dat/Când/Atunci)
• reguli orientate (lista de verificare)
• formate personalizate

Ca primul și cel de-al doilea formate au foarte structuri specifice, ne vom concentra mai ales pe ei., Cu toate acestea, este posibil să descoperiți că alte formate se potrivesc mai bine produsului dvs., astfel încât să le atingem și pe scurt.

criterii de acceptare orientate pe scenariu

formatul orientat pe scenariu de scriere AC este cunoscut sub numele de tipul dat/când/atunci (GWT).

• având în vedere o anumită condiție prealabilă
• când fac o acțiune
• atunci mă aștept la un rezultat

această abordare a fost moștenită de la behavior-driven development (BDD) și oferă o structură consistentă care ajută testerii să definească când să înceapă și să termine testarea unei anumite caracteristici., De asemenea, reduce timpul petrecut în scrierea cazurilor de testare, deoarece comportamentul sistemului este descris în avans.,fiecare criteriu de acceptare scris în acest format are următoarele afirmații:

1. scenariu – numele comportamentului care va fi descris
2. dat – starea de început a scenariului
3. când – acțiune specifică pe care utilizatorul o face
4. apoi – rezultatul acțiunii din „când”
5. și – folosit pentru a continua oricare dintre cele trei declarații anterioare

când sunt combinate aceste ia pentru a finaliza o sarcină și experimenta rezultatul.să ne uităm la câteva exemple.,

Exemplul 1

poveste utilizator: ca utilizator, vreau să pot recupera parola în Contul meu, astfel încât să pot accesa Contul meu în cazul în care am uitat parola.,igated la pagina de login

atunci Când: A selectat utilizatorul a uitat parola opțiune

Și: a Intrat un e-mail validă pentru a primi un link pentru recuperarea parolei

Atunci: sistemul a trimis link-ul a intrat de e-mail

Având în vedere: utilizatorul primit link-ul prin e-mail

atunci Când: Utilizatorul a navigat prin link-ul primit în e-mail

Atunci: sistemul permite utilizatorului pentru a seta o nouă parolă

Exemplu 2

poveste de Utilizare: Ca utilizator, vreau să fie în măsură să solicite bani din contul meu în ATM-uri, astfel încât să va fi capabil de a primi banii din contul meu de repede și în locuri diferite.,capac

Și: dozatorul contine numerar

atunci Când: clientul solicită bani

Atunci: asigurați-vă contul este debitat

Și: a se asigura de numerar este distribuit

Și: asigura cardul este returnat

criterii de Acceptare 2:

Având în vedere: ca, contul e pe minus

Și: cardul este valabil

atunci Când: clientul solicită bani

Atunci: asigura respingerea mesaj este afișat

Și: a se asigura de numerar nu este distribuit

Reguli orientate criterii de acceptare a format

În unele cazuri, este dificil pentru a se potrivi criteriile de acceptare în Dat/Când/Apoi structura., De exemplu, GWT ar fi cu greu util pentru următoarele cazuri:

• lucrați cu povești de utilizator care descriu funcționalitatea la nivel de sistem care are nevoie de alte metode de asigurare a calității.
• publicul țintă pentru criteriile de acceptare nu are nevoie de detalii precise ale scenariilor de testare.
• scenarii GWT nu se potrivesc pentru a descrie constrângerile de proiectare și experiența utilizatorului de o caracteristică. Dezvoltatorii pot pierde o serie de detalii critice.

puteți aborda aceste cazuri cu formatul AC orientat pe reguli.,

forma orientată spre reguli presupune că există un set de reguli care descriu comportamentul unui sistem. Pe baza acestor reguli, puteți desena scenarii specifice.de obicei, criteriile compuse folosind acest formular arată ca o listă simplă de gloanțe. Să aruncăm o privire la un exemplu.

exemplu

poveste utilizator: ca utilizator, vreau să folosesc un câmp de căutare pentru a introduce un oraș, un nume sau o stradă, astfel încât să pot găsi opțiuni de hotel potrivite.,

criterii de acceptare a interfeței de căutare de bază

• câmpul de căutare este plasat în bara de sus
• căutarea începe odată ce utilizatorul face clic pe „Căutare”
• câmpul conține un substituent cu un text de culoare gri: „unde te duci?”
• substituentul dispare odată ce utilizatorul începe să tasteze
• căutarea este efectuată dacă un utilizator introduce într-un oraș, nume de hotel, stradă sau toate combinate
• căutarea este în engleză, franceză, germană și ucraineană
• utilizatorul nu poate introduce mai mult de 200 de simboluri
• căutarea nu acceptă simboluri speciale (caractere)., Dacă utilizatorul a tastat un simbol special, afișați mesajul de avertizare: „intrarea de căutare nu poate conține simboluri speciale.”

alte formate

majoritatea poveștilor utilizatorilor pot fi acoperite cu două formate menționate mai sus. Cu toate acestea, puteți inventa propriile criterii de acceptare, având în vedere că servesc scopurilor lor, sunt scrise clar în limba engleză și nu pot fi interpretate greșit. Unele Echipe folosesc chiar și text simplu.,

Uneori, criteriile pot fi specificate ca un exemplu de sistem de comportament:

Un simplu set de AC pentru parole puternice de Mark Levison pentru agilepainpainrelief.com

Această abordare oferă orientări clare pentru parola caracteristică de testare.

roluri responsabile și modul în care sunt create criteriile de acceptare

unele dintre criterii sunt definite și scrise de proprietarul produsului atunci când creează produsul restante. Iar celelalte pot fi specificate în continuare de către echipă în timpul discuțiilor despre poveștile utilizatorilor după planificarea sprintului., Nu există recomandări stricte pentru alegerea persoanei responsabile pentru scrierea criteriilor. Clientul le poate documenta dacă are cunoștințe tehnice și de documentare a produsului ample. În acest caz, Clientul negociază criteriile cu echipa pentru a evita neînțelegerile reciproce. În caz contrar, criteriile sunt create de un proprietar de produs, un analist de afaceri, un analist de cerințe sau un manager de proiect.,

procesul începe cu o poveste de utilizator prioritizare și se termină cu negociere detalii cu întreaga echipă

Principalele provocări și bune practici de scriere criteriile de acceptare

criterii de Acceptare a arata ca în cazul în care acestea sunt foarte ușor de a scrie. În ciuda formatelor lor simpliste, scrierea reprezintă o provocare pentru multe echipe. Să aruncăm o privire mai profundă asupra celor mai bune practici care ajută la evitarea greșelilor comune.

Document criterii înainte de dezvoltare. Criteriile de acceptare trebuie documentate înainte de începerea dezvoltării efective., În acest fel, echipa va capta probabil toate nevoile clienților în avans. La început, este suficient să setați criteriile pentru un număr mic de povești de utilizator pentru a umple întârzierile pentru două sprinturi (dacă practicați Scrum sau o metodă similară). Acestea trebuie să fie convenite de ambele părți. Apoi, criteriile de acceptare documentate sunt utilizate de dezvoltatori pentru a planifica procesul tehnic.

nu face AC prea îngust. Criteriile de acceptare pot fi mult prea specifice care trăiesc puțin sau deloc Opțiuni de manevră pentru dezvoltatori. Pentru a evita acest lucru, amintiți-vă că AC trebuie să transmită intenția, dar nu o soluție finală., Mai mult, AC îngust poate fi lipsit de comportamente multiple ale utilizatorilor care nu sunt acoperite.

păstrați criteriile realizabile. Acest punct se intersectează strâns cu cel precedent. Criteriile eficiente de acceptare definesc bucata minimă rezonabilă de funcționalitate pe care o puteți livra. Dar, în cazul în care cedezi descrierii tuturor detaliilor mici, există riscul ca echipa ta să rămână blocată cu sute de sarcini mici.păstrați AC măsurabile și nu prea larg. Criteriile largi de acceptare fac o poveste de utilizator vagă., Criteriile eficiente de acceptare trebuie să contureze domeniul de activitate, astfel încât dezvoltatorii să își poată planifica și estima efortul în mod corespunzător.evitați detaliile tehnice. După cum am menționat, criteriile de acceptare trebuie să fie scrise în limba engleză. Acest lucru le va face clare și ușor de înțeles pentru toată lumea: este posibil ca părțile interesate sau managerii dvs. să nu aibă cunoștințe tehnice.

ajunge la un consens. Aceeași problemă poate fi rezolvată în mod diferit de către o echipă și părțile interesate, în funcție de punctele lor de vedere. Asigurați-vă că ați comunicat AC-ul dvs. părților interesate și că ați ajuns la un acord reciproc., Același lucru este valabil și pentru membrii echipei. Toată lumea trebuie să revizuiască AC și să confirme că înțeleg și sunt de acord cu fiecare linie.

scrie AC testabil. Acest lucru va permite testerilor să verifice dacă toate cerințele au fost îndeplinite. În caz contrar, dezvoltatorii nu vor înțelege dacă povestea utilizatorului este finalizată.

ultimul cuvânt

nu neglija criteriile de acceptare, deoarece acestea – fiind simple și abordabile-rezolvă mai multe probleme simultan., Acestea documentează așteptările clienților, oferă o perspectivă a utilizatorului final, clarifică cerințele și previn ambiguitatea și, în cele din urmă, ajută la asigurarea calității să verifice dacă obiectivele de dezvoltare au fost îndeplinite. Indiferent dacă utilizați sau nu metode Agile, asigurați-vă că alegeți cel mai bun format sau experimentați cu cele proprii. Diferite tipuri de povești de utilizator și în cele din urmă caracteristici pot necesita diferite de Laats și testarea celor noi care lucrează pentru tine este o bună practică.