Folosind analiza Gap în procesul de testare pentru a alinia Devs și testeri

este o credință larg răspândită că dezvoltatorii și testeri obține pe ca creta și brânză. Dezvoltatorii de multe ori uita în jos nasul lor la testeri, vizualizându-le ca un drag inflexibil și nefolositoare pe dezvoltarea de cod nou, care nu reușesc să ofere detalii clare în biletele lor bug. La fel, testerii văd adesea dezvoltatorii cu iritare pentru că nu au reușit să-i țină la curent cu modificările codului și pentru a împinge noi modificări în timpul ciclurilor de testare. Acesta este motivul pentru care analiza gap în procesul de testare QA poate fi deosebit de benefică pentru alinierea atât a dev-urilor, cât și a testerilor.

deși acest punct de vedere poate fi apocrif, este adesea cazul este că dezvoltatorii și testerii nu comunică bine. De multe ori comunicarea se întâmplă doar prin management (manageri de proiect și manageri de linie) sau prin bilete în Jira. Rezultatul este că testarea se dovedește adesea inadecvată. În special, de prea multe ori noul cod este slab testat sau nu este testat deloc. Cercetările au arătat că acest nou cod netestat este cea mai mare sursă de erori și eșecuri viitoare. Aici intră în joc conceptul de analiză a decalajelor de testare.

în acest blog, vom explora ce este analiza decalajului de testare, vom arăta cum poate ajuta la identificarea codului care trebuie testat și vom explora dacă această abordare este panaceul care poate reduce decalajul dintre Dev și testeri.

ce este analiza decalajului de testare?

când dezvoltați pentru prima dată un sistem software, este ușor să vă asigurați că testați întregul sistem. Testerii sunt capabili să ia specificațiile codului și să utilizeze o combinație de teste planificate și exploratorii pentru a se asigura că testează fiecare parte în mișcare a bazei de cod. Cu toate acestea, majoritatea software-ului nu este static. Companiile fie fac lansări periodice monolitice de cod de lungă durată, fie folosesc un anumit nivel de integrare continuă și implementare continuă (CI/CD). În ambele cazuri, codebase este în continuă schimbare. Cu toate acestea, de prea multe ori cazurile de testare nu sunt actualizate în același ritm. Uneori, testerii pur și simplu nu știu că a fost făcută o modificare a codului. Alteori, schimbarea codului este împinsă imediat după ce au fost executate un anumit set de teste. Aceste teste par să fi trecut, dar schimbarea codului le-a încălcat.

analiza decalajului de testare este procesul de identificare a acestor lacune în cazul în care noul cod a fost implementat, dar nu a fost încă testat. Aceasta necesită o combinație de analiză statică a tuturor modificărilor de cod și analiză dinamică a tuturor testărilor curente. Prin compararea acestor două analize, puteți vedea cu ușurință în cazul în care orice lacune sunt. Adică zone de cod nou care au fost testate în mod adecvat. De obicei, acest lucru se face prin trasarea codului folosind o formă de diagramă arborescentă în care codul este împărțit în blocuri funcționale, sub fiecare bloc sunt clasele constitutive, sub acestea sunt metodele și funcțiile reale. La fiecare nivel din ierarhie, dimensiunea relativă a blocului indică cantitatea de cod. Prin suprapunerea arborelui care arată modificările Codului cu arborele care arată starea actuală de testare, este ușor să observați zonele în care lipsește acoperirea testului.

o hartă copac care arată Cod neschimbat (gri), revizuit/cod nou, care este testat (Verde), Cod revizuit, care este netestat (portocaliu) și cod nou, care este netestat (roșu).

de ce ar putea analiza diferența de testare contează în procesul de testare?

într-o lucrare din 2013, cercetătorii de la Universitatea Tehnică din Munchen au efectuat un studiu pentru a analiza corelația dintre Codul nou, netestat și viitoarele erori software. Au lucrat cu Munich Re (o mare companie de asigurări), monitorizând sistemul IT de lungă durată prin 2 lansări. În timpul lansării, au stabilit ce Cod era nou și, de asemenea, au analizat ce cod a fost testat și ce cod a fost lansat netestat. După aceea, au monitorizat sistemul mult timp și au urmărit toate erorile raportate înapoi la sursa originală. Au descoperit două lucruri cheie. În primul rând, aproximativ o treime din tot codul a fost eliberat netestat. În al doilea rând, atunci când au urmărit bug-uri au descoperit în general între 70 și 80% din toate bug-uri au fost în cod netestat. Graficul de mai jos arată acest lucru mai clar.

după cum puteți vedea, vechiul cod testat nu avea erori. Noul cod testat a avut între 22 și 30% din bug-uri, iar bug-urile rămase au fost distribuite destul de uniform între noul cod netestat și vechiul cod netestat. Cu toate acestea, deoarece noul cod a reprezentat doar 15% din Codul total, puteți vedea că noul cod netestat a reprezentat un număr disproporționat de mare de erori.

analiza decalajului de testare este concepută pentru a identifica acest nou cod netestat. Cu toate acestea, vă poate ajuta și în alte moduri. De exemplu, deoarece monitorizează ceea ce testați, poate identifica zone ale codului existent care sunt depășite (de exemplu, acestea sunt încă testate, dar nu sunt de fapt apelate de niciun cod). De asemenea, poate evidenția pe ce domenii trebuie să vă concentrați resursele de testare. Rulând-o în mod regulat, managerii pot îmbunătăți planificarea testelor, concentrându-se pe testarea noului cod și încercând să asigure o acoperire uniformă a testelor.

Devs și testeri aliniate prin analiza decalajului de testare

analiza decalajului de testare este în mod clar un concept puternic. Dar este, de asemenea, clar că nu toate echipele vor beneficia în mod egal de aceasta. Echipele care vor beneficia cel mai mult sunt cele care mențin baze de cod de lungă durată cu lansări monolitice periodice. În codebases de lungă durată, dezvoltatorii lucrează adesea la cod care a fost scris de alte persoane. Testerii se pot baza pe planurile de testare produse cu mai multe versiuni înainte. Luate în combinație, acești factori pot însemna că nimeni nu este destul de clar ce cod este testat sau cum interacționează acel cod cu alte părți ale sistemului. Aici, TGA poate permite testerilor să vadă exact ce cod S-a schimbat, ceea ce le permite să se concentreze asupra acestui lucru. De asemenea, pot identifica codul din sistemul existent care nu este testat.

echipele care folosesc CI / CD pot beneficia, de asemenea, de această abordare, deoarece va permite testerilor să identifice rapid ce cod este schimbat și astfel să le permită să se concentreze asupra acestui lucru. Se poate evita, de asemenea, problema menționată mai sus în cazul în care o bucată de cod este modificat imediat după ce a fost testat și apoi devine eliberat cu modificările netestat.

pe de altă parte, echipele care lucrează la coduri noi sau de scurtă durată vor beneficia mai puțin, deoarece, prin definiție, majoritatea codurilor vor fi netestate la început. Aici este important să utilizați metodologii standard de testare pentru a vă asigura că testarea dvs. este bună. Cu toate acestea, poate fi util ca astfel de echipe să înceapă monitorizarea acoperirii testului folosind TGA, deoarece acest lucru le va permite să evite problemele viitoare.

care sunt problemele potențiale?

există câteva probleme cu TGA. Una dintre cele mai mari se referă la faptul că nu vă poate spune ce cod este apelat în mod activ în baza de cod. Dezvoltatorii adaugă adesea cod nou în pregătirea pentru versiunile viitoare, dar din moment ce acest lucru este inactiv, suita de testare nu o poate numi. Ca rezultat, acest cod va apărea întotdeauna ca un nou cod netestat. La fel, multe baze de cod mari conțin blocuri de cod vechi sau orfan. Acestea ar trebui curățate periodic, dar din nou acestea vor distorsiona imaginea pentru analiza decalajului de testare.

o altă observație importantă este că doar pentru că o bucată de cod este testată nu împiedică acest cod să declanșeze erori în altă parte. Unele dintre cele mai grave bug-uri sunt cele în care o mică modificare a unei bucăți de cod determină o funcție sau o metodă să eșueze într-un bloc de cod total fără legătură. Deci, este vital să continuăm atât testarea exploratorie, cât și testarea regresiei. Ceea ce poate face TGA este să identifice zonele din Baza de cod existentă care nu sunt testate corespunzător în timpul testării regresiei.

ce alte alternative ajută la reducerea decalajului?

analiza decalajului de testare este cu siguranță un instrument util pentru unele Echipe. Cu toate acestea, există și alte modalități de a evita o nepotrivire între ceea ce testerii dvs. testează și ceea ce codificatorii dvs. codifică. O modalitate este de a utiliza o automatizare mai inteligentă a testelor, care este capabilă să identifice unde și când lucrurile s-au schimbat, atât pe frontend, cât și, important, în backend. Aici, la Functionize, testele noastre folosesc amprentarea inteligentă cuplată cu învățarea automată și auto-vindecarea pentru a reduce întreținerea testelor. Acest lucru permite testelor să se adapteze proactiv la modificările frontend, precum și să monitorizeze lucruri precum apelurile serverului, timpii de răspuns și dacă butoanele/funcțiile sunt de fapt vizibile. Aceasta înseamnă că testerii dvs. nu vor fi prinși de modificările făcute în codul backend sau modificările de design/CSS care modifică aspectul frontend.

sistemul nostru inteligent poate crea, de asemenea, teste prin monitorizarea modului în care utilizatorii interacționează cu sistemul. Acest lucru vă ajută să vă asigurați că există mai puține lacune în acoperirea testului. Unul dintre cele mai noi instrumente vă permite să scrieți noi teste în limba engleză simplă. Acestea sunt analizate de instrumentul nostru de procesare a limbajului Natural și transformate în teste utilizabile. Aceasta înseamnă că, în timpul dezvoltării, dezvoltatorii pot specifica pur și simplu ce va trebui testat folosind engleza normală, reducând astfel decalajul dintre cele două discipline.

concluzii

analiza decalajului de testare vă ajută să identificați ce cod este eliberat netestat și, prin urmare, vă poate ajuta să vă concentrați resursele de testare mai eficient. În mod surprinzător, se pare că codul netestat este mult mai probabil să conțină erori și, prin urmare, orice instrument care poate ajuta la asigurarea faptului că acest cod este testat corect este util. Cu toate acestea, după cum am văzut, TGA nu poate decât să completeze cele mai bune practici existente. Este vital să vă mențineți testarea regresiei și testarea exploratorie. Multe dintre beneficiile TGA pot fi obținute și prin utilizarea instrumentelor inteligente de testare. Dar, în general, principalul lucru de evitat este izolarea echipei de testare de munca dezvoltatorilor tăi. Pentru a cita greșit o zicală veche, ar trebui să vă asigurați că mâna stângă știe ce face mâna dreaptă!