Blog

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

Następnie biznes krwią podpisywał się pod tymi dokumentami, gwarantując, że zdania nie zmieni (prawda, że nie zmieniał…?). Stawało się wtedy możliwe zaprojektowanie architektury rozwiązania i zaplanowanie prac niezbędnych do realizacji produktu. Pod tymi planami i projektami krwią podpisywali się wytwórcy oraz, zarządzający ich pracą, Project Manager, dając gwarancję, że wszystko będzie w terminie, 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ć, i 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 od biznesu i jego 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 „jak idzie”. Bywa tak, że ujawniają się problemy, które wymuszają zmianę projektów i planów, które są owych projektów pochodną. Nieustannie zmieniają się potrzeby biznesu, 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” produktu. 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 potrzebujemy.

Warto uświadomić sobie różnicę między tymi dwoma pytaniami. Można przecież wykonać oprogramowanie idealnie spełniające spisaną listę wymagań, a kompletnie nieużyteczne z dwóch powodów:

• od spisania wymagań potrzeby się zmieniły, a wymagania pozostały w starej formie,
• w niewłaściwy sposób zostały zrozumiane zapisy w specyfikacji.

Jest to skutek oderwania tych, którzy software tworzą, od tych, którzy go będą używać i wiedzą, czego im tak naprawdę potrzeba.

Krytyczna rola testów akceptacyjnych

Co dzieje się po „stabilizacji”? Ano, biznes sprawdza, czy to, co dostał, jest tym, co dostać powinien, czyli rozpoczyna się faza testów akceptacyjnych (UAT – User Acceptance Testing lub CAT – Customer Acceptance Testing). Desygnowani przez biznes (lub klienta) testerzy sprawdzają, czy oprogramowanie spełnia zapisy wymagań, a czasami (choć niestety nie zawsze), czy nadaje się ono do rzeczywistego użycia.

Testerami takimi są zazwyczaj użytkownicy (aktualni lub przyszli) tego oprogramowania, zdarza się, że oderwani od swych innych obowiązków i mało doświadczeni w realizacji testów. Jeszcze upiorniej wygląda to, gdy do zrobienia UAT / CAT zatrudniana jest jakaś zewnętrzna firma – wtedy z niemal stuprocentową pewnością sprawdzana będzie jedynie zgodność rozwiązania z dokumentacją.

Faza ta w klasycznym procesie wytwarzania oprogramowania jest krytyczna, ponieważ jest ostatnią szansą na upewnienie się, przed decyzją o wdrożeniu, że produkt w istocie nadaje się do użytku. W praktyce dopiero na tym etapie zaczyna się naprawdę iteracyjna praca i dyskusja z biznesem o wymaganiach; niestety ma formę użerania się o to, które błędy trzeba rozwiązać, a które można na razie tolerować.

Dysfunkcyjny UAT

W rzeczywistości UAT nie wygląda tak różowo, jak opisałem to 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 biznesu (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 biznesu 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 jest, gdy stosuje się metody zwinne, warto zwrócić uwagę na dwa aspekty testowania produktu, nie tylko software’owego.

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/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 do integracji złożonych systemów, poprzez sprawdzenie 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 w poprzedniej wersji.

Za weryfikację odpowiada wytwórca, czyli najczęściej zespół developerski lub organizacja developerska, która produkt dostarcza biznesowi.

Aby mówić, że produkt robi to, co powinien i dostarcza oczekiwanej wartości, należy sprawdzić, na ile dostarczone rozwiązanie odpowiada rzeczywistym potrzebom. Sprawdzenie czy oprogramowanie może skutecznie zostać użyte przez biznes nosi nazwę walidacji. 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 od strony technologicznej. Sprawdza się więc w ramach walidacji jedynie typowe scenariusze i potwierdza użyteczność nowych funkcji dla biznesu.

Kto odpowiada za walidację? Tu sprawa nie jest taka prosta: jeśli dostawca rozwiązania chce mieć pewność, że jego produkt nie zostanie odrzucony przez biznes, sam powinien przeprowadzić niezbędne testy i udostępnić ich wyniki biznesowi w uzgodnionej formie. Jeśli wymagania były zaopatrzone w zestaw kryteriów akceptacyjnych, to najczęściej mają one formę testów biznesowych lub warunków, jakie rozwiązanie musi spełnić. Kryteria akceptacyjne stanowią dobrą podstawę do takiej wstępnej walidacji.

Wytwórca (development) powinien testy walidacyjne zrobić, choć… cóż, nie będzie to walidacja, bo jedynie biznes może odpowiedzieć na pytanie czy to, co dostał, odpowiada jego potrzebom. Ale mając wiedzę od wytwórcy na temat przeprowadzonych przez niego testów, może własne sprawdzenie ograniczyć wyłącznie do tego, co krytyczne i czego development sprawdzić samodzielnie nie mógł. To powoduje, że faza UAT robi się wyjątkowo krótka i jest skupiona często tylko na sprawdzeniu kilku najbardziej krytycznych aspektów produktu.

A jak to jest w Agile?

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

Praca zwinna zakłada, że development pozostaje w ciągłym kontakcie z biznesem i współpracuje nad rozwojem produktu, dopasowując go do ciągle zmieniających się potrzeb i szukając najlepszych rozwiązań. To implikuje brak faz, w szczególności nie ma czegoś takiego jak „stabilizacja” na koniec. W każdej iteracji musi powstać coś, co działa, aby dało się zdecydować, co robić z tym dalej.

Scrum posługuje się konceptem Definition of Done, które musi zostać spełnione przez developerów, a które ma zapewnić, że produkt (w Scrumie zwany przyrostem produktu) będzie technicznie ukończony i można go użyć. To oznacza, że dla wszystkich prac, jakie realizowane są w ramach iteracji (sprintu), wykonane muszą zostać niezbędne testy – a więc weryfikacja. Co więcej, muszą te testy zostać wykonane w czasie iteracji (sprintu), ponieważ o ukończeniu prac można mówić w Scrumie tylko wtedy, gdy powstanie produkt spełniający Definition of Done, a to wymaga zweryfikowania, że tak jest w istocie.

Taki produkt (przyrost) jest poddawany przeglądowi wraz z biznesem na koniec każdego sprintu. Aby mieć pewność, że wymagania realizowane w tej iteracji są zaimplementowane poprawnie, zespół developerski musi wykonać również testy akceptacyjne. Wbrew błędnym obiegowym opiniom o Scrumie, produkt nie jest „demonstrowany” biznesowi, ale dokonuje się realnej oceny jego działania i dyskutuje nad tym, czy zaspokaja on potrzeby biznesu. Tym samym w ramach przeglądu na koniec sprintu odbywa się walidacja nowej wersji produktu.

UAT w Agile…

…nie ma zatem racji bytu, po prostu. Wszystkie cele, które były w klasycznych metodach osiągane w ramach tej dedykowanej fazy testów biznesowych, są już osiągnięte wcześniej, w ramach sprintów lub podczas przeglądów na koniec sprintu.

Pojawi się zaraz pytanie: no dobra, dobra, wszystko pięknie, ale kiedy biznes „odbiera” wymagania/produkt od developerów? Wcześniej działo się to na zakończenie fazy UAT, gdzie biznes krwią podpisywał (a jakże) 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 zaangażowanie biznesu w sposób stały w rozwój produktu. Nie może być tak, że najpierw spiszemy „wszystkie wymagania”, a potem przyjdziemy „odebrać produkt”, w jakim zostały zrealizowane. Zamiast specyfikacji z kompletem wymagań, tworzona jest lista wymagań (backlog produktu), która nigdy nie jest kompletna i cały czas ewoluuje. To pozwala szybko reagować na zmieniające się potrzeby biznesu.

Przed każdym sprintem ustalane jest przez Product Ownera, co w danym momencie jest najbardziej potrzebne. Nieustannie więc rozmawia się o wymaganiach i dokonuje w nich zmian, regularnie (co iterację) dokonuje się oceny wartości i przydatności tego, co udało się do tej pory zbudować.

Jeśli w czasie przeglądu sprintu w Scrumie okaże się, że wytworzone funkcjonalności wymagają dalszych prac lub istotnych zmian, to… bardzo dobrze! To nie porażka developerów, tylko sukces wszystkich zaangażowanych w wytwarzanie produktu: zdołali odkryć, że to, co wcześniej wydawało się dobrym pomysłem, niekoniecznie nim było i wymaga korekty, której da się dokonać od razu.

Dojrzałość i zaufanie

Wiele organizacji pracujących z wykorzystaniem metod zwinnych wciąż niestety ma fazę UAT w swym procesie. Często wynika to z braku dojrzałości lub wręcz wiary w to, że inne mechanizmy (takie, jakie proponuje na przykład Scrum) są skuteczniejsze niż podejście tradycyjne. Stawanie się Agile to proces, więc czasami jest nieuniknione pozostawienie na jakiś czas fazy UAT, jeśli biznes rzeczywiście nie jest gotowy z niej zrezygnować. Miarą postępującej transformacji do Agile będzie powolny zanik tej fazy.

Bywa też i tak, że faza UAT wciąż jest wymagana, bo biznes nie ufa jakości tego, co dostaje. Dzieje się to najczęściej tam, gdzie development dał podstawy do tego braku zaufania i gdzie w ramach UAT robi się nie tylko 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?