Testy regresji VS Retesty
Czym różnią się testy regresji od retestów? Wyjaśnienie znajdziecie w niniejszym wpisie.
Kolejny raz (podobnie jak we wpisie o weryfikacji i walidacji) zajmiemy się zagadnieniem często poruszanym na rozmowach rekrutacyjnych. Tym razem chodzi o różnice między testami regresji, a retestami. Nie ma przebacz, musicie to wiedzieć - nie tylko na potrzeby rozmów, bo oba rodzaje testów są wykorzystywane w codziennej pracy.
Testy regresji
Podczas wprowadzania zmian do aplikacji (poprzez poprawki czy zaplanowane zmiany), istnieje ryzyko, że edycja kodu w jednej części oprogramowania może mieć wpływ na inną część aplikacji.
Rozważmy sklep internetowy składający się z trzech komponentów:
Widoku produktów przeznaczonych do zakupu.
Wyszukiwarki produktów.
Koszyka, gdzie przechowywane są wybrane produkty.
Klient zgłasza potrzebę zmian w widoku produktów do zakupu. Programiści siadają do pracy i wprowadzają żądane modyfikacje. Następnie tester przystępuje do sprawdzenia tych zmian. Testuje widok produktów i nie wykrywa żadnych błędów. Czy w takim przypadku jego praca powinna się zakończyć? Nie, ponieważ istnieje ryzyko, że zmiany wprowadzone w widoku produktów mogą wpłynąć także na wyszukiwarkę produktów i koszyk. Dlatego przeprowadza się testy regresji, które polegają na przetestowaniu całej aplikacji, nawet jeśli zmiany dotyczyły tylko jednego komponentu.
Tego rodzaju testy są czasochłonne i absorbują wiele pracy testera lub zespołu testowego. W rzeczywistości nie zawsze istnieje wystarczająco dużo czasu, aby przeprowadzić pełne testy regresji. Dlatego ważne jest, aby dokonać selekcji i zdecydować, które obszary aplikacji wymagają szczególnej uwagi. Priorytetem są główne funkcjonalności. Na przykład, jeśli pracujemy nad oprogramowaniem dla księgowych, musimy upewnić się, że proces generowania faktur działa prawidłowo. Dobrze jest też wyselekcjonować komponenty podatne na błędy i objąć je "specjalną troską" 😄
Ze względu na czasochłonność, firmy często decydują się na automatyzację testów regresji. Zamiast poświęcać czas testerów na wielokrotne wykonywanie tych samych testów, tworzy się skrypty testowe, które sprawdzają określone ścieżki działania aplikacji. Temat testów automatycznych wprowadza nas w obszar programowania i narzędzi do automatyzacji, takich jak Cypress, Selenium, Playwright czy Appium - zostawmy więc to na osobne wpisy.
Retesty
Przejdźmy teraz do wspomnianych wcześniej retestów. Tutaj sytuacja jest znacznie prostsza. Retest to po prostu ponowne przetestowanie obszaru, w którym wykryto, a potem naprawiono błąd. Wróćmy do przykładu sklepu internetowego. Załóżmy, że w trakcie testów zauważyliście, że wyszukiwarka nie odnajduje żadnych produktów i zawsze zwraca pusty wynik, niezależnie od wpisanego zapytania. Zgłaszacie ten błąd, programista go naprawia, a retest polega na ponownym sprawdzeniu wyszukiwarki.
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
