Un drum către o mai bună testare agilă

Raportul anual de calitate mondial creat de Capgemini arată că 42% dintre respondenții la sondaj menționează „lipsa expertizei profesionale în materie de testare” drept o provocare în aplicarea testării în dezvoltarea Agile. În timp ce apariția Agile a adus o viteză crescută a iterațiilor pentru dezvoltarea de software, în unele cazuri, acest lucru a venit cu prețul calității.

Concurența acerbă presează echipele să furnizeze în mod constant noi actualizări de produse, dar uneori acest lucru vine cu propriul cost, inclusiv scăderea atenției față de testare. Unii, precum Rob Mason, merg chiar mai departe și susțin că Agile distruge testarea software-ului. Recent, Facebook și-a schimbat motto-ul de la „mișcă-te rapid și sparge lucrurile” în „mișcă-te rapid cu o infrastructură stabilă” în încercarea de a rezolva tentațiile de a sacrifica calitatea.

Deci, cum poate testarea să fie mai bine integrată în noua lume a dezvoltării software Agile? Testare agilă.

Testarea tradițională este destul de greoaie și depinde de multă documentație. Testarea Agile este o abordare a procesului de testare care imită principiile dezvoltării software Agile prin care:

• Testarea se face mult mai des,
• Testarea se bazează mai puțin pe documentație și mai mult pe colaborarea membrilor echipei și
• Unele activități de testare sunt întreprinse nu numai de testeri, ci și de dezvoltatori.

În ultimii șapte ani, am făcut tranziția multor echipe la testarea Agile și am lucrat cot la cot cu testeri pentru a ajuta procesele lor să se potrivească noii metodologii. În acest articol, voi împărtăși câteva dintre cele mai importante sfaturi pe care le-am învățat în drumul meu către o mai bună testare Agile. Deși este firesc să existe o fricțiune între viteză și calitate în cadrul practicilor Agile, acest articol va acoperi câteva tehnici care pot fi utilizate pentru a crește calitatea testării fără a compromite agilitatea. Cele mai multe dintre sugestiile prezentate aici vor necesita implicarea echipei, așa că va fi benefic ca atât dezvoltatorii, cât și testerii să participe la planificare.

Formalizați un proces de ciclu de testare a lansării

O problemă cu testarea este absența ciclului de testare a lansării, lipsa unui program de lansare sau solicitările neregulate de testare. Solicitările de testare la cerere fac procesul de QA dificil, mai ales dacă testerii se ocupă de mai multe proiecte.

Multe echipe fac doar o singură construcție după fiecare sprint, ceea ce nu este ideal pentru proiecte Agile. Trecerea la versiuni o dată pe săptămână ar putea fi benefică, trecând treptat la versiuni multiple pe săptămână. În mod ideal, build-urile și testarea de dezvoltare ar trebui să aibă loc zilnic, ceea ce înseamnă că dezvoltatorii împing codul în depozit în fiecare zi, iar build-urile sunt programate să ruleze la o anumită oră. Pentru a face acest pas mai departe, dezvoltatorii ar putea implementa cod nou la cerere. Pentru a implementa acest lucru, echipele pot folosi un proces de integrare continuă și implementare continuă (CI/CD). CI/CD limitează posibilitatea unei versiuni eșuate în ziua unei lansări majore.

Când CI/CD și automatizarea testelor sunt combinate, este posibilă detectarea timpurie a erorilor critice, permițând dezvoltatorilor să aibă suficient timp pentru a remedia erorile critice înainte de lansarea programată a clientului. Unul dintre principiile Agile afirmă că software-ul de lucru este principala măsură a progresului. În acest context, un ciclu de lansare formalizat face procesul de testare mai agil.

Împuterniciți testatorii cu instrumente de implementare

Unul dintre punctele de frecare comune pentru testare este implementarea codului într-un mediu de pregătire. Acest proces depinde de infrastructura tehnică pe care echipa dvs. ar putea să nu o poată afecta. Cu toate acestea, dacă există o oarecare flexibilitate, pot fi create instrumente pentru persoane netehnice, cum ar fi testeri sau manageri de proiect, care le-ar permite să implementeze baza de cod actualizată pentru testarea ei înșiși.

De exemplu, într-una dintre echipele mele, am folosit Git pentru controlul versiunilor și Slack pentru comunicare. Dezvoltatorii au creat un Slackbot care avea acces la Git, scripturi de implementare și o mașină virtuală. Testerii au reușit să pună ping bot-ului cu un nume de ramură achiziționat de la GitHub sau Jira și să-l implementeze într-un mediu de staging.

Această configurare a eliberat mult timp pentru dezvoltatori, reducând în același timp risipa de comunicare și întreruperile constante atunci când testerii au fost nevoiți să le ceară dezvoltatorilor să implementeze o ramură pentru testare.

Experimentați cu TDD și ATDD

Dezvoltarea bazată pe teste (TDD) este un tip de proces de dezvoltare software care pune mult accent pe calitate. În mod tradițional, un dezvoltator scrie cod și apoi cineva îl testează și raportează dacă au fost găsite erori. În TDD, dezvoltatorii scriu mai întâi teste unitare înainte chiar de a scrie orice cod care ar completa o poveste de utilizator. Testele eșuează inițial până când dezvoltatorul scrie cantitatea minimă de cod pentru a trece testele. După aceea, codul este refactorizat pentru a îndeplini cerințele de calitate ale echipei.

Dezvoltarea bazată pe teste de acceptare (ATDD) urmează o logică similară cu cea a TDD, dar, după cum sugerează și numele, se concentrează pe testele de acceptare. În acest caz, testele de acceptare sunt create înainte de dezvoltare în colaborare cu dezvoltatorii, testerii și solicitantul (client, proprietar de produs, analist de afaceri etc.). Aceste teste îi ajută pe toți membrii echipei să înțeleagă cerințele clientului înainte ca orice cod să fie scris.

Tehnici precum TDD și ATDD fac testarea mai agilă prin mutarea procedurilor de testare la etapele incipiente ale ciclului de viață al dezvoltării. Când scriu scenarii de testare de la început, dezvoltatorii trebuie să înțeleagă foarte bine cerințele. Acest lucru minimizează crearea inutilă de cod și, de asemenea, rezolvă orice incertitudini despre produs la începutul ciclului de dezvoltare. Când întrebările sau conflictele despre produse apar doar în etapele ulterioare, timpul și costurile de dezvoltare cresc.

Descoperiți ineficiențe urmărind mișcarea cardului de activitate

Într-una dintre echipele mele, am avut un dezvoltator care a fost extrem de rapid, mai ales cu funcții mici. Ar primi o mulțime de comentarii în timpul revizuirii codului, dar maestrul nostru Scrum și cu mine am renunțat la asta ca lipsă de experiență. Cu toate acestea, pe măsură ce a început să codifice caracteristici mai complexe, problemele au devenit mai evidente. El a dezvoltat un model de trecere a codului la testare înainte ca acesta să fie complet gata. Acest model se dezvoltă de obicei atunci când există o lipsă de transparență în procesul de dezvoltare - de exemplu, nu este clar cât timp petrec diferiți oameni pentru o anumită sarcină.

Uneori, dezvoltatorii își grăbesc munca în încercarea de a obține funcții cât mai curând posibil și de a „externaliza” calitatea către testeri. O astfel de configurație nu face decât să mute blocajul mai în jos pe sprint. Asigurarea calității (QA) este cea mai importantă plasă de siguranță pe care o are echipa, dar asta poate însemna că existența QA oferă dezvoltatorilor posibilitatea de a renunța la considerente de calitate.

Multe instrumente moderne de management de proiect au capabilitățile de a urmări mișcarea cardurilor de sarcini pe o placă Scrum sau Kanban. În cazul nostru, am folosit Jira pentru a analiza ce s-a întâmplat cu sarcinile dezvoltatorului în cauză și am făcut comparații cu alți dezvoltatori din echipă. Am aflat ca:

• Sarcinile lui au petrecut aproape de două ori mai mult timp în coloana de testare a consiliului nostru;
• Sarcinile lui ar fi mult mai des returnate de la QA pentru a doua sau a treia rundă de reparații.

Deci, în afară de faptul că testerii trebuie să petreacă mai mult timp sarcinilor sale, au trebuit să o facă de mai multe ori. Procesul nostru opac a făcut să pară că dezvoltatorul a fost foarte rapid; totuși, asta s-a dovedit a fi fals când am luat în considerare timpul de testare. Mutarea poveștilor utilizatorilor înainte și înapoi nu este, evident, o abordare slabă.

Pentru a rezolva acest lucru, am început prin a avea o discuție sinceră cu acest dezvoltator. În cazul nostru, pur și simplu nu era conștient de cât de dăunător era modelul său de lucru. A fost doar modul în care s-a obișnuit să lucreze în compania sa anterioară, care avea cerințe de calitate mai scăzute și un bazin de teste mai mare. După conversația noastră și cu ajutorul câtorva sesiuni de programare în pereche cu maestrul nostru Scrum, a trecut treptat la o abordare de calitate superioară a dezvoltării. Datorită abilităților sale rapide de codare, a fost încă un performant, dar „deșeurile” eliminate din procesul de QA au făcut ca întregul proces de testare să fie mult mai agil.

Adăugați automatizarea testelor la setul de abilități ale echipei QA

Testarea în proiecte non-Agile implică activități precum analiza testelor, proiectarea testelor și execuția testelor. Aceste activități sunt secvențiale și necesită o documentare extinsă. Când o companie trece la Agile, de cele mai multe ori, tranziția se concentrează mai ales pe dezvoltatori și nu atât de mult pe testeri. Aceștia nu mai creează documentație extinsă (un pilon al testării tradiționale), dar continuă să efectueze teste manuale. Cu toate acestea, testarea manuală este lentă și de obicei nu poate face față buclelor rapide de feedback ale Agile.

Automatizarea testelor este o soluție populară la această problemă. Testele automate facilitează testarea funcțiilor noi și mici, deoarece codul de testare poate rula în fundal, în timp ce dezvoltatorii și testerii se concentrează pe alte sarcini. Mai mult, deoarece testele sunt executate automat, acoperirea testării poate fi mult mai mare în comparație cu eforturile de testare manuală.

Testele automate sunt bucăți de cod software similar cu baza de cod care este testată. Aceasta înseamnă că oamenii care scriu teste automate vor avea nevoie de abilități tehnice pentru a avea succes. Există multe variante diferite ale modului în care testarea automatizată este implementată în diferite echipe. Uneori, dezvoltatorii înșiși își asumă rolul de testeri și măresc baza de cod de testare cu fiecare funcție nouă. În alte echipe, testerii manuali învață să folosească instrumente de automatizare a testelor sau este angajat un tester tehnic cu experiență pentru a automatiza procesul de testare. Indiferent de calea urmată de echipa, automatizarea duce la testare mult mai agile.

Gestionați prioritățile de testare

În cazul dezvoltării software non-Agile, testerii sunt de obicei alocați pe bază de proiect. Cu toate acestea, odată cu apariția Agile și Scrum, a devenit obișnuit ca aceiași profesioniști QA să opereze în mai multe proiecte. Această responsabilitate suprapusă poate crea conflicte în programe și poate duce la ratarea ceremoniilor critice de către testatori atunci când un tester acordă prioritate testării lansării unei echipe față de sesiunea de planificare a sprintului a alteia.

Motivul pentru care testerii lucrează uneori la mai multe proiecte este evident – ​​rareori există un flux constant de sarcini pentru testare pentru a ocupa un rol cu ​​normă întreagă. Prin urmare, ar putea fi greu să convingi părțile interesate să aibă o resursă de testare dedicată alocată unei echipe. Cu toate acestea, există unele sarcini rezonabile pe care un tester le poate face pentru a-și umple timpul de nefuncționare atunci când nu se angajează în activități de testare.

Suport pentru clienți

O posibilă configurație este ca testatorul să-și petreacă timpul de nefuncționare a sprintului ajutând echipa de asistență pentru clienți. Confruntându-se constant cu problemele pe care le au clienții, testerul are o mai bună înțelegere a experienței utilizatorului și a modului de îmbunătățire a acesteia. Ei pot contribui la discuțiile din timpul sesiunilor de planificare. În plus, ei devin mai atenți în timpul activităților lor de testare, deoarece sunt mai bine familiarizați cu modul în care clienții își folosesc de fapt software-ul.

Management de produs

O altă tehnică de gestionare a priorităților testerilor este, în esență, de a-i face manageri de produs juniori care efectuează teste manuale. Aceasta este, de asemenea, o soluție viabilă pentru a completa timpul liber al unui tester, deoarece managerii de produs juniori petrec mult timp creând cerințe pentru poveștile utilizatorilor și, prin urmare, au cunoștințe intime despre majoritatea sarcinilor.

Test de automatizare

După cum am discutat anterior, testarea manuală este adesea inferioară automatizării. În acest context, impulsul pentru automatizare poate fi cuplat cu faptul că un tester își dedică întreaga atenție echipei și își folosește timpul liber în învățare pentru a lucra cu instrumente de automatizare a testelor precum Selenium.

Rezumat: Testare Agile de calitate

Facerea testării mai agile este o inevitabilitate cu care se confruntă acum multe echipe de dezvoltare de software. Cu toate acestea, calitatea nu ar trebui să fie compromisă prin adoptarea unui „test cât de repede poți”. Este imperativ ca o tranziție Agile să includă o trecere la testarea Agile și există câteva modalități de a realiza acest lucru:

• Formalizați un proces de ciclu de testare a lansării.
• Îmbunătățiți testerii cu instrumente de implementare.
• Experimentați dezvoltarea bazată pe teste și dezvoltarea bazată pe teste de acceptare.
• Descoperiți ineficiențe urmărind mișcarea cardului de activitate.
• Adăugați automatizarea testelor la setul de abilități ale echipei QA.
• Gestionați prioritățile testerului.

În fiecare an, software-ul devine din ce în ce mai bun și așteptările utilizatorilor cresc. Mai mult, pe măsură ce clienții se obișnuiesc cu produse de înaltă calitate ale mărcilor de software de top precum Google, Apple și Facebook, aceste așteptări se transferă și în alte produse software. Astfel, accentul pus pe calitate este probabil să fie și mai important în următorii ani. Aceste îmbunătățiri ale procesului de testare și dezvoltare generală pot face testarea mai agilă și pot asigura un nivel ridicat de calitate a produsului.