Lekcja 8 / finał kursu

Finał: mini smoke suite API dla procesu zakupowego

Finał nie jest kolejną definicją. Składasz mały proces QA: kilka requestów, zmienne, testy, runner i krótka notatka, która mówi zespołowi, co działa, co jest ryzykowne i co trzeba sprawdzić dalej.

Scenariusz końcowy

Wyobraź sobie prosty checkout. Nie testujesz całego sklepu. Robisz smoke: czy API odpowiada, czy lista produktów wraca, czy da się utworzyć koszyk i czy można dodać pozycję. To szybki sygnał, nie pełna regresja.

Krok	Request	Minimalny test
1	`GET {{baseUrl}}/health`	Status 200
2	`GET {{baseUrl}}/products`	Odpowiedź jest listą
3	`POST {{baseUrl}}/carts`	Powstaje `cartId`
4	`POST {{baseUrl}}/carts/{{cartId}}/items`	Pozycja ma ilość i produkt

Postman: request zakończony statusem 200 i odpowiedzią JSON — W finale nie patrzysz tylko na zielony status. Zbierasz fakty: metoda, endpoint, status, body i to, czy odpowiedź pasuje do oczekiwania.

Przykładowy test dla health checka

Jeśli Twoje API nie ma endpointu /health, użyj innego prostego endpointu technicznego. Sens jest taki: najpierw sprawdzasz, czy API w ogóle odpowiada.

pm.test("API is available", function () {
  pm.response.to.have.status(200);
});

Przykładowy test dla listy produktów

pm.test("products response is a list", function () {
  const body = pm.response.json();

  pm.expect(body).to.be.an("array");
  pm.expect(body.length).to.be.greaterThan(0);
});

Ten test nie udaje, że sprawdza wszystko. Mówi tylko: endpoint zwrócił listę i nie jest pusta. W smoke te małe sygnały są wartościowe, bo szybko wykrywają grube awarie.

Notatka QA po uruchomieniu

Szablon notatki
Co sprawdziliśmy? Jaki był wynik runnera? Który request padł? Czy problem blokuje checkout? Czego smoke suite nie obejmuje i trzeba sprawdzić osobno?

Dobra notatka nie brzmi „coś nie działa”. Dobra notatka mówi: krok 3 zwrócił 500, więc nie powstał cartId, przez co nie da się przejść do dodania pozycji.

Projekt finałowy

Zbuduj kolekcję Checkout Smoke API. Dodaj cztery requesty według tabeli. Każdy request ma mieć przynajmniej jeden test. Jeżeli nie masz realnego API sklepu, opisz requesty na mocku albo API treningowym, ale zachowaj strukturę flow.

Mini-zadanie

Dodaj test, który celowo failuje, żeby zobaczyć, jak runner pokazuje błąd.

Większa praktyka

Uruchom kolekcję w runnerze i napisz krótką notatkę QA: „co wiemy”, „czego nie wiemy”, „co zgłaszamy dalej”, „jakie jest ryzyko dla checkoutu”.

Quiz

Czym smoke suite różni się od pełnej regresji?

Smoke sprawdza najważniejsze sygnały działania. Pełna regresja pokrywa dużo więcej wariantów i przypadków brzegowych.

Dlaczego finałowy flow powinien mieć notatkę QA?

Bo wynik testów musi być zrozumiały dla zespołu, a nie tylko widoczny jako zielone lub czerwone requesty.

Czy jeden test statusu wystarczy dla checkoutu?

Nie. Status jest dobrym początkiem, ale warto sprawdzać też pola, ID, listy i zależności między krokami.

Co dalej?

Masz fundament do pracy z API w Postmanie: czytasz requesty, używasz zmiennych, piszesz testy i układasz flow. Następny naturalny krok to Newman albo CI, czyli uruchamianie kolekcji poza ręcznym klikaniem.