Radek Smilgin
Testowanie akceptacyjne (inaczej UAT-y, User Acceptance Test) pojawia się zazwyczaj w kosztownych projektach, w których zlecającym wytworzenie oprogramowania jest podmiot publiczny lub duża instytucja (zazwyczaj finansowa). W projektach tych pojawią się silne regulacje i dużo biurokracji. Od prostego RfP (request for price), czyli wstępną wycenę i studium wykonalności (feasability study), poprzez procedurę przetargową z SIWZ (Specyfikacja Istotnych Warunków Zamówienia) i podpisanie umowy, po testy odbiorowe oraz SLA (Service Level Agreement), czyli umowę gwarantująca poziom świadczonych usług. Na wyższym poziomie spotkamy też takie ciało, jak Komitet Sterujący (steering committee), czyli nadrzędną komórkę, która w teorii ma pilnować przebiegu projektu, ale w rzeczywistości jest to miejsce rozwiązywania problemów. Jeśli do tego wszystkiego Wasz projekt obudowany jest prawnikami, to właśnie odkryliście projektowe piekło. Projekty takie toczone są przez nowotwór braku zaufania. Każdy podpisany papier, każdy wysłany mail, każde spotkanie to skomplikowana partia szachów, podczas gdy na planszy walczy dwóch przeciwników: Zamawiający oprogramowanie klient oraz Wykonawca produkujący rozwiązanie informatyczne.
Skąd bierze się konflikt?
Źródłem problemy projektu z testami odbiorowymi jest nieufność Zamawiającego do Wykonawcy oraz Wykonawcy dla Zamawiającego. To od samego początku ustala reguły gry i jest praprzyczyną wszystkich późniejszych problemów.
Zamawiający obawia się, że Wykonawca będzie chciał dostarczyć niedziałające, awaryjne i niedopasowane do jego potrzeb oprogramowanie. Wykonawca z kolei obawia się, że Zamawiający, który w momencie definiowania swoich wymagań nie ma pełnej świadomości tego, co potrzebuje, będzie próbował forsować zmiany w specyfikacji projektów, które znacząco podniosą koszty wytworzenia produktu.
Oba podmioty wybierają więc najtrudniejszą ścieżkę współpracy i zamiast już na początku zaadresować swoje obawy, decydują się prowadzić projekt z założeniem, że przyjdzie im przeprowadzić wojnę. Stąd wybierają najbardziej formalne środki, kaskadowe modele rozwoju oprogramowania oraz zatrudniają prawników do dyskutowania najdrobniejszych zapisów umowy. Żadna ze stron nie odpuszcza, każda z nich broni zapisów specyfikacji, jakby to była święta księga. Z jednej strony nic w tym dziwnego, z drugiej patrząc z zewnątrz można odnieść wrażenie, że patrzymy trochę na parę, która jest ze sobą tylko po to, by robić sobie na złość.
Objawy:
Każdy ze wspomnianych elementów jest objawem patologicznej sytuacji projektowej, ale niekoniecznie mogą być one widoczne na poziomie członków zespołu projektowego.
Oto kilka elementów, które powinny zwrócić Waszą uwagę, aby ocenić, że wasz projekt degradowany jest przez dogmat akceptacji:
- Rozbudowana dokumentacja projektowa, w tym przypadki testowe do jednokrotnego uruchomienia. Opisałem ten aspekt szerzej w osobnej publikacji o marnotrawstwie w tworzeniu przypadków testowych.
- Nadmierny formalizm raportowania wykonania i raportowania wyników pracy, w tym dla każdego wykonanego kroku testu dostarczany ma być zrzut ekranu, który pokazuje rezultat wykonania.
- Marnotrawstwo wykonania testów, które zostały już wykonane wcześniej przez kogoś innego lub będą ponownie wykonane. W zależności od tego, czy reprezentujesz Wykonawcę czy Zamawiającego, przyjdzie Ci uczestniczyć w procedurze, w której testy, zanim zostaną uruchomione przez Klienta, zostaną uruchomione przez zespół Wykonawcy. Mamy więc do czynienia z testami testów, gdzie w drugiej rundzie nie mają one już prawa ujawnić błędów.
- Zamawiającemu nie wolno wykonać innych testów niż te zaprojektowane przez Wykonawcę, co wynika z tego, że zbiór przypadków testów akceptacyjnych jest zaakceptowanym przez obie strony dokumentem. Odbiera to wszelką kreatywność oraz utrudnia znalezienie poważnych defektów, które mogły być przegapione na poziomie tworzenia dokumentacji.
- Zakaz raportowania defektów, gdzie każdy znaleziony problem musi zostać przeanalizowany przez każdą ze stron i w oparciu o predefiniowaną definicję co jest, a co nie jest defektem. Z tego też powodu prowadzi się po stronie Wykonawcy osobną instancję narzędzia do raportowania defektów niedostępną dla Zamawiającego, albo co gorsza defekty zgłaszane są mailowo.
A to dopiero początek, bo opisałem jedynie aspekty przypadków testowych, ich uruchomienia oraz raportowania wyników. Podobnie rzecz ma się na poziomie specyfikacji wymagań, której zapisy są interpretowane i negocjowane na każdym spotkaniu Zamawiający – Wykonawca i na poziomie programowania, gdzie zrobienie czegoś ponad wymaganie jest błędem poważniejszym, niż defekt krytyczny.
Rozwiązanie:
Naprawdę można inaczej, ale setki projektów z testami akceptacyjnymi, w których pracowałem lub też obserwowałem, pokazały, że ten świat wymaga porządnego kopniaka w kierunku refromy. Odporność na zwinność, niechęć do kooperacji, brak informacji zwrotnej tylko podbudowują tę ciągłą nieufność. Takie projekty są doskonałym przykładem strategii lose – lose, w której każda ze stron przegrywa wojnę, albo win – lose, w której jedna ze stron bierze całość, a drugi podmiot zostaje z niczym. Ci, którzy powinni być są partnerami, mają zakodowany w genach konflikt zanim jeszcze projekt się rozpocznie. Bez względu na to na jakim etapie swojego projektu jesteś pamiętaj, że w dowolnym momencie można wprowadzić zmiany. Umowa ma to do siebie, że zawarta jest z dwoma podmiotami i jeśli po obu stronach jest wola do jej zmiany, to jest to wszystko, czego potrzeba. Niestety, jest to już w większości bariera nie do pokonania.
Zmiana musi więc przyjść z zewnątrz. Takim rozjemcą może stać się niezależny podmiot wykonujący testy akceptacyjne z uwzględnieniem wszelkich zapisów, jakie się w projekcie znajdują. Innym rozwiązaniem jest zewnętrzny konsultant, który pokaże ludziom, którzy w standardzie odpowiadają "nie da się", że można inaczej. I to nawet w projektach prowadzonych w sektorze publicznym, czego potwierdzeniem są dostępne odpowiednie analizy, prowadzone przez Ministerstwa. Zmiana zatem jest możliwa, ale musi być mentalna.
