Testowanie Potwierdzające

Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.

Present in sylabi

Przykład użycia

Przypadek testowy dla funkcji logowania zakończył się niepowodzeniem, ponieważ wykryto defekt walidacji hasła. Programista usuwa defekt. Retestowanie polega następnie na ponownym uruchomieniu tego samego przypadku testowego w celu weryfikacji, czy działanie naprawcze zadziałało: logowanie teraz się udaje, a wcześniej nieudany przypadek testowy przechodzi pomyślnie. Zauważ, że retestowanie uruchamia ponownie wyłącznie testy, które zakończyły się niepowodzeniem — weryfikowanie niezmienionej funkcjonalności to testowanie regresji.

Częste pytania

Jaka jest różnica między retestowaniem a testowaniem regresji? Retestowanie uruchamia przypadki testowe, które przy ostatnim wykonaniu zakończyły się niepowodzeniem, aby zweryfikować, czy działania naprawcze powiodły się. Testowanie regresji testuje wcześniej przetestowaną, niezmienioną funkcjonalność, aby upewnić się, że zmiana nie wprowadziła nowych defektów. Po każdej poprawce potrzebne są oba podejścia.

Czy retestowanie nazywane jest też testowaniem potwierdzającym? Słownik ISTQB traktuje je jako terminy pokrewne: testowanie potwierdzające to to samo pojęcie weryfikacji, że defekt został usunięty, a oba kontrastują z testowaniem regresji. W wielu sylabusach terminy te są używane zamiennie.

Kiedy wykonuje się retestowanie? Po poprawce defektu, zanim poprawka zostanie zaakceptowana. Zwykle następuje po nim testowanie regresji otaczającej funkcjonalności.

Czy retestowanie można zautomatyzować? Tak. Wcześniej nieudany zautomatyzowany przypadek testowy jest uruchamiany ponownie — najlepiej w ramach potoku integracji ciągłej (CI), który uruchamia również zestaw testów regresji.

Powiązane terminy