Blog

Kiedyś wytwarzanie oprogramowania zaczynało się od zebrania „wszystkich wymagań” i ich dokładnej analizy. Na tej podstawie powstawała specyfikacja produktu, który należy zbudować. W przekonaniu wielu zawierała ona odpowiedź na każde pytanie, jakie wytwórcy produktu mogą w przyszłości zadać.

Następnie interesariusze krwią podpisywali się pod tymi dokumentami, gwarantując, że zdania nie zmienią (i co, nie zmieniali…?). Stawało się wtedy możliwe zaprojektowanie architektury rozwiązania i zaplanowanie prac niezbędnych do realizacji produktu. Pod tymi planami i projektami podpisywali się (znów krwią, a jakże) autorzy oraz zarządzający ich pracą kierownik projektu, dając gwarancję, że wszystko będzie na termin, bez cięcia zakresu i przekroczenia budżetu (jak często się to udawało…?).

Dopiero wtedy zaczynała się faza konstruowania rozwiązania, które z mniejszą lub większą czkawką, w budżecie lub niekoniecznie, na czas lub nieco później, udawało się doprowadzić do stanu umożliwiającego sensowne testy. Pomińmy milczeniem wcale nierzadką sytuację, że dopiero na tym etapie zadawane bywały pytania o to, jak właściwie produkt ma działać i czemu służyć. Przyjmijmy, że tym razem się udało: powstało mniej więcej to, co powinno.

Gdy już uda się coś zbudować…

W opisanym powyżej procesie wytworzenie produktu odbywa się niemal w zupełnym oderwaniu Developerów od interesariuszy i ich potrzeb. Jedyne interakcje zachodzą w obszarze raportowania postępu developmentu. Czasami ustalone są jakieś terminy częściowego ukończenia prac, w których dokonuje się weryfikacji tego, czy robota idzie zgodnie z planem. Bywa tak, że ujawniają się przy tej problemy, które wymuszają zmianę projektów i planów, które są owych projektów pochodną. Oczywiście potrzeby interesariuszy nie są statyczne i zmieniają się nieustannie, więc gdzieś w tle trwa ciągła walka o zmianę zakresu (który rzekomo miał być niezmienny) i projekt obrasta change requestami. Znacie to?

Efektem jest ściśle nieokreślony stan produktu w momencie zakończenia prac. Zdarza się, że w ogóle nie nadaje się on do użytku i development przechodzi płynnie w trwającą nawet drugie tyle „fazę stabilizacji”, która w istocie jest paniczną próbą reanimacji trupa. Natomiast niezależnie od jakości technologicznej tego, co powstało, od razu pojawia się pytanie o jakość funkcjonalną: czy produkt rzeczywiście robi to, co powinien? Dużo rzadziej zadawane jest inne, choć istotniejsze pytanie: czy taki produkt rzeczywiście jest tym, czego potrzebują interesariusze?

Warto uświadomić sobie różnicę między tymi dwoma pytaniami. Można przecież wytworzyć oprogramowanie idealnie spełniające spisaną listę wymagań – czyli teoretycznie takie, jakie powinno powstać – a mimo to kompletnie bezużyteczne. Istnieją dwa typowe scenariusze, które do tego wiodą:

• potrzeby interesariuszy się zmieniły, ale Developerzy nie wiedzieli o tym i trzymali się nieaktualnych wymagań, których nikt nie zmodyfikował,
• wymagania zapisane zostały w specyfikacji produktu w sposób, który tylko pozornie jest jednoznaczny, przez co Developerzy zrozumieli je inaczej niż interesariusze.

Żaden z tych scenariuszy nie nastąp, jeśli Developerzy budujący software mają bezpośredni bieżący kontakt z tymi, którzy będą z niego korzystać.

Krytyczna rola testów akceptacyjnych

Co dzieje się po zakończeniu developmentu prowadzonego w klasyczny sposób i ewentualnej „stabilizacji” produktu? Ano, interesariusze sprawdzają, czy to, co dostali, jest tym, co dostać chcieli – czyli rozpoczyna się faza testów akceptacyjnych (ang. user acceptance testing, w skrócie UAT, ewentualnie customer acceptance testing, w skrócie CAT). Desygnowani przez interesariuszy (a nierzadko końcowego klienta) testerzy sprawdzają, czy oprogramowanie spełnia zapisy wymagań, a czasami (choć niestety nie zawsze), czy w ogóle nadaje się ono do rzeczywistego użycia.

Testerami takimi są zazwyczaj użytkownicy oprogramowania, jeśli ono już istnieje w jakiejś starszej wersji. Ewentualnie potencjalni użytkownicy, jeśli żadne wydanie jeszcze się nie odbyło. Zdarza się, że oderwani zostają od swych innych obowiązków i są mało doświadczeni w realizacji testów. Jeszcze upiorniej wygląda to, gdy do przeprowadzenia fazy UAT projektu zatrudniana jest jakaś zewnętrzna firma – wtedy z niemal stuprocentową pewnością sprawdzana będzie jedynie zgodność rozwiązania z dokumentacją, a nie adekwatność (wartość) wytworzonych rozwiązań.

Faza UAT w klasycznym procesie wytwarzania oprogramowania jest krytyczna, ponieważ jest ostatnią szansą na upewnienie się, przed decyzją o wdrożeniu, że produkt nadaje się do użytku. W praktyce dopiero na tym etapie zaczyna się naprawdę iteracyjna praca i dyskusja z interesariuszami o wymaganiach; niestety ma formę użerania się o to, które błędy trzeba rozwiązać, a które trzeba na razie tolerować. Jeśli software budowany jest dla zewnętrznego klienta, dochodzi czasem do kłótni o pieniądze i wymachiwania kontraktem, w którym zapisane zostały rozliczne kary umowne.

Dysfunkcyjny UAT

W rzeczywistości UAT wygląda jeszcze gorzej, niż opisałem powyżej. Testerzy w tej fazie są obarczani odpowiedzialnością za zapewnienie, że produkt działa. Poza sprawdzeniem, czy spełnia wymagania, poza oceną przydatności dla użytkowników (jeśli w ogóle to jest robione), ludzie ci… raz jeszcze testują wszystko, powtarzając w znacznym stopniu wysiłki Developerów, a nierzadko wykonując pełne testy regresyjne (czyli sprawdzenie, że zmiany nie zepsuły niczego, co zmienić się nie powinno). Im częściej development dostarcza buble, tym niższy jest poziom zaufania interesariuszy do nowej wersji produktu i tym bardziej faza UAT zamienia się w regularne testowanie każdego aspektu rozwiązania.

Weryfikacja i walidacja

Zanim napiszę, jak to wygląda, gdy stosuje się metody zwinne, warto zwrócić uwagę na dwa aspekty testowania produktu – każdego, nie tylko software’u.

Aby mówić o produkcie, który nadaje się do użytku, musimy upewnić się, że nie ma on wad technologicznych, związanych ze sposobem jego wytworzenia lub z architekturą utrudniającą dalszy rozwój i utrzymanie oprogramowania w działaniu.

Sprawdzenie, czy produkt spełnia standardy, jest technologicznie ukończony i zbudowany jak należy, określa się mianem weryfikacji. Powinna objąć ona wszystkie aspekty produktu i wymaga testów na wszystkich poziomach – od pojedynczych instrukcji w kodzie, poprzez integrację komponentów i złożonych systemów, do sprawdzenia wydajności, bezpieczeństwa, ergonomii i tym podobnych. To w ramach weryfikacji powinno wykonać się testy regresyjne, aby upewnić się, że cechy i funkcjonalności produktu, których nie należało zmieniać, działają tak, jak dotychczas.

Za weryfikację odpowiada wytwórca, czyli najczęściej Developerzy, którzy dostarczają produkt interesariuszom.

Aby mówić, że produkt robi to, co powinien i dostarcza oczekiwanej wartości, należy sprawdzić, w jakim stopniu dostarczone rozwiązanie odpowiada rzeczywistym potrzebom. To sprawdzenie, czy oprogramowanie może skutecznie zostać użyte, nosi nazwę walidacji.

W jej ramach nie trzeba ponownie weryfikować, że produkt działa – bo to przecież już wiemy. Nie ma bowiem sensu poddawać walidacji oprogramowania, które wcześniej nie przeszło weryfikacji. A to oznacza, że walidacja wymaga sprawdzenia jedynie takich scenariuszy, które są kluczowe dla biznesu oraz potwierdzają użyteczność i wartość wprowadzonych do oprogramowania zmian.

Kto odpowiada za walidację? Cóż, to zależy.

Jeśli brakuje zaufania w relacji między wytwórcami oprogramowania a interesariuszami (klientami, użytkownikami), wtedy walidację będzie zapewne przeprowadzał odbiorca produktu. Gdy zaufania jest choć trochę, dostawca oprogramowania może wykonać większość testów walidacyjnych i udostępnić ich wyniki w uzgodnionej formie.

Sporo zależy też od realnej wiedzy o tym, jak produkt w rzeczywistości jest użytkowany. Dostawca oprogramowania może nie być w stanie przeprowadzić miarodajnych testów samodzielnie, o ile nie zostały uzgodnione jakieś kryteria akceptacyjne, którymi mógłby się posiłkować. Kryteria takie najczęściej przedstawiane są w formie warunków, jakie rozwiązanie musi spełnić, więc stanowią dobrą podstawę do tworzenia testów walidacyjnych.

UAT to faza wyjątkowo krótka

Walidacja w porównaniu do poprzedzającej ją weryfikacji obejmuje zdecydowanie mniejszy zakres testów i to niezależnie od tego, kto je wykonuje. Przykładowo, jeśli do stu istniejących funkcjonalności produktu dodane zostały trzy kolejne, to walidacja powinna skupić się na potwierdzeniu ich wartości. Nie powinno być konieczne ponowne walidowanie wszystkich wcześniej istniejących mechanizmów produktu, o ile intencjonalnie nie wprowadzono w nich zmiany.

A co ze zmianami nieintencjonalnymi, wynikającymi ze źle przeprowadzonego developmentu? Te powinny zostać wykryte i wycofane w ramach testów regresyjnych, które stanowią jeden z kluczowych składników weryfikacji oprogramowania. Inaczej mówiąc, na tym etapie – czyli w trakcie walidacji – takich nieoczekiwanych zmian w produkcie być nie powinno, a jeśli się to zdarzy, będzie to wyjątek, nie zaś reguła.

Skoro więc faza UAT służy walidacji, jej przeprowadzenie powinno być o wiele szybsze i wymagać powinno o wiele mniej wysiłku i środków, niż samo wytworzenie oprogramowania. A im mniejszy jest zakres każdego wydania produktu, tym bardziej faza UAT stawać się będzie symboliczna.

Jak to jest w Agile?

Najlepiej odpowiedzieć na to pytanie na przykładzie metody Scrum (choć w przypadku każdej innej będzie dokładnie tak samo).

Produkt w Scrumie buduje się iteracyjnie i przyrostowo. Co to oznacza? Nie ma specyfikacji produktu, jest za to plan rozwoju produktu (Backlog Produktu), który zmienia się za każdym razem, jeśli ujawni się taka konieczność. Zespół pracuje w krótkich iteracjach (Sprintach), implementując w każdej z nich niewielką liczbę zmian w produkcie i sprawdzając na koniec (w ramach Przeglądu Sprintu) wraz z interesariuszami, czy powstały dobre rozwiązania. Odbywa się też wtedy dyskusja o tym, jak powinien wyglądać dalszy rozwój produktu.

Dzięki temu Zespół pozostaje w ciągłym kontakcie z interesariuszami i minimalizowane jest ryzyko pójścia rozwoju produktu w niewłaściwą stronę. Co więcej, działający produkt – taki, którego da się użyć – powstaje bardzo często: kolejne jego wersje pojawiają się przynajmniej raz przed końcem Sprintu, a nierzadko w iteracji Developerzy są w stanie wykonać cały ich szereg.

Ze względu na to, że zmiany wykonywane są małymi kroczkami (przyrostowo), łatwo każdą z takich zmian przetestować i nie pojawia się konieczność „stabilizowania” produktu po zakończeniu developmentu. Poza tym Scrum wymaga określenia i późniejszego stosowania Definicji Ukończenia, która opisuje warunki, jakie spełnić ma produkt technicznie nadający się do użycia. Warunki te Zespół musi spełnić przynajmniej na koniec Sprintu.

Dzięki takiemu podejściu w zasadzie w każdej iteracji (albo częściej) pojawia się nowa wersja oprogramowania, które można przekazać użytkownikom. Jedyną rzeczą, jaka pozostaje do zrobienia, jest wykonanie samego wydania (o ile nie dzieje się ono automatycznie).

Taki sposób działania wymaga by weryfikacja każdej zmiany, jaka wprowadzona została do produktu, odbyła się w ramach tego samego Sprintu, w którym Developerzy jej dokonali. Dzięki temu w dyskusji z interesariuszami, która odbywa się podczas Przeglądu Sprintu, nie trzeba zastanawiać się, czy oprogramowanie w ogóle działa i co należy zrobić, by nadawało się do użycia. Zamiast tego można skupić się na ocenie, czy jest to właściwe oprogramowanie. Inaczej mówiąc, czy skutecznie odpowiada ono na potrzeby użytkowników.

Stąd wniosek, że w Scrumie walidacja rozwiązań odbywa się w ramach iteracji, w których rozwiązania te zostają wytworzone.

UAT w Agile…

…nie ma zatem racji bytu. Wszystkie cele, które były w klasycznych metodach osiągane w ramach tej dedykowanej fazy testów walidacyjnych, są już osiągnięte w ramach poszczególnych iteracji.

Oczywiście zdarzają się wyjątkowe sytuacje, gdy niezbędne jest wykonanie jakichś specjalistycznych testów przez eksperta. To oznacza, że jakaś szczątkowa faza UAT będzie być może istnieć również tam, gdzie stosowane są metody zwinne. Natomiast w takiej sytuacji po pewnym czasie ów ekspert wciągnięty zostaje po prostu do Zespołu Scrum i od tego momentu, już jako jeden z Developerów, realizuje niezbędne testy w ramach iteracji, a nie po jej zakończeniu.

Pojawi się zaraz pytanie: no dobra, dobra, wszystko pięknie, ale kiedy interesariusze „odbierają” wymagania i sam produkt od Zespołu? Wcześniej działo się to zwykle na zakończenie fazy UAT, gdzie krwią podpisywali (a jakże, krew musi być!) zgodę na wydanie produktu. A skoro tej fazy nie będzie…?

Jeśli kogoś nurtują takie pytania, prawdopodobnie nie do końca rozumie jak działa Scrum i inne metody zwinne. Kluczowe w nich jest zrozumienie, że nikt nie próbuje w nich spisać „wszystkich wymagań” i czekać, a potem przyjść „odebrać produkt” zbudowany na ich podstawie. Zespół i interesariusze współpracują nad rozwojem produktu, wspólnie ustalając, co powinno być w nim zrealizowane.

Jeśli oprogramowanie, które powstało w iteracji, skutecznie rozwiązuje postawiony przed nim problem, tylko głupiec odmówiłby „odebrania” go. A jeśli software nie robi tego, co powinien, wtedy nikt nie będzie domagał się jego „odbioru”. I to niezależnie od tego, czy stało się tak dlatego, że Zespół źle zrozumiał wymagania, czy też dlatego, że interesariusze domagali się nie tego, czego faktycznie potrzebują. Dyskusja skupi się przede wszystkim na ustaleniu, jakich zmian trzeba dokonać.

Dojrzałość i zaufanie

Wiele organizacji pracujących z wykorzystaniem metod zwinnych wciąż niestety ma rozbudowaną fazę UAT w swym procesie. Często jest to wynikiem braku dojrzałości lub wręcz niewiary w to, że inne mechanizmy (takie, jakie proponuje na przykład Scrum) są skuteczniejsze niż podejście tradycyjne.

Oczywiście nauka działania zwinnego to proces, więc czasami pozostawienie na jakiś czas fazy UAT, jeśli interesariusze nie są jeszcze gotowi z niej zrezygnować, może być koniecznością. Miarą rozwoju Zespołu i organizacji będzie powolny zanik tej fazy.

Bywa też i tak, że faza UAT wciąż jest wymagana, bo interesariusze zwyczajnie nie ufają jakości tego, co dostają. Dzieje się to najczęściej tam, gdzie Zespoły dały podstawy do tego braku zaufania i gdzie w ramach UAT robi się nie walidację, ale i ponowną weryfikację produktu. Tak długo, jak testerzy UAT będą w stanie znajdować błędy wynikające z długu technicznego lub niedbalstwa Developerów, tak długo faza ta będzie trwać.

A jak jest u was?