Odpowiedź.

Ręczne testowanie API to proces weryfikacji działania interfejsu programowania aplikacji bez użycia automatyzacji, za pomocą specjalistycznych narzędzi, takich jak Postman, Swagger czy curl.

Historia pytania

Pierwsze API były testowane ręcznie z powodu braku automatyzacji i względnej prostoty interfejsów. Dziś, mimo automatyzacji, ręczne testowanie wciąż ma znaczenie, szczególnie dla podstawowej weryfikacji nowych lub niestabilnych metod.

Problem

Główne trudności związane są z:

koniecznością dokładnego zrozumienia struktury danych wejściowych i wyjściowych (JSON, XML itp.)
trudnością w powtarzaniu złożonych scenariuszy (uwierzytelnianie, zależność od stanu systemu)
ryzykiem przeoczenia ukrytych błędów, które nie są oczywiste przez UI

Rozwiązanie

Sukcesywne testowanie wymaga:

starannej pracy z dokumentacją API
tworzenia zestawów ręcznych zapytań, obejmujących różne parametry i scenariusze błędów
testowania zarówno pozytywnych, jak i negatywnych scenariuszy (walidacja danych, kontrola autoryzacji)

Kluczowe cechy:

Możliwość szybkiego sprawdzenia nowego lub zmienionego end pointa bez czekania na testy zautomatyzowane
Elastyczność w analizie anomalii i błędów, gdy wynik nie jest oczywisty
Wizualna kontrola nad wszystkimi etapami zapytania i odpowiedzi

Pytania z podstępem.

Czy do ręcznego testowania API można używać tylko UI, bez narzędzi typu Postman?

Nie, ponieważ wiele błędów objawia się tylko na poziomie przesyłania danych i nie jest widoczne przez UI, do pełnej weryfikacji potrzebne są specjalne narzędzia.

Czy wystarczy wysłać tylko jedno poprawne zapytanie, aby sprawdzić działanie API-endpointa?

Nie, ważne jest testowanie nie tylko ważnych zapytań, ale także wszystkich granicznych, niepoprawnych i rzadkich przypadków, w przeciwnym razie błędy nie zostaną znalezione.

Czy należy testować negatywne scenariusze osobno, czy to dodatkowa praca?

Zdecydowanie należy. Ważne jest upewnienie się, że system prawidłowo obsługuje błędy i odrzuca niepoprawne zapytania, w przeciwnym razie bezpieczeństwo i stabilność mogą być zagrożone.

Typowe błędy i antywzorce

Testowanie tylko "idealnych" scenariuszy (brak weryfikacji niepoprawnych wartości)
Ignorowanie stanu systemu — testy na już istniejących danych lub nieprzygotowanej bazie
Brak weryfikacji nagłówków, statusów błędów, nietypowych przypadków

Przykład z życia

Negatywny przypadek

Tester sprawdza tylko udane zapytanie POST do API "utwórz użytkownika" — wysyła poprawny JSON, otrzymuje 200 OK, uważa test za zakończony.

Zalety:

Szybka weryfikacja podstawowego scenariusza

Wady:

Przeoczone błędy związane z brakiem pól, niepoprawnym formatem email, ponownym tworzeniem tego samego użytkownika
Brak pewności, że API zwróci poprawny kod błędu

Pozytywny przypadek

Tester systematycznie sprawdza API "utwórz użytkownika":

sukces dla ważnego zapytania
błędy przy pominięciu wymaganych parametrów
błąd przy ponownym tworzeniu
sprawdza różne kody HTTP, komunikaty o błędach, walidację email