Competența în domeniul TestOps este acum o cerință de bază pentru inginerii QA, precum și capacitatea de a scrie teste automate. Acest lucru se datorează dezvoltării continue a CI/CD și numărului tot mai mare de ingineri QA care lucrează cu conducte (sau secvența de etape în CI/CD) și implementează propriile lor. Deci, de ce este CI/CD un instrument atât de grozav pentru controlul calității? Să aflăm.
Executarea automată a testelor
În zilele noastre, conductele CI / CD rulează teste automat ca una dintre funcțiile lor principale.
Configurația pipeline poate fi atribuită DevOps. Dar atunci vom fi departe de a folosi a doua funcție a CI/CD: controlul calității, sau mai precis, „porțile calității”.
Controlul calității folosind porți de calitate
Dar ce sunt porțile de calitate? Să presupunem că codul produsului este ca un castel. În fiecare zi, dezvoltatorii scriu cod nou – care ar putea slăbi fundațiile castelului nostru sau chiar să facă găuri în el, dacă avem cu adevărat ghinion. Scopul unui inginer QA este de a testa fiecare caracteristică și de a reduce probabilitatea ca erorile să-și găsească drumul în codul produsului. Lipsa automatizării procesului QA ar putea face ca inginerii QA să piardă somnul, deoarece nu există nimeni care să supravegheze toate diferitele valori – mai ales în momente periculoase, cum ar fi vineri serile când toată lumea vrea să plece de la serviciu și se grăbește să termine totul. O fuziune nefastă în acel moment poate cauza o mulțime de probleme pe drum.
Această problemă poate fi rezolvată prin integrarea controalelor de calitate.
Fiecare cec tratează o valoare importantă diferită. Dacă codul nu trece de verificare, porțile se închid și caracteristica nu are voie să intre. O caracteristică va fi îmbinată în produs numai atunci când trece toate verificările și eventualele erori au fost prevenite.
Ce verificări de calitate pot fi incluse în CI/CD?
Trebuie să alcătuim o listă de verificări pentru a ne asigura că procesul este cât mai automatizat posibil. Ele pot fi secvențiate într-o ordine de „eșec mai întâi”. O caracteristică trebuie să treacă toate verificările pentru a trece cu succes prin conductă. Verificările inițiale sunt cele care se asigură că aplicația este capabilă să funcționeze: construirea, verificarea stilului de cod și analiza statică.
„Build” vorbește de la sine: dacă aplicația nu poate fi construită, funcția nu progresează. Este important să includeți o verificare a stilului codului în conducta CI/CD pentru a vă asigura că codul îndeplinește cerințele unificate, deoarece acest lucru vă permite să evitați pierderea timpului cu acest tip de eroare în timpul revizuirii codului.
Analiza statică este un instrument extrem de important pentru evaluarea calității codului. Poate evidenția un număr mare de erori critice care duc la erori.
Continuăm apoi cu verificările din etapa a doua: teste unitare cu analiză de acoperire și control al calității acoperirii, precum și teste de integrare și sisteme. În continuare, examinăm rapoarte detaliate ale rezultatelor pentru a ne asigura că nimic nu a fost ratat. În această etapă, putem efectua, de asemenea, o serie de teste nefuncționale pentru a verifica performanța, confortul și securitatea, precum și teste de captură de ecran.
Atunci când dezvoltăm, trebuie să acordăm atenție la două cerințe concurente:
Exemple de instrumente de încorporat în verificările calității
Evidențierea stilului codului
Un stil de cod este un set de reguli care ar trebui urmate în fiecare linie de cod dintr-un proiect, de la reguli de aliniere la reguli precum „nu utilizați niciodată variabile globale”.
S-ar putea să vă întrebați ce legătură are stilul cu testerii. Răspunsul este mult, de fapt. O verificare a stilului oferă mai multe beneficii pentru experții QA, ca să nu mai vorbim de restul echipei:
Un stil unificat îi ajută pe dezvoltatori să lucreze cu codul și le oferă mai mult timp pentru a implementa funcții noi și a remedia erorile.
Un stil unificat vă permite să renunțați la verificările manuale ale codului și să utilizați un instrument CI / CD pentru a rula verificările.
Companiile mari au de obicei propriile ghiduri de stil care pot fi folosite ca exemple. De exemplu, Airbnb are un ghid de stil JavaScript, iar Google are o serie de ghiduri. Poți chiar să-l scrii pe al tău.
Alegerea instrumentelor pentru verificarea codului depinde de limbă. Puteți găsi un instrument potrivit pe GitHub sau puteți afla ce instrumente folosesc alte echipe. Linters folosesc corpuri de reguli și evidențiază coduri care nu le respectă. Câteva exemple includ ktlint pentru Kotlin, checkstyle pentru Java, eslint pentru JavaScript.
Analiza codului static
Analiza codului static este o metodă de depanare prin examinarea codului sursă fără a executa un program. Există multe analizoare de cod static diferite pe piață. Vom arunca o privire acum la o platformă pe care o dezvoltăm noi înșine – Qodana. Avantajul major al acestui analizor de cod este că include o serie de inspecții care ne sunt disponibile în mediile de dezvoltare JetBrains atunci când scriem cod.
Mulți dintre voi probabil utilizați o abordare bazată pe IDE, în care IDE vă ajută să scrieți cod și subliniază diverse erori, cum ar fi utilizarea suboptimă a codului, NullPointerExceptions, duplicate și așa mai departe.
Dar, din păcate, nu poți fi niciodată sigur că toate problemele critice găsite de IDE au fost rezolvate înainte de comitere. O modalitate prin care puteți garanta că toate problemele vor fi rezolvate este prin încorporarea Qodana în conducta CI/CD. Dacă nu puteți remedia totul dintr-o dată, puteți selecta problemele critice, le puteți adăuga la linia de bază și, treptat, puteți rezolva datoria tehnică. Acest lucru vă permite să evitați încetinirea procesului de dezvoltare, ținând în același timp sub control problemele care au fost găsite.
Acoperire de testare
Acoperirea codului este o valoare care vă ajută să înțelegeți cât de bine a fost acoperit codul dvs. de teste (în general, teste unitare).
Aici trebuie să definiți procentul minim de acoperire pe care doriți să îl susțineți. Codul nu va putea intra în vigoare până când nu va fi acoperit suficient de teste. Procentul minim este stabilit empiric, dar ar trebui să vă amintiți că chiar și o acoperire de 100% poate să nu vă salveze complet codul de erori. Potrivit acestui articol de la Atlassian, 80% este o cifră bună spre care să ținești.
Sunt disponibile diferite analizoare de acoperire pentru diferite limbi, cum ar fi Jacoco pentru Java, Istanbul pentru JavaScript sau Coverage.py pentru Python. Puteți să construiți toate aceste analizoare în conducta dvs. CI/CD și să urmăriți cu ușurință valorile.
Modelarea procesului de eliberare
Pe lângă rularea automată a testelor și asigurarea faptului că sunt îndeplinite anumite cerințe de calitate a codului, CI/CD le permite testatorilor să organizeze procesul de lansare.
Procesul de lansare poate fi complex și poate depinde de o mulțime de acțiuni manuale diferite. Este adesea un proces complet manual: artefactul este creat de un dezvoltator, apoi transmis testatorilor pentru verificări și, în sfârșit, ajunge la persoana care știe cum să-l lanseze pentru lansare. Încă o dată, există o mulțime de potențiale puncte de sufocare aici. De exemplu, unul dintre acești oameni s-ar putea îmbolnăvi sau s-ar putea duce în vacanță.
Un proces eficient de lansare va arăta diferit pentru fiecare echipă, dar va include, în general, următorii pași:
Orice sistem CI/CD vă permite să configurați acest tip de proces. Procesul ar trebui să fie convenabil pentru întreaga echipă, inclusiv pentru echipa de testare.
Având în vedere factorii menționați mai sus, credem că următoarele reguli de bază vor ajuta la asigurarea unui proces de lansare ușor și eficient:
De asemenea, dorim să vă reamintim că, dacă valorile de calitate nu sunt controlate automat și nu afectează nimic, acestea sunt inutile, deoarece nu există nicio modalitate de a garanta că aceste valori vor fi respectate.
Implementați conducte, automatizați procesele și utilizați analiza statică a codului!
Etiam magna arcu, ullamcorper ut pulvinar et, ornare sit amet ligula. Aliquam vitae bibendum lorem. Cras id dui lectus. Pellentesque nec felis tristique urna lacinia sollicitudin ac ac ex. Maecenas mattis faucibus condimentum. Curabitur imperdiet felis at est posuere bibendum. Sed quis nulla tellus.
63739 street lorem ipsum City, Country
+12 (0) 345 678 9
info@company.com