În acest articol, se vor expune câteva dintre lucrurile esențiale, de care avem nevoie când încercăm să punem bazele unei echipe de QA care să fie omogenă, performantă, scalabilă și durabilă. Cu siguranță, în realitate, e nevoie, probabil, de sute de acțiuni ca să atingem obiectivul descris mai sus. În următoarele rânduri, ne vom concentra pe analizarea acelor demersuri care sunt absolut esențiale pentru a avea succes.
Puternic ancorate în lessons learned specifice activității unui consultant contractor, aceste demersuri pe care le vom enumera în rândurile următoare, pot fi aplicate cu succes și în cazul echipelor create în cadrul firmelor de produs sau în contexte diferite de mediul outsourcing.
Nu cred că pot să subliniez cu adevărat, cât de important e acest prim pas. Înainte de a scrie primul test sau de a începe primul sprint, chiar și înainte de a angaja primul membru al echipei, e necesar să înțelegem care sunt așteptările clientului de la echipa pe care o construim.
Pentru a ajunge să avem un grad de înțelegere cât mai ridicat, e nevoie de comunicare. Toate întâlnirile premergătoare au rolul de a identifica atât nevoile pe termen scurt, cât și planurile de viitor. Aici e esențial să avem o abordare de consultant și să ținem minte că motivul principal pentru care clientul a venit înspre noi, e acela de a beneficia de experiența și de cunoștințele pe care le avem în domeniu.
Din primele întâlniri ar trebui să avem formată o idee destul de clară despre dimensiunea echipei pe care vrem să o construim, despre modul în care e alcătuită, despre cum vor arăta sprinturile și ciclul de release, și eventual un plan pentru următorul an, și așa mai departe.
Poate să fie tentant, în acest punct, să intrăm foarte mult în detalii, dar cel mai indicat este să nu o facem. Avem timp suficient în viitorul apropiat să ne ocupăm și de părțile care necesită un nivel mai mare de atenție.
Un aspect esențial și de luat în considerare e faptul că, în majoritatea cazurilor, niciodată nu vom putea construi o echipa perfectă și cu dimensiunea și alcătuirea pe care noi le considerăm ideale. De foarte multe ori, e posibil să fie nevoie să învățăm să ne descurcăm cu echipe de dimensiuni mai mici decât ceea ce considerăm a fi minimul necesar. Aceasta e o realitate de care ne vom lovi în mod repetat. Cu cât învățăm să ne adaptăm mai repede la această stare de fapt și încercăm să găsim soluții creative de a ieși din impas, cu atât ne vom consuma mai puțin (nervii și energia).
Când vine vorba de componența echipei, cea mai importantă regulă e să ne ferim de a cădea în extreme. O echipă formată doar din oameni seniori, de exemplu, poate părea o idee excelentă pe hârtie. În realitate, când avem o echipă formată preponderent din oameni cu experiență, profesioniști, motivați și competitivi, tensiunile nu vor întârzia să apară. Cu atât mai mult cu cât, toți își vor dori să continue să avanseze în carieră și, așa cum știm cu toții, cu cât ne apropiem de vârful piramidei, locurile sunt tot mai puține.
Cealaltă extremă e reprezentată de o echipă cu foarte mulți juniori. Aceștia, deși bine intenționați, nu au cunoștințele și experiența necesară pentru a putea livra un volum mare de muncă într-un timp scurt. Pe lângă aceste aspecte, team leadului echipei respective îi va fi foarte dificil să delege sarcini și să se ocupe de partea de management a echipei, pentru că va fi tot timpul prins cu explicații și demonstrații pentru cei din echipă.
Era o perioadă când încercam să mă ghidez după un raport de 1:2:1 între juniori, middle și seniori. Cu timpul, însă, vom învăța că nu există un raport ideal și că fiecare echipă trebuie formată în funcție de necesitățile proiectului.
Aici nu e vorba de a crea o listă de proceduri pentru fiecare activitate pe care o poate face un membru al echipei. Mai degrabă, trebuie să ne concentrăm să definim niște procese care să ne ajute să avem control și vizibilitate asupra celor doi factori importanți - proiectul și echipa (nu neapărat în ordinea asta).
În cazul proiectului, în special dacă vorbim despre unul care implică o echipă formată din contractori, avem nevoie de vizibilitate și traceability. Ca să obținem aceasta, toți membri echipei trebuie să fie de acord să abordeze comunicarea într-un mod unitar, atunci când se trimit e-mailuri, când se documentează întâlnirile cu clientul sau când se arhivează totul. Ținând cont că informația înseamnă putere, cu cât avem mai mult acces la informație clară și de calitate, cu atât vom putea crea o echipă care va funcționa la standarde înalte.
Legat de echipă, trebuie să stabilim clar responsabilitățile fiecăruia, modul în care ne așteptăm să interacționeze între ei și cu clientul. Pe lângă aceasta, e bine să clarificăm de la început ce fel de metrici de performanță vrem să urmărim și să ne asigurăm că sunt comunicate și acceptate clar de toată lumea. După ce reușim să stabilim lucrurile de mai sus, putem să intrăm în detalii care țin de modul în care scriem și rulăm teste, cine și când participă în meetinguri cu clientul și tot așa.
Am făcut referire în paragraful anterior la întâlnirile cu clientul. Acestea nu sunt ceva nou, dar sunt un început bun (și necesar). În prezent, majoritatea companiilor la nivel global folosesc metodologii Agile sau derivate ale lor. Ceea ce diferă considerabil, este cât de mult Agile este folosit pentru fiecare proiect/client/companie în parte.
Dar este important să nu presupunem niciodată că Agile e un template pe care îl luăm și îl aplicăm și -- poof! -- ne rezolvă toate problemele. Din contră, implementarea fără cap, ne poate încurca extraordinar de mult. Așa că o etapă inițială e necesar să presupună o evaluare corectă și obiectivă a necesităților proiectului. Probabil anumite ceremonii standard -- daily meetings, user stories, kick-off meetings, retrospective meetings -- vor fi implementate by default. Cu toate acestea, nu vom avea nevoie de tot spectrul de activități pe care Agile îl oferă. Dacă nu avem nevoie să folosim User Stories, Points, Planning Poker, de exemplu, nu există niciunde o regulă care să ne oblige să le folosim.
Scopul principal al metodologiei Agile este să fie un proces care oferă proiectului agilitate și flexibilitate. Putem folosi exact acele metodologii si bune practici care aduc beneficii proiectului nostru și să le ignorăm pe restul.
Dacă ne înecăm echipa în standarde și bune practici, nu vor mai avea niciodată timp să chiar fie productivi.
Uneori, poate fi dificil să ne dăm seama de la început care e cel mai eficient mod în care ne structurăm testele, în funcție de parametrii specifici proiectului nostru. În ciuda acestui fapt, putem să folosim anumite abordări care ne pot ajuta să evităm instalarea unui haos general în doar câteva luni.
Majoritatea punctelor de mai jos pot părea destul de common sense, dar, eu, cel puțin, m-am lovit de probleme cauzate de omiterea fiecăruia dintre ele (în unele cazuri, chiar în mod repetat).
Putem să grupăm testele după anumite criterii comune -- “teste de sign in” sau “teste care verifică același feature”.
În interiorul unei suite de teste, putem să rafinăm și mai mult modul în care sunt organizate testele. În exemplul de mai sus -- “teste de sign in” -- putem să creăm secțiuni pentru teste de Sign Up, Sign with Facebook/Google, Forgot Password și așa mai departe. O structură detaliată ne va ajuta să găsim mult mai ușor ce avem nevoie.
Pe cât posibil, testele ar trebui să respecte principiul KISS -- Keep It Simple, Stupid -- dacă sunt ușor de scris, atunci sunt ușor de citit, executat și contribuim considerabil la creșterea eficienței.
Să nu uităm de automatizarea testelor. Dacă generăm scenarii de test care pot fi preluate ușor de echipa de automation și transformate în teste automate, vom obține rezultate mult mai bune, într-un timp mult mai scurt.
Testele din aceeași suită ar trebui să urmeze natural, în ordine, unul după altul. Aceasta înseamnă că, în măsura în care este posibil, al doilea test ar trebui să continue natural verificările din primul test, al treilea din al doilea, și tot așa. Cu cât putem obține un flow mai natural, cu atât vom putea rula mai multe teste, într-un timp mai scurt.
Lista de mai sus nu e exhaustivă -- are rolul de a sublinia ideea că e necesar să avem un plan și să ne gândim în avans la ce vrem să facem. Probabil nu sunt singurul care s-a găsit în situația în care pași relativ simpli, ca acei de mai sus, nu au fost respectați și au ajuns în contexte destul de dificil de clarificat.
Defectele, neconformitățile, bugurile sunt, practic, pâinea oricărei echipe de QA. Modul în care echipa e văzută de client și de alte echipe similare este determinată și de calitatea cu care se face această raportare. Deși contează și cantitatea până la un punct, este deosebit de neimportantă în comparație cu calitatea și modul în care se escaladează defectele găsite în aplicație. Să nu uităm, QA vine de la Quality Assurance, nu de la Quantity Assurance. Am întâlnit de nenumărate ori cazuri în care echipe de QA se străduiau să arate valoare printr-un număr mare de buguri create și, prinși fiind de acest curent, să rateze probleme destul de grave în proiectele lor.
Trebuie să ne asigurăm că ceea ce raportăm respectă aceleași standarde înalte de calitate pe care le aplicăm pe proiect în general. E esențial să putem găsi un echilibru între a da informație concisă, dar suficientă, complexă, dar nu complicată. Și cel mai important e să găsim aceste defecte la timp.
Ar trebui să investigăm un bug până reușim să oferim toate detaliile posibile -- pași de reproducere, atașamente -- poze, video-uri, loguri, date de test -- toate sunt importante și ar trebui să fie prezente (aproape) în orice raport. E de datoria echipei de QA să se asigure că echipele de Development au toate informațiile de care au nevoie ca să poată găsi fixuri la bug-urile pe care le descoperim.
Pe lângă defecte, majoritatea toolurilor oferă și posibilitatea de a crea alte tipuri de tichete. E, în general, un sfat bun să ne folosim de întreaga plajă de posibilități -- aceasta ne va ajuta să rămânem organizați și să putem oferi transparență și vizibilitate asupra lucrurilor pe care le facem.
Responsabilitatea echipei de QA e să poată oferi informații la timp, pe care se poate acționa și care sunt cât de precise posibil -- e important să nu uitam aceasta niciodată -- Accurate, Actionable and Timely Information.
Acestea se referă, în general, la stabilirea cât mai din timp a resurselor de care echipa de QA are nevoie ca să diminueze timpul pe care îl petrece așteptând să se întâmple ceva:
Proiectul ar beneficia de CI/CD? Dacă răspunsul e da, hai să vedem cum putem să implementăm aceasta.
Avem o aplicație dezvoltată pe modelul client-server? Atunci trebuie să investim în soluții de monitorizare și manipulare a fluxului de date (Charles, Fiddler, Wireshark etc.) .
Avem nevoie de un environment de test/staging care să ne permită să testăm în întregime noile funcționalități?
Avem o aplicație mobilă? Putem să obținem device-uri fizice sau ne limităm la simulatoare și emulatoare?
Desigur, cele expuse mai sus sunt doar câteva exemple. Ideea e că trebuie să ne gândim la întregul proces, să identificam punctele unde pot să apară bottleneckuri, și să încercam să optimizăm lucrurile înainte să fim obligați să o facem.
Nimeni nu poate să ruleze un proiect de unul singur. Ca Team Lead sau Project Manager sau orice alt rol am avea, avem nevoie de colaborarea tuturor departamentelor de suport când încercăm să creăm o echipă nouă.
Și e responsabilitatea noastră să știm ce avem nevoie și de la cine -- IT, HR, Recrutare, Administrativ și așa mai departe. Deși, ideal, nu ar trebui să ne ocupăm prea mult cu aspectele logistice care țin de onboardingul unei echipe noi, în realitate orice întârziere sau inconsistență în comunicare va ajunge tot pe capul nostru până la urmă.
Mă consider norocos să fac parte dintr-un proiect mare și care continuă să crească. În cadrul lui, avem mai multe echipe de QA, fiecare cu structura, metodele de lucru și provocările specifice. Aceasta înseamnă că am avut ocazia să văd cu ochii mei ce funcționează și ce nu. Am avut succese și eșecuri și, trecând prin toate, mi-am dat seama cât de important e să poți să te bazezi pe companie, colegi, mentori și comunități. Majoritatea celor cu mai multă experiență decât mine, au trecut prin provocări similare și am primit sfaturi deosebit de pertinente, care mi-au permis să am o abordare eficientă la problemele care, inevitabil, au apărut.
Managementul riscului e un lucru complicat și care poate foarte ușor să ducă la probleme, dacă nu e înțeles și aplicat corect. Fie că vorbim de riscuri de proiect, la nivel de echipă sau riscuri individuale, nu e o știință exactă. Oricine ar fi în poziția de a conduce și coordona echipa, trebuie să fie capabil să facă față situațiilor neprevăzute care pot ieși la iveală.
Deosebit de important aici e ca persoana care e responsabilă de identificarea, negocierea și eliminarea riscurilor să poată relaționa pe cât mai multe planuri cu echipa pe care o coordonează. Trebuie să fie capabilă să rezolve probleme, să înțeleagă de unde apar și să găsească soluții durabile și sustenabile.
Deși cele de mai sus sună destul de ușor de realizat, din experiența pe care am avut-o, managementul riscului e unul dintre subiectele cele mai greu de abordat și de soluționat.
Dacă până aici am reușit să bifăm toate punctele, înseamnă că plutim. Dar scopul nostru și al echipei noastre e să înaintăm, să creăm forward momentum, să creștem. Pentru aceasta, e important să putem să creăm valoare, să fim mai mult decât suma părților, să devenim indispensabili în proces. Aici intră în joc mindsetul de consultant pe care o echipă de outsourcing trebuie să îl aibă. Dacă arătăm că știm ce facem, că planurile noastre sunt solide, că suntem fully invested în direcția și viziunea pe care clientul și-o dorește, obținem în schimb încredere. Și dacă avem încredere, putem să obținem nu doar creștere, ci și expansiune orizontală în alte zone de business.
Ca o scurtă concluzie la tot ce-am scris mai sus – trebuie să identificăm ceea ce vrea clientul, să îi oferim ceea ce are nevoie (chiar dacă trebuie să îl convingem înainte), să planificăm cu acuratețe, să fim pregătiți pentru potențialele pericole și tot timpul să ne arătăm interesați de creștere și de obținerea de rezultate.
Super simple stuff, right?
de Ovidiu Mățan
de Ovidiu Mățan
