General vorbind, QA (asigurarea calităţii) apare în peisaj după ce dezvoltarea este finalizată. Apoi, echipa QA testează funcţionalităţile implementate și găsește defecte la nivelul aplicaţiei. Astfel crește calitatea aplicaţiei dezvoltate. Este oare aceasta cea mai bună abordare? Reduce aceasta costurile? Răspunsul este "Nu". Atunci care ar fi metodele și procesele de urmat prin care un QA aduce cea mai bună calitate?
Dacă același defect ar fi fost identificat în etapa de stabilire a cerinţelor/specificaţiilor (requirements), costurile ar fi fost drastic reduse iar valoarea ar fi fost mai mare. Experienţa ne arată că tehnicile de testare proactive ar putea preveni multe greșeli în faza de dezvoltare și ar reduce timpul necesar creării și executării testelor, din moment ce un specialist QA este deja familiarizat cu toate cerinţele și problemele ascunse. Iată câteva exemple de schimbări la nivel de proces ce pot facilita tranziţia de la testarea reactivă la testarea proactivă:
Înţelegerea informaţiei de business este cel mai important aspect pe care toată echipa, inclusiv echipa de QA, ar trebui să îl înveţe.
Treceţi în revistă cerinţele/specificaţiile.
Verificaţi orice deficienţă ce poate afecta funcţionalităţile vechi (deja implementate).
Creaţi și revizuiţi testele înaintea etapei de dezvoltare.
Validaţi cât de bine sunt acoperite specificaţiile.
A înţelege proiectul este cheia dezvoltării eficiente: echipa va lucra mai rapid dacă are documentaţie și dacă poate comunica eficient cu product ownerul. De asemenea, uneori, specificaţiile de business nu conţin informaţii evidente pentru un product owner, ceea ce face ca proiectul să fie deschis interpretării de către echipele de dezvoltare și QA. Organizarea de sesiuni de transfer de cunoștinţe cu product ownerul sau cu experţi în domeniu, transformarea specificaţiilor de business în specificaţii tehnice va aduce beneficii pe termen lung. Echipa de teste trebuie să cunoască produsul integral pentru calitate maximă. A înţelege proiectul din punct de vedere funcţional este cheia succesului echipei.
Etapa de revizuire este o modalitate de a obţine o perspectivă nouă asupra problemelor sau de a identifica soluţii. Această etapă permite identificarea timpurie a greșelilor. Pot exista mai multe stagii de revizuire (QA manager -> echipa -> product owner) sau o singură revizuire ce implică echipa în totalitate sau în parte (în funcţie de mărimea echipei și de distribuţia responsabilităţilor). Aceasta va permite tuturor să fie pe aceeași lungime de undă, așa cum va arăta programatorilor care sunt așteptările echipei de QA referitor la dezvoltare.
Revizuirea atentă a specificaţiilor dă ocazia testerului de a găsi problemele potenţiale pe baza cunoștinţelor anterioare pe care le deţine despre produs. Problemele identificate în această etapă vor reduce semnificativ costurile și vor aduce valoare.
După cum am menţionat anterior, unele informaţii se pot pierde în timpul conversiunii specificaţiilor de business în specificaţii tehnice. În acest sens, sunt necesare clarificări realizate de echipa de QA. De obicei, există trei moduri pentru a solicita clarificări: email, ședinţe lungi sau monitorizarea fluxului de informaţie/documentaţie/progres printr-un instrument de gestiune. Ultima abordare este cea mai eficientă. Product ownerul și programatorii pot veni din domenii diferite și pot vorbi limbi diferite. Pregătirea subiectelor problematice pentru discuţii în cadrul unui instrument de monitorizare a sarcinilor de lucru va permite părţilor implicate să pregătească și să desfășoare ședinţe eficiente.
Adăugarea de funcţionalităţi noi aduce cu sine riscul de a se defecta ceva existent, chiar și în proiectele ce conţin multe teste. Este dificil, dacă nu imposibil, să prezicem astfel de probleme:
Echipa ar trebui să înţeleagă funcţionalităţile proiectului și dependenţele dintre module.
Dacă proiectul este parte a unui proces de infrastructură/business, echipa ar trebui să înţeleagă impactul pe care fiecare schimbare îl are asupra aplicaţiei ( de exemplu, schimbarea cerinţelor/a formatului de răspuns, schimbarea formatului de export de date, schimbări în baza de date, dacă aceasta este comună mai multor aplicaţii etc.).
Numărul defectelor găsite în faza de regresie poate scădea, dacă se documentează toate linkurile de integrare și toate problemele tipice în cadrul unei liste scurte.
Echipa de teste poate petrece mult timp pentru a asigura acoperirea totală a funcţionalităţilor, ceea ce va avea un impact imens asupra echipei de dezvoltare, dar și asupra echipei de teste ce va identifica problemele posibile. Echipa de teste trebuie să ia în calcul și aspectele non-funcţionale precum: motoarele de căutare, aparatura, sistemele de operare, dimensiunea ecranului etc. . În ceea ce privește testarea API, se vor lua în calcul: testarea backend, testarea middle ware testing, etc.
Stabilirea defectelor cu un instrument de gestionare a acestora ajută echipa la monitorizarea și prioritizarea reparării lor. Triarea defectelor va permite clasificarea lor în funcţie de gradul de severitate. Mai mult, gestionarea defectelor ajută la măsurarea diferitelor aspecte ale muncii: volum, viteză, calitate, fiabilitate etc.
Nu există o "pastilă magică" pentru ca procesul QA să fie 100% eficient; toate instrucţiunile necesită ajustări specifice proiectului. Contează dinamica echipei și implicarea din partea PO în procesul de dezvoltare. Respectarea acestor instrucţiuni în spiritul Agile poate fi mai benefică decât respectarea unui proces cu orice preţ.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
