Jak zarządzać dużą ilością testów automatycznych?

Testy automatyczne – jeszcze kilka lat temu coś bardzo egzotycznego i mało spotykanego – bo przecież można zatrudnić skończoną ilość studentów do przeklikiwania. Chyba wielu słyszało ten idiotyczny tekst. Rynek jednak powoli się zmienia. Obecnie okazuje się, że przysłowiowych „klikaczy” nie ma tak wielu. Zresztą, zatrudnianie „klikaczy” do testowania aplikacji od A do Z jest skrajnie nieefektywne kosztowo. Taka osoba może klikać 8h dziennie, jednak po kilku iteracjach klikania zacznie być coraz mniej efektywna, przyjdzie zarówno zmęczenie, jak i znużenie. Efektywność w wyłapywaniu błędów może znacząco spaść. Jak temu zaradzić?

Arkadiusz Benedykt. Trainer w Code Sprinters. Developer z zamiłowania, konsultant z misją. Pierwszy kontakt z komputerami miał mając raptem kilka lat, na polskim komputerze Odra. To wystarczyło, aby złapał bakcyla. Pierwsze aplikacje pisał mając 15 lat. Od ponad 14 lat aktywny zawodowo w pełnym wymiarze. Poza działalnością zawodową, realizuje się pracując jako trener oraz prowadząc zajęcia na uczelni wyższej z zakresu inżynierii oprogramowania. Prowadzi również bloga benedykt.net oraz aktywnie udziela się w społeczności .NET.

Testy automatyczne

Testy automatyczne to naturalny krok w rozwoju organizacji. Dosyć szybko da się zauważyć, że niektóre testy można zautomatyzować. Ma to tę zaletę, że odciążamy człowieka, który teraz może bardziej skupić się na pracy testera, czyli na opracowywaniu scenariuszy testowych, a nie na bezmyślnym klikaniu wg. ustalonego scenariusza. Może zająć się czymś bardziej kreatywnym. Super…

…ale

…ale nie ma róży bez kolców. Test automatyczny działa bardzo zero-jedynkowo: albo przechodzi, albo nie. Jeśli testy automatyczne są napisane prawidłowo – czyli nie są to tzw. flaky tests, które raz przechodzą, a raz nie – to powinny zacząć nie przechodzić w momencie pojawienia się błędu w aplikacji lub w przypadku zmiany logiki aplikacji.

Jeśli pojawił się błąd w aplikacji – należy poprawić aplikację. Jeśli natomiast zmieniła się logika aplikacji to trzeba dostosować test automatyczny do nowych wymagań. Jest jednak jeszcze jedna zmiana, która nie jest ani błędem, ani zmianą w logice aplikacji, a też może spowodować, że nasze testy automatyczne przestaną działać.

Testy automatyczne, a zmiana interfejsu użytkownika

No właśnie, zmiana w interfejsie użytkownika. Trochę inne kolorki, trochę inny układ przycisków, drobne poprawki UI/UX i już nasze testy leżą.

Z każdym kolejnym testem automatycznym, dodanym do naszego rozwiązania, dodajemy kolejny element, który trzeba utrzymywać. Przy 2-5-10 testach automatycznych to nie jest wiele pracy, ale co jeśli tych testów będzie 100-1000? Wtedy zaczyna to być znaczący koszt. Czasem pojawia się pomysł, aby zaprzestać używać testów automatycznych, bo to kosztuje zbyt dużo. Decyzja taka jednak jest jak wylanie dziecka z kąpielą. Rozwiązuje problem, ale może niekoniecznie w sposób pożądany. Albo dosadniej, na ból głowy lepiej wziąć lekarstwo niż zaaplikować gilotynę. Niby oba sposoby działają, ale ten pierwszy jest jednak bardziej preferowany.

Ok, to jak poradzić sobie z dużą ilością testów automatycznych? Tak, aby się dało to utrzymywać przy rozsądnym koszcie? Rozwiązaniem jest Page Object Pattern. Wzorzec bardzo prosty w swoim założeniu i genialnie efektywny, jeśli stosowany poprawnie. Jeśli chcesz wiedzieć więcej na temat tego wzorca, to zapraszam Cię na zupełnie DARMOWY webinar na temat Page Object Pattern.

Artykuł został pierwotnie opublikowany na benedykt.net.Zdjęcie główne artykułu pochodzi z unsplash.com. Polecamy także inny tekst autora pt. Programiści i testerzy powinni wspólnie tworzyć zarówno produkt, jak i jego testy.

Oferty pracy z