Postman de la zero: cum trimiți primul request și validezi un API REST în 30 de minute

Știi senzația aceea când colegii de development vorbesc despre „endpoint‑uri", „status codes" și „payload JSON" și tu zâmbești politicos, sperând că nimeni nu te întreabă nimic? Ei bine, azi se termină cu zâmbetul acela. Postman este tool‑ul care a democratizat testarea de API și, după ce parcurgi rândurile de mai jos, vei putea trimite primul tău request și vei înțelege ce se întâmplă „în culise" — în mai puțin de 30 de minute. Shall we? **De ce API testing și de ce acum?** Înainte să deschidem Postman, merită un minut de context. Într‑un proiect modern — indiferent că vorbim de banking, retail sau automotive — interfața vizuală (UI‑ul) este doar vârful icebergului. Sub el trăiesc zeci de API‑uri REST care mișcă date între servicii, baze de date MySQL, sisteme ERP și aplicații mobile. Un bug prins la nivel de API costă de 10 ori mai puțin decât același bug descoperit în producție, după ce a trecut prin toată pipeline‑ul de livrare. La DevTalks și la A4Q Summit, subiectul „shift‑left testing" apare în fiecare ediție tocmai pentru că echipele înțeleg că trebuie să testezi mai devreme, mai aproape de cod. API testing este prima treaptă practică a acestei filozofii, iar Postman este cel mai bun prieten al unui tester care vrea să urce acea treaptă. **Pasul 1: Instalare și primul GET request** Descarcă Postman de pe postman.com — există versiune desktop pentru Windows, macOS și Linux, dar și varianta web dacă preferi să nu instalezi nimic. Creează un cont gratuit (îți trebuie pentru sincronizare) și ești gata. Acum deschide o fereastră nouă de request. În bara de URL scrie: https://jsonplaceholder.typicode.com/posts/1 Selectează metoda GET din dropdown‑ul din stânga și apasă Send. În mai puțin de o secundă, în panoul de jos apare un răspuns JSON cu un titlu, un body și un userId. Felicitări — tocmai ai trimis primul tău API request. Nu e magie, e HTTP. Uită-te la cele două lucruri esențiale din răspuns: **Status Code** (ar trebui să vezi 200 OK — server‑ul e fericit) și **Response Time** (de obicei sub 300ms pentru un endpoint public sănătos). Aceste două cifre vor deveni reflexe pentru tine în orice sesiune de testare. **Pasul 2: POST, Body și autentificare — primii pași spre scenarii reale** GET‑ul îți aduce date. POST‑ul le trimite. Schimbă metoda în POST și URL‑ul în: https://jsonplaceholder.typicode.com/posts Mergi la tab‑ul Body, selectează raw și din dropdown‑ul din dreapta alege JSON. Scrie un payload simplu: { "title": "Primul meu test", "body": "Testez API‑ul cu Postman", "userId": 1 } Apasă Send. Vei primi 201 Created — server‑ul confirmă că resursa a fost „creată" (JSONPlaceholder simulează, nu stochează cu adevărat, dar comportamentul HTTP este identic cu un API real). Acum vine un detaliu important pentru proiectele reale: autentificarea. Majoritatea API‑urilor din producție cer un token. În Postman, tab‑ul Authorization îți oferă opțiuni pentru Bearer Token, Basic Auth, OAuth 2.0 și altele. Îl completezi o singură dată la nivel de Collection și toate request‑urile din acea colecție îl moștenesc automat — punct ochit, punct lovit, fără să copiezi token‑ul în fiecare request manual. **Pasul 3: Validarea cu Tests — aici începe testarea propriu‑zisă** Până acum am trimis request‑uri și am citit răspunsuri cu ochii. Dar un tester adevărat automatizează validarea. În Postman, tab‑ul Tests conține un editor de JavaScript unde scrii assertions care rulează imediat după ce primești răspunsul. Câteva exemple esențiale pe care le poți lipi direct: pm.test("Status code este 200", function () { pm.response.to.have.status(200); }); pm.test("Răspunsul conține userId", function () { var jsonData = pm.response.json(); pm.expect(jsonData.userId).to.eql(1); }); pm.test("Timpul de răspuns sub 500ms", function () { pm.expect(pm.response.responseTime).to.be.below(500); }); Rulează din nou request‑ul GET de mai devreme și vei vedea în panoul Test Results trei checkmark‑uri verzi. Dacă ceva eșuează, Postman îți spune exact ce assertion a picat — mult mai clar decât un bug raportat vag în JIRA fără detalii tehnice. Aceste teste sunt piatra de temelie a oricărei suites de API testing. Când le aduni într‑o Collection și le rulezi cu Newman (CLI‑ul oficial al Postman), ele pot intra direct într‑un pipeline CI/CD — alături de Selenium 4 sau Playwright pentru testele de UI. **Pasul 4: Environments și Variables — pentru că nimeni nu testează doar în producție** Un API trece prin cel puțin trei medii: development, staging, producție. URL‑urile diferă, token‑urile diferă, uneori și structura răspunsului diferă ușor. Copierea manuală a URL‑ului de la un mediu la altul este o rețetă sigură pentru erori umane. Soluția Postman: Environments. Creezi un environment „Dev" cu variabila `{{base_url}}` setată la adresa de development și altul „Staging" cu altă adresă. În request‑uri folosești `{{base_url}}/posts/1` în loc de URL‑ul hardcodat. Când schimbi environment‑ul din dropdown, toate request‑urile se actualizează instantaneu. Același principiu funcționează pentru token‑uri, user ID‑uri de test sau orice altă valoare care se schimbă între medii. Echipele cu care lucrăm la Academia Testarii — de la companii din domeniul energiei până la retail și ospitalitate — câștigă ore întregi pe săptămână doar prin această practică simplă. **Pasul 5: Colecții, Runner și raportare — de la experiment la proces** Acum că ai câteva request‑uri cu teste atașate, organizează-le într‑o Collection. Poți adăuga folder‑e (Happy Path, Edge Cases, Auth Flows), poți seta ordine de execuție și poți adăuga Pre‑request Scripts pentru a genera date dinamice înainte de fiecare request. Când colecția e gata, dai click pe Run Collection. Postman Collection Runner execută toate request‑urile în ordine, rulează toate testele și îți oferă un raport clar: câte teste au trecut, câte au picat, timpii de răspuns. Exportezi raportul, îl atașezi în JIRA la task‑ul de regresie și echipa știe exact starea API‑ului — fără discuții în cerc. Un #FunFact din teren: echipele care integrează colecțiile Postman în pipeline‑ul lor CI/CD găsesc în medie cu 41% mai multe bug‑uri înainte de release față de cele care testează API‑ul doar manual, ad‑hoc. **Ce urmează după aceste 30 de minute?** Postman este un tool generos — cu cât îl folosești mai mult, cu atât descoperi mai multe: Mock Servers pentru a testa fără un backend real, API Documentation generată automat din colecție, integrări cu GitHub și Azure DevOps. Dar cel mai important lucru pe care l‑ai câștigat azi este mindset‑ul: un API nu este o cutie neagră. Este un contract pe care îl poți citi, interoga și valida. Dacă vrei să treci de la experimente de 30 de minute la un skill solid, recunoscut pe piața muncii, Academia Testarii te așteaptă. Cursurile noastre acoperă API testing cu Postman de la nivel zero până la integrarea în pipeline‑uri CI/CD, alături de fundamente ISTQB, testare manuală și automatizare cu Selenium și Playwright. Suntem școala care a contribuit la introducerea profesiei de „Analist Testare Software" în COR (cod 351108) și știm exact ce au nevoie angajatorii români de la un tester pregătit. Intră pe academiatestarii.ro, descoperă programul potrivit pentru tine și fă primul pas serios spre o carieră în QA. Abia aștept să te văd în primul test cu status 200. 😊 #DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #TestareSoftware