Pojęcia weryfikacji i walidacji są znaczeniowo na tyle bliskie, że przy wielu pytaniach egzaminacyjnych mogą przysporzyć trudności. Tłumaczenie tych pojęć dostępne w podręcznikach i słownikach też nie ułatwia rozgraniczenia. Dodatkowo często używa tych słów podczas pracy projektowej w znaczeniach potocznych i wynikających z przyzwyczajeń w danej organizacji.
Zarówno weryfikacja jak i walidacja produktu procesu są czynnościami, które służą sprawdzeniu, czy wytworzony produkt jest taki, jak sobie życzyliśmy my, bądź inny interesariusz (zwłaszcza odbiorca systemu). Gdy czytamy tutaj „produktu procesu” możemy rozumieć to jako dany moduł systemu, blok kodu, cały system, ale też istotny dokument, na bazie którego moduł lub system będzie budowany).
Warto zapamiętać, że obie te czynności zachodzą w wielu różnych momentach i mogą pojawić się w wielu fazach procesu tworzenia systemu. Błędnym będzie zatem rozumienie np. walidacji, jako jakiegoś etapu wieńczącego budowę systemu. (Uwaga ta jest tu stosowna o tyle, że nieraz w praktyce projektowej w wielu zespołach określa się potocznie „walidacją” testy akceptacyjne.)
Różnice między weryfikacją i walidacją dotyczą przede wszystkim tego, z jakiej perspektywy dokonujemy sprawdzenia (czyli czy raczej technologicznej i typowej dla zespołów budujących system, czy raczej z perspektywy użytkownika końcowego, który nie ma obowiązku rozumieć technicznej strony systemu, którego będzie używał).
Najprościej jest zapamiętać, że weryfikujemy to, co da się wyliczyć, wykazać logicznie i nie ma jak zanegować tego, co już zweryfikowane. Przy dobrze spisanych wymaganiach weryfikacji dokonać może każdy człowiek rozumiejący tekst specyfikacji i wiedzący, jak wykonać test.
Natomiast walidacja jest po stronie odbiorcy i to zaspokojenie jego potrzeb jest ostatecznym kryterium sukcesu. Odcinając się od możliwości konsultowania z klientem spraw dotyczących choćby wygody użytkowania produktu, wytwórcy ryzykują niepowodzenie walidacji.
Kluczowym słowem jest tu „zdefiniowane”. Weryfikacja domaga się odniesienia do wymogów, które spisano w taki sposób, że można je sprawdzić w sposób jednoznaczny. Weryfikacja polega na stwierdzeniu, że dany punkt np. specyfikacji technicznej jest oto zdaniem, które w sposób prawdziwy opisuje dany produkt, który poddajemy testowi. W praktyce powinniśmy zatem kojarzyć weryfikację z procesem, który zakończy się „zero-jedynkowym” rozstrzygnięciem, że produkt wygląda, bądź zachowuje się, bądź jest taki, jak ustalono dla niego w specyfikacji.
Jeśli na przykład jakąś funkcjonalność można sprawdzić poprzez odczytanie wyniku liczbowego, którego ona dostarcza; zbadanie, czy odpowiedź systemu nastąpi w konkretnie ustalonym czasie; sprawdzenie, czy następuje przesłanie odpowiedniego pliku między serwerem a klientem – wtedy możemy oczekiwać, że proces sprawdzania tego produktu jest weryfikacją.
Najistotniejsze do zrozumienia walidacji jest to, że to, co było jasno zdefiniowanym kryterium zaliczenia testu, tutaj jest zamienione na potrzeby i wymagania użytkownika. O ile zweryfikować można różne rzeczy bez wczuwania się w rolę użytkownika końcowego (bo wystarczy się oprzeć choćby na wyliczeniach i sprawdzaniu, czy wyniki są zgodne z założeniami ze specyfikacji), to walidacja służy właśnie do sprawdzenia wszystkich tych funkcjonalności, które użytkownik będzie oceniał pod kątem swoich osobistych upodobań, często subiektywnie, nieraz w oparciu o rozmaite nawyki.
Sukces walidacji opiera się często na sprawach, które ciężko jest przewidzieć podczas pisania specyfikacji funkcjonalnej. Odbiorca systemu nieraz nie uświadamia sobie swoich własnych upodobań i może stwierdzić, że „coś mu się nie podoba” dopiero, gdy przystępuje do finałowego testu akceptacyjnego. Często wtedy słyszanym argumentem z ust niezadowolonego odbiorcy jest to, że coś było „tak oczywiste, że nie trzeba tego było spisywać w specyfikacji”.
O ile kluczem do udanej weryfikacji produktu jest klarowne zdefiniowanie kryteriów zaliczenia testu, o tyle kluczem do udanej walidacji jest pogłębiona i sprawna komunikacja z odbiorcą, zadawanie celnych pytań pomagających w zrozumieniu autentycznych potrzeb klienta, przeprowadzanie wraz z klientem symulacji zastosowań systemu na wszelkiego rodzaju makietach. Kolejną bardzo istotną sprawą jest umiejętne korzystanie z badań aktualnych rozwiązań i tendencji w produktach dostępnych na rynku (choćby po to, by przewidzieć, co będzie sprawdzał klient, który sprawdził kilka rozwiązań dostarczanych przez naszą konkurencję).
W kontekście nauki do egzaminu ISTQB należy jeszcze wspomnieć o tym, że ryzykownym jest ścisłe wiązanie weryfikacji z wymaganiami funkcjonalnymi, a walidacji z niefunkcjonalnymi. Faktycznie testowanie funkcjonalności w oparciu o dostarczone wymagania funkcjonalne kojarzy się chętniej z „zero-jedynkową” konstatacją obecności danego, zaplanowanego rozwiązania w systemie, a wymagania niefunkcjonalne pamiętamy zazwyczaj jako te, które są słabiej opisane w specyfikacji, ale nie oznacza to, że wymagań niefunkcjonalnych nie da się opisać w formie pozwalającej na ich weryfikację. Najprostszym przykładem byłby test wydajności (atrybutu jak najbardziej niefunkcjonalnego), którego kryterium zaliczenia byłaby odpowiedź systemu w czasie krótszym niż 50ms. Widzimy wyraźnie, że można taki wymóg sprawdzić i opisać wynik testu jednoznacznym stwierdzeniem, że system wykonuje bądź nie wykonuje zadania w wyznaczonym czasie.
Walidację warto zapamiętać jako ogół tych czynności, które zwiększają szansę na zadowolenie odbiorcy tworzonego produktu i które będą brały pod uwagę konsultacje z tym odbiorcą, wspólne wypracowywanie rozwiązania i przewidywanie jego preferencji. Niewątpliwie dobra orientacja w zdefiniowanych w normach i literaturze atrybutach niefunkcjonalnych bardzo pomaga w takim prognozowaniu.
