QA to nie tylko klikanie w przyciski
Większość firm traktuje testowanie jak zło konieczne, które dzieje się na samym końcu procesu. W TyeVals widzimy, że takie myślenie kosztuje średnio 4200 PLN miesięcznie w samym tylko czasie zmarnowanym na poprawianie błędów, które mogły w ogóle nie powstać. Prawdziwa rola QA zaczyna się na papierze, zanim programista napisze choćby jedną linię kodu w Katowicach czy gdziekolwiek indziej.
Planowanie to połowa sukcesu w QA
Kiedy zaczynaliśmy TyeVals w marcu 2017 roku, najczęstszym błędem, jaki widziałem, było odsuwanie testerów od rozmów o biznesie. Wyobraź sobie sytuację: zespół planuje nową funkcję płatności. Jeśli tester nie siedzi przy stole, nikt nie zapyta, co się stanie, gdy użytkownik odświeży stronę w 14. sekundzie transakcji. Potem programista spędza 3 dni na kodowaniu, a tester znajduje błąd w 5 minut po wdrożeniu. To czysta strata pieniędzy i czasu zespołu.
W jednym z naszych projektów dla firmy logistycznej z 8 programistami na pokładzie, wprowadziliśmy zasadę 'QA na planowaniu'. Wynik był mierzalny już po dwóch sprintach. Liczba powrotów zadań z testów do poprawki spadła z 12 do 4 przypadków miesięcznie. Szczerze: testy manualne to dziś strata czasu, jeśli nie są podparte logicznym planem już na etapie user story. Zamiast klikać bezmyślnie w przyciski, tester musi rozumieć, jak system ma zarabiać pieniądze dla klienta.
Konkretnie: QA powinien brać udział w tworzeniu kryteriów akceptacji. W TyeVals uczymy, że dokumentacja to nie jest sterta papieru, ale żywy mechanizm. Jeśli w pliku Jira brakuje opisu zachowania błędu 404, tester musi to wyłapać, zanim ruszy sprint. Dzięki temu programista nie musi zgadywać, a Ty nie płacisz za poprawki w połowie tygodnia, kiedy presja na dowiezienie funkcji jest największa.
Jeśli tester nie wie, po co klient kupuje Twój produkt, będzie znajdował tylko nieistotne błędy wizualne.
Shift Left, czyli błędy wykryte przed kodowaniem
Pojęcie 'Shift Left' brzmi mądrze, ale w praktyce chodzi o to, żeby nie być strażakiem, tylko architektem. W październiku 2023 pracowaliśmy z małym software housem, który borykał się z ogromnym długiem technicznym. Ich proces wyglądał tak: kodowanie, wrzutka na serwer testowy i wielkie zdziwienie, że nic nie działa. Przesunęliśmy testowanie na lewo. Tester zaczął pisać scenariusze testowe w tym samym momencie, gdy powstawały makiety w Figmie.
To podejście pozwoliło nam wyłapać 7 krytycznych błędów logicznych w module zamówień, zanim ktokolwiek dotknął klawiatury. Naprawa tych samych błędów na etapie produkcji kosztowałaby tę firmę około 8400 PLN w roboczogodzinach i utraconych zamówieniach od klientów. Bez zbędnych prezentacji — samo mięso. Jeśli masz w zespole testera, który tylko czeka na paczkę kodu, to znaczy, że marnujesz 60% jego potencjału i swoich funduszy.
Wdrożenie testów statycznych, czyli przeglądu wymagań przez osobę z QA, zajmuje zazwyczaj 2-3 godziny w tygodniu. To śmiesznie mało w porównaniu do 14 godzin, które zespół potrafi spędzić na szukaniu przyczyny błędu w skomplikowanym kodzie backendowym. Ustawiamy procesy, które działają same, ale tylko wtedy, gdy fundament jest solidny. Kod musi zarabiać, a nie sypać błędami tylko dlatego, że ktoś zapomniał o walidacji pola na etapie projektu.
Automatyzacja, która ma sens biznesowy
Wiele firm rzuca się na automatyzację testów, bo tak wypada. Kupują drogie narzędzia, a potem okazuje się, że testy uruchamiają się 4 godziny i nikt ich nie sprawdza. W TyeVals mamy prostą zasadę: automatyzujemy tylko to, co powtarzalne i nudne. Jeśli Twój tester codziennie przez 32 minuty klika proces rejestracji, to jest to pierwszy kandydat do skryptu. Ale jeśli funkcja zmienia się co dwa dni, automatyzacja to wyrzucanie pieniędzy w błoto.
Dla klienta z branży e-commerce wdrożyliśmy zestaw 47 testów automatycznych w Playwright, które sprawdzają kluczowe ścieżki zakupu. Działają one w każdą środę o 14:00 przy każdym nowym wydaniu. Dzięki temu czas potrzebny na regresję skrócił się z 6 godzin do zaledwie 11 minut. To pozwoliło testerowi zająć się testami eksploracyjnymi, czyli szukaniem błędów tam, gdzie automat nie zajrzy — w dziwnych zachowaniach użytkownika.
Pamiętaj, że testy automatyczne to też kod, który trzeba utrzymywać. Jeśli masz ich 500, a połowa świeci się na czerwono, to tak, jakbyś ich nie miał wcale. Skupiamy się na stabilności. Wolimy mieć 12 solidnych testów, które dają 99.2% pewności, że koszyk działa, niż 100 testów, które sypią się przy każdej zmianie koloru przycisku. Realny zysk to brak stresu podczas deployu w środku dnia.
Automatyzacja bez stabilności to tylko drogi sposób na generowanie fałszywych alarmów w Slacku.
QA jako most między biznesem a deweloperem
Dobry QA to trochę tłumacz. Biznes mówi: 'Chcę, żeby to było szybkie'. Programista mówi: 'Muszę zoptymalizować zapytania SQL'. Tester pyta: 'Co dokładnie oznacza szybkie? 2 sekundy czy 200 milisekund?'. To doprecyzowanie ratuje projekty. W lipcu 2024 pomagaliśmy zdiagnozować problem w aplikacji mobilnej, gdzie użytkownicy uciekali po 3 sekundach od uruchomienia. QA odkrył, że błąd leżał w źle obsłużonym komunikacie o braku internetu.
Nasze konsultacje często kończą się reorganizacją komunikacji. Zamiast rzucać zadaniami przez ścianę, wprowadzamy krótkie, 10-minutowe spotkania przed startem pracy nad trudnym modułem. To eliminuje domysły. Kiedy programista, tester i product owner zgadzają się co do wyniku, ryzyko błędu spada drastycznie. Takie podejście pozwoliło nam zamknąć 156 projektów z sukcesem, bez ani jednego krytycznego buga na produkcji w pierwszym tygodniu po starcie.
Podsumowując, jeśli chcesz, aby Twój kod zarabiał, przestań patrzeć na QA jak na kontrolę jakości na końcu taśmy produkcyjnej. To jest część inżynierii. W TyeVals nie bawimy się w kolorowe wykresy i nudne raporty, które lądują w szufladzie. Dajemy konkretne wytyczne, jak zmienić kulturę pracy, żebyś mógł wydawać kod bez błędów i stresu. Bo w końcu o to chodzi w tym biznesie — o spokój i działający produkt.
