V-Model to sekwencyjny model wytwarzania oprogramowania, w którym każdemu poziomowi specyfikacji odpowiada poziom testów: wymaganiom biznesowym - testy akceptacyjne, projektowi systemu - testy systemowe, projektowi szczegółowemu - testy integracyjne, kodowi - testy jednostkowe. Graficznie układa się to w literę V: lewe ramię to uszczegóławianie, prawe - weryfikacja.
Sednem modelu nie jest kolejność faz, tylko zasada: testy projektuje się równolegle ze specyfikacją, nie po napisaniu kodu. Plan testów akceptacyjnych powstaje wtedy, gdy powstają wymagania - co przy okazji bezlitośnie weryfikuje ich jakość, bo wymaganie, do którego nie da się napisać testu, jest po prostu złym wymaganiem.
Analityk spotyka V-Model w branżach regulowanych: medycyna, farmacja, automotive, kolej, finanse - wszędzie tam, gdzie audytor pyta o pokrycie wymagań testami (traceability). W MediFlow według V-Modelu poprowadzono moduł skierowań i e-recept, bo podlega wymaganiom prawnym i integruje się z centralnymi systemami e-zdrowia: do każdego zatwierdzonego wymagania od razu powstawał odpowiadający scenariusz testu akceptacyjnego, a matryca pokrycia była częścią dokumentacji odbiorowej.
Częsta pomyłka: traktowanie V-Modelu jak „waterfalla z testami na końcu". Jest dokładnie odwrotnie - model powstał po to, by testowanie przestało być ostatnią fazą i zaczęło się na poziomie projektowania. Druga pomyłka: przekonanie, że V-Model i zwinność się wykluczają. Zasada „projektuj test razem z wymaganiem" działa w każdej metodyce; w Scrumie nazywa się to kryteriami akceptacji pisanymi przed implementacją.
Jak czytać diagram V-Modelu: co stoi naprzeciw czego?
Diagram czyta się też w poziomie. Każde piętro lewego ramienia ma naprzeciw siebie piętro prawego, a pozioma linia między nimi mówi: ten dokument jest podstawą tych testów. Poniżej te same cztery pary co w definicji wyżej, rozpisane na to, kto pisze dokument, kto testuje i o co pyta dany poziom testów.
| Lewe ramię (specyfikacja) | Kto ją pisze | Prawe ramię (testy) | Kto testuje | O co pyta test |
|---|---|---|---|---|
| wymagania biznesowe | analityk z interesariuszami | testy akceptacyjne (UAT) | użytkownicy biznesowi, analityk jako organizator | czy da się na tym pracować? |
| projekt systemu (wymagania systemowe, np. SRS) | analityk, architekt | testy systemowe | zespół testowy | czy system spełnia wymagania? |
| projekt szczegółowy (moduły i interfejsy) | architekt, zespół deweloperski | testy integracyjne | testerzy, deweloperzy | czy części współpracują na stykach? |
| kod | deweloperzy | testy jednostkowe | deweloperzy, automatycznie | czy pojedyncza funkcja liczy dobrze? |
Dwa pytania z górnych wierszy pochodzą z hasła o testach systemowych, które rozdziela je tak: zespół QA pyta „czy system spełnia wymagania?", biznes na UAT pyta „czy da się na tym pracować?". Analityk biznesowy pracuje głównie w tych dwóch górnych parach. Dolne dwie zna na tyle, żeby wiedzieć, gdzie trafia opisana przez niego reguła biznesowa i który poziom testów ją sprawdzi.
Nazwy, które znaczą to samo: V-Model, model V, model w kształcie litery V, po angielsku V-model. Nazwę rozwija się też czasem jako model weryfikacji i walidacji (verification and validation model) i to rozwinięcie dobrze tłumaczy, o co w nim chodzi. O tym w osobnej sekcji niżej.
Czym V-Model różni się od modelu kaskadowego?
Fazy są te same co w modelu kaskadowym: wymagania, projekt, implementacja, testy. Oba modele są sekwencyjne i w obu faza kończy się bramką, o czym mówi pierwsza lekcja naszego kursu o Agile i Scrumie: „Każda faza kończy się »bramką« i przekazaniem dokumentu dalej". Różnica leży w tym, kiedy powstaje materiał do testów.
| Model kaskadowy | V-Model | |
|---|---|---|
| Kiedy powstają scenariusze testów | w fazie testów, po implementacji | na każdym piętrze lewego ramienia, razem ze specyfikacją |
| Z czym pracuje tester | gotowy system i specyfikacja | specyfikacja danego poziomu, jeszcze przed kodem |
| Kiedy wychodzi wymaganie, którego nie da się sprawdzić | na testach, gdy kod już jest | przy pisaniu testu akceptacyjnego, gdy wymaganie jest jeszcze na papierze |
| Co analityk robi po oddaniu specyfikacji | odpowiada na pytania zespołu | współtworzy plan testów akceptacyjnych i pilnuje, żeby każde wymaganie miało test |
Ta sama lekcja przypomina, dlaczego to przesunięcie ma znaczenie: w wodospadzie błąd w analizie odkryty na testach kosztuje wielokrotnie więcej niż odkryty w trakcie rozmowy. V-Model łapie wcześniej jedną klasę błędów, czyli wymagania nieprecyzyjne i nietestowalne. Drugiej klasy nie łapie. Wymaganie precyzyjne, ale nieaktualne, bo rynek albo przepisy zmieniły się w trakcie projektu, przejdzie przez całe V bez zarzutu. Na taki problem odpowiadają modele iteracyjne, od modelu spiralnego po Agile. Szersze porównanie ról analityka w obu światach jest we wpisie Agile vs Waterfall - rola analityka.
Jakie są zalety i wady V-Modelu?
Zalety wynikają z zasady opisanej w górze hasła. Wymaganie, do którego nie da się napisać testu, wychodzi na papierze, zanim ktoś je zakoduje. Każde wymaganie ma przypisany test, a matryca pokrycia daje audytorowi dowód, że żadnego wymagania nie pominięto w testach. Do tego wiadomo, kto odbiera który poziom.
Wady są w dużej części te same co w kaskadzie, bo V-Model też jest sekwencyjny. Pierwsza: model zakłada, że zatwierdzona specyfikacja przetrwa do testów akceptacyjnych, więc wymaganie precyzyjne, ale nieaktualne przejdzie przez całe V bez zarzutu. Druga: działający system użytkownik zobaczy dopiero wtedy, gdy projekt zejdzie na dno litery i wróci prawym ramieniem do testów akceptacyjnych. Lekcja o wodospadzie przypomina, że ludzie nie wiedzą, czego chcą, dopóki nie zobaczą. Trzecia: zmiana wymagania w połowie projektu to poprawki w dwóch miejscach naraz, w specyfikacji i w przygotowanych do niej testach.
Co znaczą weryfikacja i walidacja w V-Modelu?
Góra hasła nazywa całe prawe ramię weryfikacją i to jest skrót. Najwyższe piętro prawego ramienia sprawdza coś innego: waliduje. W naszym kursie przygotowującym do ECBA ta para ma krótką ściągę z inżynierii: verify = are we building the thing RIGHT? validate = are we building the RIGHT thing? Weryfikacja sprawdza, czy rzecz zrobiono zgodnie z opisem. Walidacja sprawdza, czy zrobiono właściwą rzecz.
Na diagramie V wygląda to tak. Testy jednostkowe, integracyjne i systemowe porównują system z dokumentem z tego samego piętra, czyli weryfikują. Test akceptacyjny porównuje system z potrzebą biznesu, czyli waliduje. Dlatego UAT nie jest powtórką testów systemowych. Hasło o testach systemowych mówi to wprost: system może być w pełni zgodny ze specyfikacją i jednocześnie nieużywalny w realnym procesie, bo specyfikacja czegoś nie przewidziała.
Te same dwa słowa analityk spotyka w trzech różnych znaczeniach i łatwo je pomylić:
| Gdzie je słyszysz | Co sprawdza weryfikacja | Co sprawdza walidacja |
|---|---|---|
| V-Model, testy systemu | czy system zgadza się ze specyfikacją | czy system rozwiązuje problem użytkowników |
| BABOK: Verify Requirements i Validate Requirements | czy wymaganie jest dobrze napisane (jednoznaczne, testowalne, spójne) | czy wymaganie jest warte realizacji, czyli wspiera cel biznesowy |
| programiści: „walidacja formularza" | nie dotyczy | sprawdzanie poprawności wpisanych danych, bez związku z dwoma wierszami wyżej |
Przykład z drugiego wiersza, z lekcji o weryfikacji, walidacji i zatwierdzaniu wymagań w kursie wprowadzającym do analizy: w RentaSali wymaganie „system co noc drukuje na recepcji listę rezerwacji na następny dzień" jest jasne, jednoznaczne i testowalne, więc przechodzi weryfikację. Walidacji nie przechodzi, bo cel projektu to odciążyć recepcję, a wydruk ją obciąża. Techniki przeglądu wymagań opisuje wpis Testowanie wymagań - weryfikacja.
Jakie dokumenty analityka łączy V-Model?
Góra hasła mówi, że w MediFlow do każdego zatwierdzonego wymagania modułu skierowań i e-recept od razu powstawał scenariusz testu akceptacyjnego, a matryca pokrycia była częścią dokumentacji odbiorowej. Za tym zdaniem stoi kilka dokumentów, które w V-Modelu analityk pisze albo współtworzy:
- Specyfikacja z identyfikatorami wymagań. Bez numerów typu WYM-01 nie da się niczego powiązać, dlatego minikurs o wymaganiach nadaje je w pierwszym kroku ćwiczenia końcowego.
- Plan testów akceptacyjnych i scenariusze. Powstają razem z wymaganiami, nie po kodzie. Strukturę planu opisuje hasło plan testów, a pojedynczy scenariusz hasło scenariusz testowy.
- Kolumna weryfikacji przy wymaganiu. W lekcji o wymaganiach niefunkcjonalnych w kursie o API tabela ma osobną kolumnę „Weryfikacja", obok źródła. To jest pozioma linia V zapisana w jednym wierszu: wymaganie od razu mówi, jak je sprawdzimy.
- Matryca śledzenia wymagań. W minikursie o wymaganiach łączy cel, wymaganie, kryterium akceptacji, przypadek testowy i komponent. Czytana wprzód odpowiada audytorowi, czy każde wymaganie ma test, czytana wstecz pokazuje funkcje bez uzasadnienia. Kierunki opisuje hasło traceability, budowę krok po kroku wpis Traceability matrix - śledzenie wymagań.
- Protokół odbioru. Formalny sign-off zamyka prawe ramię: biznes podpisuje, że testy akceptacyjne przeszły.
Po czym poznać, że projekt idzie V-Modelem, choć nikt tak go nie nazywa?
Nazwa może w ogóle nie paść na spotkaniu. Widać za to objawy. Jeśli rozpoznasz kilka z nich naraz, pracujesz w logice V, nawet gdy w dokumentacji projektu stoi po prostu „kaskada":
- wymaganie nie może zostać zatwierdzone bez scenariusza testu albo kryterium, jak je sprawdzimy;
- plan testów akceptacyjnych przechodzi przegląd razem ze specyfikacją;
- każdy poziom testów ma własne kryteria wyjścia i własny raport, a przejście do następnego poziomu wymaga zgody;
- przy odbiorze ktoś pyta o pokrycie wymagań testami i chce to zobaczyć w tabeli;
- projekt dotyczy obszaru, w którym ktoś z zewnątrz może zażądać dowodu, że wymaganie sprawdzono, jak moduł skierowań i e-recept z góry hasła.
Dla analityka ten rozpoznany układ zmienia jedno: specyfikację oddajesz razem z pomysłem na test każdego wymagania, bo bez tego dokument może wrócić do Ciebie z bramki.
Co z V-Modelu zostaje, gdy zespół pracuje w sprintach?
Góra hasła mówi, że zasada „projektuj test razem z wymaganiem" działa w każdej metodyce. W Scrumie litera V kurczy się do jednej historyjki. Lewe ramię to historyjka z kryteriami akceptacji spisanymi, zanim zespół weźmie ją do sprintu. Prawe to sprawdzenie tych kryteriów, zanim historyjka zostanie uznana za zrobioną według Definition of Done. W kursie o Agile i Scrumie fragment DoD zespołu MediFlow ma właśnie taki punkt: „kryteria akceptacji zweryfikowane na środowisku testowym (kto weryfikuje? najczęściej Ania)". Ania to w tym kursie analityczka zespołu MediFlow, która często też sama testuje akceptacyjnie.
Co się nie przenosi: jedna matryca dla całego systemu i formalne bramki między poziomami testów. W projektach, które podlegają przepisom, zespoły często łączą oba światy: pracują w sprintach, a przed wydaniem przechodzą formalny odbiór z matrycą pokrycia (to obserwacja z projektów, nie reguła). Taki układ opisuje sekcja o hybrydzie we wpisie o Agile i Waterfallu, podlinkowanym wyżej.
Jak odpowiedzieć na pytanie o V-Model na rozmowie rekrutacyjnej?
Pytanie o modele cyklu życia oprogramowania to klasyka rozmów na stanowisko analityka, co zauważa też hasło o modelu spiralnym. Samo wyrecytowanie czterech par z diagramu pokazuje głównie pamięć. Mocniejsza odpowiedź ma trzy zdania:
- Co to jest: model sekwencyjny, w którym każdemu poziomowi specyfikacji odpowiada poziom testów, a testy projektuje się razem ze specyfikacją.
- Co to zmienia dla analityka: przy każdym wymaganiu od razu myślę, jak je sprawdzimy, a plan testów akceptacyjnych powstaje razem z wymaganiami.
- Gdzie się go stosuje: tam, gdzie trzeba udowodnić, że każde wymaganie przetestowano, czyli w projektach podlegających przepisom i audytowi.
Po takiej odpowiedzi może paść dopytanie o różnicę względem waterfalla, o parę weryfikacja i walidacja albo o to, jak to wygląda w Scrumie. Każde z tych pytań ma wyżej własną sekcję.
Gdzie iść dalej
- Poziomy testów po kolei: testy jednostkowe, integracyjne, systemowe, UAT; środowiska, na których biegną: środowisko testowe.
- Śledzenie wymagań: traceability, matryca śledzenia wymagań, sign-off.
- Organizacja odbioru przez biznes: wpis UAT - testy akceptacyjne.
- Sprawdź się bez zakładania konta: test o testowaniu dla analityka, UAT i kryteriach akceptacji.
Jeśli chcesz przerobić wymagania, kryteria akceptacji i testy na jednym case'ie, załóż darmowe konto: dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.