W sprincie wszystkie testy przechodzą, ale po prezentacji zespół słyszy, że aplikacja rozwiązuje nie ten problem. Weryfikacja sprawdza zgodność z ustalonymi wymaganiami, a walidacja konfrontuje produkt z potrzebą użytkownika, choć oba procesy mogą korzystać z tych samych testów.
Dwa procesy odpowiadają na różne pytania o jakość
- Weryfikacja: czy produkt spełnia zapisane wymagania?
- Walidacja: czy produkt pomaga użytkownikowi osiągnąć cel?
- Testy nie mają jednej etykiety: test akceptacyjny może dostarczyć dowodów w obu procesach.
- Przy niejasnym wyniku: najpierw sprawdź kryterium, potem ustal, czy odpowiada ono rzeczywistej potrzebie.
Weryfikacja pilnuje wymagań, walidacja sensu produktu
Wyobraź sobie ekran logowania, który poprawnie odrzuca błędne hasło, zapisuje zdarzenie w logu i spełnia wymagania bezpieczeństwa. Technicznie wszystko gra. A jednak osoba korzystająca z aplikacji nie może odzyskać dostępu, bo proces resetowania hasła jest dla niej nieczytelny.
Pierwsza część to weryfikacja: zespół sprawdza kod, dokumentację i działanie względem ustalonych kryteriów. Druga to walidacja: sprawdzenie, czy gotowe rozwiązanie rzeczywiście wspiera użytkownika w jego zadaniu. Uważam, że ten podział najlepiej zapamiętać przez dwa pytania: „Czy zbudowaliśmy zgodnie z wymaganiami?” oraz „Czy zbudowaliśmy to, czego potrzeba?”.
Granica nie przebiega między kodem a rozmową z klientem. Walidować można już wymagania, zanim powstanie interfejs, a weryfikować da się dokument, projekt czy zestaw testów. To przydaje się szczególnie wtedy, gdy błąd pojawia się przed implementacją.
Jeden przepływ logowania może ujawnić dwa różne problemy
Załóżmy, że serwis z ofertami pracy ma pozwalać zapisać ogłoszenie na później. W wymaganiu zapisano, że kliknięcie ikony dodaje ofertę do listy zapisanych, a stan ma być widoczny po ponownym otwarciu strony. Test sprawdza zatem, czy zapis trafia do właściwego konta i czy znika po cofnięciu akcji. To weryfikacja zachowania opisanego w specyfikacji.
Podczas sesji z osobami szukającymi pracy wychodzi jednak, że zapisane ogłoszenia trudno odnaleźć, bo lista nie pokazuje nazwy firmy ani lokalizacji. Funkcja działa zgodnie z opisem, lecz słabo wspiera decyzję o aplikowaniu. To sygnał z walidacji, który może prowadzić do zmiany wymagań, a nie tylko poprawki kodu.
W przykładowym zestawie testowym znajduje się 40 ofert, z których 12 spełnia warunek „praca zdalna”. Weryfikacja potwierdza, że filtr zwraca właśnie te 12 pozycji; walidacja sprawdza, czy osoba szukająca pracy potrafi wśród nich znaleźć ofertę odpowiadającą jej sytuacji. Same zgodne wyniki filtra nie dowodzą jeszcze, że filtr został dobrze pomyślany.
Testy dynamiczne nie oznaczają automatycznie walidacji
Często spotyka się skrót myślowy: przegląd kodu to weryfikacja, a uruchomienie aplikacji to walidacja. To mylący podział. Testy, inspekcje, analizy i demonstracje mogą służyć obu celom; znaczenie ma pytanie, na które dana czynność ma odpowiedzieć.
Test jednostkowy sprawdzający, czy komponent odrzuca niepoprawny format adresu e-mail, zwykle weryfikuje wymaganie. Ten sam komponent można też ocenić podczas walidacji, jeśli zespół sprawdza z użytkownikami, czy komunikat błędu pomaga poprawić wpis. Z kolei prototyp bez działającego backendu może zwalidować układ formularza, zanim będzie co testować automatycznie.
W wymaganiach NASA dotyczących inżynierii oprogramowania, NPR 7150.2D, oba procesy obejmują cykl życia projektu, a metody mogą obejmować przeglądy, testy, demonstracje i analizy. Rozstrzygający pozostaje cel działania, nie to, czy ktoś uruchomił kod.
Przy niezgodności najpierw ustal, co miało być sprawdzone
Gdy tester zgłasza problem, jego rodzaj wskazuje, gdzie szukać źródła. Jeśli rozbieżność dotyczy zatwierdzonej specyfikacji, chodzi o weryfikację; jeśli wymaganie jest spełnione, lecz użytkownik nadal nie może wykonać zadania, potrzebna jest walidacja. Poniższa tabela pomaga przejść od objawu do kolejnego kroku.
| Sytuacja | Co może oznaczać | Co zrobić |
|---|---|---|
| Funkcja nie przechodzi kryterium z wymagania | Problem z implementacją albo niejasnym kryterium weryfikacji | Odtwórz przypadek testowy i porównaj wynik z zatwierdzonym wymaganiem |
| Wszystkie kryteria są spełnione, ale użytkownik nie kończy zadania | Możliwy problem z trafnością wymagania lub przepływem produktu | Obserwuj wykonanie zadania i sprawdź, w którym miejscu cel się rozchodzi z projektem |
| Użytkownik oczekuje zachowania, którego nie ma w specyfikacji | Potrzeba mogła zostać pominięta albo wymaganie nie odzwierciedla ustaleń | Potwierdź oczekiwanie z interesariuszami, zaktualizuj wymaganie i dobierz do niego kryterium testowe |
| Wymaganie nie ma jednoznacznego wyniku testu | Nie da się obiektywnie stwierdzić zgodności | Doprecyzuj warunek, dane wejściowe i oczekiwany rezultat przed odbiorem |
Praktyczna reguła jest prosta: jeśli nie da się wskazać wymagania i oczekiwanego wyniku, zacznij od doprecyzowania weryfikacji. Jeśli test przechodzi, ale cel użytkownika pozostaje poza zasięgiem, zbierz dowody walidacyjne i wróć do potrzeby. Próba naprawienia kodem źle postawionego wymagania zwykle tylko utrwala problem.
IEEE 1012-2024 pokazuje, że V&V obejmuje cały produkt
Weryfikacja i walidacja bywają przedstawiane jako końcowe etapy przed wydaniem aplikacji. IEEE 1012-2024 ujmuje je szerzej: procesy dotyczą produktów systemowych, programowych i sprzętowych oraz ich interfejsów, a dowodów mogą dostarczać między innymi analizy, przeglądy, inspekcje i testy.
Dla zespołu aplikacji webowej oznacza to, że kontrola nie musi czekać na gotową funkcję. Można sprawdzić spójność wymagań API przed implementacją, przeanalizować uprawnienia w projekcie, a potem zweryfikować zachowanie wdrożonego kodu. Walidacja może równolegle sprawdzać, czy taki przepływ odpowiada temu, jak użytkownicy faktycznie pracują.
Dobra decyzja produktowa łączy oba rodzaje dowodów
Po incydencie na demo łatwo skupić się wyłącznie na naprawie widocznego błędu. Wróć wtedy do dwóch osobnych pytań: czy rozwiązanie spełnia uzgodnione wymagania oraz czy te wymagania prowadzą do użytecznego produktu. Kompletna decyzja o jakości potrzebuje odpowiedzi na oba, nawet gdy każdą zbiera się inną metodą.
Jeśli filtr ofert zwraca właściwe wyniki, lecz nadal utrudnia znalezienie pracy, kod może przejść weryfikację, a produkt wciąż wymaga zmiany. Właśnie w tym miejscu rozróżnienie przestaje być definicją z rozmowy rekrutacyjnej i zaczyna oszczędzać zespołowi kolejny sprint.
