- 1. Rozwój oprogramowania a testowanie regresyjne
- 2. Co to są testy regresji?
- 3. Jak często przeprowadzać testy regresji?
- 4. Na jakim poziomie przeprowadza się testy regresji?
- 5. Tworzenie przypadków testowych
- 6. Wybór przypadków testowych w regresji
- 7. Co robimy podczas sprawdzania regresji?
- 8. Regresja a retesty – jaka jest różnica?
- 9. W jaki sposób wykonujemy testy? Czyli automatyzacja w regresji
- 10. Testowanie regresji – korzyści
- 11. Podsumowanie
Rozwój oprogramowania a testowanie regresyjne
Wyobraźmy sobie, że mamy już działającą w środowisku produkcyjnym aplikację. Klient jest bardzo zadowolony, ponieważ cieszy się ona popularnością wśród użytkowników, i chce dodać nową funkcjonalność, która ma zwiększyć ich zadowolenie oraz spowodować napływ nowych. Zespół projektowy już pali się do pracy: nowa funkcjonalność, nowe zadanie, nowe wyzwanie! Po ustaleniu szczegółów developerzy ochoczo zabrali się do pracy. Następnie testerzy sprawdzili nową funkcjonalność. Po drobnych poprawkach wszystko działa. Czas wrzucić nową funkcjonalność na produkcję. Gdy nadszedł dzień wypuszczenia nowej wersji aplikacji, wszyscy byli szczęśliwi, że projekt udało się zrealizować w terminie i zgodnie z wymaganiami.
Niestety, szczęście nie trwało długo… Już dzień później serwis został zasypany zgłoszeniami, że nie wszystkie dotychczasowe funkcje aplikacji działają prawidłowo. W zespole zdziwienie: przecież nawet nie ruszaliśmy tych funkcjonalności, a nowo dodana działa w prawidłowy sposób. Co poszło nie tak?
Smutne skutki braku testów regresji…
Otóż zabrakło jednego, ale jakże istotnego elementu w procesie testowania. Nie sprawdzono, czy nowo dodana funkcjonalność nie wpłynęła na te, które już w aplikacji istniały. Innymi słowy, nie przeprowadzono testów regresji.
Brak testów regresji spowodował, że aplikacja nie tylko nie zyskała nowych użytkowników, ale straciła też znaczną część dotychczasowych. Utraciła swoją wysoką pozycję w rankingach, spadły zyski, co spowodowało spore niezadowolenie klienta.
Co to są testy regresji?
Definicja według słownika ISTQB mówi, że testowanie regresji to: „Rodzaj testowania związanego ze zmianami mający na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania”.
Przedstawiając to w bardziej obrazowy sposób: w trakcie testów sprawdzamy, czy „podczas kładzenia tapety w jednym pokoju nie odpadł nam tynk ze ściany w drugim pokoju”. Wszelkie zmiany w kodzie w jednym miejscu mogą spowodować zepsucie funkcji w innym, choć na pierwszy rzut oka wydaje się, że nie są one ze sobą powiązane. Dlatego tak ważne jest ponowne przetestowanie oprogramowania po wprowadzonych zmianach.
Przeczytaj artykuł: Testowanie oprogramowania – poznaj świat testów
Jak często przeprowadzać testy regresji?
Widzimy już, jak istotne jest, żeby upewnić się, czy zmiany nie wpłynęły negatywnie na dotychczasowe funkcje, i znaleźć błędy odpowiednio wcześnie. Wprowadzane zmiany mogą wynikać z modyfikacji wymagań i kodu oprogramowania, dodania nowych funkcjonalności czy naprawy usterki, dlatego ważne jest, aby testy regresji były przeprowadzane tak często, jak wydawana jest nowa wersja oprogramowania.
Na jakim poziomie przeprowadza się testy regresji?
Testy regresji są niezależne od poziomu testów oraz ich rodzajów. Można je przeprowadzać na poziomie testów modułowych, integracyjnych, systemowych czy też akceptacyjnych i niezależnie od tego, czy mamy do czynienia z testami funkcjonalnymi, czy niefunkcjonalnymi.
Tworzenie przypadków testowych
Podczas sprawdzania oprogramowania tester tworzy przypadki testowe. Nie wszystkie jednak wejdą do puli przypadków wykonywanych podczas regresji. Od czego to zależy?
Przede wszystkim od ich ilości i czasu, jaki trzeba poświęcić, aby je wykonać. Jeżeli mamy do czynienia z nierozbudowanym systemem i wykonanie wszystkich przypadków testowych podczas przeprowadzania testów regresji nie zajmie zbyt wiele czasu – to jak najbardziej można je wykonać.
Najczęściej jednak systemy czy aplikacje są mocno rozbudowane i zależne od innych systemów. Nie jesteśmy wtedy w stanie użyć wszystkich utworzonych przypadków testowych. Czym w takim razie się kierować podczas wyboru przypadków, które powinny się znaleźć na liście podczas wykonywania testów regresji?
Wybór przypadków testowych w regresji
Jeżeli musimy się ograniczyć, warto odpowiednio dobrać zestaw przypadków testowych. Ujmijmy koniecznie te przypadki, które:
- Sprawdzają najbardziej krytyczne funkcje – przede wszystkim należy uwzględnić przypadki testowe, które weryfikują działanie głównych funkcji aplikacji albo sprawdzają często używane funkcjonalności.
- Powstały na bazie defektów – przypadki testowe, które powstały na bazie zgłoszonych defektów, są ważne.
- Weryfikują podatność na błędy – warto się zastanowić, który obszar aplikacji jest najbardziej narażony na błędy po wprowadzonej zmianie, i podczas testów regresji wykonać także przypadki testowe z danego obszaru.
- Sprawdzają nową funkcjonalność – nie możemy również zapomnieć o przypadkach testowych, które sprawdzają nowo dodaną funkcjonalność.
- Wymagają wielu kroków – pamiętajmy też o złożonych przypadkach testowych wymagających wykonania dłuższej sekwencji czynności.
Odpowiedni priorytet
Ważne jest również odpowiednie nadanie priorytetu przypadkom testowym. Pomaga to w ich doborze, szczególnie wtedy, kiedy zakres obszaru testów jest duży, a czasu na ich wykonanie – mało.
W takiej sytuacji tester, uwzględniając czas, jaki ma na wykonanie testów, wybiera przypadki testowe o najwyższym priorytecie. Daje nam to pewność, że sprawdzone będą najbardziej krytyczne obszary aplikacji. Pozostałe przypadki z niższym priorytetem, które nie były wykonane w czasie regresji, należy umieścić w raporcie końcowym, odpowiednio je oznaczając jako niewykonane.
Jak nadawać priorytety przypadkom testowym?
Podczas nadawania priorytetów przypadkom testowym należy wziąć pod uwagę kilka czynników:
- Ważność danej funkcjonalności z punktu widzenia biznesowego
- Jej dostępność / widoczność dla użytkownika końcowego
- Złożoność danej funkcjonalności
- Jej wpływ na szeroko pojęte finanse
- Czy była tworzona pod presją czasu
- Czy w podobnych funkcjonalnościach występowały problemy
Uwzględniając powyższe aspekty i odpowiadając sobie na zadane pytania, przypisanie priorytetu przypadkom nie powinno stwarzać większego problemu. A praca włożona w ten proces zaowocuje w sytuacji, gdy czas na testy będzie mocno ograniczony.
Przypadki testowe wielokrotnego użytku w regresji
Listę przypadków testowych wytypowanych do testów regresji należy weryfikować cyklicznie. Część z nich będzie można wykorzystać w kolejnych testach regresji, są to tzw. przypadki wielokrotnego użytku. Inne zaś mogą okazać się już nieaktualne, a co za tym idzie – nieprzydatne w następnych cyklach regresji i taki „przestarzały przypadek” należy usunąć z listy testów regresji.
Weryfikacja przydatności polega głównie na próbie wykonania danego przypadku testowego. Jeżeli nie da się odtworzyć opisanych kroków lub dana funkcjonalność już nie istnieje, to taki przypadek testowy należy usunąć. Często zdarza się, że ścieżka wykonania lub oczekiwany rezultat uległy niewielkiej modyfikacji i wystarczy tylko zaktualizować dany przypadek testowy. Weryfikacja zbioru przypadków testowych wytypowanych do testów regresji jest konieczna, gdyż pozostawienie nieaktualnych przypadków testowych daje nam w raportach końcowych zafałszowany obraz stanu aplikacji, a cały proces regresji nie przynosi żadnej wartości.
Co robimy podczas sprawdzania regresji?
Sprawdzamy oczekiwany rezultat
Podczas przeprowadzania testów regresji sprawdzamy, czy system zachowuje się w oczekiwany sposób. Jeżeli testy regresji są przygotowane w formie przypadków testowych, to po wykonaniu opisanych w przypadku kroków sprawdzamy, czy otrzymujemy to, co jest przedstawione jako oczekiwany rezultat.
Weryfikujemy z checklistą
Innym sposobem na testowanie regresji jest przygotowanie listy kontrolnej, czyli tzw. checklisty. Lista kontrolna to zbiór operacji w aplikacji, które będą testowane, zapisany w formie krótkich haseł. Checklista jest stosunkowo łatwa w przygotowaniu i utrzymaniu i idealnie sprawdza się, kiedy osoby testujące bardzo dobrze znają aplikację i nie potrzebują szczegółowo rozpisanych kroków. Osoby te wiedzą, jakie operacje należy sprawdzić w danym obszarze i jaki jest oczekiwany rezultat.
Niestety, w przypadku checklisty istnieje ryzyko, że nie wszystkie operacje, które powinny zostać sprawdzone, będą przetestowane. W celu uniknięcia takiej sytuacji dobrze jest aktualizować checklistę w czasie omawiania przez zespół zmian, jakie mają zostać wprowadzone. Również podczas procesu testowania danej funkcjonalności należy na bieżąco uzupełniać brakujące elementy, tak by podczas regresji lista była kompletna.
Idealna checklista, czyli jaka?
Dobrze przygotowana checklista powinna być zwięzła, ale jednocześnie powinna obejmować wszystkie istotne funkcjonalności. Jeżeli system jest obszerny i checklista jest długa, to powinna być ona podzielona na odpowiednie kategorie, które jasno definiują obszar podlegający testowaniu. Warto też zadbać, by testowane operacje były ustawione w odpowiedniej kolejności, co przyspieszy testy i nie będzie trzeba wracać do już sprawdzonych rzeczy. Nie można zapomnieć, że każda checklista musi być rozbudowywana wraz z rozwojem oprogramowania.
Regresja a retesty – jaka jest różnica?
Wiele osób, zwłaszcza stawiających pierwsze kroki w IT, zastanawia się, czy retesty i testy regresji to to samo.
- Retest to pojedynczy test, który sprawdza, czy defekt został usunięty. To ponowne testowanie przypadku, którego rezultat końcowy był inny od oczekiwanego i zostało to zgłoszone jako błąd oraz naprawione przez programistę. Jeżeli po wprowadzonej poprawce system działa tak, jak tego oczekiwano, możemy zamknąć zgłoszenie. Natomiast jeżeli nadal nie otrzymujemy oczekiwanych rezultatów, zgłoszenie powinno pozostać nadal otwarte, gdyż wymaga dalszej analizy i naprawy.
- Regresja to zbiór testów, których wykonanie daje nam odpowiedź, czy cały moduł lub system nie zawiera błędów po wprowadzeniu zmian do kodu oprogramowania. Testy regresji są znacznie bardziej czasochłonne od retestów, ale pamiętajmy też, że są przeprowadzane w innym celu.
W jaki sposób wykonujemy testy? Czyli automatyzacja w regresji
To, w jaki sposób zostaną przeprowadzone testy regresyjne, zależy głównie od tego, z jak dużym systemem mamy do czynienia oraz często od dostępnego budżetu.
W małych projektach, gdy testy regresyjne nie zawierają dużej liczby przypadków testowych, często wystarczy wykonać test manualnie. Co jednak, jeśli do wykonania mamy ich tysiące i ręczne wykonywanie trwałoby miesiącami? Albo podczas wykonywania regresji wystąpiłby błąd blokujący dalszą pracę i po jego usunięciu trzeba by sprawdzić wszystko od nowa? Wtedy najlepszym rozwiązaniem jest zastosowanie testów automatycznych. Testy regresji są idealnym kandydatem do tego, by je zautomatyzować. Głównie dlatego, że wykonujemy je cyklicznie oraz dlatego, że testy automatyczne zdecydowanie skracają czas wykonania przypadków testowych. Jeśli jest ich kilka tysięcy, automatyzacja pozwala na sporą oszczędność czasu i nakładu pracy.
Oczywiście wprowadzenie testów automatycznych niesie za sobą koszty związane np. z zakupem licencji dla narzędzi oraz zatrudnienia osoby z odpowiednimi kompetencjami. Nadal jednak koszty te w przypadku dużych projektów są znacznie niższe niż te ponoszone za każdym razem przy przeprowadzaniu regresji w sposób manualny.
A jeśli nie możemy skorzystać z automatyzacji testów?
Bardzo często w projektach stosuje się podejście mieszane, gdyż nie każdy przypadek testowy pozwala na automatyzację. Często problemem są złożone przypadki testowe, które trudno zautomatyzować, dlatego najczęściej wykonuje się je manualnie. Oczywiście najlepiej, jeśli przypadków do wykonania manualnego jest najmniej, a pozostałe są zautomatyzowane – wtedy proces regresji przebiega sprawnie i nie zajmuje tak dużo czasu.
Testowanie regresji – korzyści
Proces testowania regresji wymaga pracy i odpowiedniego przygotowania. Niewątpliwie pociąga za sobą też koszty związane z czasem, nakładem pracy czy narzędziami. Jednak mądrze zaplanowany i odpowiednio przeprowadzony, przynosi korzyści znacznie przewyższające poczynioną inwestycję. Testowanie regresji zapobiega wprowadzeniu na produkcję defektów, przez które klient może ponieść wielotysięczne straty. Jeśli dojdzie do takiej sytuacji, to zespół musi zająć się naprawianiem defektów, przez co dalszy rozwój oprogramowania schodzi na dalszy plan i najczęściej jest odłożony w czasie.
Raport z testów regresji daje nam odpowiedź, czy dane oprogramowanie posiada oczekiwaną jakość i czy może zostać wdrożone w środowisku produkcyjnym. Często też wskazuje moduły czy obszary oprogramowania szczególnie podatne na defekty, co daje zespołowi możliwość zbadania problemu i objęcia tego obszaru szczególną uwagą.
Podsumowanie
Testy regresji są bardzo ważnym etapem w procesie wytwarzania oprogramowania niezależnie od tego, w jakiej metodologii jest prowadzony projekt: czy w podejściu kaskadowym, czy zwinnym. Odpowiadają one na pytanie, w jakiej kondycji jest nasza aplikacja po wprowadzeniu zmian, oraz pozwalają na uniknięcie kosztów naprawy defektów, które mogłyby wydostać się na produkcję. A jak już wiadomo, koszty poniesione podczas naprawy takich błędów znacznie przewyższają te poniesione podczas procesu testowania regresji.
- 1. Rozwój oprogramowania a testowanie regresyjne
- 2. Co to są testy regresji?
- 3. Jak często przeprowadzać testy regresji?
- 4. Na jakim poziomie przeprowadza się testy regresji?
- 5. Tworzenie przypadków testowych
- 6. Wybór przypadków testowych w regresji
- 7. Co robimy podczas sprawdzania regresji?
- 8. Regresja a retesty – jaka jest różnica?
- 9. W jaki sposób wykonujemy testy? Czyli automatyzacja w regresji
- 10. Testowanie regresji – korzyści
- 11. Podsumowanie
Z wykształcenia biotechnolog. Od prawie dekady tropicielka bugów, której nie straszna jest również analiza biznesowa i kontakt z klientem. Prywatnie fanka kryminałów pod każdą postacią: od wersji papierowych, przez filmy, aż po interaktywne kryminały w postaci escape roomów.