Wyobraźmy sobie projekt IT bez testów. Zero. Nic. Żadnych scenariuszy, żadnych checklist, żadnych „ostatnich rzutów oka”.
Kod trafia prosto na produkcję jak świeżo upieczony chleb, jeszcze paruje, pachnie obietnicą, ale ktoś już mówi: „Klient jest głodny, nie ma czasu sprawdzać”.
Brzmi ryzykownie? Oczywiście. Brzmi znajomo? Jeszcze jak.
Ten artykuł to nie manifest ani instrukcja. To raczej opowieść o konsekwencjach. O tym, co się dzieje, gdy testowanie:
- nie istnieje wcale,
- istnieje w nadmiarze,
- albo w końcu zaczyna mieć sens.
Świat bez testów: YOLO w wersji enterprise
Zacznijmy uczciwie – brak testów ma swoje zalety.
Projekt bez formalnego testowania często oznacza szybkie deploymenty, mniej procesów i mniej blokad. Developerzy są bliżej systemu, lepiej znają jego zachowanie i szybciej reagują na zmiany. Sporo rzeczy jest „sprawdzanych przy okazji” – lokalnie, na środowisku testowym albo nawet na produkcji.
Często słyszy się wtedy, że „Dev sprawdził”, że To tylko mała zmiana” albo że „Jak coś się wysypie, to poprawimy”. W praktyce oznacza to testowanie wykonywane przez developerów w wolnych chwilach, bez formalnych scenariuszy, skupione głównie na happy pathach i aktualnie modyfikowanym fragmencie kodu.
Na krótką metę to działa. Czasem nawet bardzo dobrze. Problem zaczyna się później.
Projekt bez testów to jak jazda samochodem bez hamulców, ale z bardzo głośnym klaksonem. Teoretycznie można jechać, nawet szybko. Problem w tym, że klakson nie zatrzymuje auta.
W świecie bez testów brak błędów jest tylko złudzeniem. One istnieją, tylko jeszcze nikt na nie nie trafił, nie zdążył ich zgłosić albo uznał, że: „Tak już musi być”.
Co naprawdę dzieje się w takim projekcie?
Błędy wychodzą na produkcji. I to nie te kosmetyczne, tylko takie, które blokują płatności, kasują dane albo sprawiają, że użytkownik widzi cudze zamówienia. Zwykle nie są oczywiste od razu – pojawiają się w specyficznych scenariuszach, przy określonej sekwencji danych lub w nietypowych stanach systemu.
Klient bardzo szybko staje się testerem. Nieformalnym, nieopłacanym i często mocno sfrustrowanym. Zgłoszenia są ogólne, typu: „Coś nie działa”. Support nie potrafi ich odtworzyć, a użytkownik zamiast korzystać z produktu, zaczyna z nim walczyć.
Zespół wchodzi w tryb gaszenia pożarów. Sprint przestaje służyć rozwojowi, backlog zapełnia się zadaniami „fix urgently”, a regularne cele są odkładane na później. Zaufanie spada – raz, drugi, trzeci – aż w końcu ktoś zadaje pytanie: „Czy my w ogóle kontrolujemy ten system?”.
Brak testów nie oznacza braku kosztów. Oznacza tylko, że koszty pojawiają się później i są dużo mniej przewidywalne.
Historia z życia projektu #1: „Przecież to działało wczoraj”
Zmiana była mała. Naprawdę mała. Kilka linijek. Jeden warunek. „Nic ryzykownego”.
Nikt tego nie testował, bo:
- nie było czasu,
- nie było testów,
- nie było nawyku sprawdzania wpływu zmian.
Dzień później:
- proces kończy się w połowie,
- dane zapisują się częściowo,
- support dostaje zgłoszenia, których nie umie odtworzyć.
Najgorsze pytanie, jakie wtedy pada, brzmi: „A co dokładnie się zepsuło?”
I nikt nie zna odpowiedzi.
A może testujmy wszystko, zawsze i wszędzie?
Po kilku takich sytuacjach przychodzi odruchowa reakcja: „Dobra. Od teraz testujemy wszystko.”
I znów, to podejście też ma swoje plusy.
Pełne testowanie daje poczucie kontroli, porządkuje wiedzę o systemie i często poprawia architekturę. Pokrycie wygląda świetnie, raporty są imponujące, a organizacja może powiedzieć, że „jakość jest zaopiekowana”.
Problem w tym, że w praktyce często kończy się to przeciążeniem… testowym przeciążeniem.
Jak wygląda świat testowego overkillu?
- Testy są wszędzie.
- Każda zmiana powoduje lawinę poprawek w testach.
- Pipeline trwa tak długo, że nikt nie czeka na wynik.
- Testy częściej są fałszywie czerwone niż zielone.
Zespół zaczyna:
- ignorować wyniki,
- traktować testy jako przeszkodę,
- „tymczasowo” je wyłączać.
I paradoksalnie, mimo ogromnej liczby testów, jakość wcale się nie poprawia.
Bo testowanie przestało być narzędziem. Stało się celem samym w sobie.
Historia z życia projektu #2: „Testy są, ale i tak się boimy”
Projekt ma imponującą liczbę testów. Pokrycie wygląda świetnie.
Tylko że:
- nikt nie ufa wynikom,
- każdy deploy to stres,
- zmiany są odkładane „na później”.
Testy istnieją, ale nie dają poczucia bezpieczeństwa. A jeśli testy nie dają bezpieczeństwa, to po co one w ogóle są?
Gdzie jest balans? Czyli testowanie oparte na ryzyku
Balans w testowaniu nie polega na liczbie testów. Polega na świadomych decyzjach. Dojrzałe testowanie zaczyna się w głowie, nie w narzędziu.
Nie od pytania: „Co jeszcze możemy przetestować?”.
Ale od pytania: „Co się stanie, jeśli tego nie przetestujemy?”.
Myślenie ryzykiem zmienia wszystko
Zamiast testować wszystko:
- testujemy to, co może zaboleć najbardziej,
- skupiamy się na miejscach kruchych,
- chronimy kluczowe procesy.
Zadajemy pytania:
- Co jest krytyczne dla użytkownika?
- Co jest krytyczne dla biznesu?
- Co najczęściej się zmienia?
- Co już kiedyś się zepsuło?
I dopiero wtedy decydujemy:
- gdzie testować dokładnie,
- gdzie wystarczy lekko,
- gdzie testy nie są potrzebne wcale.
Tester jako osoba od ryzyka
W tym miejscu pojawia się prawdziwa rola testera. Tester to nie jest osoba od „sprawdzania”. To osoba od niewygodnych pytań.
Tester myśli:
- scenariuszami awarii,
- skutkami błędów,
- zachowaniami nieoczywistymi.
Nie pyta tylko: „Czy działa?”
Pyta: „Co się stanie, jeśli nie zadziała?”
Dobry tester:
- widzi system jako całość,
- rozumie konsekwencje błędów,
- pomaga zespołowi podejmować decyzje świadomie.
Nie blokuje zmian. Pomaga je bezpiecznie wprowadzać.
Historia z życia projektu #3: „Nagle zrobiło się spokojniej”
Projekt istniał od lat. Testów prawie nie było.
Zespół postanowił nie robić rewolucji:
- wybrał kilka krytycznych obszarów,
- dodał proste testy regresji,
- zaczął regularnie rozmawiać o ryzykach.
Po kilku iteracjach:
- deploye przestały być loterią,
- zespół zaczął ufać zmianom,
- tempo pracy wzrosło… paradoksalnie dzięki testom.
Nie dlatego, że testów było więcej. Tylko dlatego, że były sensowne.
Jeśli czytając ten tekst masz wrażenie, że opisuje on Twój projekt, to nie jest przypadek. Większość zespołów przechodzi dokładnie tę samą drogę. Różnica polega tylko na tym, na którym etapie ktoś zaczyna zadawać właściwe pytania.
A co, jeśli projekt już trwa i testów brak?
To bardzo częsty punkt wyjścia. I wbrew pozorom, całkiem dobry.
Wdrożenie testów w istniejącym projekcie to:
- nie sprint,
- nie rewolucja,
- tylko ciągła ewolucja.
Zaczynamy od:
- widoczności,
- stabilności,
- rozmowy o ryzyku.
Nie od perfekcji.
Podsumowanie
Nie testować to ryzykować w ciemno. Testować wszystko to zaplątać się we własnej sieci zabezpieczeń.
Testować mądrze to:
- rozumieć ryzyko,
- rozumieć produkt,
- rozumieć użytkownika,
- i rozumieć zespół.
Bo najlepsze testy to nie te, które znajdują najwięcej błędów. To te, które pozwalają spać spokojnie, zanim zadzwoni klient.
A tego chyba wszyscy chcemy. 😉
Zostaw komentarz