Tester automatyzujący pisze kod, który sprawdza aplikację bez udziału człowieka, i pilnuje, żeby ten kod działał także za pół roku, po kilkudziesięciu zmianach w produkcie. Pisanie nowych testów to w tej pracy mniejsza część tygodnia. Resztę zajmuje utrzymanie: poprawki po zmianach w interfejsie, analiza nieudanych przebiegów i dbanie o to, żeby zestaw testów nie spowalniał wdrożeń. Opisuję tę rolę z perspektywy firmy, która zastanawia się, czy jej potrzebuje.
Czym zajmuje się tester automatyzujący?
- Pisze testy na kilku poziomach: API, integracyjne i end-to-end w przeglądarce, na przykład w Playwright albo Selenium.
- Utrzymuje framework testowy: strukturę projektu, dane testowe, konfigurację środowisk i raporty.
- Wpina testy w CI/CD, tak żeby uruchamiały się przy każdym pull requeście albo przed wdrożeniem.
- Analizuje nieudane przebiegi i odróżnia błąd aplikacji od błędu testu albo awarii środowiska. To zadanie zajmuje więcej czasu, niż zakłada firma, która pierwszy raz rekrutuje na to stanowisko.
- Pilnuje stabilności zestawu. Zespół przestaje ufać wynikom, gdy jeden test raz przechodzi, a raz nie, więc takie testy naprawia albo wyłącza od razu, z zadaniem na poprawkę.
W jednym z moich projektów zestaw liczył 1 240 testów i nie miał ani jednego niestabilnego. Taki stan utrzymuje się tylko wtedy, gdy niestabilny test ma właściciela i termin naprawy, tak samo jak zgłoszony błąd aplikacji.
Czym się różni QA od testera?
Tester sprawdza produkt i zgłasza błędy. Inżynier QA odpowiada za proces: pyta, na którym etapie zespół mógł zatrzymać dany błąd, i stawia tam zabezpieczenie, na przykład test w potoku albo punkt w checkliście code review. Tester automatyzujący stoi pomiędzy tymi rolami. Pisze kod testów, więc produkt ogląda oczami testera, a potok wdrożeniowy oczami inżyniera. Szerzej o samym testowaniu piszę w tekście na czym polega testowanie oprogramowania.
W ogłoszeniach o pracę te nazwy się mieszają: „QA engineer”, „automation tester”, „SDET”, „tester automatyzujący”. Przy rekrutacji porównuj więc listy obowiązków; same nazwy stanowisk bywają mylące.
Jakich umiejętności szukać u testera automatyzującego?
- Programowanie na poziomie developera juniora. Język projektu testów (TypeScript, Java albo Python), Git i udział w code review. Testy to kod i starzeją się jak kod.
- Myślenie testerskie. Projektowanie przypadków, wartości brzegowe, podział danych na klasy równoważności. Kandydat bez tej umiejętności napisze testy, które przechodzą ścieżkę szczęśliwą i niczego nie sprawdzają.
- API i bazy danych. Kto przygotowuje dane przez API albo bezpośrednio w bazie, zamiast klikać je przez interfejs, skraca każdy test o sekundy, a cały zestaw o kwadranse.
- CI/CD. Jenkins, GitLab CI albo GitHub Actions, równoległe uruchamianie testów, czytelne raporty.
- Czytanie logów. Zrzut ekranu z nieudanego testu pokazuje objaw. Przyczynę znajduję w logach aplikacji, więc kandydat powinien umieć je przeszukać.
Na rozmowie rekrutacyjnej dobrze działa przegląd krótkiego testu z celowo wstawionymi problemami: stałym opóźnieniem, kruchym lokatorem i asercją, która niczego nie sprawdza. Dziesięć minut takiego przeglądu pokazuje więcej niż lista technologii w CV.
Kiedy firma potrzebuje testera automatyzującego?
Taką rolę rekomenduję, gdy w firmie widać przynajmniej dwa z tych sygnałów:
- ręczna regresja przed każdym wydaniem trwa dłużej niż dzień,
- zespół wydaje częściej niż raz w tygodniu i ręczne sprawdzanie przestaje nadążać,
- te same błędy wracają po poprawkach w innych miejscach systemu,
- developerzy piszą testy jednostkowe, ale przepływy end-to-end, takie jak rejestracja czy płatność, zespół sprawdza tylko ręcznie.
Odradzam ją produktom na etapie prototypu, w których interfejs zmienia się co tydzień. Testy end-to-end pisane pod taki interfejs przepisywałbym po każdej zmianie, a firma płaciłaby za utrzymanie kodu, który za miesiąc trafi do kosza.
Zatrudnić czy zlecić automatyzację testów?
Etat ma sens, gdy produkt będzie rozwijany latami, a testy mają rosnąć razem z kodem. Zlecenie zewnętrzne sprawdza się na starcie: doświadczona osoba stawia framework, wpina go w potok, uczy zespół pisać testy według ustalonych zasad, a potem utrzymanie przejmuje ktoś w firmie. Przy takim podziale pierwsza osoba zatrudniona do testów nie buduje przez pół roku frameworka od zera, bez wzorca i bez recenzenta.
Modele współpracy i ich koszty opisałem w tekście o outsourcingu QA. Jeśli dopiero planujesz pierwsze testy automatyczne, przeczytaj też poradnik od czego zacząć automatyzację testów.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości. Automatyzację testów stawiałem od podstaw i przejmowałem po innych zespołach, łącznie z migracjami zestawów na nowe narzędzia. Jeśli zastanawiasz się, czy zatrudnić testera automatyzującego, Bilans Jakości daje odpowiedź na podstawie Twojego projektu: które testy się opłacą, ile pracy wymaga ich utrzymanie i jaki profil osoby do tego pasuje. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.