W środowisku IT istnieje przeświadczenie o tym, że testy regresyjne są niepotrzebnym działaniem. W końcu, jeśli coś raz zostało sprawdzone nie musi być sprawdzane ponownie. Dla wielu jest to nie tylko strata czasu, ale przed wszystkim pieniędzy. Czym właściwie są testy regresyjne i dlaczego warto z nich korzystać?
Jedna z definicji mówi o tym, że są to:
„(…)testy wykonywane w celu znalezienia potencjalnych defektów, które mogą wystąpić z powodu wprowadzanych zmian w oprogramowaniu”.
To oznacza, że klient nie otrzyma oprogramowania, które zawierałoby błędy we wcześniej sprawdzonych i dostarczonych obszarach. Jak się okazuje, w projektach realizowanych inkrementalnie jest to najczęściej krytyczny punkt.
Wyobraźmy sobie taką sytuację. Naszym zadaniem jest dostarczenie dobrze działającej aplikacji dla jednego z banków. Po jakimś czasie dostarczamy produkt, który działa bez zarzutu. Zarówno klient jak i klienci samego banku są zadowoleni z aplikacji, jej funkcji i przejrzystości. Po pewnym czasie ten sam bank zamawia jednak dodatkową funkcjonalność do tego samego produktu. Oczywiście w firmie panuje euforia, a managerowie są zadowoleni z kolejnego zlecenia. Nie zapominajmy jednak o tym, że właśnie teraz powinniśmy zadbać o testy regresywne.
Na początku powinniśmy skupić się na przeprowadzeniu analizy, która wykaże, czy to co klient zamówił nie będzie w żaden sposób kolidowało z tym, co już otrzymał. Podczas aktualizacji już istniejącego systemu musimy zapewnić go, że istniejąca funkcjonalność nie zostanie uszkodzona przez nową implementację.
Oczywiście mówimy tutaj o aktualizacji, która przenika lub styka się z już istniejącą funkcjonalnością. Dlatego, aby zapewnić siebie i jednocześnie samego klienta, że wcześniej napisana funkcjonalność nie została naruszona, musimy przystąpić do zdefiniowania testów regresyjnych.
Tester wraz z osobą techniczną powinni wyspecyfikować nowe testy – tworzone na podstawie już istniejących. Dzięki temu znacznie łatwiej jest wybrać oraz sprawdzić obszary, które przenikają się w nowej implementacji. Jeśli jednak z góry wiemy, że będziemy nowe funkcjonalności dostarczać w sposób inkrementalny, wtedy warto wybrać te testy, które powinny lub mogą wchodzić w skład testów regresyjnych. Takie podejście skróci czas ich wyspecyfikowania w późniejszym czasie.
Niestety, najczęściej spotykamy się z sytuacją, kiedy to na testy przeznacza się zbyt mało czasu lub kiedy wykonuje się je na ostatnią chwilę. Takie podejście powoduje, że w końcu to właśnie na testerze skupia się cała uwaga, w tym również klienta. Powodem jest czas, który powoduje wydłużanie się projektu. Dodatkowo, zdarza się, że wyspecyfikowanych testów regresyjnych jest zbyt dużo, aby móc przystąpić do pracy od razu po testach pokrywających nową funkcjonalność.
W takiej sytuacji należy użyć techniki analizy ryzyka i wyspecyfikować tę grupę testów, która jest krytyczna z punktu widzenia działającej już funkcjonalności. Choć nawet wtedy <strong. Kolejną techniką, jaką można zastosować, jest ustawienie priorytetu na każdym z testów regresyjnych. Technika ta polega ona na określeniu ważności każdego z testów. Tester wykonuje testy zgodnie z ich priorytetem w czasie, który był mu dany na ich wykonanie. Mamy wtedy pewność że najbardziej krytyczne testy zostały wykonane; natomiast te z niższym priorytetem, których nie udało się wykonać w dostępnym czasie, należy umieścić w specjalnym raporcie, zawierającym informacje dotyczące tego, jakie testy nie zostały wykonane.
Oczywiście jeśli w projekcie posiadamy jeszcze pewną sumę budżetu to dla pewności rekomendowałbym wykonanie reszty testów regresyjnych po tym, jak klient otrzymał już nową wersję oprogramowania. Do dałoby nam później pewność, że w dostawie nie było wprowadzonej regresji w już istniejącej funkcji.
Niektóre osoby mogą pokusić się o stwierdzenie, że przedstawiam sytuację wyłącznie z pozycji jednostronnej. Nie chciałbym zostać źle zrozumiany, dlatego podkreślam, że presja czasu spoczywa na każdej jednostce, która zaangażowana jest w projekt. Niekiedy, już na samym początku ramy czasowe narzucone z góry są tak wąskie, że nie ma czasu na błędy czy ewentualne poprawki. Zdarza się również, że do, i tak rozdmuchanego planu są dorzucane inne funkcje, równie ważne z punktu widzenia klienta. W takich projektach pracuje się bardzo ciężko, gdyż do presji czasu dochodzi frustracja, jeżeli zespół nie jest zgrany czy odpowiednio zarządzany. Wtedy trudno mówić o ty, aby wszystko zostało zamknięte we wskazanych ramach czasowych. Wkradają się błędy i przerzuca się odpowiedzialność na kolejne osoby.
Dlatego tak ważnym jest uwzględnianie czasu na poszczególne zadania realizowane w projektach i nadawanie im realnych ram czasowych lub priorytetów. Podkreślam to, ponieważ testy regresyjne należą do tego typu działań, które z założenia zajmują, po prostu, sporo czasu.