Automatyzacja 47 scenariuszy testowych dla firmy FinTech
Zamiast 4 godzin sprawdzania ręcznego przed każdym wdrożeniem, teraz system robi to sam w 9 minut. Zespół odzyskał 14 godzin tygodniowo.
Zespół FastPay Solutions co tydzień tracił pół dnia na ręczne sprawdzanie, czy ich aplikacja płatnicza wciąż działa po zmianach w kodzie. Skupiliśmy się na zautomatyzowaniu tych powtarzalnych zadań, żeby programiści mogli w końcu zająć się pracą, a nie klikaniem w kółko tych samych przycisków.
Wyzwanie
Przed naszym wejściem, proces wyjścia na produkcję był udręką. Testy manualne trwały bite 4 godziny, a i tak co drugie wdrożenie kończyło się telefonem od klienta, że coś nie działa. W samym wrześniu 2024 mieli 3 awarie modułu generowania PDF, co zablokowało 83 transakcje na kilka godzin. Ludzie byli zmęczeni, a błędy wynikały po prostu z pośpiechu i zmęczenia materiału przy powtarzalnych testach.
Dodatkowym problemem był brak powtarzalności środowiska. Testerzy sprawdzali kod na swoich laptopach, a na serwerze produkcyjnym aplikacja zachowywała się inaczej. Firma traciła około 3 200 zł miesięcznie tylko na nadgodziny programistów, którzy musieli naprawiać błędy wykryte przez użytkowników już po publikacji nowej wersji aplikacji.
Podejście
Na start, 7 października, usiedliśmy z ich testerem, Markiem. Zamiast pisać testy do wszystkiego, wybraliśmy 47 krytycznych punktów, takich jak logowanie dwuskładnikowe czy autoryzacja przelewów zagranicznych. Wybraliśmy framework Playwright i język Python, bo ich zespół już trochę znał te narzędzia, więc nie musieli się uczyć wszystkiego od zera. Prace podzieliliśmy na 3 szybkie etapy, bez zbędnego gadania na spotkaniach.
W drugim tygodniu skupiliśmy się na stabilności środowiska testowego. Musieliśmy mieć pewność, że jeśli test nie przejdzie, to wina leży w kodzie, a nie w źle skonfigurowanej bazie danych. Ustawiliśmy kontenery Docker, które stawiają czystą aplikację do testów w 48 sekund. Dzięki temu wyeliminowaliśmy problem u mnie działa, a u ciebie nie, który wcześniej torpedował każdą próbę automatyzacji.
Rozwiązanie
Naprawiliśmy proces wdrażania kodu, tworząc paczkę 47 skryptów, które symulują zachowanie prawdziwego użytkownika w przeglądarce. Wpięliśmy je bezpośrednio w ich rurociąg CI/CD na GitLabie. Teraz, gdy programista wrzuca kod, testy odpalają się automatycznie na osobnym serwerze. Całość działa bez nadzoru człowieka.
Jeśli system wykryje błąd, blokuje wdrożenie i wysyła konkretny komunikat na kanał techniczny na Slacku. Pokazuje dokładnie zrzut ekranu z błędem i linię w kodzie, która zawiodła. Dodaliśmy też prosty pulpit nawigacyjny dla szefa zespołu, żeby widział, że system sprawdził moduł przelewów krajowych 12 razy w ciągu dnia i każda próba zakończyła się sukcesem. Nie ma już domysłów, czy kod jest bezpieczny.
Rezultaty
Cały proces sprawdzania skrócił się z 4 godzin do dokładnie 9 minut i 12 sekund. To oznacza, że zespół odzyskał średnio 14 godzin pracy w każdym tygodniu, które wcześniej marnowali na ręczną robotę. Od momentu odpalenia automatów nie zdarzył się ani jeden błąd krytyczny na produkcji związany z obsługą płatności.
Harmonogram
-
7 Października 2024Audyt kodu i wybór 47 kluczowych scenariuszy
-
14 Października 2024Konfiguracja Docker i stabilizacja środowiska
-
21 Października 2024Pisanie skryptów Playwright i testy dymne
-
28 Października 2024Pełna integracja z CI/CD i start automatów
"Szczerze mówiąc, byłem sceptyczny, bo poprzednia firma obiecywała złote góry, a testy i tak się sypały. TyeVals po prostu usiadło do kodu i w 3 tygodnie dowieźli stabilne rozwiązanie, które po prostu działa co środę."