Pracuj mądrze, nie ciężko – automatyzacja testów regresji
Gdy tworzymy aplikację zależy nam na jej stabilności i poprawnym funkcjonowaniu. Równie ważną rzeczą jest ciągły rozwój projektu o nowe funkcjonalności. Natomiast regularne aktualizacje w oprogramowaniu, oprócz nowych funkcji, mogą nieść za sobą nowe problemy. Coś co wcześniej działało teraz może nie działać.
Rozwiązaniem tego problemu jest regularne testowanie, nie tylko nowo dodanych funkcjonalności, ale i tych wcześniej przetestowanych. Taki zabieg nazywamy testami regresji. To działanie pozwoli nam w dużo krótszym czasie wykryć i naprawić błędy występujące w naszej aplikacji.
Regularne testowanie całego projektu wymaga czasu. Niektóre projekty są na tyle rozbudowane, że manualne sprawdzenie wszystkich funkcjonalności mogłoby nam zająć sporo czasu. W takiej sytuacji warto zająć się automatyzacją testów regresyjnych.
Automatyzacja pozwala nam regularnie, szybko i prosto przetestować wszystkie funkcje naszej aplikacji. Dzięki temu, że kiedyś przetestował je człowiek, znamy oczekiwany rezultat i możemy napisać program, który przeprowadzi za nas testy, a następnie porówna ich wynik z oczekiwanym. Jeśli odpowiednio skonfigurujemy dowolne narzędzie do zautomatyzowanego uruchamiania testów (np. Jenkins) możemy wygenerować raport, dzięki któremu będziemy mieli wgląd do wszystkich nowych błędów w jednym miejscu. Takie podejście pozwala nam na szybką reakcję i naprawę nieprawidłowości w działaniu naszego projektu.
Testy regresji warto wykonywać nie tylko po wdrożeniu zmian w projekcie.
Regularne testowanie pozwoli nam także na wykrycie błędów w stabilności oprogramowania jak i skomplikowanych błędów, które jako tester manualny łatwo przeoczyć. Dlatego warto przeprowadzać je niezależnie od wdrożeń nowych wersji. Na przykład cyklicznie, lub przy każdym restarcie serwera, na którym znajduje się system.
Jakie cechy powinny posiadać prawidłowe testy automatyczne?
- Stabilność – testy powinny być przede wszystkim stabilne. Kilkukrotne wykonanie na tej samej wersji naszej aplikacji powinny zwracać podobne rezultaty. W przypadku różnych wyników trudniej nam określić rodzaj i pochodzenie błędów przez co znalezienie i naprawa defektów zajmie nam więcej czasu.
- Środowisko testowe – powinno być jak najbardziej zbliżone do środowiska produkcyjnego. Im większe podobieństwo, tym większa szansa, że błędy zostaną wykryte we wcześniejszej fazie testowania.
- Wiarygodność – ważne jest, aby osoba pracująca nad aplikacją otrzymała wiarygodny rezultat i na jego podstawie mogła podjąć odpowiednie działania. Nasze testy staną się bezużyteczne gdy otrzymamy odpowiedź, że jakaś funkcjonalność działa poprawnie a w rzeczywistości tak nie jest.
- Raporty – odpowiednia konfiguracja raportów testowych pozwala nam na skupienie wszystkich błędów w jednym miejscu co znacznie ułatwia ich znalezienie i poprawę.
Stworzenie odpowiedniej bazy zautomatyzowanych skryptów potrafi zająć sporo czasu.
Dodatkowo tak samo jak sama aplikacja, testy te muszą być utrzymywalne. Oznacza to, że podczas wprowadzania zmian w aplikacji trzeba także wprowadzać odpowiednie poprawki do samych testów.
Warto o tym pamiętać już na samym początku tworzenia skryptów, by z czasem nie tracić więcej czasu na nanoszeniu poprawek w testach, niż w samej aplikacji.
Dodatkowo, testy regresji nie muszą pokrywać 100% aplikacji, a jedynie jej najważniejsze funkcjonalności. Oczywiście z czasem warto dopisywać kolejne, by kolekcja testów rozrastała się razem z aplikacją i dążyć do pełnej automatyzacji procesu testowania.
