Dlaczego Twój zespół programistyczny boi się testów? 3 strategie zmiany
Kiedy ostatnio słyszałeś od swojego CTO: „Musimy pisać więcej testów”? A potem znowu priorytetem były nowe feature’y, a testy odkładano na później? To nie jest przypadek. W większości firm nastawienie do testów to nie kwestia umiejętności, ale kultury i strachu. Pracuję z zespołami od lat i widzę ten sam scenariusz: developerzy boją się testów, bo kojarzą je z karą, biurokracją lub marnowaniem czasu. A prawda jest taka, że dobrze zaprojektowane testy oszczędzają czas i pieniądze – ale tylko wtedy, gdy zespół je zrozumie i zaakceptuje.
W tym artykule pokażę trzy strategie, które realnie zmieniają podejście do testów w firmach, z którymi współpracuję. Żadna z nich nie wymaga gigantycznego budżetu ani rewolucji technologicznej. Wymagają za to zmiany myślenia.
1. Testy jako dokumentacja, a nie obowiązek
Większość developerów nienawidzi pisać dokumentacji. Jest nudna, szybko się dezaktualizuje, a i tak nikt jej nie czyta. Testy – zwłaszcza te jednostkowe i integracyjne – mogą pełnić tę samą funkcję, ale są żywe i weryfikowalne.
Klient z branży fintech narzekał, że nowi programiści spędzają tygodnie na zrozumieniu logiki biznesowej. Mieli rozbudowaną dokumentację w Confluence, ale nikt jej nie aktualizował. Zaproponowałem, żeby zamiast opisywać funkcje w dokumentach, pisali testy, które demonstrują, jak dana funkcja działa. Efekt? Nowi członkowie zespołu zaczęli czytać testy jako pierwszą rzecz. Zrozumienie systemu skróciło się z dwóch tygodni do kilku dni.
Jak to wdrożyć?
- Nie każ developerom pisać testy po fakcie – niech piszą je razem z kodem, jako sposób na udokumentowanie zachowania.
- W code review zwracaj uwagę, czy testy czytelnie opisują przypadek użycia.
- Nagradzaj tych, którzy piszą testy tak, by były zrozumiałe dla innych.
2. Automatyzacja testów to nie tylko Selenium
Kiedy mówimy „automatyzacja testów”, większość myśli o Selenium i testach end-to-end (E2E). Problem polega na tym, że E2E są wolne, kruche i często zawodzą z powodów niezwiązanych z logiką aplikacji (np. zmiana selektora CSS). To sprawia, że developerzy tracą zaufanie do testów.
Zamiast tego warto zastosować piramidę testów w praktyce. W jednym z projektów e-commerce mieliśmy 70% testów E2E i 20% jednostkowych. Wydawało się, że automatyzacja działa, ale codziennie przynajmniej dwa testy E2E odpadały z błędem „element not found”. Zespół spędzał godzinę na analizie, czy to realny bug, czy fałszywy alarm. Po zmianie proporcji na 80% testów jednostkowych, 15% integracyjnych i 5% E2E, czas wykonywania całego zestawu spadł z 45 minut do 5, a wiarygodność wzrosła.
Co z tego wynika?
- Zainwestuj w testy jednostkowe – są szybkie, tanie i precyzyjne.
- Testy integracyjne (np. do API) dają więcej pewności niż E2E przy mniejszym koszcie.
- E2E zostaw na krytyczne ścieżki użytkownika – i to tylko kilka.
3. Zabij strach przed „czerwonym” pipeline’em
W wielu firmach commit, który wywołuje czerwony pipeline, oznacza reprymendę. Developerzy boją się, że popsują build, więc albo nie mergują zmian, albo piszą testy, które zawsze przechodzą – czyli testy, które niczego nie sprawdzają.
Pamiętam przypadek z SaaS B2B, gdzie pipeline był tak rygorystyczny, że średni czas merga pull requesta wynosił trzy dni. Nikt nie chciał być tym, który wywoła awarię. Problemem nie były testy, tylko kultura błędu. Zmieniliśmy podejście: zamiast „nie może być czerwonych”, wprowadziliśmy zasadę „czerwony jest ok, ale musisz go naprawić w ciągu godziny”. Dodatkowo, jeśli testy wykryły błąd, a nie był on krytyczny, dopuszczaliśmy merge z czerwonym pipeline’em i tworzyliśmy task do naprawy.
Efekt? Czas merga spadł do kilku godzin, a jakość kodu wzrosła, bo developerzy przestali bać się testów. Zaczęli je traktować jak asystenta, a nie wroga.
Kluczowe zasady:
- Pipeline ma być pomocny, nie karzący.
- Błędy wychwycone przez testy to sukces, nie porażka.
- Autoryzuj zespół do naprawiania błędów na bieżąco.
Podsumowanie
Testy to nie fanaberia – to narzędzie do szybszego dostarczania wartości. Ale żeby działały, trzeba zmienić podejście. Zamiast nakazów i kar, postaw na:
- Testy jako dokumentację – zmniejszają próg wejścia nowym osobom.
- Właściwą piramidę testów – oszczędza czas i nerwy.
- Kulturę akceptacji porażek – developerzy przestaną się bać.
Od lat widzę, że firmy, które traktują testy jak inwestycję, a nie koszt, wyprzedzają konkurencję. W JurskiTech pomagamy zespołom przeprojektować strategię testowania – bez fanfar, za to z realnym wpływem na prędkość wdrożeń i jakość kodu.
