QA cod sursă: nu mai este doar pentru dezvoltatori

În urmă cu douăzeci de ani, când lucram în industria auto, directorul unei fabrici spunea adesea: „Avem o zi pentru a construi o mașină, dar clientul nostru are o viață întreagă pentru a o inspecta”. Calitatea a fost de cea mai mare importanță. Într-adevăr, în sectoarele mai mature, cum ar fi industria auto și cea a construcțiilor, asigurarea calității este un aspect cheie care este integrat în mod sistematic în procesul de dezvoltare a produsului. Deși acest lucru este determinat cu siguranță de presiunea din partea companiilor de asigurări, este, de asemenea, dictat – după cum a remarcat directorul de fabrică – de durata de viață a produsului rezultat.

Când vine vorba de software, totuși, ciclurile de viață mai scurte și actualizările continue înseamnă că integritatea codului sursă este adesea trecută cu vederea în favoarea noilor funcții, funcționalități sofisticate și viteza de lansare pe piață. Managerii de produs deseori prioritizează asigurarea calității codului sursă sau lasă în seama dezvoltatorilor să se ocupe, în ciuda faptului că este unul dintre factorii cei mai critici în determinarea destinului unui produs. Pentru managerii de produs preocupați de construirea unei baze solide pentru dezvoltarea produsului și eliminarea riscurilor, definirea și implementarea unei evaluări sistematice a calității codului sursă este esențială.

Definirea „calității”

Înainte de a explora modalitățile de evaluare și implementare adecvată a unui proces de asigurare a calității codului sursă, este important să se determine ce înseamnă „calitate” în contextul dezvoltării software. Aceasta este o problemă complexă și cu mai multe fațete, dar de dragul simplității, putem spune că calitatea se referă la codul sursă care susține propunerea de valoare a unui produs fără a compromite satisfacția consumatorilor sau a pune în pericol modelul de afaceri al companiei de dezvoltare.

Cu alte cuvinte, codul sursă de calitate implementează cu acuratețe specificațiile funcționale ale produsului, satisface cerințele nefuncționale, asigură satisfacția consumatorilor, minimizează riscurile de securitate și legale și poate fi întreținut și extins la prețuri accesibile.

Având în vedere cât de larg și de rapid este distribuit software-ul, impactul defectelor software poate fi semnificativ. Probleme precum bug-urile și complexitatea codului pot afecta rezultatul unei companii, împiedicând adoptarea produsului și crescând costurile de gestionare a activelor software (SAM), în timp ce încălcările de securitate și încălcările conformității licențelor pot afecta reputația companiei și pot ridica preocupări legale. Chiar și atunci când defectele software-ului nu au rezultate catastrofale, ele au un cost incontestabil. Într-un raport din 2018, compania de software Tricentis a constatat că 606 defecțiuni de software de la 314 companii au reprezentat pierderi de venituri de 1,7 trilioane de dolari în anul precedent. Într-un raport recent lansat în 2020, CISQ a estimat costul software-ului de proastă calitate în SUA la 2,08 trilioane de dolari, cu alte costuri estimate la 1,31 trilioane de dolari suportate prin datoria tehnică. Aceste cifre ar putea fi atenuate prin intervenții anterioare; costul mediu de rezolvare a unei probleme în timpul proiectării produsului este semnificativ mai mic decât rezolvarea aceleiași probleme în timpul testării, care este, la rândul său, exponențial mai mic decât rezolvarea problemei după implementare.

Manipularea cartofului fierbinte

În ciuda riscurilor, asigurarea calității în dezvoltarea de software este tratată fragmentar și se caracterizează printr-o abordare reactivă mai degrabă decât cea proactivă adoptată în alte industrii. Proprietatea calității codului sursă este contestată, când ar trebui privită ca responsabilitate colectivă a diferitelor funcții. Managerii de produs trebuie să vadă calitatea ca pe o caracteristică de impact, mai degrabă decât ca pe un cost general, directorii ar trebui să acorde atenție stării calității și să investească în ea, iar funcțiile de inginerie ar trebui să reziste la tratarea curățării codului ca pe un „cartof fierbinte”.

Aceste provocări de delegare sunt agravate de faptul că metodologiile și instrumentele existente nu reușesc să abordeze problema calității codului în ansamblu. Utilizarea metodologiilor de integrare continuă/livrare continuă reduce impactul codului de calitate scăzută, dar dacă CI/CD nu se bazează pe o analiză a calității amănunțită și holistică, acesta nu poate anticipa și aborda în mod eficient majoritatea pericolelor. Echipele responsabile cu testarea QA, securitatea aplicațiilor și conformitatea cu licența lucrează în siloz folosind instrumente care au fost concepute pentru a rezolva doar o parte a problemei și pentru a evalua doar unele dintre cerințele nefuncționale sau funcționale.

Luând în considerare rolul managerului de produs

Calitatea codului sursă joacă un rol în numeroase dileme cu care se confruntă un manager de produs în timpul proiectării produsului și pe tot parcursul ciclului de viață al dezvoltării software. Datoria tehnică este grea. Este mai greu și mai costisitor să adăugați și să modificați caracteristici pe o bază de cod de calitate scăzută, iar susținerea complexității codului existent necesită investiții semnificative de timp și resurse care altfel ar putea fi cheltuite pentru dezvoltarea de noi produse. Pe măsură ce managerii de produs echilibrează continuu riscul cu viteza de lansare pe piață, ei trebuie să ia în considerare întrebări precum:

• Ar trebui să folosesc o bibliotecă OSS (software open source) sau să construiesc funcționalități de la zero? Ce licențe și potențiale responsabilități sunt asociate cu bibliotecile selectate?
• Care stivă tehnologică este cea mai sigură? Ceea ce asigură un ciclu de dezvoltare rapid și cu costuri reduse?
• Ar trebui să prioritizez configurabilitatea aplicației (cost mare/întârziere de timp) sau să implementez versiuni personalizate (cost ridicat de întreținere/lipsa de scalabilitate)?
• Cât de fezabilă va fi integrarea produselor digitale nou achiziționate, menținând în același timp calitatea ridicată a codului, minimizând riscurile și menținând costurile de inginerie scăzute?

Răspunsurile la aceste întrebări pot avea un impact serios asupra rezultatelor afacerii și asupra propriei reputații a managerului de produs, dar deciziile sunt adesea luate pe baza intuiției sau a experienței anterioare, mai degrabă decât a investigațiilor riguroase și a unor metrici solide. Un proces amănunțit de evaluare a calității software-ului nu numai că oferă datele necesare pentru luarea deciziilor, ci și aliniază părțile interesate, construiește încredere și contribuie la o cultură a transparenței, în care prioritățile sunt clare și convenite.

Implementarea unui proces în 7 pași

Un proces complet de evaluare a calității codului sursă are ca rezultat un diagnostic care ia în considerare întregul set de determinări ale calității, mai degrabă decât câteva simptome izolate ale unei probleme mai mari. Metoda în șapte pași prezentată mai jos este aliniată cu recomandările CISQ pentru îmbunătățirea procesului și este menită să faciliteze următoarele obiective:

• Găsiți, măsurați și remediați problema aproape de cauza ei rădăcină.
• Investește inteligent în îmbunătățirea calității software-ului pe baza măsurătorilor calității generale.
• Atacați problema analizând setul complet de măsurători și identificând cele mai bune și mai rentabile îmbunătățiri.
• Luați în considerare costul complet al unui produs software, inclusiv costurile de proprietate, întreținere și alinierea reglementărilor de licență/securitate.
• Monitorizați calitatea codului în SDLC pentru a preveni surprizele neplăcute.

1. Maparea produs la cod: Urmărirea caracteristicilor produsului înapoi la baza lor de cod poate părea un prim pas evident, dar având în vedere ritmul cu care crește complexitatea dezvoltării, nu este neapărat simplu. În unele situații, codul unui produs este împărțit între mai multe depozite, în timp ce în altele, mai multe produse partajează același depozit. Identificarea diferitelor locații care găzduiesc anumite părți ale codului unui produs este necesară înainte de a putea avea loc o evaluare ulterioară.

2. Analiza stivei tehnice: Acest pas ia în considerare diferitele limbaje de programare și instrumente de dezvoltare utilizate, procentul de comentarii pe fișier, procentul de cod generat automat, costul mediu de dezvoltare și multe altele.

Instrumente recomandate: cloc

Alternative: Tokei, scc, sloccount

3. Analiza versiunilor: Pe baza rezultatelor acestei părți a auditului, care implică identificarea tuturor versiunilor unei baze de cod și calcularea asemănărilor, versiunile pot fi îmbinate și dublările eliminate. Acest pas poate fi combinat cu o analiză a punctelor de eroare (puncte fierbinți), care identifică părțile complicate ale codului care sunt revizuite cel mai frecvent și tind să genereze costuri de întreținere mai mari.

Instrumente sugerate: cloc, scc, sloccount

4. Revizuirea automată a codului: această inspecție verifică codul pentru defecte, încălcări ale practicii de programare și elemente riscante, cum ar fi jetoane codificate, metode lungi și duplicări. Instrumentul(ele) selectat(e) pentru acest proces vor depinde de rezultatele analizelor stivei tehnologice și ale versiunilor de mai sus.

Instrumente sugerate: SonarQube, Codacy

Alternative: RIPS, Veracode, Micro Focus, Parasoft și multe altele. O altă opțiune este Sourcegraph, o soluție universală de căutare a codului.

5. Analiza de securitate statică: Acest pas, cunoscut și sub denumirea de testare statică de securitate a aplicațiilor (SAST), explorează și identifică potențialele vulnerabilități de securitate ale aplicațiilor. Majoritatea instrumentelor disponibile scanează codul împotriva problemelor de securitate care apar frecvent identificate de organizații precum OWASP și SANS.

Instrumente sugerate: WhiteSource, Snyk, Coverity

Alternative: SonarQube, Reshift, Kiuwan, Veracode

6. Analiza componentelor software (SCA)/Analiza conformității licenței: Această revizuire implică identificarea bibliotecilor open source legate direct sau indirect de cod, licențele care protejează fiecare dintre aceste biblioteci și permisiunile asociate cu fiecare dintre aceste licențe.

Instrumente sugerate: Snyk, WhiteSource, Black Duck

Alternative: FOSSA, Sonatype și altele

7. Analiza riscului de afaceri: Această măsură finală presupune consolidarea informațiilor culese din pașii anteriori pentru a înțelege impactul deplin al calității codului sursă asupra afacerii. Analiza ar trebui să aibă ca rezultat un raport cuprinzător care să ofere părților interesate, inclusiv managerilor de produs, managerilor de proiect, echipelor de inginerie și directorilor executivi, detaliile de care au nevoie pentru a cântări riscurile și pentru a lua decizii informate despre produse.

Deși pașii anteriori din acest proces de evaluare pot fi automatizați și facilitați printr-o gamă largă de produse open source și comerciale, nu există instrumente existente care să sprijine procesul complet în șapte pași sau agregarea rezultatelor acestuia. Deoarece compilarea acestor date este o sarcină obositoare și consumatoare de timp, este fie efectuată la întâmplare, fie omisă în întregime, punând în pericol procesul de dezvoltare. Acesta este punctul în care un proces amănunțit de inspecție a software-ului se destramă adesea, făcând acest ultim pas probabil cel mai critic în procesul de evaluare.

Selectarea instrumentelor potrivite

Deși calitatea software-ului are impact asupra produsului și, prin urmare, asupra rezultatelor afacerii, selecția instrumentelor este în general delegată departamentelor de dezvoltare, iar rezultatele pot fi dificil de interpretat de către non-dezvoltatori. Managerii de produs ar trebui să fie implicați activ în selectarea instrumentelor care asigură un proces de asigurare a calității transparent și accesibil. Deși instrumentele specifice pentru diferitele etape ale evaluării sunt sugerate mai sus, există o serie de considerații generale care ar trebui luate în considerare în orice proces de selecție a instrumentului:

• Stiva tehnologică acceptată: rețineți că majoritatea ofertelor disponibile acceptă doar un set mic de instrumente de dezvoltare și pot duce la raportări parțiale sau înșelătoare.
• Simplitatea instalării: instrumentele ale căror procese de instalare se bazează pe scripturi complexe pot necesita o investiție semnificativă în inginerie.
• Raportare: ar trebui să se acorde preferință instrumentelor care exportă rapoarte detaliate, bine structurate, care identifică probleme majore și oferă recomandări pentru remedieri.
• Integrare: Instrumentele ar trebui verificate pentru o integrare ușoară cu celelalte instrumente de dezvoltare și management utilizate.
• Prețuri: instrumentele vin rareori cu o listă cuprinzătoare de prețuri, așa că este important să luați în considerare cu atenție investiția implicată. Diverse modele de prețuri iau în considerare de obicei lucruri precum numărul de echipe, dimensiunea codului și instrumentele de dezvoltare implicate.
• Implementare: atunci când cântăriți implementarea on-premise față de implementarea în cloud, luați în considerare factori precum securitatea. De exemplu, dacă produsul evaluat gestionează date confidențiale sau sensibile, instrumentele locale și instrumentele care utilizează abordarea de audit oarbă (FOSSID) pot fi de preferat.

Păstrând-o

Odată ce riscurile au fost identificate și analizate metodic, managerii de produs pot lua decizii bine gândite cu privire la prioritizarea și triarea defectelor cu mai multă acuratețe. Echipele ar putea fi restructurate și resursele alocate pentru a aborda problemele cele mai emergente sau predominante. „Showstoppers”, cum ar fi încălcările de licență cu risc ridicat, ar avea prioritate față de defectele de severitate mai mică și s-ar pune mai mult accent pe activitățile care contribuie la reducerea dimensiunii și complexității codului.

Totuși, acesta nu este un proces unic. Măsurarea și monitorizarea calității software-ului ar trebui să aibă loc continuu pe tot parcursul SDLC. Evaluarea completă în șapte etape ar trebui efectuată periodic, eforturile de îmbunătățire a calității începând imediat după fiecare analiză. Cu cât este identificat mai repede un nou punct de risc, cu atât remediul este mai ieftin și consecințele sunt mai limitate. Evaluarea calității codului sursă este centrală pentru procesul de dezvoltare a produsului, concentrează echipele, aliniază părțile interesate, atenuează riscurile și oferă unui produs cea mai bună șansă de succes - și aceasta este afacerea fiecărui manager de produs.