Imaginează-ți că ești la prima zi pe un proiect nou. Designerul încă lucrează la mockup‑uri, frontend‑ul e la două sprint‑uri distanță, dar backend‑ul e deja up. Ce faci? Aștepți? Niciodată. Deschizi Postman și începi să testezi.
Acesta e unul dintre cele mai valoroase mindset‑uri pe care le poți dezvolta ca tester: să înțelegi că aplicația nu înseamnă doar ce vezi pe ecran. Dincolo de butoane și formulare există un strat de logică — API‑ul — și acolo se ascund unele dintre cele mai interesante bug‑uri.
Ce este un API REST și de ce ar trebui să te intereseze
API înseamnă Application Programming Interface. Concret, e un „translator" care permite două sisteme să comunice. REST (Representational State Transfer) e cel mai comun stil arhitectural pentru web — îl întâlnești în banking, retail, automotive, energie, ospitalitate, practic în orice domeniu digital.
Când apeși „Adaugă în coș" pe un site, frontend‑ul trimite un request către un API. API‑ul vorbește cu baza de date — adesea MySQL sau PostgreSQL — și îți întoarce un răspuns. Tu, ca tester, poți reproduce exact acel schimb de mesaje fără să ai nevoie de interfață. Asta înseamnă putere reală.
Postman: primul tău instrument de API testing
Postman e un tool gratuit, cu interfață vizuală, perfect pentru cei care încep. Nu ai nevoie să scrii cod ca să trimiți primul request — dar dacă vrei să mergi mai departe, Postman îți permite să scrii teste în JavaScript chiar în colecțiile tale.
Pașii esențiali pentru început
- Instalezi Postman de pe postman.com (varianta desktop sau web).
- Creezi o colecție nouă — gândește‑o ca pe un dosar organizat de test case‑uri pentru un modul sau un endpoint.
- Adaugi un request: selectezi metoda HTTP (GET, POST, PUT, DELETE), introduci URL‑ul și, dacă e cazul, un body în format JSON.
- Trimiți request‑ul și analizezi răspunsul.
Un exemplu simplu: vrei să verifici că endpoint‑ul /users/1 returnează datele corecte pentru un utilizator existent. Selectezi GET, introduci URL‑ul, apeși Send. Dacă totul e bine, primești un status 200 OK și un JSON cu datele utilizatorului. Dacă primești 404, înseamnă că resursa nu există. Dacă primești 500, serverul are o problemă internă. Punct ochit, punct lovit.
Cum citești un răspuns HTTP fără să te pierzi
Codurile de status HTTP sunt limba în care API‑ul îți vorbește. Nu e nevoie să le memorezi pe toate, dar câteva sunt esențiale pentru orice tester:
- 2xx — Succes. 200 OK (totul bine), 201 Created (resursa a fost creată), 204 No Content (acțiunea s‑a executat, dar nu e nimic de returnat).
- 4xx — Eroare de client. 400 Bad Request (ai trimis date incorecte), 401 Unauthorized (lipsește autentificarea), 403 Forbidden (ai autentificare, dar nu ai permisiune), 404 Not Found (resursa nu există), 422 Unprocessable Entity (datele sunt structurate corect, dar conțin valori invalide).
- 5xx — Eroare de server. 500 Internal Server Error (ceva a explodat pe backend), 503 Service Unavailable (serverul e supraîncărcat sau în mentenanță).
Pe lângă status code, uită-te și la body‑ul răspunsului. Un API bine scris îți returnează mesaje descriptive — „email already in use", „field 'phone' is required". Un API prost scris îți dă un generic „error" și trebuie să sapi. Documentează ambele situații.
Cum raportezi un bug de API fără să existe interfața
Mulți juniori se blochează aici: „Cum raportez un defect dacă nu am screenshot?" Răspuns simplu — nu ai nevoie de screenshot, ai nevoie de ceva mai precis.
Un bug report de API bun, în JIRA sau orice alt tracker, conține
- Endpoint + metodă HTTP: POST /api/v1/register
- Request body (sau parametrii trimiși): JSON‑ul exact pe care l‑ai folosit.
- Comportament actual: status code primit + body‑ul răspunsului, copiat din Postman.
- Comportament așteptat: ce spune documentația API (Swagger, Confluence, un simplu document Word) că ar trebui să se întâmple.
- Severitate și prioritate: un 500 pe endpoint‑ul de login e critic. Un mesaj de eroare formulat greșit e minor.
Un exemplu real: trimiți un request de înregistrare cu un email invalid (fără @). Aștepți un 400 cu un mesaj clar. Primești în schimb un 200 OK și utilizatorul e creat în baza de date cu email invalid. Ăsta e un bug serios — și l‑ai găsit înainte ca orice utilizator real să fi atins vreun buton.
Postman Collections și automatizare ușoară
Odată ce ai câteva request‑uri funcționale, poți face mai mult decât testare manuală. Postman îți permite să adaugi teste în tab‑ul Tests al fiecărui request — bucăți mici de JavaScript care verifică automat răspunsul:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response has user id", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.id).to.be.a("number");
});
Rulezi toată colecția cu Collection Runner și ai un raport instant: câte teste au trecut, câte au picat. Nu e Selenium 4, nu e Cypress, nu e Playwright — dar e un prim pas solid spre test automation, accesibil oricui. La evenimentele din comunitate — DevTalks, A4Q Summit — vei auzi tot mai des că diferența dintre un junior bun și unul excelent e tocmai această curiozitate de a merge dincolo de UI.
Câteva greșeli comune pe care să le eviți de la început
Prima greșeală: să testezi doar happy path‑ul. Da, e frumos când totul merge. Dar trimite și date goale, și valori negative, și string‑uri acolo unde se așteaptă numere. API‑ul trebuie să fie robust, nu doar politicos.
A doua greșeală: să ignori headerele. Content‑Type, Authorization, Accept — fac parte din request și pot schimba complet comportamentul API‑ului. Un request fără Authorization header pe un endpoint protejat ar trebui să returneze 401, nu 200.
A treia greșeală: să nu salvezi nimic. Organizează request‑urile în colecții, folosește variabile de mediu pentru URL‑ul de bază și token‑uri, exportă colecția și pune‑o în repository. Munca ta are valoare dincolo de sesiunea curentă.
Fă primul pas împreună cu noi
API testing nu e un subiect exotic rezervat seniorilor cu ani de experiență. E o competență practică, mâini-în‑code (sau mai degrabă mâini-în‑Postman), pe care o poți construi de la zero în câteva săptămâni.
La Academia Testarii predăm exact asta: nu teorie de dragul teoriei, ci skilluri pe care le poți demonstra la interviu sau folosi din prima zi la job. Avem cursanți care au trecut prin modulele noastre de testing tehnic și au reușit să raporteze bug‑uri de API reale înainte să termine programul.
Dacă vrei să afli cum arată un curriculum complet — de la manual testing, prin API testing cu Postman, până la automatizare cu Selenium sau Playwright — intră pe academiatestarii.ro și explorează cursurile disponibile. Sau scrie‑ne direct; noi răspundem. 🚀
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #TestareSoftware