Weryfikacja i walidacja (oprogramowanie)

Weryfikacja i walidacja oprogramowania − inaczej kontrola jakości oprogramowania lub testy oprogramowania. Do kryterium weryfikacji należy zakwalifikowanie produktu oraz określenie, czy spełnia on lub pasuje do właściwego jego wykorzystania (wysoki poziom kontroli) – czy jest on wbudowany w odpowiedni produkt.

Analiza programu pod kątem jego formalnej poprawności pozwala znaleźć błędy zarówno na poziomie koncepcji, jak i detali implementacyjnych. Jednak proces dowodzenia zgodności programu z wymaganiami nie sprowadza się wyłącznie do stwierdzenia, że system jest bądź nie jest poprawny.

Walidacja jest to proces wyznaczania stopnia, w jakim model jest wiernym odzwierciedleniem rzeczywistego systemu z przyjętego punktu widzenia. Ma na celu określenie, czy symulacja daje wiarygodne wyniki, w założonym stopniu zgodne z odpowiedziami rzeczywistego systemu na takie same dane wejściowe. O ile dzięki weryfikacji projektant uzyskuje informacje o zgodności systemu symulacyjnego z jego założeniami, o tyle walidacja weryfikuje zgodność jego wizji z realnym światem. Obie te fazy wzajemnie się uzupełniają i jako takie czasami przedstawiane są wspólnie jako faza oceny adekwatności modelu.

Weryfikacja i walidacja produktu

Weryfikację, czyli postrzeganie, można sprowadzić do odpowiedzi na pytanie: „Czy produkt tworzony jest prawidłowo?”, a z kolei walidację: „Czy tworzony produkt jest prawidłowy?”. Prawidłowo – to znaczy zgodnie z wytycznymi programowania, z zastosowaniem odpowiednich metod, języka programowania i algorytmów. Weryfikacja dokonywana jest podczas testów systemowych pojedynczego produktu, oraz testów integracyjnych, po wprowadzeniu produktu do istniejącego już i działającego środowiska informatycznego. Weryfikację można wykonywać na dwa sposoby – statyczny i dynamiczny. Weryfikacja dynamiczna przeprowadzana jest już po uruchomieniu programu, z użyciem danych testowych, i kontroluje zachowanie systemu widoczne dla użytkownika.

Powiązane pojęcia

Zarówno weryfikacja jak i walidacja dotyczą koncepcji jakości i zapewnienia jakości oprogramowania. Sama weryfikacja i walidacja nie gwarantują jakości oprogramowania – wymagane jest planowanie, identyfikowalność, zarządzanie konfiguracją oraz inne aspekty inżynierii oprogramowania.

W społeczności modelowania i symulacji, definicje weryfikacji, walidacji i akredytacji są podobne:

• Weryfikacja modelowania i symulacji to proces określania, że model komputerowy, symulacja lub federacja implementacji modeli i symulacji oraz związane z nimi dane dokładnie odzwierciedlają koncepcyjny opis i specyfikacje projektanta.
• Walidacja modelowania i symulacji to proces określania stopnia, w jakim model, symulacja lub federacja modeli i symulacji oraz związane z nimi dane są dokładnymi reprezentacjami świata rzeczywistego z punktu widzenia zamierzonych zastosowań.
• Akredytacja to formalny certyfikat, który potwierdza, że model lub symulacja mogą być zastosowane w określonym celu.

Definicja walidacji modelowania i symulacji koncentruje się na dokładności, z jaką M&S (modelowanie i symulacja) reprezentują zamierzone zastosowania w świecie rzeczywistym. Określenie stopnia dokładności M&S jest wymagane, ponieważ wszystkie M&S są przybliżeniami rzeczywistości i zazwyczaj decydujące jest określenie, czy stopień aproksymacji jest akceptowalny dla zamierzonych zastosowań. Stanowi to przeciwieństwo walidacji oprogramowania.

Testowanie i walidacja oprogramowania

Aplikacje software'owe są specyficznym produktem, a ich sprawdzenie dotyczy oceny następujących cech:

• czy produkt wytwarzany jest prawidłowo, zgodnie ze sztuką tworzenia oprogramowania (weryfikacja);
• czy spełnia wymagania postawione przez klienta (walidacja);
• czy produkt działa poprawnie i niezawodnie.

Efektywny proces sprawdzania produktów umożliwiający wykrywanie błędów na najwcześniejszym etapie wytwarzania produktów wymaga zaprojektowania właściwych metod przeprowadzania testów oraz zastosowania do tego odpowiednich narzędzi. Walidacja środowiska testowego oraz przyjętych metod testowania to procedura oceny, czy przyjęty sposób kontroli produktów (przeprowadzania testów), jest skuteczny i umożliwia wykrywanie błędów.

Błędy weryfikacji i walidacji oprogramowania

Każdy model jest tylko reprezentacją systemu rzeczywistego i jego zachowania są w najlepszym wypadku aproksymacją rzeczywistego działania. Posługując się przykładem, nie można powiedzieć, że model domu wykonany w pewnej skali, nawet 1:1, posiada wszelkie cechy budynku rzeczywistego. Przeciwnie, prezentuje on jedynie pewne aspekty budynku w przybliżeniu, na jakie godzi się projektant modelu i jego użytkownik. Według statystyka George'a Boksa: „Wszystkie modele są błędne. Niektóre są użyteczne”. Pamiętając o pierwszym, należy starać się spełnić warunek drugi. Nie jest to zadanie łatwe. Nie można bowiem ostatecznie stwierdzić, kiedy model osiągnął odpowiedni stopień adekwatności, jest stabilny i pozbawiony błędów logicznych, kiedy można zakończyć pracę. Przez model, który przeszedł weryfikację i walidację rozumieć należy model poddany serii operacji mających na celu uszczegółowienie go do poziomu, na jaki będzie mógł sprostać postawionym przed nim zadaniom. Wiarygodność modelu zależy od zaufania, jakie ma do niego użytkownik. Proces weryfikacji i walidacji ma na celu doprowadzić do tego poziomu wiarygodności. Błędy popełniane w czasie prac nad systemem symulacyjnym można podzielić na kilka grup. Wiedząc, gdzie zazwyczaj zdarzają się usterki, łatwiej można je znaleźć i poprawić.

Do najczęściej popełnianych należą następujące błędy:

• funkcjonalny – zła lub brakująca funkcja;
• systemowy – pomylone interfejsy, nieprawidłowe zarządzanie zasobami;
• przetwarzania – niewłaściwe przetwarzanie danych;
• danych – błędna specyfikacja, projekt, rozmieszczenie;
• kodowania – niewłaściwe użycie języka oprogramowania;
• dokumentacyjny – niepełna lub błędna treść dokumentu.

Niezależna weryfikacja i walidacja

Inną metodą kontroli jakości jest tzw. niezależna weryfikacja i walidacja (ang. Independent Verification And Validation IV&V). Zgodnie z nią wykorzystuje się trzecią niezależną grupę ludzi, niezwiązaną ani z projektantami, ani z użytkownikami systemu. To ta grupa ma za zadanie zdecydować, czy model jest adekwatny do systemu rzeczywistego. Podejście to często stosuje się w przypadku systemów bardzo obszernych, nad których stworzeniem pracowała duża grupa ludzi lub, gdy poniesiono znaczne nakłady na ich opracowanie. Sposób ten podnosi wiarygodność modelu. Niezbędne jest jednak, aby zespół walidacyjny posiadał zarówno wiedzę o systemie, jak i o celach którym ma służyć symulacja. To od jego oceny będzie zależało, czy system zostanie uznany za narzędzie odpowiednie do rozwiązania problemu.

Istnieją dwa podejścia do procesu walidacji. Pierwsze opiera się na równoległej pracy zespołu walidacyjnego z projektantami systemu i bieżącej ocenie adekwatności modelu. Drugie zakłada walidację i weryfikację systemu symulacyjnego po zakończeniu nad nim prac. To podejście jest jednak droższe i bardziej czasochłonne od pierwszego. Dlatego zalecane jest podejście równoległej walidacji podczas całego procesu powstawania modelu symulacyjnego.

Jeżeli istnieje możliwość, walidacja systemu powinna być wsparta przez rozmowy z użytkownikiem systemu. Mając przez długi czas styczność z systemem rzeczywistym, ekspert często potrafi odpowiedzieć na pytania dotyczące całości systemu lub wskazać rażące błędy, których podstawą jest niezrozumienie rzeczywistego systemu, które są przyczyną generowania przez symulację złych wyników. Nie należy traktować tego jako błędu, lecz jako etap pracy nad modelem. Poza tym bardzo istotną kwestią jest osobiste zaangażowanie użytkownika w proces tworzenia systemu. Jeżeli będzie miał on wrażenie współtworzenia modelu, będzie chętniej współpracował z projektantem, co na pewno korzystnie wpłynie na jakość i wiarygodność symulacji.

Poszczególne etapy testowania powinny być podzielone na następujące osoby:

• programista – testy jednostkowe (ma naturalną tendencję „chronienia” swojego wytworu);
• specjalista tester – testy systemowe, integracyjne, alfa testy;
• użytkownik systemu – beta testy, testy akceptacyjne systemu (osobiście lub nadzorując je).

Cele testowania oprogramowania

Warto wspomnieć o tym, że testowanie oprogramowania to nie tylko wykonywanie testów. Jest to przede wszystkim rozumiane jako cały proces testowy na który składają się m.in. takie czynności jak analiza podstawy testowej, projektowanie testów i implementacja testów. Proces testowy jest związany zarówno z obszarami weryfikacji jak i walidacji oprogramowania. Główne cele testowania to np.

• Ocena produktów pracy takich jak wymagania, historyjki użytkowników, projekt i kod.
• Sprawdzanie czy wszystkie określone wymagania zostały spełnione, a także czy obiekt testowy jest kompletny i działa tak, jak oczekuje tego użytkownik i inni interesariusze.
• Budowanie zaufania odnośnie do poziomu jakości testowanego produktu.
• Zapobieganie defektom np. dzięki weryfikacji podstawy testowej. W ten sposób zapobiegamy wprowadzeniu defektów na późniejszych etapach pracy.
• Wykrywanie defektów oraz obserwowanie awarii.
• Obniżanie poziomu ryzyka związanego z jakością oprogramowania (np. ryzyko wystąpienia niewykrytych wcześniej awarii podczas działania).
• Dostarczanie informacji zainteresowanym stronom, aby mogły podejmować świadome decyzje, w szczególności w odniesieniu do poziomu jakości obiektu testowego.
• Przestrzeganie standardów przepisów prawa lub regulacyjnych i weryfikacji zgodności testowanego produktu z takimi wymaganiami lub standardami.

Podsumowanie

Przy pomocy weryfikacji i walidacji nie ma możliwości rozwiązania wszystkich problemów z jakimi wiąże się tworzenie oprogramowania. Szczególną uwagę powinno się zwrócić na potencjalne koszty tworzenia modelu symulacyjnego, aby zmieścić się w ustalonych ramach. Ponadto należy zdawać sobie sprawę z tego, że przyjęte metody weryfikacji i walidacji będą skuteczne w zależności od indywidualnych potrzeb użytkownika.