|
Często mówi się, że chcąc wykonać regresję, bierzemy na tapet całą aplikację. Testujemy wtedy bardzo wysokie pokrycie aplikacji. Ale czy tak zawsze musi być? Otóż nie.
Regresja będąca testem CAŁEJ aplikacji to stereotyp. I tak, często się to wykonuje, gdy chcemy skrupulatnie zweryfikować jakość przed wyjściem na produkcję. Ale często regresja dotyczyć będzie testów wybranych obszarów czy funkcjonalności. Nawet wówczas, gdy mówimy o regresji przed wydaniem na produkcję. Dlaczego? Bo zależy nam na idealnym stosunku czasu do jakości. Chcemy zweryfikować przede wszystkim występowanie defektów (nowych lub powrotu starych), więc skupiamy się na obszarach, które w ostatnim sprincie programiści dotykali. Jeżeli przez cały sprint pracowaliśmy nad funkcją zakupów (koszyk, kody zniżkowe i inne takie), szkoda czasu na wykonywanie regresji w obszarze polityk haseł, dostępu do regulaminów, dodawania użytkowników do systemu z poziomu konta administratora i tak dalej. Oczywiście wiedza domenowa jest tu niezbędna - musimy wiedzieć na jakie obszary wpływały funkcje, które były tworzone lub zmieniane.
|
