Automatyzacja testów dla małego startupu — od czego zacząć?
Prowadzenie startupu w Katowicach z 3-osobowym zespołem programistów to ciągła walka o czas. Kiedy co środę o 14:00 wypuszczacie nową wersję aplikacji, stres związany z bugami na produkcji potrafi zabić kreatywność. Nie musisz od razu zatrudniać armii testerów, żeby spać spokojnie.
Dlaczego ręczne klikanie kosztuje Cię 144 godziny rocznie
Większość małych zespołów IT w Polsce wpada w tę samą pułapkę. Przy każdym nowym wydaniu jeden z programistów musi poświęcić około 1.5 godziny na ręczne sprawdzenie, czy logowanie, koszyk i płatności nadal działają. Przy 87 funkcjonalnościach, które obecnie macie w systemie, prawdopodobieństwo przeoczenia błędu wynosi aż 31%. Jeden z naszych klientów z branży e-commerce wyliczył, że w marcu 2024 roku jego zespół zmarnował 12 godzin na samo klikanie w przycisk 'Dodaj do koszyka' po różnych poprawkach kodu.
Kod musi zarabiać, a nie sypać błędami, dlatego przeliczanie czasu pracy programisty na powtarzalne czynności manualne jest po prostu nieopłacalne. Jeśli Twój główny deweloper zarabia określoną stawkę, to te 144 godziny rocznie poświęcone na regresję kosztują firmę tyle, co porządny serwer lub licencje na narzędzia wspomagające przez 3 lata. Szczerze: testy manualne to dziś strata czasu, gdy można je zastąpić prostym skryptem uruchamianym automatycznie.
Zamiast szukać testera manualnego na pełny etat, lepiej skupić się na tym, co już macie. Automatyzacja nie musi być wielkim projektem na pół roku. Wystarczy zacząć od 3 najbardziej krytycznych ścieżek, które generują 83% Twojego przychodu. Jeśli te procesy będą bezpieczne, resztę możecie łatać na bieżąco bez ryzyka bankructwa w środku tygodnia.
Szczerze: testy manualne to dziś strata czasu. Kod musi zarabiać, a nie sypać błędami.
Wybór narzędzia: Playwright vs reszta świata
Nie trać 4 dni na czytanie porównań w sieci. Dla małego zespołu, który pisze w JavaScripcie lub TypeScripcie, wybór jest prosty: Playwright. Instalacja podstawowej paczki trwa dokładnie 3 minuty i 20 sekund na typowym laptopie deweloperskim. Nie szukaj rozwiązań klasy enterprise, bo one wymagają oddzielnego etatu do samej konfiguracji. My w TyeVals ustawiamy procesy, które działają same, a Playwright idealnie wpisuje się w tę filozofię.
W październiku 2024 wdrażaliśmy to narzędzie w startupie z Gliwic. Programista potrzebował zaledwie 124 linijek kodu, aby w pełni zabezpieczyć proces rejestracji użytkownika. Wcześniej ten sam test wykonywany ręcznie zajmował 7 minut przy każdym wdrożeniu. Teraz skrypt wykonuje to w 14 sekund. Różnica jest kolosalna, zwłaszcza gdy robicie 5 deployów dziennie. Playwright pozwala też nagrywać ruch użytkownika, co oszczędza czas na ręczne pisanie selektorów CSS.
Ważne jest, aby testy pisali ci sami ludzie, którzy tworzą funkcjonalności. Jeśli masz 3 programistów, każdy z nich powinien poświęcić 15% swojego czasu na dbanie o stabilność kodu. To lepsze niż zatrudnianie nowej osoby, która musiałaby uczyć się logiki biznesowej od zera przez 3 tygodnie. Ustawiamy procesy, które działają same, zaczynając od najprostszych testów interfejsu.
Plan na 14 dni: od zera do pierwszej zielonej fajki
Pierwsze 72 godziny poświęć wyłącznie na czystą konfigurację środowiska. Nie próbuj pisać testów, dopóki Playwright nie odpala się stabilnie na maszynie każdego programisty. W czwartym dniu skup się na jednej, najważniejszej rzeczy: procesie logowania. To fundament. Jeśli użytkownik nie może wejść do systemu, cała reszta nie ma znaczenia. Napisanie tego testu i obsłużenie 2 różnych scenariuszy błędnych danych powinno zająć nie więcej niż 4 godziny pracy.
Między 7. a 10. dniem dodaj testowanie 'Happy Path' dla głównej funkcji produktu. Jeśli sprzedajecie subskrypcje, przetestujcie proces płatności testową kartą. Do 14. dnia powinieneś mieć zestaw 4-6 testów, które pokrywają około 23% kodu, ale za to 89.6% krytycznych operacji biznesowych. To wystarczy, żeby wyłapać większość błędów regresji, które zazwyczaj pojawiają się po szybkich poprawkach w CSS czy bazie danych.
Pamiętaj o zasadzie: bez zbędnych prezentacji — samo mięso. Nie twórz raportów w PDF dla zarządu. Wystarczy, że deweloper widzi na Slacku informację: 'Testy przeszły' lub 'Testy padły na linii 47'. Taka informacja zwrotna w czasie rzeczywistym skraca czas naprawy buga z kilku godzin do średnio 11 minut. To jest realna wartość, którą odczuje Twój zespół już w drugim tygodniu pracy.
Nie twórz raportów PDF. Wystarczy informacja na Slacku: Testy przeszły lub padły.
CI/CD: Testy, które nie dają o sobie zapomnieć
Nawet najlepszy zestaw testów jest bezużyteczny, jeśli nikt go nie uruchamia. GitHub Actions to obecnie najbardziej pragmatyczne rozwiązanie dla małych firm. Skrypt uruchamiający testy przy każdym 'Pull Request' konfiguruje się w około 35 minut. W TyeVals widzieliśmy wiele projektów, gdzie testy były uruchamiane tylko 'przed wydaniem'. To błąd. Testy muszą biegać przy każdej zmianie, żeby programista wiedział o błędzie, zanim jeszcze zdąży zaparzyć drugą kawę.
W jednym z wdrożeń w listopadzie 2024 ustawiliśmy automat, który odpala testy o 2:15 w nocy na serwerze testowym. Jeśli coś nie działa, rano o 8:00 zespół ma gotową listę rzeczy do poprawy. Skróciło to cykl wydawniczy z 7 dni do zaledwie 2 dni roboczych. Programiści przestali bać się refaktoryzacji starego kodu, bo wiedzieli, że automat wyłapie każdą pomyłkę w logice bazy danych w ciągu 3 minut od wysłania zmian.
Koszt utrzymania takiego rozwiązania to często kilka dolarów miesięcznie za czas procesora w chmurze. To śmieszna kwota w porównaniu do kosztu naprawy błędu na produkcji, który zauważyło 47 aktywnych użytkowników jednocześnie. Automatyzacja to ubezpieczenie Twojego biznesu. Bez zbędnych prezentacji i komplikacji — po prostu skrypt, który mówi 'tak' lub 'nie' Twojemu kodowi.
Pułapka 99.1% pokrycia i jak jej uniknąć
Wielu właścicieli startupów pyta: 'Kiedy będziemy mieć przetestowane wszystko?'. Odpowiedź brzmi: nigdy. Dążenie do 99.4% pokrycia kodu testami to najkrótsza droga do bankructwa małej firmy. Utrzymanie takiej liczby skryptów przy szybko zmieniającym się produkcie zajmowałoby 78.6% czasu Twoich programistów. Realny i zdrowy cel to utrzymanie pokrycia na poziomie 31-47% dla stabilnych części systemu.
Skup się na stabilności, a nie na ilości. Jeśli test 'miga' (raz przechodzi, raz nie), usuń go i napisz od nowa lub zrezygnuj z niego całkowicie. Nic tak nie irytuje zespołu jak fałszywe alarmy o 15:00 w piątek. W jednym z projektów w Katowicach wycięliśmy 12 niestabilnych testów, co paradoksalnie poprawiło zaufanie zespołu do automatyzacji i przyspieszyło pracę o 1.5 dnia w skali miesiąca.
Podsumowując: zacznij od małych kroków. Wybierz Playwright, napisz test logowania w 14 dni, podepnij pod GitHub Actions i nie celuj w perfekcję. Ustawiamy procesy, które działają same, pozwalając Ci skupić się na budowaniu funkcji, za które klienci chcą płacić. Jeśli utkniesz, odezwij się do nas — team@tyevals.com odpowiada zazwyczaj w ciągu 4 godzin w dni robocze.
