Oana Coșman
Așa că, la momentul respectiv nu avea suficientă încredere că poate scrie cod “adevărat”, de producție.
”Și mi-am spus: “ah, trebuie doar să găsesc problemele din cod? Deci nu să-l scriu eu… Hm, interesant. Pot să fac asta!”. Poate părea ciudată lipsa de încredere, având în vedere că terminasem o facultate de profil, dar când petreci timp printre oameni deștepți, ai standarde ridicate”.
Acum Anca este QE (Quality Engineering) Developer la Adobe, în echipa de Video Analytics. Și are un rol care i se potrivește. Anca ne-a povestit, pe scurt, pentru proiectul Oamenii din spatele codului, ce a învățat în anii de coding pentru testare.
- Automatizare, automatizare.
Automatizarea testelor face munca mai ușoară.
Am scris cod încă de la acel prim job, pur și simplu pentru că mi-a fost mai comod să automatizez anumite teste. Iar codul de producție nu era neapărat un mister, pentru că era unul dintre locurile în care vânam bug-uri.
- Privire de ansamblu și unde și în câte moduri ar putea să crape?
Dincolo de cod, s-a mai întamplat un lucru interesant: am învățat cât de important este să privesc un proiect în ansamblu, să pun altfel de întrebări, să mă pun în postura unui client care ar folosi produsul final, asta pe lângă exercițiul de imaginație obișnuit: unde și în câte moduri ar putea să crape?
- UX este the new black.
Mi se pare esențial să ai noțiuni de UX (user experience), pentru că degeaba ai un super produs, dacă utilizatorii nu au o experiență plăcută atunci când îl folosesc, dacă nu e suficient de intuitiv sau ușor de învățat.
Când am lucrat cu servicii, mă interesa ca API-urile să răspundă rapid, voiam să văd performanță,. Degeaba ai o interfață foarte bine gândită, dacă durează câteva secunde bune să-ți afișeze informațiile.
- Big data –întrebările despre performanța sistemului.
În echipa curentă, la Video Analytics, avem de a face cu (buzz word alert!) big data. Îmi pun întrebări precum: cât de performant este sistemul? Cum influențează varietatea datelor care intră în el performanța și corectitudinea procesării? Care sunt rezultatele procesării, și în ce formă ajung ele la clienți? Cum scalăm și ce se întâmplă când scalăm?
Lucrăm cu tehnologii relativ recente (Spark Streaming, Kafka), iar lista de întrebări de mai sus este ca un balaur: îi tai un cap, apar încă șapte. E fascinant!
- Limbajul sau framework-ul potrivit pentru problema de rezolvat.
Admir oamenii care se entuziasmează când apare un limbaj sau o tehnologie nouă, și la fel de mult îi admir pe cei care cunosc un limbaj pe dinăuntru și pe dinafară: exploratori și experți.
Orice tehnologie nouă va avea limitările ei la un moment dat, sau va apărea ceva mai bun (new things get old), și la fel nu există limbaj bun la toate. Cred că este esențial să fie ales limbajul sau framework-ul potrivit pentru problema ce trebuie rezolvată.
- Creativitate și imaginație.
În munca de QE, e important să ai imaginație și să prevezi cât mai multe scenarii cu care se pot confrunta utilizatorii, chiar dacă unele pot părea improbabile. Creativitatea cu care abordezi fiecare situație, constrângere sau limitare cu care te confrunți ajută la identificarea unor soluții eficiente.
- Am găsit un bug! 1 - 0 pentru mine, ha!
Se spune adesea că testerii au o plăcere macabră în a strica lucruri. Ceea ce nu se spune la fel de des este că fac asta pentru a vedea apoi dacă piesele se mai potrivesc la loc, și chiar dacă se potrivesc, oare mai merge totul ca înainte?
Trebuie să recunosc că uneori am o oarecare satisfacție când mă duc la un coleg, îl bat pe umăr, și îi zic cu un rânjet victorios: “Am găsit un bug! 1 - 0 pentru mine, ha!” (glumesc, nu țin scorul... dar zic “ha!").
Adevărul este că ne dorim la fel de mult cu toții ca un feature să fie de succes și să depistăm problemele înainte ca ele să ajungă în producție, de aceea colaborarea cu echipa de developeri rămâne poate cel mai important aspect al muncii de QE.
