Testarea cu o eroare în cap (nu genul de software)

Lucrând în QA, aud adesea o voce în capul meu: „Ești sigur că ai verificat totul?” Uneori este un ghiont util, dar dacă nu este bifat, începe să devină o problemă. Mai jos, voi vorbi despre acest bug interior plictisitor și despre cum se manifestă.

În acest articol, vreau să vă împărtășesc gândurile și perspectivele pe care le-am obținut în urma studierii acestui fenomen. Sper că le găsiți utile și mi-ar plăcea să aud punctul dumneavoastră de vedere în comentarii. La urma urmei, feedback-ul este una dintre cele mai bune modalități de a mă vedea din exterior și de a mă îmbunătăți.

Avantajele bug-ului interior: „Ești sigur că ai verificat totul?”

Vă împinge să abordați chiar și cele mai simple sarcini cu grijă și atenție la detalii.

Odată, după ce am schimbat între sarcini și am terminat deja testarea, am decis să verific totul, pentru orice eventualitate. Atunci am observat un mic, dar crucial detaliu. Sarcina nu includea formula pentru un calcul pe care trebuia să o efectueze noua funcție. Curios, am recitit atât descrierea sarcinii, cât și epopeea și, spre surprinderea mea, formula de calcul nu a fost specificată nicăieri. Deci, cum l-am calculat?

Este jenant să recunosc, dar am folosit și verificat calculele cu o formulă dintr-o altă sarcină. În timp ce cele două sarcini erau legate, formulele trebuiau să funcționeze independent. Dându-mi seama de această neglijență, am cerut rapid regulile de calcul corecte, am retestat sarcina și am descoperit că dezvoltatorul a făcut aceeași greșeală. Și ei folosiseră formula de la cealaltă sarcină.

Acest mic insectă plictisitor îmi permite să găsesc erori non-triviale și să fac produsul mai fiabil

Odată ce am trecut prin planul de testare, acest mic generator de probleme începe să arunce idei de genul „Ce se întâmplă dacă clientul folosește o dimensiune mai mare a fontului sau un sistem de operare învechit?”

Datorită acesteia, îmi documentez testele mai amănunțit și includ adesea videoclipuri și capturi de ecran în rapoartele mele

Acest lucru este incredibil de util atunci când se face testarea, funcția este live și dintr-o dată apare o eroare. După ce este identificat și remediat, îmi verific înregistrările de testare pentru a determina dacă am ratat problema în timpul testării sau dacă a fost introdusă mai târziu în producție. Uneori, observ bug-ul ascuns la vedere în capturile de ecran sau înregistrările mele. Când se întâmplă acest lucru, analizez de ce l-am trecut cu vederea și de ce nu a existat un caz de testare care să-l prindă.

Pe această notă de auto-reflexie, să trecem la dezavantajele acestei Voci Interioare

Mă face mai anxioasă, adesea fără un motiv întemeiat

Acest lucru se întâmplă uneori după o înșurubare, dar există și momente în care vocea Micului Grășun se ridică neprovocată. În câteva ocazii, nu m-ar lăsa în pace nici după ce mă duceam la culcare și ajungeam să-mi fac notițe despre ce altceva ar trebui să verific.

Adesea mă face să pierd timpul cu cazuri de testare foarte complicate

Aceasta este o consecință directă a primului punct: anxietatea generează cele mai ciudate și mai coșmaroase scenarii din capul meu. În acest moment, par critici, dar privind în urmă, se dovedesc adesea a fi ceva de genul „Dar dacă un sturz fluieră într-un pin sub lună?”

Mă împiedică să mă concentrez pe alte sarcini

Uneori, chiar și după ce am mutat o sarcină la următoarea stare și am început ceva nou, gândurile despre acele cazuri de testare mă bântuie și mă împiedică să mă concentrez asupra noii sarcini. În astfel de cazuri, poate fi dificil să opriți anxios Checker-Bug.

Cum, atunci, poate cineva să folosească acest Bug în avantajul cuiva și cum îl împiedicați să preia controlul?

Primul lucru

care mi-a venit în minte când scriam despre dezavantaje – și ceva pe care îl repet ca pe o mantră – este următorul: Testarea exhaustivă este un mit. Întotdeauna vor exista bug-uri.

Indiferent cât de minuțios ești, este imposibil să prezici fiecare combinație de acțiuni și scenarii, ceea ce înseamnă că nu poți depista fiecare eroare înainte ca utilizatorii să o facă.

Mai ales într-o lume în continuă schimbare.

Acesta este ceva ce trebuie doar să accepti și să mergi mai departe.

Ceea ce m-a ajutat să mă împac cu acest lucru a fost să analizez cauzele principale ale erorilor de producție – ceea ce unii oameni numesc autopsie . Este atunci când discutați cu toți cei implicați pentru a afla cum s-a întâmplat eroarea și ce am putea face pentru a preveni să se repete.

Și am învățat că, de cele mai multe ori, defecte serioase au fost cauzate de simple neglijențe: uneori, cazuri de testare cu valori goale nu au fost verificate, ceea ce duce la neexpunerea anumitor produse în magazin; alteori, localizarea a fost ratată, rezultând un titlu al ecranului gol.

Cu toate acestea, cerul nu a căzut. Lucrările au continuat și am acordat cu toții mai multă atenție zonelor în care mai alunecasem înainte.

Al doilea lucru

Obișnuiam să liniștesc neplăcutul Checker-Bug implementa tehnici de proiectare a testelor: tabele de decizie și diagrame de tranziție de stări.

Acestea vă ajută să vizualizați logica aplicației și să obțineți o imagine mai clară a posibilelor cazuri de testare, ceea ce înseamnă că puteți fi mai sigur că nu le veți trece cu vederea.

Dacă aveți nevoie de o actualizare, un tabel de decizie este un tabel în care introducem condiții și reguli în coloane și rânduri. După ce am specificat opțiunile pentru toate condițiile și regulile, completăm rezultatul așteptat.

O diagramă de tranziție de stări este folosită atunci când avem un obiect cu stări diferite, iar obiectul își schimbă starea în funcție de anumite condiții. Nu este întotdeauna potrivită, dar a fost de mare ajutor când am lucrat la dezvoltarea unui serviciu de contabilitate; obiectele din acele diagrame erau lucruri precum rapoarte, aplicații sau semnături digitale.

Treilea,

remediul pentru acea insectă interioară plictisitoare m-a găsit de fapt pe cont propriu. S-a dovedit a fi o evaluare inter pares a cazurilor de testare și comunicarea după greșeli.

Simplu, poate chiar evident, dar funcționează ca un farmec.

Iar al patrulea

modalitatea de a-mi calma creierul a fost prin evaluarea eficacității și riscurilor. Când Inner Bug a început să-mi șoptească la ureche: „Verifică încă câteva cazuri de testare”, îmi aminteam de liderul echipei mele și puneam trei întrebări:

• Cât timp va dura?
• Care va fi beneficiul?
• Care este probabilitatea ca asta să descopere ceva important?

Da, uneori este logic să testați pe mai multe versiuni de sistem de operare, cu setări de limbă diferite, teme întunecate și deschise, dimensiune crescută a fontului și așa mai departe, dar de cele mai multe ori, aceste verificări sunt inutile.

Imaginați-vă că găsiți o eroare în timp ce efectuați astfel de teste: ce prioritate ar avea? Datorită pașilor specifici de reproducere, chiar și unui accident i se poate atribui o prioritate minoră.

Cât vor dura aceste verificări? Cinci până la zece minute – nu e mare lucru, dar nici măcar acel timp nu este întotdeauna disponibil. În acel timp, ați putea citi descrierea unei sarcini de dimensiuni medii.

Încheiere (sper)

Ca orice unealtă, acel insectă interior sâcâitor al tău poate fi o binecuvântare sau un blestem. Adesea este nevoie de experiență și timp pentru a învăța cum să folosești ceva eficient. Și sper că acest articol vă va ajuta să vă îmblânziți criticul interior mai repede, să vă salvați nervii și să vă sporiți încrederea în sine.

Vreau doar să-ți ofer puțin sprijin și poate în loc să te lupți până când ești epuizat, vei găsi o modalitate de a lucra cu această mică fiară și de a-ți face aliatul.