Ce presupune Testare/QA și se poate avansa?

Am avut o discuție ieri cu cineva care vrea să facă o schimbare majoră în carieră și se gândea la un parcurs de genul: jobul curent → tester/qa → programator. (am mai văzut raționamentul ăsta pe forum pe undeva.)

Acum… trebuie să recunosc, nu sunt foarte sigur ce presupune testarea asta. Ce am găsit intră în două categorii:

  • testarea automată (unit/e2e & co), unde este nevoie să știi programare, ori altfel… nu poți scrie testele
  • testarea manuală, care, din ce am găsit pe youtube e făcută în general de indieni și implică un script foarte detaliat de genul „faci click acolo → completezi cu X → faci click dincolo etc”.

(Presupun că testarea unei aplicații fără script ar implica o cunoaștere foarte bună a domeniului de aplicare, ceea ce de multe ori este… imposibil.)

Deci: ce presupune testarea/QA de fapt? Script? Altceva? Poți migra chiar atât de ușor pe cât spun alții spre dev (fără să urmezi vreun mentor de IT adică)?

3 Likes

Cea mai importanta parte acolo e cea de analiza si pregatirea scenariilor de test.
Ca si QA ar trebui sa poti lua o aplicatie sa identifici partile critice si sa pregatesti scenariile de test pentru astea (smoke test) si pe urma sa intri mai in detaliu cu testarea tuturor functionalitatilor.
Asta e partea importanta indiferent daca faci testare manuala sau automata.

Testele automate (e2e) se construiesc pe baza acestor scenarii pe urma, se prioritizeaza care sunt workflow-urile mai importante, se analizeaza care se pot automatiza si care nu.

Stabilirea scenariilor importante de test sunt lucrurile care definesc un QA bun.

Legat de trecerea de la QA la dev se poate ca de obicei prinzi un loc in echipa si daca este cerinta pe proiect si nu e nimeni altcineva disponibil sunt sanse mai bune sa poti continua ca developer decat cineva din afara.

3 Likes

Testarea e mult mai complexă decât pare dacă o faci bine.

Trebuie să faci matrici de teste, să evaluezi mereu cum poți testa cât mai mult cu cât mai puțin. Câteodată ai cross-browser testing sau ai mai multe dispozitive pe mobile.
Trebuie sa știi să scrii test case-uri, să creezi test plan-uri, să faci o suită cât mai stabilă, să creezi conținutul/datele.

Un tester bun e și proxy product owner pentru programator, adică poate explica ce și cum trebuie să funcționeze, arate și de ce. Se asigură și că fiecare task/story e destul de clar din punct de vedere al utilizatorului.
Un tester prost poate raporta ca și bug lucruri care n-au fost cerute sau nu estimează în sprint bine cât durează testarea. (cel mai dificil e când se livrează un feature la sfârșitul sprint-ului)

La anumite proiecte se rulează un așa numit regression testing manual, care înseamnă că înainte de un release testerii iau fiecare test case, se uită cam ce a fost afectat de schimbările recente și le pun intr-un test run si rulează testele.

Când se găsesc bug-uri (defecte față de cerințele din task/story/design) se descrie bug-ul cu pasii de reprodus, care ar fi expected resultul si care e actual resultul.

Unele bug-uri sunt foarte dificil de reprodus și poate fi foarte stresant să descrii exact pașii pentru reprodus.

Testerii creează și environment-urile de testare și staging, întrețin datele pentru teste.

Un tester care face automation e deja programator, poate fi foarte dificil la anumite proiecte. Câteodată fiecare programator scrie și teste automate. Dar sunt și cazuri în care pur și șimplu înregistrezi pașii din test case-ul manual cu un program. Sunt și teste de performanta, API testing sau chiar contract testing între microservicii , care sunt iarăși 100% programare și implica chiar multă matematică.

Sunt așa numitele smoke test-uri, care se rulează preferabil automat, deci nu e acceptabil să fie teste flaky, aici e mult de muncă de obicei fiindcă implica tot de la pipeline pana la test data.

În general te ajută mult să știi să testezi la ce lucrezi, te ajută să înțelegi mai bine task/story-urile.

Testarea manuală pe mine cel puțin m-ar omora psihic pe termen lung, trebuie să ai intuiție și experiență chiar mai multă ca programatorul în anumite cazuri. De exemplu un tester bun știe de SQL injection, de regex poisoning, de buffer overflow, de XSS, încearcă lucruri aiurea sistematic dar rațional, precum 30 februarie la data nasterii … Dacă sunt probleme în producție în post-mortem primii care vor fi luați la rost sunt testerii. (Un singur incident îți garanteaza probleme la performance review)

Dacă automation-ul e în definition of done o să fie criminal proiectul, în special dacă nu e trivial de automatizat.

La noi sunt cazuri de trecere de pe testare manuală pe testare automată, dar a luat 2-3 ani cu 5-10 ani experiență pe testare manuală. E mai ușor dacă te specializezi pe automatizare de teste când deja ești programator. De multe ori e chiar mai bine plătit fiindcă puțini știu cu ce se mănâncă.

Nu cred că cineva poate scăpa ușor de automatizare și să devină front-end de exemplu. E nevoie de o cerere clară, în majoritatea locurilor e mult mai greu să găsești pe cineva pe automatizare decât un dev.

5 Likes

Am vazut destule cazuri in care QA au trecut la dev, de obicei testerii care-si baga nasul si scriu teste automate complexe sunt racolati pentru dev la produsul respectiv. E un career path ok, numai tre sa vrea si sa munceasca.

4 Likes

Hello there,
Mă prinde subiectul și din experiența de mic pionier (2 ani) aș vrea să zic multe, dar prefer să nu las loc de prea mari interpretări și invit pe orice curios să-și scrie gandurile și să dea submit:

  • Ca path, cel mai probabil e la indemână să treci prin testare manuală, semi-automată și apoi să-ți formezi tu o idee despre liniile pe care le scrii inainte de a crea teste automate;
  • De multe ori, am observat, contează modul in care privești lucrurile, și de asta trebuie să vezi challenge-urile cu gând bun, pentru că, oarecum, face parte din ‘meserie’ să fi deschis la minte;
  • Nu te îndoi de abilitățile tale sub orice formă. tehnică, practică, whatever; poate ajută pe unii să zic că, în întregime, toți de pe forum sau din tech am fost la un moment dat debusolați că cel de lângă este sau pare mai bine pregătit, fiecare are path-ul lui și plecând de la Pascal la Python nu mi-a fost rușine niciodată nici să cer răspunsuri, nici să ofer.
    P.S. uite c-am făcut-o personală și lungă, părerea, că nu despre altceva vorbesc :wink:
2 Likes