Po wprowadzeniu w systemie zmian mających na celu usunięcie defektów bądź dodanie lub zmodyfikowanie funkcjonalności należy przeprowadzić testy, które potwierdzą, że wprowadzone zmiany faktycznie skutkowały naprawieniem defektu lub poprawną implementacją odpowiedniej funkcjonalności, a przy tym nie wywołały żadnych nieprzewidzianych, niekorzystnych zachowań oprogramowania.

• Testowanie potwierdzające. Po naprawieniu defektu można przetestować oprogramowanie przy użyciu wszystkich przypadków testowych, które wcześniej nie zostały zaliczone z powodu wystąpienia tego defektu, a powinny zostać ponownie wykonane w nowej wersji oprogramowania. Oprogramowanie może być również testowane nowymi testami, jeśli na przykład defektem była brakująca funkcjonalność. Absolutnym minimum jest ponowne wykonanie w nowej wersji oprogramowania kroków niezbędnych do odtworzenia awarii wywoływanej przez dany defekt. Celem testu potwierdzającego jest sprawdzenie, czy pierwotny defekt został pomyślnie usunięty.
• Testowanie regresji. Istnieje ryzyko, że zmiana (poprawka lub inna modyfikacja) wprowadzona w jednej części kodu wpłynie przypadkowo na zachowanie innych części kodu w tym samym module, w innych modułach tego samego systemu, a nawet w innych systemach. Ponadto należy wziąć pod uwagę zmiany dotyczące środowiska, takie jak wprowadzenie nowej wersji systemu operacyjnego lub systemu zarządzania bazami danych. Powyższe, niezamierzone skutki uboczne, są nazywane regresjami, a testowanie regresji polega na ponownym wykonaniu testów w celu ich wykrycia.

Testowanie potwierdzające i testowanie regresji można wykonywać na wszystkich poziomach testów.

Zwłaszcza w iteracyjnych i przyrostowych modelach wytwarzania oprogramowania (np. w modelu zwinnym) nowe funkcjonalności, zmiany dotychczasowych funkcjonalności oraz refaktoryzacja powodują częste zmiany kodu, które pociągają za sobą konieczność przeprowadzenia odpowiednich testów. Z uwagi na ciągłą ewolucję systemu, testowanie potwierdzające i testowanie regresji są bardzo istotne, szczególnie w przypadku systemów związanych z Internetem rzeczy (IoT), w których poszczególne obiekty (np. urządzenia) są często aktualizowane lub wymieniane.

Zestawy testów regresji są wykonywane wielokrotnie i zwykle ewoluują dość wolno, w związku z czym testowanie regresji świetnie nadaje się do automatyzacji – dlatego też automatyzację tego rodzaju testów należy rozpocząć w początkowym etapie projektu (patrz rozdział 6.).