Cum să documentați desenele dvs. utilizând povestiri despre utilizatori care conduc comportamentul

O problemă comună atunci când cerințele de documentare este de a lua un punct de vedere din punct de vedere al sistemului pentru a descrie ceea ce este necesar, uitând că este utilizatorul care va fi în centrul interacțiunilor. Poveștile utilizatorilor, introduse de Agile, abordează această problemă, făcând utilizatorul centrul cerinței, iar Dezvoltarea comportamentului (Behavior Driven Development - BDD) face lucrurile un pas mai departe oferind un cadru în care comportamentul utilizatorilor este ceea ce conduce dezvoltarea.

Utilizarea tehnicilor BDD pentru a crea povestiri de utilizatori face ca cerințele de documentare să fie mai ușor de scris și citite. De asemenea, furnizează instrumente suplimentare pentru a comunica experiența dorită a unui design, pe care designerii, dezvoltatorii și inginerii QA le pot utiliza pentru a urmări rapid și chiar automatiza o parte din munca lor. În acest articol voi explora această abordare și ar arăta cum o puteți folosi pentru a vă documenta propriile desene sau modele, începând de la povestiri mici până la organizarea acestor povestiri pentru a comunica caracteristici funcționale pe deplin.

Cerințele UI față de cerințele UX

Există o distincție importantă între cerințele UI (cunoscute și ca specificații) și cerințele UX. Pe de o parte, cerințele UI sunt documente tehnice care enumeră specificul despre interfața utilizatorului, inclusiv tipurile de fonturi, culorile, dimensiunile și aspectul elementelor. Un bun exemplu al acestui tip de documentație sunt ghidurile stilului de viață.

Cerințele UX, pe de altă parte, descriu ce ar trebui să fie experiența pentru a specific utilizator, dat fiind faptul că acest utilizator se află într-un anumit scenariu, efectuând o acțiune specifică. O poveste de utilizator poate capta o cerință UX într-un mod foarte succint. De exemplu:

• Ca… utilizator de editori,
• Vreau sa… să fie capabil să revizuiască articolele înainte de a fi publicate,
• Astfel încât… Pot oferi feedback și asigurarea calității în timp util.

Această poveste indică mai întâi rolul utilizatorului, ceea ce acest utilizator dorește să realizeze și explică apoi motivul din spatele acestuia. Acest lucru este grozav, deoarece oferă o perspectivă dezvoltatorilor și testerelor asupra a ceea ce este scopul final: să fie suficientă o nevoie a utilizatorului. Rețineți că cuvintele bold sunt șablonul folosit pentru a scrie povestea. Există întotdeauna un utilizator, care dorește să facă ceva, astfel încât să poată atinge un anumit scop. Puteți urma aceste sfaturi pentru a scrie povestiri bune ale utilizatorilor.

Având în vedere această poveste, echipa de proiectare poate decide că este necesară o acțiune de "aprobare" pentru a atinge scopul utilizatorului. Apoi, pentru a oferi detalii despre cum va funcționa acest lucru, puteți utiliza sintaxa Gherkin, care este un instrument BBD pentru scrierea unor cerințe lizibile pentru afaceri. Sintaxa Gherkin este similară cu povestile de utilizatori agile deoarece oferă o modalitate de scriere a cerințelor care poate fi, de asemenea, utilizată ca șablon. Avantajul este că puteți obține mai multe detalii, oferind scenarii și acțiuni pe care utilizatorul le-ar lua fără a obține cum trebuie implementată implementarea. Să aruncăm o privire mai atentă la ea.

Scrierea de povești despre utilizatori utilizând sintaxa Gherkin

Elementele de bază ale unei povesti folosind sintaxa Gherkin pot fi rezumate în aceste părți:

• O caracteristica
• Un scenariu
• O condiție prealabilă
• O actiune
• Un rezultat

O caracteristica este un loc pentru a descrie valoarea de afaceri globală a implementării. Acesta poate fi, de asemenea, utilizat pentru a furniza informații suplimentare, cum ar fi regulile de afaceri, sau orice altceva care facilitează înțelegerea acestei caracteristici (cum ar fi legăturile cu prototipurile sau cerințele UI).

Un scenariu descrie circumstanțele specifice în care este utilizatorul. Din perspectiva designului utilizatorului, scenariile permit comunicarea variabilelor multiple ale unui design și a modului în care UI ar trebui să se ocupe de acestea, în funcție de utilizator.

O condiție prealabilă ajută la construirea scenariului și elimină orice ambiguitate. De exemplu, într-un scenariu care descrie un prim utilizator care accesează un anumit ecran, condiția prealabilă poate clarifica faptul că utilizatorul este conectat.

O actiune indică exact ceea ce face utilizatorul în interfață și este de obicei un "declanșator", cum ar fi clic pe un buton, trimiterea unui formular sau navigarea către alt loc.

Un rezultat este consecința acțiunii și trebuie să fie întotdeauna ceva care poate fi testat.

Având în vedere aceste părți, să scriem o poveste a utilizatorului pentru funcția pe care am descris-o mai devreme:

• Ca…  utilizator de editori,
• Vreau sa…  să fie capabil să revizuiască articolele înainte de a fi publicate,
• Astfel încât…  Pot oferi feedback și asigurarea calității în timp util.

Folosind sintaxa Gherkin această poveste ar arăta astfel:

Puteți vedea cum povestea inițială se transformă într-un flux mai detaliat pe care utilizatorul îl poate urmări și, prin urmare, poate fi testat. De asemenea, rețineți că cuvintele cu caractere aldine sunt cuvintele cheie pe care le utilizează software-ul, cum ar fi castravetele, pentru a automatiza executarea testelor. Voi explica mai multe despre acest lucru mai târziu, dar deocamdată, vreau să subliniez că aceste cuvinte cheie sunt foarte utile și pentru scrierea povestirii, deoarece acestea ajută la distingerea diferitelor părți ale povestirii.

Alt lucru care trebuie subliniat este că, deși povestea oferă mai multe detalii despre fluxul de utilizator, interfața nu este descrisă. Motivul pentru aceasta este faptul că descrierea UI poate transforma rapid povestea în cerințe UI, ceea ce reprezintă o mare problemă, deoarece poate deveni depășită destul de repede. De exemplu, în cazul în care povestea descrie modul în care arată alerta de succes și ce ar trebui să spună mesajul specific, atunci povestea poate să se sincronizeze dacă oricare dintre acestea se schimbă, creând potențialul unor teste care nu au.

Deci, trucul este acela de a oferi suficiente detalii, fără a face treaba cu instrumente mai adecvate, cum ar fi machete de design, prototipuri și ghiduri de stil. În acest sens, veți observa că acțiunea indică "selectarea aprobă", doar folosind "aprobarea". "Selectarea aprobării" nu este specifică în ceea ce privește cum arată acest control (ar putea fi un buton, un buton care arată ca un link sau o casetă pe care se poate da clic), dar implică faptul că se declanșează un element din interfața de utilizare. De asemenea, indică faptul că acest element a scris în el "aprobă". Aceasta este o zonă gri în care va trebui să folosiți bunul simț, deoarece în unele cazuri veți dori să fiți așa de specific, astfel încât acțiunile să poată fi distinse de altele. De exemplu, dacă există o altă modalitate de a aproba un articol pe aceeași pagină, indicând că în acest scenariu utilizatorul trebuie să-l "selecteze", să facă diferențierea.

Importanța scenariilor

Pe lângă sintaxa atentă pe care o oferă Gherkin, unul dintre lucrurile pe care le consider cel mai util este utilizarea secțiunii "scenarii". Scenariile sunt puternice, deoarece pot fi folosite pentru a testa designul și pentru a vă asigura că toate bazele sunt acoperite.

De obicei, desene sau modele de orice fel încep cu "calea fericită", ceea ce înseamnă ce se întâmplă atunci când totul merge bine în interfață și cum se aplică majorității utilizatorilor. În exemplul nostru precedent am avut:

De asemenea, pentru că știm că articolele au date de publicare, putem afirma: Acesta este primul nostru scenariu deoarece, în majoritatea cazurilor, articolele care trebuie aprobate ar trebui să fie pregătite pentru publicare. Dar acest lucru aduce întrebarea: ce se întâmplă atunci când un articol nu este pregătit pentru publicare și editorul îl accesează? Ar trebui chiar să aibă acces la aceste articole?

• Ce s-ar întâmpla dacă un articol aprobat are o dată de publicare în trecut? Dacă articolul va fi publicat imediat sau ar trebui să intre într-o coadă? 
• Și mergând un pas mai departe, ce se întâmplă dacă un editor aprobă un articol din greșeală? Care este procedura pentru anularea acestei acțiuni? Cine ar trebui să fie notificat?

Toate aceste întrebări fac parte din procesul de proiectare și, cel mai probabil, de când sari în cerințele de documentare, veți cunoaște răspunsurile. Vestea minunată este că folosirea de scenarii în documentația dvs. de poveste vă va ajuta să le structurați și, în multe cazuri, vă va ajuta să vă asigurați că aveți un design și un flux destinat fiecăruia.

Să vedem cum se va schimba povestea noastră cu scenariile suplimentare:

În funcție de caracteristică, pot exista multe scenarii care trebuie luate în considerare. Ele sunt esențiale pentru a le menține scurte, astfel încât să le puteți descrie și să le testați cu ușurință. De asemenea, puteți încerca să le grupați, folosind numitori comuni. De exemplu, dacă câteva scenarii au aceeași condiție prealabilă, puteți încapsula acest lucru într-un "fundal" care poate fi folosit de mai multe scenarii. De exemplu:

Organizarea de povestiri pentru a comunica o caracteristică

O provocare comună care apare atunci când cerințele de documentare este de a decide care ordine să o facă. Motivul este că în majoritatea cazurilor totul este în construcție, ceea ce face dificilă testarea unei interacțiuni când părțile interacțiunilor nu sunt încă construite. De exemplu, în simpla interacțiune a "aprobării" unui articol, multe lucruri trebuie să fie pregătite:

1. UI ar trebui să poată returna un mesaj de succes dacă aprobarea are succes și un mesaj de eroare în cazul în care există o problemă de sistem.
2. UI ar trebui să poată "eticheta" articolele aprobate.
3. UI ar trebui să poată afișa articolul conform logicii de afaceri "publicate".
4. Notificările sistemului ar trebui să fie activate, astfel încât scriitorii să poată fi avertizați atunci când are loc aprobarea.

O abordare a cerințelor de documentare pentru fiecare dintre aceste dependențe le înregistrează ca caracteristici diferite care pot fi apoi prioritizate în funcție de valoarea lor de afaceri.

Apoi, puteți crea o poveste de "integrare" pentru a le aduce împreună. De exemplu, o poveste de utilizator pentru sistemul de etichetare ar dori acest lucru:

În povestea de integrare, puteți face referire la povestea de etichetare, în cazul în care detaliile pentru acest scenariu trebuie să fie verificate din nou sau dacă pur și simplu doriți să știți dacă aceste cazuri au fost deja verificate.

Ideea este de a evita repetarea documentației care nu numai că consumă timp inutil, dar și că poate să nu mai fie sincronizată.

Transformarea povestilor utilizatorilor în cazuri de testare

Am văzut cât de utile sunt ghidurile comportamentale conduse de utilizatori pentru a scrie cerințe care sunt concentrate, concise, dar și detaliate și descriptive. Pornind de la faza de proiectare, acest instrument poate da un bun primer pentru inginerii QA pentru scrierea cazurilor de testare reale.

În afară de aceste avantaje deosebite, povestile utilizatorilor cu comportament de conduită pot fi efectiv transformate în teste funcționale cu ajutorul software-ului, cum ar fi Castraveți sau Salată. Ideea de bază este că, odată ce poveștile sunt scrise folosind sintaxa Gherkin, le puteți plasa într-un .caracteristică fișier în interiorul aplicației dvs. și apoi executați-le ca teste pentru a arăta dacă au reușit sau nu. Pentru un tutorial în profunzime despre modul de utilizare a salatei pentru o verificare a implementării Python, tutorialul David Sale:

Concluzie

Scrierea poveștilor utilizatorilor utilizând principiile BDD poate servi la comunicarea detaliată a cerințelor de afaceri și de proiectare, cu o abordare orientată spre utilizator, folosind o limbă care poate fi citită de om, dar poate fi extinsă pentru interpretarea software-ului. În plus, poate fi folosit pentru a testa:

• propriile dvs. modele, pe măsură ce cereți documente
• aplicația actuală manuală, o dată transformată în cazuri de testare de către un inginer de QA
• aplicația reală în mod automat, când a fost transformată în teste funcționale utilizând software-ul BDD.

Acest lucru înseamnă mai multe straturi pentru bug-uri pentru a trece prin, împiedicând goluri în design și bulletproofing mai mult aplicația dvs. de la erori de bug-uri.