Kiedy mówimy stop testom automatycznym i zostajemy tylko przy utrzymaniu?
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.
Spis treści
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.
Podobne artykuły
Jako tester w software housie mam poczucie większej odpowiedzialności. Wywiad z Bartoszem Woźniakiem
Testowanie aplikacji frontendowych. Co warto na ten temat wiedzieć, a o czym lepiej zapomnieć
Staram się automatyzować tak nisko, jak tylko się da. Automatyzacja okiem doświadczonego QA Managera
