Primul meu job a fost in testare. Desi nu aveam nici macar un internship la activ, ceva imi spunea ca a lucra intr-o companie, la un produs “adevarat” presupune ceva mai mult decat proiectele din facultate, adica chiar sa mearga, si sa mearga bine.
Material realizat pe platforma Oamenii din Spatele Codului de Anca Balanel, QE la Adobe Romania.
Asa ca la momentul respectiv nu aveam suficienta incredere ca pot scrie cod “adevarat”, de productie. Si mi-am spus: “ah, trebuie doar sa gasesc problemele din cod? Deci nu sa-l scriu eu… Hm, interesant. Pot sa fac asta!”. Poate parea ciudata lipsa de incredere, avand in vedere ca terminasem o facultate de profil, dar cand petreci timp printre oameni destepti, ai standarde ridicate.
Fast forward cu cativa ani: acum sunt QE (Quality Engineering) Developer la Adobe, in echipa de Video Analytics. Si imi place sa spun ca am un rol care mi se potriveste. Ce am invatat in anii de coding pentru testare:
1. Automatizare, automatizare
Automatizarea testelor face munca mai usoara. Am scris cod inca de la acel prim job, pur si simplu pentru ca mi-a fost mai comod sa automatizez anumite teste. Iar codul de productie nu era neaparat un mister, pentru ca era unul dintre locurile in care vanam bug-uri.
2. Privire de ansamblu si unde si in cate moduri ar putea sa crape?
Dincolo de cod, s-a mai intamplat un lucru interesant: am invatat cat de important este sa privesc un proiect in ansamblu, sa pun altfel de intrebari, sa ma pun in postura unui client care ar folosi produsul final, asta pe langa exercitiul de imaginatie obisnuit: unde si in cate moduri ar putea sa crape?
3. UX este the new black
Mi se pare esential sa ai notiuni de UX (user experience), pentru ca degeaba ai un super produs, daca utilizatorii nu au o experienta placuta cand il folosesc, daca nu e suficient de intuitiv sau usor de invatat.
Cand am lucrat cu servicii, ma interesa ca API-urile sa raspunda rapid, voiam sa vad performanta, degeaba ai o interfata foarte bine gandita, daca dureaza cateva secunde bune sa-ti afiseze informatiile.
4. Big data –intrebarile despre performanta sistemului
In echipa curenta, la Video Analytics, avem de a face cu (buzz word alert!) big data. Imi pun intrebari precum: cat de performant este sistemul? cum influenteaza varietatea datelor care intra in el performanta si corectitudinea procesarii? care sunt rezultatele procesarii, si in ce forma ajung ele la clienti? cum scalam si ce se intampla cand scalam? Lucram cu tehnologii relativ recente (Spark Streaming, Kafka), iar lista de intrebari de mai sus este ca un balaur: ii tai un cap, apar inca sapte. E fascinant!
5. Limbajul sau framework-ul potrivit pentru problema de rezolvat
Admir oamenii care se entuziasmeaza cand apare un limbaj sau o tehnologie noua, si la fel de mult ii admir pe cei care cunosc un limbaj pe dinauntru si pe dinafara: exploratori si experti. Orice tehnologie noua va avea limitarile ei la un moment dat, sau va aparea ceva mai bun (new things get old), si la fel nu exista limbaj bun la toate. Cred ca este esential sa fie ales limbajul sau framework-ul potrivit pentru problema ce trebuie rezolvata.
6. Creativitate si imaginatie
In munca de QE, e important sa ai imaginatie si sa prevezi cat mai multe scenarii cu care se pot confrunta utilizatorii, chiar daca unele pot parea improbabile. Creativitatea cu care abordezi fiecare situatie, constangere sau limitare cu care te confrunti ajuta la identificarea unor solutii eficiente.
7. Am gasit un bug! 1 - 0 pentru mine, ha!
Se spune adesea ca testerii au o placere macabra in a strica lucruri. Ceea ce nu se spune la fel de des este ca fac asta pentru a vedea apoi daca piesele se mai potrivesc la loc, si chiar daca se potrivesc, oare mai merge totul ca inainte? Trebuie sa recunosc ca uneori am o oarecare satisfactie cand ma duc la un coleg, il bat pe umar, si ii zic cu un ranjet victorios: “Am gasit un bug! 1 - 0 pentru mine, ha!” (glumesc, nu tin scorul... dar zic “ha!").
Adevarul este ca ne dorim la fel de mult cu totii ca un feature sa fie de succes si sa depistam problemele inainte ca ele sa ajunga in productie, de aceea colaborarea cu echipa de developer ramane poate cel mai important aspect al muncii de QE.
Primul meu job a fost in testare. Desi nu aveam nici macar un internship la activ, ceva imi spunea ca a lucra intr-o companie, la un produs “adevarat” presupune ceva mai mult decat proiectele din facultate, adica chiar sa mearga, si sa mearga bine.
Material realizat pe platforma Oamenii din Spatele Codului de Anca Balanel, QE la Adobe Romania.
Asa ca la momentul respectiv nu aveam suficienta incredere ca pot scrie cod “adevarat”, de productie. Si mi-am spus: “ah, trebuie doar sa gasesc problemele din cod? Deci nu sa-l scriu eu… Hm, interesant. Pot sa fac asta!”. Poate parea ciudata lipsa de incredere, avand in vedere ca terminasem o facultate de profil, dar cand petreci timp printre oameni destepti, ai standarde ridicate.
Fast forward cu cativa ani: acum sunt QE (Quality Engineering) Developer la Adobe, in echipa de Video Analytics. Si imi place sa spun ca am un rol care mi se potriveste. Ce am invatat in anii de coding pentru testare:
1. Automatizare, automatizare
Automatizarea testelor face munca mai usoara. Am scris cod inca de la acel prim job, pur si simplu pentru ca mi-a fost mai comod sa automatizez anumite teste. Iar codul de productie nu era neaparat un mister, pentru ca era unul dintre locurile in care vanam bug-uri.
2. Privire de ansamblu si unde si in cate moduri ar putea sa crape?
Dincolo de cod, s-a mai intamplat un lucru interesant: am invatat cat de important este sa privesc un proiect in ansamblu, sa pun altfel de intrebari, sa ma pun in postura unui client care ar folosi produsul final, asta pe langa exercitiul de imaginatie obisnuit: unde si in cate moduri ar putea sa crape?
3. UX este the new black
Mi se pare esential sa ai notiuni de UX (user experience), pentru ca degeaba ai un super produs, daca utilizatorii nu au o experienta placuta cand il folosesc, daca nu e suficient de intuitiv sau usor de invatat.
Cand am lucrat cu servicii, ma interesa ca API-urile sa raspunda rapid, voiam sa vad performanta, degeaba ai o interfata foarte bine gandita, daca dureaza cateva secunde bune sa-ti afiseze informatiile.
4. Big data –intrebarile despre performanta sistemului
In echipa curenta, la Video Analytics, avem de a face cu (buzz word alert!) big data. Imi pun intrebari precum: cat de performant este sistemul? cum influenteaza varietatea datelor care intra in el performanta si corectitudinea procesarii? care sunt rezultatele procesarii, si in ce forma ajung ele la clienti? cum scalam si ce se intampla cand scalam? Lucram cu tehnologii relativ recente (Spark Streaming, Kafka), iar lista de intrebari de mai sus este ca un balaur: ii tai un cap, apar inca sapte. E fascinant!
5. Limbajul sau framework-ul potrivit pentru problema de rezolvat
Admir oamenii care se entuziasmeaza cand apare un limbaj sau o tehnologie noua, si la fel de mult ii admir pe cei care cunosc un limbaj pe dinauntru si pe dinafara: exploratori si experti. Orice tehnologie noua va avea limitarile ei la un moment dat, sau va aparea ceva mai bun (new things get old), si la fel nu exista limbaj bun la toate. Cred ca este esential sa fie ales limbajul sau framework-ul potrivit pentru problema ce trebuie rezolvata.
6. Creativitate si imaginatie
In munca de QE, e important sa ai imaginatie si sa prevezi cat mai multe scenarii cu care se pot confrunta utilizatorii, chiar daca unele pot parea improbabile. Creativitatea cu care abordezi fiecare situatie, constangere sau limitare cu care te confrunti ajuta la identificarea unor solutii eficiente.
7. Am gasit un bug! 1 - 0 pentru mine, ha!
Se spune adesea ca testerii au o placere macabra in a strica lucruri. Ceea ce nu se spune la fel de des este ca fac asta pentru a vedea apoi daca piesele se mai potrivesc la loc, si chiar daca se potrivesc, oare mai merge totul ca inainte? Trebuie sa recunosc ca uneori am o oarecare satisfactie cand ma duc la un coleg, il bat pe umar, si ii zic cu un ranjet victorios: “Am gasit un bug! 1 - 0 pentru mine, ha!” (glumesc, nu tin scorul... dar zic “ha!").
Adevarul este ca ne dorim la fel de mult cu totii ca un feature sa fie de succes si sa depistam problemele inainte ca ele sa ajunga in productie, de aceea colaborarea cu echipa de developer ramane poate cel mai important aspect al muncii de QE.