Dacă ai trimis măcar o dată un GET request în Postman și ai văzut un 200 OK, știi deja că tool‑ul e intuitiv. Problema apare când proiectul crește: 3 medii de test, 40 de endpoint‑uri, și colegul de lângă tine îți zice că "nu știe ce token să pună". Acolo intervine Postman avansat — nu Postman ca sandbox, ci Postman ca instrument serios de testare API, integrat în fluxul de QA al echipei.
Acest ghid e pentru tine dacă ești tester manual care vrea să facă pasul spre testare API, sau junior care a auzit de Postman la un curs sau la DevTalks și vrea să vadă ce înseamnă în viața reală de proiect.
Ce înveți concret aici: cum organizezi endpoint‑urile în colecții reutilizabile, cum folosești variabile de mediu ca să nu mai schimbi manual URL‑uri și tokeni, și cum scrii validări automate în tab‑ul Tests — fără framework extern, fără Selenium, fără nimic complicat.
---
Colecțiile Postman — de ce contează structura înainte de orice altceva
O colecție Postman nu e doar un folder cu request‑uri. E documentație vie, suită de teste și artefact de onboarding pentru orice coleg nou — toate trei în același fișier JSON exportabil.
Gândește‑te la o aplicație de e‑commerce: ai endpoint‑uri pentru autentificare, catalog de produse, coș, comandă, plată. Dacă le ții în tab‑uri separate, fără nicio organizare, după două săptămâni nu mai știi care request e "cel bun". Structura recomandată e simplă: un folder per modul funcțional, request‑urile ordonate logic (happy path primul, edge cases după), și un nume descriptiv care include metoda HTTP și scopul — de exemplu "POST - Creare cont utilizator nou" sau "GET - Produse din categoria Electronice".
Un detaliu pe care mulți juniori îl omit: adaugă o descriere la fiecare request. Postman le agregă automat într‑o documentație publicabilă. La un proiect cu 40+ endpoint‑uri, diferența dintre o colecție documentată și una nedocumentată e câteva ore de debugging pentru oricine intră pe proiect după tine.
---
Variabilele de mediu — cum scapi de copy‑paste și de erori umane
Acesta e locul unde Postman devine cu adevărat puternic pentru testere.
Scenariul clasic: ai trei medii — DEV, STAGING și PROD. Fiecare are alt URL de bază, altă cheie de API, alt token de autentificare. Dacă schimbi manual fiecare request când treci dintr‑un mediu în altul, nu faci testare, faci muncă de copist. Și greșești.
Soluția: creezi trei Environment‑uri în Postman (DEV, STAGING, PROD) și definești în fiecare aceleași variabile — {{base_url}}, {{api_key}}, {{auth_token}}. În request‑uri folosești doar variabilele, nu valorile directe. Când vrei să testezi pe STAGING, selectezi environmentul din dropdown și gata — toate cele 40 de request‑uri din colecție folosesc automat URL‑ul și credențialele corecte.
Există și variabile globale (disponibile în toate colecțiile) și variabile de colecție (valabile doar în colecția respectivă). Ca regulă practică: datele sensibile — tokeni, parole — stau în variabile de environment, nu în colecție, ca să nu le exporți accidental într‑un fișier JSON partajat pe Git.
Un pas în plus: poți seta variabile dinamic, din răspunsul unui request. De exemplu, după un POST la /login primești un JWT token în response body. Cu două linii în tab‑ul Pre‑request Script sau Tests, salvezi acel token într‑o variabilă de mediu și îl folosești automat în toate request‑urile următoare. Zero copy‑paste, zero eroare umană.
---
Scripturile de validare din Tests — automatizare fără cod "serios"
Tab‑ul Tests din Postman rulează JavaScript după ce primești răspunsul. Sună complicat, dar Postman pune la dispoziție snippets gata scrise — dai click și codul apare. Nu trebuie să știi JavaScript ca să începi.
Cele mai utile validări pe care ar trebui să le ai în orice request de test
- Status code corect: pm.test("Status 200", () => pm.response.to.have.status(200));
- Timp de răspuns acceptabil: pm.test("Raspuns sub 500ms", () => pm.expect(pm.response.responseTime).to.be.below(500));
- Câmp prezent în response body: pm.test("Exista campul userId", () => pm.expect(pm.response.json()).to.have.property("userId"));
- Valoare exactă: pm.test("Status comanda este PENDING", () => pm.expect(pm.response.json().status).to.eql("PENDING"));
Aceste patru tipuri de validare acoperă 80% din nevoile de testare API ale unui proiect obișnuit. Nu ai nevoie de Selenium, nu ai nevoie de un framework de testare separat — Postman face totul în browser sau în aplicația desktop.
Un detaliu important pentru credibilitate în echipă: când un test eșuează, mesajul din pm.test e cel care apare în raport. Fă-l descriptiv — "Status 200 la GET /products" bate "test1" de fiecare dată.
---
Collection Runner și Newman — de la click manual la pipeline
Până acum ai validat request‑urile individual. Collection Runner îți permite să rulezi toată colecția dintr‑o singură acțiune — cu iterații, cu date din fișiere CSV sau JSON, cu delay între request‑uri dacă API‑ul are rate limiting.
Scenariul practic: vrei să testezi că poți crea 50 de utilizatori cu date diferite. Pregătești un fișier CSV cu 50 de rânduri (username, email, password), îl încarci în Runner, și Postman rulează colecția de 50 de ori, câte un set de date per iterație. Rezultatele — câte teste au trecut, câte au picat, timpii de răspuns — le ai într‑un raport vizual.
Pentru integrare în pipeline‑ul de CI/CD, Postman oferă Newman — un runner de linie de comandă. Instalezi Newman cu npm, rulezi colecția ta cu o comandă, și raportul apare în GitHub Actions sau Azure DevOps exact ca orice alt pas de build. Echipele care au adoptat această abordare raportează că detectează regresii de API cu ore înaintea echipei de development — ceea ce schimbă dramatic dinamica de colaborare.
La A4Q Summit și la edițiile recente de DevTalks, testarea API a apărut constant în discuțiile despre maturizarea echipelor de QA. Nu mai e un nice‑to‑have — e o competență de bază așteptată chiar și de la testeri cu experiență de 1‑2 ani.
---
Greșeli frecvente pe care le fac testerii la început cu Postman
Prima greșeală: să nu versionezi colecțiile. Exportează colecția ca JSON și pune‑o în același repository Git cu codul aplicației. Când aplicația se schimbă, și testele API se schimbă — trebuie să fie sincronizate.
A doua greșeală: tokeni hardcodați în request‑uri. Am văzut colecții exportate pe Slack cu API keys reale în ele. Variabilele de environment există exact pentru asta.
A treia greșeală: să ignori tab‑ul Tests complet și să validezi manual fiecare response. E ok la început, când înveți structura unui API. Dar pe termen lung, validarea manuală nu scalează — și primul sprint în care ai 200 de endpoint‑uri de testat te va convinge rapid.
---
Postman e unul dintre acele tool‑uri care cresc odată cu tine. Poți să îl folosești la nivel de beginner toată viața, sau poți să deblochezi nivelul următor și să devii testerul din echipă care știe să construiască o suită de teste API solidă, integrată în pipeline și ușor de menținut.
Dacă vrei să aprofundezi testarea API și să lucrezi cu exerciții hands‑on pe scenarii reale — din domenii precum bancar, retail sau energie — cursurile noastre de la Academia Testarii sunt construite exact pentru asta. 🚀 Găsești toate detaliile pe academiatestarii.ro — inclusiv opțiunile de certificare și programul cursurilor disponibile.
Primul pas e mereu cel mai greu. Restul vine de la sine. 😊
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #QualityAssurance