După o experiență de mai mult de nouă ani în industria software pot să spun că am ajuns să fac câte puțin din tot ce oferă acest domeniu. Am început cu un internship unde am făcut testare înainte de a învăța să scriu cod, am fost programator într-o firmă mică unde am făcut totul de la zero, inclusiv dezvoltare de baze de date. Acum ca tester la Betfair, sunt implicată în testarea funcțională cu accent pe automatizare, livrare continuă și testare de performanță.
În momentul în care mă gândeam să studiez programarea nu mi-aș fi imaginat care va fi calea mea în acest domeniu. Dar toate lucrurile pe care le-am făcut de-a lungul anilor m-au ajutat să devin bună în rolul actual.
Întrebările din titlul ar putea părea familiare majorității și unii dintre voi s-ar putea să aveți chiar opinii puternice în ceea ce privește răspunsurile la aceste întrebări. În ultimii ani au fost numeroase ocazii în care acest subiect a fost adus în discuție și s-au purtat conversații despre împărțirea responsabilităților în ceea ce privește testarea și programarea. În timp ce făceam cercetare pentru acest articol, m-am confruntat cu o multitudine de opinii despre acest subiect. Deși sunt de acord cu unele dintre ele, acest articol reprezintă viziunea mea asupra relației complexe dintre un programator și un tester, din perspectiva unei persoane care a ocupat ambele roluri de-a lungul carierei.
Au trecut vremurile în care un programator se ocupa doar cu scrisul codului, fără a-i păsa de ceea ce se întâmplă după. Sau cel puțin așa ar trebui. Codul pe care îl scriem trebuie să compileze, să ruleze, să poată fi instalat și să funcționeze cât de cât înainte de a-l testa. Cum poate un programator să fie sigur că codul pe care l-a scris face toate lucrurile enumerate mai sus fără a-l testa? Un programator ar trebui să depună un anumit efort pe partea de testare, fie că vorbim despre scrierea de unit teste, fie că vorbim despre testarea funcțională a codului pe propriul calculator. A înțelege și a vedea cum se comportă codul după ce a fost scris, cum se integrează cu restul produsului duce la creșterea nivelului unui programator. Oricând aveți dubii dacă trebuie să testați codul pe care îl scrieți întrebați-vă un lucru: „Mă simt confortabil să instalez codul în producție fără a fi testat și să îmi asum întreaga responsabilitate pentru defectele care apar?”
Programatorii nu ar trebuie să testeze în același fel în care o fac testerii. Cu toate acestea, acest lucru nu înseamnă că nu sunt în măsură să ajute în testare, iar în unele domenii specifice o vor face chiar mai bine decât testeri.
Dacă vă întrebați cât de multă testare ar trebui să facă un programator, răspunsul la această întrebare este în funcție de context. Din experiența mea, lista de mai jos este ceea ce un programator ar trebui să facă în termeni de testare înainte de a preda o bucată de cod testerilor:
Totodată, după cum cred că știți majoritatea, cu cât un defect este descoperit mai devreme, cu atât este mai ieftin de reparat și cu atât este produsul final mai de calitate.
Cred că toată lumea din domeniul software a auzit despre cuvântul „automation”, cel puțin o dată. Cel puțin o parte dintre oamenii care citesc acest articol au făcut sau fac automatizare. De asemenea, ar putea fi unii dintre voi care nu au încercat niciodată să scrie teste automate sau nu doresc să o facă. Nu este nicio problemă să nu vrei să scrii cod, dar tu ar trebui cel puțin să înveți cum să codezi.
Nu suntem așa de diferiți când vine vorba de scris cod. Sau cel puțin nu ar trebui să fim. Îmi place să privesc testarea automată tot ca programare, doar cu un set diferit de cerințe. Dacă ceea ce se cere de la un programator este de a scrie cod pentru a implementa o anumită funcționalitate, cerințele pentru un tester sunt de a scrie cod care să testeze acea funcționalitate. Uneori e mai greu să scrii cod, alteori să testezi. Într-o lume ideală, pentru fiecare programator care lucrează la un proiect există pe partea opusă un tester care încearcă sa strice codul, făcându-l astfel mai bun.
Din experiența mea, a știi să scrii cod te face un tester mai bun. În primul rând, adaugă valoarea la produsul final prin abilitatea de a rula aceleași teste în repetate rânduri după efortul inițial de implementare. În al doilea rând, îți oferă o mai bună înțelegere asupra implementării codului și poți descoperi noi modalități de a-l face să crape. Nu în ultimul rând, îți oferă timp în plus pe care îl poți petrece testând . A fi bun pe partea de testare și a învața să scrii cod nu se exclud reciproc. Învățând să codezi poți câștiga o cunoaștere mai aprofundată a arhitecturii, limitările și punctele forte ale unui limbaj de programare precum și alegerile pe care programatorii le fac în implementare. Toate aceste lucruri pot afecta efortul de testare.
Evident, ținând cont de experiența mea, ar părea că lucrurile sunt mai degrabă ușor de zis, dar greu de făcut. Dar eu sunt ferm convinsă că testele automate și testerii care scriu cod sunt viitorul în acest domeniu. Fără a merge prea departe, aici sunt câteva lucruri pe care un tester ar trebui să le automatizeze:
La prima vedere lista de mai sus nu pare foarte complicat de implementat însă o dată ce ai început, lucrurile se pot duce si mai departe
Deci, nu pare că rolurile se contopesc? În opinia mea, rolul de programator și cel de tester sunt încă roluri diferite și fiecare are propria zonă de expertiză. Dar, o dată cu extinderea echipelor cu abilități variate și cu nevoia de a livra din ce în ce mai repede noi toți trebuie să învățăm unii de la alții, în scopul de a avea cel mai bun produs. Ar trebui să avem întotdeauna imaginea de ansamblu în minte, produsul, clienții și când toate încercările eșuează, nu uitați să vorbiți unul cu celălalt.
de Peter Lawrey
de Răzvan Costa
