Prima zi într‑o echipă de QA. Primești acces la JIRA, deschizi board‑ul și... te uiți la vreo 200 de carduri colorate, filtre necunoscute și un backlog care pare că nu se mai termină. Senzația că ai intrat în camera greșită e perfect normală.
Vestea bună: JIRA nu e complicat. E doar nefamiliar. Și există o diferență uriașă între cele două.
În tutorialul ăsta îți arăt exact ce trebuie să știi ca tester junior: cum creezi un task, cum raportezi un bug ca un profesionist, cum citești un sprint board fără să intri în panică și unde NU trebuie să apeși niciodată fără să întrebi. Shall we?
Ce este JIRA și de ce îl folosesc aproape toate echipele de QA
JIRA este un tool de project management creat de Atlassian, folosit pentru a urmări activitatea unei echipe în cicluri scurte numite sprinturi (de obicei 1‑2 săptămâni). În România, îl găsești în echipe din domenii extrem de diverse: bancar, automotive, retail, energie, ospitalitate. La evenimentele de industrie — DevTalks, A4Q Summit, GoTech World — aproape niciun speaker care prezintă un workflow de QA nu trece peste JIRA sau un echivalent al lui.
Ca tester, rolul tău în JIRA este triplu: consumi task‑uri (preiei ce ai de testat), creezi bug‑uri (raportezi ce găsești) și monitorizezi progresul (știi oricând unde se află echipa față de obiectivul sprint‑ului). Simplu în teorie, ușor de aplicat în practică odată ce ai structura clară.
Anatomia unui proiect JIRA: ce vezi pe ecran și ce înseamnă fiecare element
Când intri într‑un proiect, ai câteva zone esențiale
- Board — tabloul de bord vizual al sprint‑ului activ, cu coloane de tipul To Do / In Progress / In Review / Done. Acesta este locul unde petreci cel mai mult timp.
- Backlog — lista tuturor task‑urilor care nu sunt încă într‑un sprint. Aici Product Owner‑ul și Scrum Master‑ul fac prioritizarea.
- Issues — orice "item" din JIRA: story, task, sub‑task, bug, epic. Termenul generic e issue.
- Sprint — un interval de timp fix în care echipa se angajează să livreze un set definit de issue‑uri.
Un sfat pe care orice senior tester îl va confirma: nu modifica niciodată statusul unui task dacă nu ești sigur că ai voie. Întreabă mai întâi. Unele echipe au workflow‑uri customizate și un click greșit poate scoate un card din sprint fără să vrea nimeni asta.
Cum creezi un task sau un sub‑task în JIRA: pas cu pas
Crearea unui issue e simplă: butonul "+ Create" din bara de navigare de sus. Dar ce completezi acolo face toată diferența.
Câmpurile pe care nu le sări niciodată
- Summary — titlul issue‑ului. Fii specific: "Test login cu credențiale invalide — modul autentificare" e mai util decât "Test login".
- Issue Type — alegi Task, Sub‑task sau Bug, în funcție de ce creezi.
- Project și Sprint — asigură-te că issue‑ul ajunge în locul potrivit, nu în alt proiect.
- Assignee — cine preia task‑ul. Dacă e pentru tine, te auto‑asignezi.
- Priority — Most și Highest le lași pentru situații cu adevărat critice. Nu totul e blocker.
- Description — scrie ce trebuie testat, ce context există, orice link relevant.
Un sub‑task îl creezi din interiorul unui task‑părinte, din secțiunea "Child issues" sau "Sub‑tasks", în funcție de versiunea JIRA pe care o folosești (Cloud vs. Server au interfețe ușor diferite).
Cum raportezi un bug ca un profesionist, nu ca un junior
Bug‑ul bun e bug‑ul care nu necesită întrebări suplimentare. Dacă un developer deschide issue‑ul tău și înțelege imediat ce s‑a întâmplat, unde și în ce condiții — ai câștigat respectul echipei fără să scoți un cuvânt.
Structura unui bug report solid în JIRA
- Summary: "[Modul] Scurtă descriere a problemei" — ex.: "[Coș de cumpărături] Prețul nu se actualizează la schimbarea cantității"
- Steps to Reproduce: pași numerotați, clari, reproductibili de oricine
- Expected Result: ce ar trebui să se întâmple conform specificațiilor sau logicii comune
- Actual Result: ce se întâmplă de fapt
- Environment: browser, OS, versiunea aplicației — ex.: Chrome 124, Windows 11, staging build 3.4.1
- Severity / Priority: ai grijă să nu supraevaluezi. Un bug cosmetic nu e Critical.
- Attachments: screenshot, video, log — JIRA permite atașamente direct în issue. Folosește‑le.
Dacă echipa folosește și Selenium 4 sau Playwright pentru automation, poți atașa direct output‑ul de test eșuat sau stack trace‑ul din pipeline. Contextul tehnic în plus e întotdeauna apreciat.
Cum urmărești progresul unui sprint fără să deranjezi echipa la fiecare 10 minute
Board‑ul de sprint e cel mai honest indicator al sănătății unui sprint. Uită-te la el dimineața înainte de daily standup și vei ști deja jumătate din ce se discută acolo.
Ce să urmărești
- Câte issue‑uri sunt în Done față de total — îți dă o idee despre ritmul echipei.
- Carduri blocate sau în In Progress de mai mult de 2‑3 zile — pot semnala impedimente pe care le poți raporta în standup.
- Bug‑urile tale — verifică dacă au primit un comentariu, dacă statusul s‑a schimbat în "In Progress" (înseamnă că developerul lucrează la fix) sau dacă au primit eticheta "Won't Fix" sau "Duplicate" (caz în care merită o discuție scurtă).
JIRA oferă și un Burndown Chart în secțiunea Reports — un grafic care arată dacă echipa e pe drumul cel bun față de obiectivul sprint‑ului. Nu e obligatoriu să îl analizezi în profunzime de la prima zi, dar merită să știi că există.
Un #FunFact util: la evenimentele A4Q Summit la care participăm și noi, un subiect recurent în sesiunile pentru juniori este tocmai igiena JIRA — cum arată un backlog bine întreținut versus unul neglijat și ce impact are asta asupra calității livrărilor. Infrastructura unui proiect sănătos începe din board.
Greșelile clasice ale unui tester junior în JIRA (și cum le eviți)
Le‑am văzut, le‑am trăit, le‑am share‑uit cu cursanții noștri. Scurtă listă:
- Raportezi bug‑uri duplicate pentru că nu ai căutat înainte în backlog. Folosește filtrul de Search înainte să creezi orice issue nou.
- Lași câmpul Environment gol. Niciodată.
- Muți singur un card în Done fără să confirmi cu developerul sau Scrum Master‑ul.
- Scrii un Summary vag de tipul "nu merge butonul". Cui nu îi merge? Unde? Când?
- Setezi prioritatea Maximum la tot ce găsești. Lupul cel rău din fabulă — dacă totul e critic, nimic nu e critic.
Evitând aceste cinci greșeli ești deja mai helpful decât mulți juniori în prima lună de job.
---
JIRA e un tool, nu un test de admitere. Odată ce îi înțelegi logica, devine o extensie naturală a felului în care gândești ca tester: structurat, precis, orientat spre context.
Dacă vrei să înveți JIRA în contextul unui curs complet de testare software — alături de test case‑uri, SQL cu MySQL, Postman, Chrome DevTools și primele noțiuni de automation — te așteptăm la Academia Testarii. Cursanții noștri au un avantaj real când intră la interviuri: știu să lucreze în tool‑urile pe care le folosesc echipele reale din România. Intră pe academiatestarii.ro și descoperă cursul potrivit pentru tine. 🚀
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #CursuriTestare