S-au spus multe lucruri despre faptul ca programatorii si testerii gandesc diferit. Este destul de evident ca un software tester se uita la un produs dintr-o perspectiva diferita fata de un programator - de multe ori este mult mai usor sa identifici o greseala in munca cuiva decat sa o identifici in propria ta munca. Din acest motiv avem nevoie de o testare cat mai independenta in proiectele de software development.

Exista si o alta diferenta la nivel de stil de lucru. Munca unui software tester necesita schimbari dese in ceea ce priveste atentia: in timpul unei zile de lucru un tester poate sa execute o multitudine de sarcini care nu au legatura intre ele. Programatorii in schimb sunt exact opusul: ei lucreaza de cele mai multe ori intr-o stare “de flow”. Aceasta particularitate a muncii unui programator a fost descrisa de Tom Demarco si Timothy Lister in cartea lor Peopleware: Productive Projects and Teams: “Flow este o conditie a unei implicari profunde, aproape meditative. In aceasta stare, apare un sentiment de euforie, iar multi oameni nu mai sunt atenti la trecerea timpului: ”Am inceput sa muncesc. Mi-am ridicat capul, si deja trecusera trei ore.” Nu este vorba de un efort constient; munca pur si simplu pare sa vina de la sine. Aceasta stare mentala este potrivita pentru un programator care vrea sa scrie cod de calitate.

Nu poti sa intri in aceasta stare imediat; ai nevoie de cel putin 15 minute de implicare si concentrare. Dar este foarte usor sa scoti pe cineva din aceasta stare. Daca o persoana te intrerupe constant, nu vei putea sa reintri in aceasta stare cu usurinta...Rezultatul este un nivel scazut de productivitate si un grad ridicat de iritare fata de cei care te deranjeaza.

Ar trebui sa tinem cont de asta cand comunicam cu colegii nostri programatori. Pe cat posibil, trebuie sa incercam sa gasim modalitati discrete de a comunica cu ei. Astfel mail-ul este mai bun ca chat-ul intern, chat-ul intern este mai bun fata de un apel telefonic sau sa aparem la biroul lor neanuntati. Unii oamenii pot fi usor distrasi chiar si de mesajele de pe chat deoarece cred ca se asteapta de la ei sa raspunda imediat.
Dar sa nu ne intelegem gresit. Scopul sfatului de mai sus nu este de a opri orice forma de comunicare cu colegii vostri, ci pur si simplu o incurajare in a planifica acest aspect.

Daca lucrati in acelasi birou cu programatorii, tineti minte ca zgomotele puternice pot sa afecteze starea de flow. Insa o atitudine linistita arata respect fata de colegii vostri, indiferent ca sunt sau nu programatori. Intr-una din companiile unde lucram era o regula care spunea ca oricine vroia sa vorbeasca la telefon trebuia sa iasa pe hol. Cred ca asta este o regula foarte buna pentru companiile IT.

Critica constructiva

Ca sa o spunem sincer, nimanui nu ii place sa fie criticat. Cu totii suntem diferiti; unii din noi sunt mai sensibili la critica fata de altii, dar nimeni in cele din urma nu este un fan. Faptul ca suntem suparati sau iritati atunci cand altii scot in evidenta greselile noastre este normal si natural. Munca unui tester, insa, este de a cauta defecte si probleme si de a le raporta. De fapt, toata echipa unui proiect intelege asta, cel putin in teorie, dar nu esta asa usor sa controlezi aceasta stare de spirit...

S-au spus multe despre critica constructiva, dar nu tot ce s-a spus poate fi aplicat in munca in IT. Nu va voi sugera sa scrieti rapoartele cu bug-uri sub forma de feedback sandwich (lauda la inceput, critica la mijloc si lauda la sfarsit). Asta nu mai functioneaza nici macar cu un copil de 5 ani. In general, forma in care trebuie elaborat un raport legat de un bug ne scapa de critica non-constructiva. Asa ca atunci cand descrieti defectele tineti minte un principiu – critica constructiva trebuie fundamentata. Explicati de ce considerati ca este un defect. Ideal ar trebui sa faceti referinta la specificatiile sau standardele pe care programul trebuie sa le respecte. Daca intampinati dificultati in a explica de ce este ceva un bug, mai mult ca sigur este o problema undeva. Daca pur si simplu credeti ca “ar merge mai bine altfel’ poate ca acest comentariu ar fi mai degraba o imbunatatire sau o cerinta.

Nu este foarte greu sa faceti un raport obiectiv si constructiv. Este mult mai greu sa comunicati acest lucru fata in fata. Din cand in cand trebuie sa discutati anumite aspecte in persoana. De multe ori 5-10 minute de discutie cu persoana respectiva s-ar putea sa fie mult mai productive decat saptamani de schimburi de mailuri. Este foarte important insa sa aveti un dialog constructiv.

Asa ca in acest context ar trebui sa aplicati urmatoarele principii:

Alegeti timpul si locul. Nu ar trebui sa abordati un programator cu “Cand o sa repari bug-ul AB-123?!” pe hol sau cand isi iau cafeaua dimineata. Oamenii accepta critica mult mai usor atunci cand si unde se asteapta sa o auda. Ideal ar fi sa aveti intalniri regulate intre echipele de testare si dezvoltare.

Evitati sa fiti prea personali. Critica sau observatia ta trebuie sa se refere la situatie, nu la persoana cu care vorbesti altfel te vei confrunta cu o persoana defensiva si este imposibil sa ai un dialog constructiv in aceasta situatie.

Controlati-va comportamentul non-verbal. Poate fi dificil uneori in special pentru cei care sunt mai emotionali sau pentru cei care isi iau munca foarte in serios si sunt ingrijorati de produsul sau proiectul la care lucreaza. Dar este util sa depui efort pentru a te controla. Tonul vocii, gesturile voastre, intonatia – sunt la fel de importante ca mesajul pe care incercati sa il transmiteti. Chiar daca folositi fraze neutre, dar va exprimati non-verbal emotiile negative, tot puteti sa va afectati colegii si ei la randul lor vor reactiona negativ si nu vor intelege mesajul pe care incercati sa il transmiteti.

Concentrati-va pe cele mai importante aspecte. Alege punctele cheie asupra carora vrei sa atragi atentia si discuta despre aceste puncte. Lasa deoparte orice aspecte cu prioritate scazuta. Daca oferi prea multe informatii acestia nu vor tine minte aspectele importante.

Dati ocazia colegilor vostri sa raspunda. Ascultati observatiile si explicatiile lor. Chiar daca nu sunteti de acord, este important sa le oferiti ocazia de a vorbi.

Aratati ca si voi sunteti deschisi la critica. Este un lucru important prin care aratati ca procesul nu este unidirectional si ca sunteti gata sa acceptati critici si feedback fata de munca voastra. Puteti sa le sugerati programatorilor sa ia parte la sesiunea de peer review a documentatiei de testare (test cases, test plan etc). Daca sunt de acord si aloca timp pentru asta, este util atat din punct de vedere psihologic dar si la nivel de rezultate si idei potentiale pe care le-ar putea avea fata de procesul de testare.

Tineti minte faptul ca sunteti o echipa. Oricat de trivial ar parea, trebuie sa tineti minte si sa le aduceti aminte si celorlalti acest aspect cand vedeti ca observatiile voastre nu sunt luate in seama.

Si un alt aspect care este important atunci cand impartiti biroul cu programatorii. Cand descoperiti un bug interesant sau critic, este normal sa va bucurati (majoritatea testerilor ar fi de acord cu voi) dar aveti grija cum faceti asta – oamenii ar putea sa va inteleaga gresit si sa creada ca va bucurati de problemele lor.
In partea a doua a acestui articol ne vom uita la strategii pentru a creste calitatea feedabck-ului tehnic intre tester si programator.

Victoria Slinyavchuk
Consultant on Software Testing