Ți s‑a întâmplat vreodată să primești un fișier ZIP cu „testele_finale_v3_FINAL_ok.zip" și să te întrebi dacă există o cale mai bună? Există. Se numește Git, și nu e un secret rezervat exclusiv dezvoltatorilor. Este, de fapt, unul dintre cele mai utile tool‑uri pe care le poate stăpâni un tester modern — indiferent dacă lucrezi cu teste manuale documentate în Markdown, scripturi Selenium 4, fluxuri Playwright sau colecții Postman.
Hai să vorbim concret: ce faci cu Git de luni dimineața, cum nu strici nimic și cum arăți echipei că ești un coleg de nădejde în repository.
Git pentru testeri — De ce e treaba ta, nu doar a dev‑ilor
La DevTalks sau la A4Q Summit auzi tot mai des același lucru: testerul modern e un partener activ în pipeline‑ul de livrare, nu un gatekeeper care primește build‑ul la final. Asta înseamnă că lucrezi în aceleași tool‑uri cu echipa: JIRA pentru task‑uri, Git pentru cod și artefacte de test.
Concret, ca tester folosești Git pentru
- a versiona scripturile de automatizare (Cypress, Playwright, Selenium 4)
- a salva și partaja colecțiile Postman sau fișierele de configurare
- a documenta test case‑urile în format Markdown, alături de codul sursă
- a contribui la pipeline‑ul de CI/CD prin pull request‑uri bine structurate
Nu trebuie să fii developer ca să faci asta. Trebuie doar să înțelegi câteva comenzi esențiale și logica din spatele lor.
Clone și pull — Cum îți aduci repository‑ul pe calculator
Primul pas este să aduci proiectul pe mașina ta locală. Comanda `git clone` face exact asta: descarcă o copie completă a repository‑ului, cu tot istoricul de modificări.
`git clone https://github.com/echipa/proiect‑awesome.git`
De acum ai o copie locală. Dar colegii tăi continuă să lucreze și repository‑ul se schimbă. Înainte să începi orice sesiune de lucru, rulezi `git pull` pe branch‑ul principal (de obicei `main` sau `develop`) ca să aduci ultimele modificări. E ca și cum ai sincroniza documentul Google înainte să-l editezi — punct ochit, punct lovit.
Un tester care uită de `git pull` ajunge să lucreze pe o versiune veche a aplicației și se miră de ce bug‑urile pe care le‑a raportat „nu mai există". Le‑a fix‑uit cineva ieri. Ai mai văzut asta? Eu da.
Branch — Spațiul tău de lucru, fără să deranjezi pe nimeni
Acesta e conceptul care face Git cu adevărat puternic pentru colaborare. Un branch este o „ramură" separată în care lucrezi izolat față de restul echipei. Creezi un branch, faci modificările, și abia după ce totul e revizuit și aprobat, integrezi în branch‑ul principal.
Ca tester, creezi un branch atunci când
- adaugi teste noi de automatizare pentru o funcționalitate
- actualizezi un test case existent după o schimbare de cerință
- corectezi un script care s‑a stricat după o modificare de UI
Convenție recomandată pentru numele branch‑ului (și echipele serioase o respectă):
`git checkout -b test/QA‑123‑login‑negative‑scenarios`
Prefixul `test/` semnalează că e un branch de QA, iar codul `QA‑123` face legătura directă cu task‑ul din JIRA. Colegii tăi dev vor ști imediat cu ce au de‑a face.
Regula de aur: nu lucra niciodată direct pe `main`. Niciodată. Chiar dacă pare mai rapid, riscul de a introduce o eroare în ramura principală este real, iar consecințele pot bloca întreg pipeline‑ul de CI/CD.
Pull Request — Cum îți prezinți munca și inviți la dialog
Ai terminat scripturile, ai rulat testele local, totul e verde. Acum vine momentul pull request‑ului (PR) — cererea formală prin care îți propui modificările pentru integrare în branch‑ul principal.
Un PR bun din partea unui tester conține
- Descriere clară: ce ai testat, ce scenarii acoperă scripturile noi, ce tool‑uri ai folosit (ex: Playwright 1.44, Node 20)
- Link către task‑ul JIRA: „Closes QA‑123" sau „Related to DEV‑456"
- Checklist: ai rulat testele local? Trec toate? Există dependențe de configurare (variabile de mediu, baze de date MySQL, mock‑uri)?
- Screenshot sau log: dacă e relevant, un output de terminal sau un raport de test adaugă credibilitate instantaneu
PR‑ul nu e doar un mecanism tehnic — e o conversație. Poate un developer observă că testezi un endpoint care urmează să fie refactorizat săptămâna viitoare. Mai bine să afli acum, nu după ce ai investit 3 ore în scripturi care vor fi invalide.
Colaborarea cu dev‑ii — Mindset‑ul care face diferența
Aici intervine ceva mai greu de pus în cod, dar la fel de important: mindset‑ul de colaborare. Git e un tool; relația cu echipa e ce contează cu adevărat.
Câteva principii care funcționează în echipele sănătoase
- Reviewuiești și tu PR‑urile lor. Nu neapărat codul în sine, dar poți verifica dacă au adăugat sau actualizat testele unitare, dacă descrierea acoperă cazurile edge, dacă există risc de regresie pe zone pe care le cunoști bine.
- Comentezi constructiv, nu critic. „Cred că scenariul X nu e acoperit, ce zici să-l adăugăm?" e mult mai bine decât „lipsesc teste."
- Comunici blocajele rapid. Dacă branch‑ul tău depinde de o modificare a unui API care nu e gata, spune‑o în PR sau în JIRA — nu lăsa echipa să descopere asta la review.
- Îți ții branch‑urile curate. Branch‑uri abandonate, cu nume gen `test_vechi_2` sau `ramura‑mea`, creează confuzie. Șterge‑le după ce PR‑ul e mergeuit.
Un #FunFact din teren: echipele care au implementat un proces clar de PR review — inclusiv QA‑ul în buclă — au raportat cu până la 40% mai puține bug‑uri de regresie descoperite în producție. Nu e magie, e vizibilitate.
Comenzile Git pe care le folosești zilnic ca tester
Fără teorie în plus, iată lista scurtă pe care o vei consulta des la început
- `git clone <url>` — prima dată, aduci proiectul local
- `git pull` — sincronizezi cu ce e nou în repository
- `git checkout -b test/nume‑branch` — creezi un branch de lucru
- `git status` — vezi ce fișiere ai modificat
- `git add .` — pregătești modificările pentru commit
- `git commit -m "test: adaug scenarii negative pentru login (QA‑123)"` — salvezi modificările cu un mesaj descriptiv
- `git push origin test/nume‑branch` — trimiți branch‑ul în repository‑ul remote
- Apoi deschizi PR‑ul din interfața GitHub / GitLab / Bitbucket
Mesajele de commit contează. „fix" sau „update" nu spun nimic. „test: adaug scenarii de timeout pentru API‑ul de plăți" spune tot ce trebuie.
Vrei să înveți Git în contextul QA, nu din tutoriale generice?
La Academia Testarii predăm Git exact așa cum îl folosești ca tester — în proiecte reale, alături de Selenium 4, Playwright, Postman și pipeline‑uri de CI/CD. Nu teorie izolată, ci fluxuri de lucru complete, de la clonarea repository‑ului până la primul pull request acceptat de echipă.
Dacă ești la început de drum sau vrei să-ți sistematizezi cunoștințele înainte de primul job QA, cursurile noastre de pe academiatestarii.ro sunt construite exact pentru asta. Avem cursanți care au plecat fără niciun background tehnic și care astăzi contribuie activ în echipe Agile cu zeci de developeri.
Primul pas e al tău. Noi suntem aici. 😊
Intră pe academiatestarii.ro, uită-te la traseul de învățare și, dacă ai întrebări, scrie‑ne — abia așteptăm să auzim de tine.
#DeAziEstiTester #AcademiaTestarii #TestAutomation #SoftwareTesting #TestareSoftware