UAT, czyli user acceptance tests, testy akceptacyjne mówią o tym, czy oprogramowanie zostało wykonane zgodnie ze zleceniem, czy można zaakceptować wykonaną pracę i za nią zapłacić. (faktycznie do zapłaty są konieczne tzw. testy odbioru i podpisanie protokołu odbioru, lecz jest to nazwa pochodząca z praktyki zarządzania projektami; w branży IT używa się przeważnie nazwy UAT na określenie testów ostatecznych) No, bo IT chce, żeby biznes robił te testy, bo skoro zamówił oprogramowanie, to niech teraz się podpisze, że jest dobrze albo źle. Biznes jednak nie chce robić UAT, bo testowanie to sprawa IT. Dziś zapraszam do uważniejszego przyjrzenia się temu zjawisku.
Dokąd sięga downstream?
Proces wykonywania każdej pracy, w szczególności tworzenia oprogramowania, można podzielić na dwa kawałki: upstream oraz downstream. Momentem oddzielającym od siebie te dwie części procesu jest tzw. punkt zobowiązania. Jest to moment, w którym ostatecznie podejmujesz zobowiązanie, że wykonasz jakąś pracę. Przed momentem podjęcia tej decyzji wydarzają się wszystkie aktywności związane z odpowiedzią na pytanie, czy w ogóle warto zajmować danym zagadnieniem, czy warto wykonać zlecenie. Może to być analiza, wstępne projektowanie, rozpoznanie rynku, szacowanie rentowności, itd. Te wszystkie rzeczy, które dzieją się przed momentem decyzji o wykonaniu pracy nazywamy upstream.
Już po podjęciu decyzji o wykonaniu pracy zaczyna się downstream, czyli wykonywanie albo dostarczanie tego, do czego się zobowiązałeś w momencie podejmowania decyzji.
Dokąd sięga downstream, co jest momentem jego zakończenia? Finałem jest moment, w którym praca jest GOTOWA (DONE). Cały bajer polega na tym, w jaki sposób ów moment DONE jest zdefiniowany.
W założeniu DONE oznacza, że możesz otrzymać zapłatę za wykonaną pracę. Często jest jednak tak, że DONE oznacza na przykład:
- gotowe do wdrożenia,
- albo wdrożone dla conajmniej jednego klienta,
- albo wdrożone dla x% klientów,
- albo wrzucone na środowisko przedprodukcyjne,
- i wiele innych pomysłów.
W artykule Kanban w sprzedaży pokazuję, jak można zorganizować proces sprzedaży usług, gdzie DONE oznacza, że klient zapłacił za usługę.
Co mają do tego UAT? Ano, bardzo dużo. Jak napisałem we wstępie, pozytywne przejście testów UAT oznacza, że ten kto płaci zgodził się, że dostał to, co chciał. Jest to więc końcowy etap Twojej pracy. Jeśli zatem oczekujesz, że biznes będzie wykonywał testy UAT, to w ten sposób włączasz biznes w Twój proces downstream. Czy tak można? Można, ale...
Skoro wykonanie testów UAT przez biznes staje się częścią Twojego procesu downstream, to aby zakończyć prace i otrzymać zapłatę, testy UAT muszą zostać wykonane. Biznes może być jednak w danym momencie zajęty czymś innym i siądzie do testów za miesiąc albo dwa. I przez ten czas nie otrzymasz przelewu, bo nie ma UAT i Twoja praca nie zostanie zaakceptowana i odebrana.
Drugi problem polega na tym, w jaki sposób biznes wykonuje testy UAT. Życie pokazuje, że jest tak:
- Prosisz biznes o zrobienie UAT,
- Biznes mówi, że zrobi za miesiąc,
- Miesiąc mija, Ty masz już na tapecie kolejne prace,
- Biznes bierze się za testowanie i zasypuje Cię górą zgłoszeń o błędach,
- Musisz odrywać się od pracy, wrzucać zespołom nagłe rzeczy do zrobienia, bo biznes testuje,
- I tak w kółko.
Biznes może robić UAT, może być częścią Twojego procesu downstream tylko wtedy, gdy obie strony się zobowiążą, że pracują razem. Wy dewelopujecie, biznes natychmiast UATuje, wspólnie staracie się, aby cały proces downstream działał szybko i sprawnie. Tak, wtedy to będzie działać. Jeśli jednak, nie masz takiego kontraktu z biznesem, to uwierz mi, nie chcesz, aby biznes robił testy UAT. Nie chcesz uzależniać swojej zapłaty od osób, na które nie masz żadnego wpływu.
UAT czy nie UAT
Przypatrz się obrazkowi:
Rysunek przedstawia jakieś dwa formularze w aplikacji mobilnej i przejścia między nimi. Ile Twoim zdaniem jest testów UAT na tym obrazku? Co powinen sprawdzić robiący testy UAT? Może tak:
- Sprawdzić, czy załadował się poprawny film,
- Sprawdzić, czy załadował się poprawny awatar,
- Sprawdzić, czy po kliknięciu na -Edytuj ustawienia- przechodzi do formularz edycji ustawień,
- Sprawdzić, czy po kliknięciu -Zapisz- wraca do formularza z podglądem filmu,
- itd, itd.
Rzeczy do sprawdzenia jak wyżej jest od groma. Nic dziwnego, że biznes nie chce tego sprawdzać. Co więcej dostaje taką paczkę testów do wykonania przed każdym wdrożeniem. A gdy jesteście zwinni i staracie się wdrażać częściej i częściej...I co się dziwisz, że biznes trafia szlag od tego ciągłego klikania?
Tylko, że to nie są testy UAT. Testy UAT związane są z tym, co oprogramowanie robi dla użytkownika. UAT oznacza, że sprawdzam, czy użytkownik może za pomocą oprogramowania wykonać jakieś konkretne zadanie od początku do końca. To "zadanie od początku do końca" nazywa się use case, przypadek użycia i to weryfikuje UAT. Na obrazku powyżej jest tyko jeden przypadek użycia i jeden UAT: Mogę edytować ustawienia filmu i tyle. Wchodzę do apki, sprawdzam czy mogę edytować ustawienia filmu, jeśli mogę to test przeszedł i już. Lista testów, którą napisałem dwa akapity wyżej, to testy UI (user interface), nie UAT. Są ważne, ale robi je IT, nie biznes.
Testowanie poprawności prezentowanych formularzy, walidacja, layout, to testy UI. Jeśli chcesz, aby biznes wykonywał testy UI, to ich zatrudnij w zespołach developerskich. A jeśli nie planujesz ich zatrudniać, to niech Twoje UATy będą prawdziwymi UATami i może wtedy uda Ci się namówić biznes, aby był częścią Twojego procesu downstream.
