Testy przechodzą, a produkcja się psuje – gdzie leży problem?

1. Testujemy happy path, a produkcja to chaos

Większość testów automatycznych sprawdza scenariusz idealny:

• użytkownik wpisuje poprawne dane

• backend zwraca 200

• UI wyświetla komunikat sukcesu

Tylko że produkcja nie jest idealna.

Na produkcji masz:

• opóźnienia sieci

• timeouty

• błędne dane

• użytkowników klikających 5 razy w przycisk

• requesty wysyłane równolegle

Jeśli testujemy tylko „ładną ścieżkę”, to testy będą przechodzić. A bug i tak wyjdzie, bo realne życie nie wygląda jak happy path z testu.

2. Mocki, które dają fałszywe poczucie bezpieczeństwa

Mockowanie API w testach E2E jest super. Przyspiesza suite, stabilizuje testy, eliminuje zależności.

Ale ma jedną pułapkę.

Jeśli zawsze mockujesz odpowiedź 200 z poprawnym JSON-em, to tak naprawdę testujesz tylko UI. Nie testujesz:

• czy backend faktycznie zwraca taki format

• czy pole nie zmieniło nazwy

• czy nie doszło nowe pole wymagane

• czy walidacja po stronie serwera działa

Widziałem sytuacje, gdzie testy E2E były idealne, a backend zmienił strukturę odpowiedzi. UI się wysypywał, testy dalej były zielone, bo… mock zwracał starą strukturę.

To nie był problem testów. To był problem strategii testowej.

3. Brak testów integracyjnych między serwisami

W systemach mikroserwisowych to klasyka.

Serwis A działa.
Serwis B działa.
Testy jednostkowe i integracyjne w obu repozytoriach przechodzą.

Ale:

• zmienił się kontrakt API

• pole stało się opcjonalne

• walidacja zaczęła odrzucać edge case

I nagle całość przestaje działać dopiero po deployu.

Jeśli nie masz testów kontraktowych albo integracyjnych między serwisami, to zielony pipeline w jednym repo niczego nie gwarantuje.

4. Testy nie odzwierciedlają danych produkcyjnych

To jest niedoceniany problem.

Na środowisku testowym masz:

• czyste dane

• brak duplikatów

• brak historycznych rekordów

• brak „dziwnych” przypadków

Na produkcji masz:

• rekordy sprzed 5 lat

• dane importowane z innego systemu

• null w miejscu, gdzie „nigdy nie powinno być null”

• użytkowników z egzotycznymi znakami w nazwisku

Testy przechodzą, bo testują idealny świat. Produkcja pokazuje prawdziwy.

5. Brak testów pod obciążeniem

System działa idealnie dla jednego użytkownika.

Test E2E przechodzi.
API test przechodzi.
Unit test przechodzi.

A potem 200 użytkowników robi to samo w tym samym czasie.

I nagle:

• deadlock

• race condition

• podwójne zamówienie

• timeout

Testy funkcjonalne nie wykrywają problemów z równoległością. I nie powinny. Ale jeśli nie masz żadnej formy testów wydajnościowych albo przynajmniej prostych smoke performance testów w pipeline, to ryzyko rośnie.

6. Zielony pipeline daje złudzenie kontroli

Pipeline jest potrzebny. Automatyzacja jest potrzebna.

Ale zielony pipeline to nie jest certyfikat jakości.

To jest tylko informacja:

„To, co postanowiliśmy przetestować – działa.”

Kluczowe pytanie brzmi:
Czy testujemy właściwe rzeczy?

7. Testy to strategia, nie tylko kod

Największy błąd, jaki widzę w projektach, to skupienie się na narzędziu.

Playwright.
Cypress.
Selenium.
Postman.
k6.

To wszystko są tylko narzędzia.

Jeśli strategia jest zła – czyli:

• brak analizy ryzyka

• brak testów negatywnych

• brak testów granicznych

• brak testów integracyjnych

• brak testów pod realnymi danymi

to możesz mieć 1000 testów i nadal wypuszczać bugi.

Co z tym zrobić?

Nie chodzi o to, żeby pisać więcej testów.

Chodzi o to, żeby:

• analizować realne ryzyko biznesowe

• patrzeć na architekturę systemu

• rozumieć przepływ danych

• testować miejsca, które realnie mogą się wywrócić

Czasem jeden dobrze przemyślany test integracyjny daje więcej niż 30 testów klikających formularz.