Testarea de asigurare a calității s-a perfecționat – Un tutorial pentru fluxul de utilizatori

Pe măsură ce produsele și serviciile se implementează din ce în ce mai rapid, asigurarea calității (QA) trebuie să se adapteze mediului în evoluție, atingând uneori același nivel de acoperire într-o perioadă mai scurtă de timp. Cum evităm greșeala cantității în detrimentul calității ? Cum acoperim mai mult, creștem eficiența și suntem în continuare eficienți în munca noastră?

Știm cu toții că cazurile de testare durează mult timp pentru a crea. Trebuie să aplicăm diferite tehnici, tipuri de teste și să documentăm precondițiile, pașii și rezultatele așteptate. În plus, trebuie să creăm un plan de testare.

Specialiștii în asigurarea calității trec adesea în afara timpului, mai ales atunci când încearcă să realizeze toate fazele procesului de QA. Cea mai mare durere de cap este faza de planificare și proiectare a testelor, care se învârte în jurul creării cazurilor de testare și a documentației de testare. Pot dura ore, uneori chiar zile de efort pentru a duce la bun sfârșit toată munca și, de obicei, aleg să omite anumite livrabile și să rezuma, în schimb, lăsând deoparte informațiile importante care pot duce la uitarea unui test. Acest lucru duce, de asemenea, la pierderea beneficiului schimbului de cunoștințe.

Testarea QA tradițională îndeplinește fluxul de utilizatori

Sunt un mare fan al cazurilor și planurilor de testare tradiționale. Ele nu numai că ajută la identificarea a tone de cazuri de testare, dar și documentează foarte bine produsul. Le poți folosi la antrenament, iar orice persoană din echipă le înțelege. Nu trebuie să te bazezi prea mult pe experiență pentru ca cineva să înceapă să testeze. Planurile de testare conțin informații suplimentare, cum ar fi detalierea domeniului de aplicare, elementele de testare, caracteristicile pe care le testați și cele pe care nu le testați. Există, de asemenea, o analiză de risc care intră în planul de testare. Acestea sunt doar câteva dintre beneficii, cu toate acestea, timpul total necesar este prea lung în multe cazuri.

Scopul unui plan de testare este o modalitate de comunicare și un acord între părțile interesate ale proiectului. Ajută la detalierea obiectivelor, resurselor necesare și orice abordare sau strategie pentru testarea produsului. Planul ajută la asigurarea că totul este gândit și oferă părților interesate încredere că procesul de asigurare a calității este investit strategic. Nu există o regulă concretă conform căreia acest plan trebuie să aibă 10 pagini. Îl putem redefini pentru a se potrivi unei echipe cu ritm rapid.

Alternativa este de a simplifica cazurile de testare tradiționale și planul de testare într-un mod care reduce investiția de timp necesară, dar oferă aceeași, dacă nu mai mult, acoperire și documentație care are sens pentru toate părțile interesate. Aceasta implică o singură sursă de adevăr, un flux de utilizatori cu o răsturnare. Prin structurarea și menținerea unui flux de utilizatori, veți avea cea mai mare parte a designului cazului de testare deja realizată pentru dvs. Acest lucru poate fi aplicat oricărui produs sau echipă și este versatil în modul său de detaliu și structură.

Folosirea metodei fluxului vă va ajuta să obțineți un timp de răspuns mai rapid cu documentația de testare. Acest lucru nu este doar pentru QA manual, ci și pentru automatizare. Fluxul poate contribui și la unele secțiuni ale planului de testare.

Mergând cu Fluxul

Fără întârziere, să ne aprofundăm direct în construirea unui flux de utilizatori pentru un site web de mesagerie simplu.

Mai întâi vom avea nevoie de un instrument gratuit de cartografiere a minții. Eu personal folosesc XMind. Simțiți-vă liber să descărcați orice instrument cu care vă simțiți confortabil - vom folosi doar caracteristici de bază, cum ar fi desenarea unei diagrame de flux, adăugarea de „note” la unele dintre subiecte, colorarea diferitelor condiții și utilizarea etichetelor.

Primul nostru pas este să înțelegem produsul. De obicei, veți face referire la imagini-machete sau wireframes. Dacă niciuna dintre acestea nu este disponibilă, un apel rapid de recuperare cu un dezvoltator va da exact la ce ecrane să vă așteptați. Simțiți-vă liber să urmați și să exersați pe măsură ce procedăm. Fluxul nu se limitează doar la o interfață cu utilizatorul și poate fi folosit și pentru a mapa apeluri de la API la API, diagrame de baze de date, structuri de dependență și multe altele. Se aplică aceleași principii.

Condiții, state, acțiuni

Ne restrângem fluxul folosind doar trei actori. Veți avea o Condiție , care este ca un utilizator cu un anumit rol, un cache șters sau un utilizator care se conectează pentru prima dată. În al doilea rând, avem un State/Page , care este o componentă reală a GUI, cum ar fi o pagină de pornire sau o fereastră de conectare. Urmează Action , care este o interacțiune fizică a utilizatorului care determină schimbarea stării. Să vedem asta în acțiune.

Analizarea cerințelor

Aceasta este pagina noastră de pornire, care este statul. Avem două acțiuni posibile: Înregistrare și Autentificare.

Apoi, avem fereastra Conectare, un alt stat. Acțiunile de aici sunt Înapoi și Autentificare. Rețineți că nu clasificăm câmpurile de intrare ca acțiuni. Ești mai mult decât binevenit să faci asta. Din experiența mea, am descoperit că atunci când lucrez pe sisteme complexe care rulează câteva zecimi adâncime, devine puțin dificil de întreținut, dar pentru aplicații simple, poate fi potrivit.

În cele din urmă, ajungem la tabloul de bord pe care va ateriza utilizatorul când se va conecta cu succes. Aici avem trei acțiuni: putem crea, edita sau șterge un mesaj.

Acum avem suficiente informații pentru a începe fluxul de utilizatori. Să rezumam ce avem. Notăm stările produsului. Din câte putem vedea, sunt patru pagini:

1. Pagina principala
2. Fereastra de autentificare
3. Fereastra de înregistrare
4. Bord

Notăm acțiunile noastre pe fiecare pagină/stare care poate fi „interacționată” cu:

1. Pagina principala
   1. Autentificare
   2. Inregistreaza-te
2. Fereastra de autentificare
   1. conectare
   2. Anulare
3. Fereastra de înregistrare
   1. TBD (depinde de produs)
4. Bord
   1. Crea
   2. Editați | ×
   3. Șterge

Începem cu Numele produsului , care poate fi modificat pentru a se adapta mediului dvs., dar acesta se potrivește majorității echipelor și produselor lor și oferă, de asemenea, un bun punct de plecare. Mai jos, vom observa un semn de întrebare lângă Înregistrare .

De multe ori, veți întâlni o componentă în Agile care nu este încă în domeniul de aplicare sau planificată pentru o lansare viitoare. Luați notă de existența sa, dar lăsați-o ca necunoscută până vom obține mai multe informații.

Desenarea diagramei de flux

Tragem cele de mai sus în XMind pentru a arăta astfel:

Veți observa că pur și simplu codez prin culori ce este o stare și ce este o acțiune. Am adăugat, de asemenea, o linie din acțiunea Anulare pe pagina principală pentru a reprezenta cu exactitate acel flux. De asemenea, vedem două condiții când un utilizator selectează „Autentificare”. Deși ambele merg la tabloul de bord, totuși vrem să testăm ambele condiții posibile.

Lucrul frumos cu XMind este că, dacă lucrăm la o aplicație mare și complexă, putem crea diferite niveluri ale diagramei, așa că dacă doriți să despărțiți fluxul în mai multe fluxuri, dar să le mențineți legate, este foarte ușor de făcut cu conectarea. subiectele să fie separate foi. Puteți selecta să inserați un hyperlink și, din fereastra pop-up expertului, puteți alege o „Stare” la care duce acțiunea. Aceasta înseamnă că dacă selectați „Conectare” pe XMind și hyperlinkuri către „Tabloul de bord”, cursorul mouse-ului va sări la „Tabloul de bord”, chiar dacă se află pe o altă foaie. Destul de la moda.

Ceea ce lipsește fluxul nostru sunt etichetele. Oferim produsului o etichetă cu 0, deoarece aceasta este rădăcina fluxului. Apoi, pentru fiecare State (albastru), adăugăm o etichetă S#, pentru fiecare Acțiune (verde), adăugăm o etichetă A# și, în sfârșit, pentru fiecare Condiție (cian), adăugăm o etichetă C#. Fiecare etichetă trebuie să fie unică. Ajungem cu următoarele:

Pentru a urmări numărul pe care l-ați folosit ultima dată – pentru că pe măsură ce produsul crește, încercarea de a găsi cel mai mare număr poate fi o provocare – îl stochez în subiectul rădăcină al fluxului, ca mai jos:

Acum ajungem la partea de creare a cazurilor de testare. Ne vom concentra asupra rezultatelor așteptate, care este probabil cea mai importantă informație dintr-un caz de testare și parte a criteriilor de acceptare a caracteristicii. Voi adăuga un titlu pentru fiecare secțiune sau test și apoi voi enumera rezultatele așteptate sub acesta. Voi face acest lucru doar pentru un subset pentru a menține acest articol concis:

Apoi, fereastra de autentificare:

Apoi, acțiunea de conectare:

Chiar prinde contur. Observați testele de limită și de securitate adăugate. Puteți intitula aceasta oricum doriți, oricare dintre acestea este mai ușor de etichetat pentru dvs. Uneori etichet titlul cu un tip de test, cum ar fi Security – JS Inject – Email Field, apoi listez rezultatele așteptate mai jos.

În majoritatea echipelor, cerințele în schimbare este o problemă de menținut. Nu mai. Să presupunem că tocmai am aflat că toți utilizatorii debutanți trebuie să li se prezinte fereastra Ts și Cs și trebuie să accepte înainte de a trece la tabloul de bord - nicio problemă. Putem adăuga starea și acțiunile relativ ușor, ca mai jos:

Vedem acum impactul adăugării unui nou stat. Rețineți că numerotarea poate fi ciudată la început, dar atâta timp cât ne amintim, numerele sunt doar pentru a identifica în mod unic fiecare actor, la fel ca o cheie primară dintr-o bază de date. Nu uitați să vă actualizați notele „Ultima utilizare” pentru a ține evidența numerelor pe care le utilizați.

Crearea cazurilor de testare din flux

După toate aceste progrese, ajungem acum la partea mai ușoară: crearea unui caz de testare. Permiteți-mi să subliniez câteva puncte importante. Avem etichete pentru fiecare actor, avem titluri pentru fiecare test și ne așteptam la rezultate pentru fiecare test, cu condiții încorporate ca parte a fluxului nostru. Asta sună ca rețeta unui caz de testare, nu ești de acord?

Tot ce facem acum este să copiem și să lipim ceea ce este în fluxul nostru în orice instrument de gestionare a cazurilor de testare, site Confluence sau document Excel pe care doriți. Încă folosesc vechiul Excel de încredere. Păstrez o evidență a tuturor cazurilor mele de testare într-un fișier numit „Baseline” - foarte original. Odată ce am terminat de copiere și lipire, ajung cu următoarele:

Simțiți-vă liber să adăugați coloane pentru tipurile de teste, starea testului și configurațiile de testare, după cum este necesar. Condițiile pot fi mai bine plasate înaintea acțiunii „Conectați-vă”, cu toate acestea, nu există o modalitate corectă sau greșită de a o face, depinde de preferințele personale și de modul în care vă organizați.

Sunt câteva lucruri de subliniat. Una este că am îmbinat celule care împărtășesc aceleași informații - nu este nevoie să copiați și lipiți în mod repetat, pierdeți timp și este mai dificil de întreținut. Un alt element sunt Pașii. Veți observa că două dintre teste au pași care încorporează numerele de stat și de acțiune. Acesta poate fi folosit atunci când aveți fluxul ca parte a SDLC în echipa dvs. Toate părțile interesate contribuie apoi la flux prin furnizarea de informații, machete, ridicarea riscurilor etc. Aceasta înseamnă că, prin indicarea numerelor fluxului, oricine din echipă va ști ce să facă, iar dacă există un nou membru al echipei, este la fel de ușor. ca „urmează traseul, face referire la notițe”.

Acest lucru ajută și la automatizare. Puteți da fiecărui pas sau acțiune o referință unică. Prin crearea unui pachet de automatizare care este structurat ca fluxul dvs., veți descoperi că cadrul de automatizare pe care îl puteți construi are potențialul de a fi foarte robust, modular și compatibil în întreaga aplicație. Acesta va folosi obiecte de paginare la o scară mai mare, ceea ce va reduce timpul de întreținere și vă va permite să schimbați funcțiile de testare cu altele noi.

Fluxul poate fi singura sursă de adevăr pentru toată documentația produsului, inclusiv specificațiile tehnice, specificațiile funcționale, cazurile de testare, tranziția de stare, fluxurile de date etc.

Abordarea planului de testare simplificat

Deci, ce zici de planurile de testare?, trebuie să te gândești. Acest lucru este simplu. Un plan de testare conține secțiuni precum:

1. Introducere și domeniul de aplicare
2. Elemente de testare
3. Caracteristici de testat
4. Caracteristici care nu trebuie testate
5. Ipoteze
6. Criterii de intrare
7. Criterii de ieșire
8. WBS
9. Riscuri
10. Cerințe de mediu

Introducerea și domeniul de aplicare vor fi povestea JIRA sau orice sarcină sau poveste dintr-un alt instrument. Elementele de testare sunt pur și simplu versiunile software sau numerele de comitere desfășurate în prezent în mediul dvs., pe care le puteți conecta la biletul JIRA sau la rularea de testare, fie pe Confluence, fie pe instrumentul de gestionare a testelor.

Caracteristicile care trebuie testate și Caracteristicile care nu trebuie testate sunt de fapt cazurile dvs. de testare. Cazurile de testare alese pentru a fi executate pentru această poveste JIRA sunt „Funcții de testat”, iar orice nu este listat este „Funcții care nu trebuie testate”. Pur și simplu, enumerați statele și acțiunile pe care le veți testa pe biletul de poveste.

Ipotezele, riscurile și chiar cerințele de mediu pot fi compilate într-un document sau adăugate la comentariile despre JIRA, uneori chiar plasate pe Confluence și legate de poveste.

Un WBS este o estimare pe care o atribui poveștii în termeni de puncte de poveste sau de ore, în funcție de proiectul tău. Criteriile de intrare și de ieșire vor face deja parte din poveste.

Dacă doriți să fiți aproape de planurile de testare „tradiționale”, puteți cere dezvoltatorului sau altor părți interesate să comenteze povestea cu Da sau Nu pentru a vedea dacă sunt de acord cu planul QA sau nu. Din punct de vedere tehnic, aceasta servește drept semnătură digitală. Toate acestea pot fi incluse destul de ușor în procesul de QA și vă pot ajuta să vă simplificați documentația QA.

Ce am învățat?

Fluxul de utilizatori cu abordarea de mai sus și planurile de testare simplificate pentru a utiliza instrumentele disponibile astăzi ne vor ajuta să reducem munca repetitivă și să ajute QA să obțină un timp de răspuns mai rapid fără a sacrifica calitatea.

Această abordare a fost esențială în a mă ghida să rămân organizat, să acopăr fiecare bază și să construiesc documentația pe care întreaga echipă o înțelege. În Agile, acest lucru va fi într-adevăr util, iar cea mai bună parte este că încă respectăm una dintre abordările Agile: „Simplificați documentația”.

Sper din tot sufletul că informațiile au fost de ajutor. Totul depinde de tine ca cititor. Acesta nu este un set concret de reguli de urmat, acestea sunt doar linii directoare pentru a vă oferi idei pentru a vă crește și a vă îmbunătăți eficiența. Nicio tehnică nu se va potrivi fiecărui proiect, echipă sau produs, dar poate deschide calea pentru o altă idee inovatoare.