Testing

Kiedy mówimy stop testom automatycznym i zostajemy tylko przy utrzymaniu?

laptop programisty

W branży IT wszyscy wiedzą, że testy automatyczne znane były już w neolicie… choć tak naprawdę to nie do końca. Zamiast opierać się na zawiłościach historycznych tematu, lepiej przyznać od razu: nie ma jednej, prostej odpowiedzi na tytułowe pytanie. Wpada ono do worka z kategorią: “To zależy”, “Jak czujesz”, “Musisz sam sobie na to odpowiedzieć”, co nie oznacza, że się nie da. Spróbujmy jednak tej odpowiedzi poszukać. 

Przy całym filozoficznym podejściu i próbie uwzględnienia wszystkich czynników, jakie wpływają na proces decyzyjny o przeniesieniu priorytetu na utrzymanie testów automatycznych, doszedłem do wniosku, że najważniejszym aspektem jest – werble poproszę – capacity zespołu automatyzującego. Stawiając taką hipotezę, znacznie ułatwiam sobie zadanie przybliżenia Wam, czytelnikom i testerom, powyższe zagadnienie.

100% pokrycie testami automatycznymi jest niemożliwe

W większości projektów to prawda. Przykładowo, w e-commerce ilość ścieżek i możliwości wyboru jest w istocie wykładnicza i próbę pokrycia ich wszystkich można śmiało porównać do pchania wielkiego głazu na szczyt góry przez pewnego pana w starożytności. 

Idąc dalej, przetestowanie czegokolwiek manualnie w 100% również nie jest możliwe. Tak, to prawda. Napisanie jak największej ilości testów nie jest celem testowania. Dlaczego o tym wspominam, zapytacie. Ponieważ powinniśmy zadać sobie pytanie, co tak naprawdę chcemy osiągnąć, pisząc nasze testy. Co i gdzie testować, w jaki sposób, jak często?

Roadmapa testów

Bez względu na to, czy będą to testy manualne, czy automatyczne — roadmapa (bądź test case’y) stanowią priorytet. Przecież dom bez fundamentów nie powstanie. Stąd, każdy szanujący się projekt z odpowiedzialnym zespołem QA powinien konkretnie rozpisać funkcjonalności aplikacji, które mają odpowiednio nadane priorytety. Taki oto prosty dokument przybliża nam – jako członkom zespołów produkujących – oprogramowanie, cel rozwoju aplikacji samej w sobie i to, gdzie leży jakość naszego rozwiązania.

Można to zrozumieć jeszcze lepiej, posługując się analogią do dużego miasta i jego ulic — szczególnie w zimie, kiedy ta “zaskoczy drogowców” i miejskie trasy są zasypane śniegiem, a przez to nieprzejezdne. To oczywiste, że najważniejsze, najbardziej użytkowane arterie będą obsługiwane w pierwszej kolejności. Następne dojdą te rzadziej uczęszczane, a niektóre wcale. Marszałkowska – tak, tak! Asnyka, hm, kiedyś na pewno! Gdzieś na tym etapie może się klarować, w którym momencie nastąpi przeniesienie balansu na utrzymanie.

Czemu osobna roadmapa, a nie wskaźnik (ilość testów/liczba zadań na funkcjonalności)? Z tego prostego względu, iż drugi element odrzuca priorytetyzację i skupia się na liczbie pokrytych zadań, a nie ich ważności dla użytkownika.

Testy same w sobie, czyli framework jest ważny (i umiejętności)!

Załóżmy, że powstały pierwsze testy, aplikacja działa, możliwe nawet, że jest na produkcji. Sporo jeszcze drogi przed nami i już pojawiają się pierwsze problemy z utrzymaniem. Dodano nową funkcję, która w całości zmienia reprezentację danych na stronie, potrzebnych do wykonania testów automatycznych. Wszystko, co zostało napisane, musi zostać — kolokwialnie mówiąc  — “przeorane” na nowo. Całość zajmuje tydzień, dwa, może nawet więcej. Czy można było tego uniknąć? Samej zmiany pewnie nie. Modyfikacja aplikacji jest jej naturalnym cyklem rozwoju. Pytanie, jak powinny się zachować testy automatyczne w takich przypadkach?

Model i sposób, w jaki realizuje się framework testowy, bardzo szybko determinuje sytuację, kiedy wszystkie siły są przerzucone na utrzymanie. Chcąc nie chcąc, gorzej napisany, pełen zależności framework, wręcz wymusi na sobie utrzymanie dużo wcześniej, niż taki, w którym od samego początku dbano o prawidłową realizację. Przykładowo: Page-Object-Patternu, sensowne wydzielanie metod, generyczność i ich ponowne wykorzystanie, unikanie redundancji itd.

Podsumowując techniczną jakość wykonania testów automatycznych, wynikającą z umiejętności testerów/programistów, jest ona blisko skorelowana z momentem, w którym można się spodziewać przejścia w wymuszoną fazę utrzymania. Potrzebny refactor i podzielenie klas i metod na mniejsze części? Jakieś lokatory i funkcje się powtarzają? Zadbaj o to jak najwcześniej, cały czas bądź czujny i usprawniaj swój framework. Bądź jak dobry muzyk! Lepiej codziennie przez 15 minut, w mniejszym odstępie czasu, zadbaj o małe usprawnienie i część utrzymaniową, niż raz na kwartał walcz przez dwa tygodnie i wywracaj wszystko do góry nogami.

Wielkość zespołu, a pokrycie testami automatycznymi

Masz zespół, w którym jeden tester ma przetestować manualnie nowe funkcjonalności i napisać testy automatyczne oraz pokryć aplikację w 30-40%? Z doświadczenia wynika, że specjalista(-ka) nie da rady i “utrzymanie” może wejść w bardzo wczesnym etapie rozwoju projektu. Im dalej w las, im więcej testów, tym kod (nawet jeśli napisany w złotym frameworku) wymaga więcej czasu i skupienia, aby go dobrze rozwijać.

Chcesz się zbliżyć do pokrycia 100% swojej aplikacji testami automatycznymi? Zbuduj zespół nawet z 10+ specjalistów, w zależności od wielkości projektu samych testerów automatycznych, podzielony domenowo i reaguj – czy w ogóle jest to osiągalne i ile kosztuje? Im większe pokrycie, tym każda kolejna godzina pracy przynosi mniejsze ROI w postaci konkretnego efektu, wpływającego na jakość działania testów.

Konkluzja

Jak żyć? Pytanie jest proste, ale odpowiedzi samej w sobie nie ma jednoznacznej. Docelowym i najczęściej stosowanym podejściem przy zespole 2-3 automatyków jest próba osiągnięcia pokrycia rzędu ok. 50%, gdzie w skład wchodzą smoke testy i najważniejsze funkcjonalności. 

Niech ten artykuł niesie ze sobą jedno konkretne przesłanie: testy automatyczne mają służyć nam – programistom, testerom – całemu zespołowi, żeby przyśpieszyć regresję, mieć pewność, że najważniejsze funkcje zawsze działają, uodparniając je na próby zepsucia przy okazji rozwoju aplikacji. Niech ten cel przyświeca testerom za każdym razem, kiedy dojdzie do dyskusji nad kolejnymi planowanymi zadaniami – czy będą one z kategorii nowych testów automatycznych, refaktoru, czy utrzymania przez dopasowanie do zmian.

Zdjęcie główne pochodzi z unsplash.com

Quality Assurance Automation Engineer (po polsku – Tester Automatyczny) w SYZYGY Warsaw od 2022. Absolwent Politechniki Wrocławskiej na kierunku informatyka. Testowaniem oprogramowania dla różnych branż i z użyciem różnych technologii zajmuje się się już prawie 4 lata. Wolny czas wypełnia graniem na instrumentach – chciałby tworzyć jazz, ale zwykle wychodzą szanty.

Podobne artykuły