Ce reprezinta QAOps in IT?

Munca in industria IT se bazeaza cu regularitate pe existenta anumitor metodologii de lucru si paradigme de organizare a proceselor din cadrul echipelor si companiilor. Acestea vin sa explice, sa ajute si sa descalceasca sirul de operatiuni si responsabilitati pe care inginerii software si nu numai le au, cine intervine in situatia X, ce sa intampla dupa si asa mai departe.

Metodologiile de lucru au aparut cu scopul de a aduce ordine in executia proiectelor, de aceea e bine ca ele sa fie cunoscute, macar la nivel general de cei implicati. Desigur, nu intotdeauna ele se respecta ca la manual, dar ideea este sa existe totusi o organizare. Una dintre aceste paradigme care s-a dezvoltat in ultimii ani este cea numita QAOps.

O prima metodologie: DevOps

Pentru a intelege mai bine ce vom discuta in continuarea articolului, e bine sa oferim un alt exemplu, poate mult mai cunoscut, de astfel de metodologie care s-a dezvoltat in IT in ultimii 15 ani si care este astazi prezenta in cea mai mare parte a companiilor de profil: DevOps.

In cadrul procesului de operatiuni din IT, exista nu demult o ruptura intre zona de Development (unde se scria codul pentru viitoarea aplicatie) si partea de Operations (deployerea aplicatiei, punerea ei in functiune pentru clienti). Aceasta ruptura se referea la faptul ca nu exista o coordonare explicita intre cele 2 paliere, iar daca apareau probleme, acestea pur si simplu erau ignorate ori pasate ca un cartof fierbinte de la unii la altii, iar proiectul si clientii aveau de suferit.

Asa a aparut DevOps, o paradigma de lucru care sa umple golul dintre cele 2 zone, sa creeze o punte prin care anumiti developeri sa poata sa intervina in procesul de operatiuni cand e nevoie, astfel incat sa existe o comunicare permanenta intre cei care dezvolta codul si cei care il pun „in miscare”. Sigur, acesta e doar un exemplu, si am mentionat foarte succint ce este, cu scopul de a trece la subiectul nostru principal.

QAOps, o noua paradigma de lucru

Daca DevOps, dupa cum rezulta din numele sau (Development Operations) se referea la integrarea programatorilor in circuitul operatiunilor de deployment, QAOps vizeaza integrarea inginerilor QA in procesul de CI / CD (Continuous Integration / Continuous Delivery).

Despre procesul de CI / CD am mai discutat in trecut aici pe blog. Integrarea continua, prima componenta fundamentala a procesului general de CI / CD, este acea metoda prin care diversele schimbari sau imbunatatiri ale codului (commit-uri in terminologia Git), sunt integrate direct si automat in fisierul central al proiectului (central repository ori Master branch).

Dupa ce codul cu imbunatatiri a trecut prin CI, a fost testat si pregatit, acesta ajunge sa fie integrat intr-un repository de pe GitHub, fiind deci testat automat in vederea asigurarii calitatii acestuia (in special pentru a preveni bug-urile de regresie). Ulterior, de pe GitHub sau de oriunde este stocat codul sursa al proiectului, se poate trece oricand la partea de deploy, adica de lansare a proiectului intr-un mediu de productie, la clientii si utilizatorii finali.

Astfel, acest proces este completat prin paradigma QAOps cu includerea inginerilor QA care sa testeze in paralel si continuu noul build al aplicatiei (Release Candidate intr-o denumire mai formala), pentru un flow cat mai fluid din punct de vedere tehnic. Practic, testerii sunt integrati drept o componenta distincta si la fel de importanta in acest proces de integrare si lansare continua precum laturile de Development si Operatiuni, nemaifiind o veriga secundara, optionala.

Acest mod de lucru numit QAOps prezinta 3 etape principale. Prima etapa se numeste Trigger. In aceasta etapa de inceput sunt gandite si scrise testele care sunt apoi integrate in CI / CD pipeline, care au scopul de a verifica in mod tintit componentele cele mai importante ale aplicatiei, ca sa nu se piarda timp cu alte test cases mai putin relevante.

A doua etapa, denumita Execute sau Implement, incepe atunci cand build-ul aplicatiei este pregatit si incepe sa fie deployat, in paralel fiind pornite si testele asupra lui pentru a putea verifica in paralel daca exista probleme tehnice de orice natura, care sa fie raportate din timp si rezolvate cat mai repede.

Iar a treia etapa dupa executia deploy-ului si a rularii testelor este cea de Report. Aici echipa de QA alcatuieste un rezumat care sa cuprinda detaliile principale despre verificarea si validarea build-ului aplicatiei ce tocmai a fost lansata. Acest raport cuprinde bug-urile descoperite (daca sunt), sugestii de imbunatatire si evaluarea scalabilitatii proiectului in general, de care sa se tina cont in viitor la urmatorul proces de CI / CD.

QAOps nu trebuie privita ca un mod individual de a executa anumite procese in IT, ci dimpotriva, este o maniera integrata care coaguleaza simultan munca celor trei ramuri tehnice principale, Development – Quality Assurance – Operations, si care se inscrie in mai largul ciclu de SDLC (Software Development Life Cycle).

Importanta pe care o are QAOps

Desi poate parea un proces suplimentar in tot angrenajul de mecanisme deja existente in industria software, care doar adauga mai multa ”birocratie”, de fapt QAOps a aparut dintr-o nevoie cat se poate de stringenta de a imbunatati mecanismul de deploy al produselor software si a le asigura o calitate cat mai buna, intr-un ritm sustinut, care sa conduca in final la rezolvarea cat mai timpurie a defectelor si la satisfacerea cerintelor de business.

Importanta paradigmei QAOps este una fundamentala deoarece prezinta mai multe avantaje, toate sustinand un principiu extrem de evident pentru dezvoltarea software, si anume intarirea calitatii produselor. Din aceasta perspectiva, QAOps asigura prin diferitele sale modele de aplicare o mai buna calitate a aplicatiilor ce ulterior ajung la clienti, avand cat mai putine defecte si o experienta mult imbunatatita.

Acest lucru se datoreaza si faptului ca metodologia QAOps ajuta la reducerea timpilor de asteptare si eficientizarea muncii: bug-urile sunt descoperite cat mai din timp, corectarea lor se face rapid, si exista resursele de timp si de bani pentru a finisa acele detalii care poate nu sunt cruciale, dar care fac diferenta pentru experienta de utilizare a clientilor care ulterior sustin business-ul respectiv.

Toate aceste avantaje ale QAOps conduc si spre un stil de lucru general bine organizat al echipelor de development, testare si operatiuni, existand o mai buna coordonare intre ele, fiecare isi stie rolul si scopul, iar comunicarea este mult imbunatatita in toate sensurile.

Concluzii

In incheiere, modelul de lucru QAOps este unul care desi a aparut relativ recent, vine sa rezolve anumite probleme destul de vechi specifice flow-ului de lucru din IT. Acesta integreaza mult mai concret si intr-o formula unitara munca inginerilor QA in cadrul procesului de CI / CD, asigurand o testare paralela si o eficientizare mai mare in descoperirea eventualelor probleme.

Surse consultate si suplimentare

Informatii generale despre ce reprezinta QAOps, cum se aplica si etapele sale in articole de pe BrowserStack, Software Testing Material si LinkedIn.

Bune practici legate de QAOps

Avantaje, provocari si ROI (return of investment) ale QAOps