Ceea ce urmează este un articol care a fost publicat în 2005 pe situl Stagii pe Bune. L-am redescoperit acum ceva vreme, apoi am constatat că s-a schimbat link-ul și am decis să-l republic aici, să am și eu un backup. Singurele modificări față de varianta originală sunt caracterele cu diacritice, bold-urile și italicele.

Eu testez, tu testezi, el testează…

de Ovidiu Constantin, Linux/Unices Testing Manager

Suntem implicați în IT, folosim calculatorul peste 10 ore pe zi, lucrăm cu studenți, power-useri, administratori, programatori. Auzim de proiecte noi, aplicații, situri, sisteme de operare și limbaje de programare. De câte ori nu v-ați adresat colegului care lucrează la cel mai cool proiect de care ați auzit vreodată spunându-i “Vreau și eu să văd ce faci”, “Dă-mi și mie o versiune”?

Cum nimeni nu ratează șansa de a-și arăta munca unui prieten binevoitor, probabil ați și intrat în posesia cd-ului, arhivei, kit-ului. Și ați devenit, fără să știți, testeri.

Mulți dintre voi ați auzit probabil de programe de beta-testing, versiuni beta la aplicații, testare. Și totuși, ce este această activitate de testare? Și cine sunt testerii?

Un prieten mi-a spus că testerii sunt niște programatori frustrați. De fapt nu-i deloc așa, ba chiar pot afirma foarte răspicat că un bun tester este un slab programator. Și invers. Și ăsta este un lucru foarte bun, testerii și programatorii se completează reciproc pentru a produce ceva de calitate – Aplicația.

Activitatea de testare, deși ușor de definit (am căutat pe Google “define:testing” și al doilea răspuns este “The process of exercising software to verify that it satisfies specified requirements and to detect errors.” ), este un proces complex. Există multe metode de testare, s-au scris o mulțime de articole și cărți, există grupuri de discuții, liste de mail, cursuri. Faptul că avem o mulțime de aplicații care nu funcționează perfect (nici pe departe perfect) ne demonstrează că nu este de ajuns.

Un test pe zi (Bastard Tester From Hell)

Acest articol nu vă va spune cum se testează, n-o să vă înșire cele x (unde x > 20) metode de testare. Nici nu își propune să vă prezinte 10 pași simpli pentru a deveni tester. O să facem doar o incursiune în ziua unui tester … să-i spunem BTFH (Bastard Tester From Hell).

“Am ajuns la servici, și în timp ce-mi beau cafeaua am pornit clientul de mail. Iarăși 350 de mesaje… În timp ce șterg spam-urile care în ultimele câteva săptămâni tot insistă că am câștigat 1 milion de euro, mă gândesc dacă n-ar trebui să mă desubscriu de la câteva liste de discuție. Cred că ar trebui, dar înainte să decid de care din ele o să mă despart, privirea îmi alunecă pe folder-ul “Releases”. 6 mailuri noi… hehe, cineva din echipa de dezvoltare a lucrat târziu ieri.”

“Lecturez în viteză changelog-urile: 2-3 bug-uri fixate (YES! s-a reparat și problema “aia” care mă sâcâia de 2 săptămâni!), câteva optimizări (uf… acum trebuie să reiau testarea pentru nu-stiu-ce-for care s-a transformat în while). Destul să mă amuz astăzi toată ziua.”

“Am salvat fișierele, le-am plasat în locul celor vechi pe calculatorul de testare și am pornit aplicația. Emoție, emoție, și… merge. Toate procesele au pornit, erori n-am primit, programul face ce trebuie să facă… Azi o să fie o zi bună.”

“Bun, acum că am terminat cu Testarea de acceptanță, este cazul să mă apuc de ceva mai serios. Îmi pun căștile pe urechi, dau drumul la [insert your favorite music here] și caut în teancul virtual de documente specificațiile produsului. Trebuie să mă asigur că în afară de bug-urile rezolvate, nu au dispărut funcționalități prevăzute sau cine știe… au apărut altele noi (orice programator o să spună “It’s not a bug, it’s a feature”, orice tester o să spună exact pe dos). Două ore mai târziu constat mulțumit că produsul face tot ceea ce a fost prevăzut să facă. Și chiar bine! Pentru cei mai tehnici, aceasta a fost testarea funcțională.”

“Acum să văd ce-i cu bug-urile alea. Dezvoltatorii susțin că le-au rezolvat… dar cum până acum nu i-am crezut niciodată, n-o să încep azi. Ieri produsul se zăpăcea în 10 secunde dacă-l supuneam la micul meu script, poate astăzi este mai sigur de el. Rulez produsul, rulez scriptul și… și… și nimic. N-a pățit nimic. Script-ul meu ucigaș nu mai e bun de nimic. Bug-ul s-a rezolvat. Mai încerc de câteva ori, mai modific ceva variabile, dar produsul se încăpățânează să rămână stabil. Asta e, 1-0 pentru dezvoltare.”

“Câteva minute mai târziu, după ce am trimis mailurile bucuroase de confirmare, m-am intors la script-ul meu. Îi dau un nume mai sugestiv și îl plasez alături de celelalte script-uri care în zilele lor glorioase reușeau să producă un crash în câteva minute. Acum le mai rulez din când în când să mă asigur că problemele vechi rămân vechi. Asta s-ar numi regression testing.”

“Este acum momentul să las programatorul frustrat din mine să se manifeste. Mintea mea diabolica va născoci astăzi alte teste, din ce în ce mai grele. Date malformate, mii de conexiuni simultane, zeci de megabytes de informație de procesat. Scopul? Voi stresa la maxim aplicația, zile și zile în șir, mwahahahaha. Dacă reușesc să blochez calculatorul dar nu și programul testat înseamnă că testul de anduranță a reușit și pot să spun că avem un produs final.”

“- Ce-i faci săracului program ?“

“Este un coleg de la dezvoltare. A venit să mă întrebe dacă mergem cu toții să programăm și să testăm un algoritm de băut bere și m-a surprins în plină partidă de maltratat aplicatia. Sting repede monitorul (dezvoltatorii sunt protectivi când e vorba de programele lor…) și plecăm.”

Cam așa arată ziua unui tester. Dacă ceea ce v-am povestit vă interesează, daca v-ați văzut în locul acestui tester, de ce nu ați încerca și voi să faceți asta? Nu este foarte greu, iar pentru cei pasionați este foarte distractiv.

Un bun tester este o persoană care poate să (re)devină ignorantă, făcând abstracție de cunoștințele lui anterioare despre produs. Trebuie să se adapteze repede la schimbări, dar să păstreze un ochi critic, să caute mereu ceea ce ar putea să meargă rău într-o situație. Eventual legea lui Murphy “Dacă ceva poate merge rau, o va face” să-i fie filosofie. Sceptic și pragmatic, un tester se bazează pe ceea ce se poate observa și măsura, își poate susține cu argumente opiniile, chiar dacă de multe ori asta înseamnă că demonstrează cuiva că a gresit.

Bibliografie:

1. Google, http://www.google.com/
2. Brett Pettichord, “Testers and Developers Think Differently”, articol in “Software Testing and Quality Engineering”, ianuarie 2000, http://www.io.com/~wazmo/papers/testers_and_developers.pdf

Acest articol este publicat sub licența “Creative Commons Attribution-ShareAlike 2.0″, disponibilă la http://creativecommons.org/licenses/by-sa/2.0/

No related posts.