Scrum a UAT

Organizacje w obliczu transformacji do Agile stają w przed wieloma wyzwaniami. Jednym z największych wyzwań jest szukanie odpowiedzi na pytanie “co zrobić z UAT w Agile?”. No dobrze, w większości przypadków bardziej “co zrobić z UAT w Scrum?”. Do tej pory mieliśmy cykl, który po faziedevelopmentu miał fazę testowanie, a następnie fazę UAT. Teraz Sprint za Sprintem ma być dostarczane działające oprogramowanie. I o ile jasne jest, że testerzy mają wejść w skład Zespołu Developerskiego, albo bardziej scrumowo, testy mają być wykonane przez Zespół Developerski, to z UAT nie wiadomo co zrobić. Jak zwykle jest na to kilka pomysłów, które są bardziej lub mniej zwinne. Prześledźmy je i rozważmy ich skutki. Interesuje nas nie tylko czy się tak da, albo co jest wygodne dla organizacji; ale czy dane podejście jest kompatybilne ze Scrum i Agile.

UAT —  o co chodzi?

Zacznijmy od początku i wyjaśnijmy sobie co to jest ten nieszczęsny UAT, czyli inaczej User Acceptance Test. Nie trzeba się długo zastanawiać nad definicją jeśli mamy gotowe standardy. Najbardziej popularny standard dla testowania oprogramowania w tej części świata do ISTQB. Zasięgnijmy definicji ze słownika terminów testowych wersja 2.3. PL.

Bardziej po ludzku można powiedzieć, że UAT to po prostu testy akceptacyjne, których wynik ma ustalić czy system zostanie zaakceptowany przez użytkownika systemu lub klienta zamawiającego ten system. Takie testy polegają na przejściu przez typowe przypadki użycia, podstawowe scenariusze i wymagania zawarte w umowie. Ogólnie szukamy odpowiedzi na pytanie czy system działa tak, jak się umówiliśmy, że będzie działał?. Czasem tego typu testy są nazywane UAT, czasem CAT (ang. Customer Acceptance Test), czasem odbiór, ale zawsze oznaczają po prostu akceptację systemu.

Co na to Scrum?

Właściwie w Scrum Guide nie ma wzmianki na temat UAT. Jest natomiast jasno napisane, że przyrost Produktu musi być przetestowany. W Scrumie mamy trzy role Product Owner, Scrum Master i Development Team. Development Team wykonuje pracę i dostarcza ukończone elementy Product Backlog Items. Rolą, która akceptuje wyniki pracy Development Team jest Product Owner. Celem Sprintu jest dostarczenie potencjalnie gotowego do wydania Przyrostu (ang. Increment) produktu. Co dokładnie oznacza, że produkt jest gotowy do wydania opisuje Definicja Ukończenia (ang. Definition of Done).
Jakie z tego płyną wnioski? Jeżeli na koniec Sprintu mamy mieć gotowy do wydania Przyrost zgodny z Definicją Ukończenia, to wszystkie potrzebne do osiągnięcia tego stanu testy powinny być częścią Definicji Ukończenia i odbyć się w trakcie Sprintu. UAT to testy akceptacyjne i odbiór części pracy. Pracę akceptuje Product Owner, więc jasno wynika z tego, że UAT jest odpowiedzialnością Product Ownera. Podsumowując Product Owner jest odpowiedzialny za wykonanie testów akceptacyjnych (w tym UAT) w trakcie trwania Sprintu. Podobnie jak z pracą na Product Backlog, Product Owner nie musi wykonywać jej samodzielnie, może ją oddelegować. To oznacza, że testy akceptacyjne mogą być wykonane przez Development Team albo przez interesariuszy (ang. stakeholders). Product Owner nadal pozostanie odpowiedzialny za akceptację wyników pracy, więc powinien przynajmniej zobaczyć każdy PBI przed Sprint Review.

Opcje wykonywania UAT w Scrum

Product Owner robi UAT

I to jest sytuacja jak najbardziej prawidłowa. Ten, który jest odpowiedzialny i określał warunki satysfakcji odbiera i akceptuje lub zgłasza uwagi. Jako wadę można postrzegać tutaj duże obciążenie pracą Product Ownera. Praca z interesariuszami, zarządzanie Product Backlogiem i testy akceptacyjne to dużo pracy nawet przy jednym Zespole Developerskim. Nikt nie mówił, że będzie łatwo. Pełnienie roli Product Ownera w wartościowy i skuteczny sposób to praca na pełen etat.

Intresariusze robią UAT  w Sprincie

Zwykle pojawia się problem z dyspozycyjnością interesariuszy i ich zaangażowaniem w Sprincie. Najpierw będą narzekali, że nie mają co robić, a później kiedy ich najbardziej potrzeba są zajęci “normalną pracą”. Interesariusze nieprzyzwyczajeni do pracy w Scrum mają tendencję do zgłaszania wszystkiego co im się nie podoba i zgłaszania nowych pomysłów oczekując, że wszystko zostanie zrobione natychmiast. Jest to niebezpieczna sytuacja dla Product Ownera, ponieważ w ten sposób może dojść do przerostu zakresu wymagań i rozwoju w niepożądane strony. Może to się dziać za plecami Product Ownera. Interesariusze bez doświadczenia w testowaniu i odbiorach będą mieli kłopot z formułowaniem scenariuszy testowych. Zatem całkiem prawdopodobne jest to, że tak prowadzone testy UAT będą dodatkowym obciążeniem Zespołu Deweloperskiego. Interesariusze, którzy nie podchodzą do UAT odpowiedzialnie mogą oznaczać wszystkie testy jako udane, żeby jak najszybciej odhaczyć UAT i wrócić do “normalnej” pracy. Interesariusze mogą też lekceważyć wykonanie testów jeśli dany Sprint nie jest wydawany na produkcję. Jeśli mamy na przykład cztery Sprinty w wydaniu, to w pierwszych trzech Sprintach interesariusze będą rozbić testy “bez napinki”, bo “przecież to i tak nie idzie na produkcję”. Skutkiem będą problemy na produkcji i wielkie zdziwienie tych samych interesariuszy, bo przecież “jak to testowałem to działało”. Duża różnorodność interesariuszy może powodować konflikty, bo będą zgłaszali sprzeczne zmiany. Taka sytuacja powoduje dużo frustracji w Zespole Developerskim.

Zespół robi UAT

Kiedy te same osoby, które wykonują pracę, akceptują jej wyniki, to mamy bardzo dziwną sytuację. Można powiedzieć, że jest to sztuka dla sztuki. Dlaczego Zespół Deweloperski miałby nie zaakceptować tego, co sam wytworzył? Byłby to trochę samo-sabotaż. Negatywne skutki oprócz nienależytego przetestowania są takie, że cała odpowiedzialność za wyniki Sprintu i dostarczenie wartości będzie w rękach Zespołu Developerskiego. Product Owner nie będzie brał na siebie odpowiedzialności i będzie robił z Zespołu kozła ofiarnego. W tej sytuacji może dojść nawet do takich zachowań jak odcięcie się od wyników Sprintu na Sprint Review i atakowanie Zespołu. Cokolwiek złego się stanie, co nie wyjdzie, to będzie wina zespołu.

Eksperci robią UAT poza Sprintem

Kiedy trudno jest zmieścić się z testami UAT w Sprincie, to naturalnie pojawi się pomysłowy Dobromir i zaproponuje testy UAT osobnym strumieniem, gdzieś poza Sprintami. Sprinty idą swoją drogą, a testy odbywają się wtedy kiedy trzeba i kiedy łapanka na testerów biznesowych okazała się skuteczna. Gdzieś jakiś ekspert biznesowy przechodził z kawą, albo nieopacznie przyznał się, że ma chwilę wolnego czasu i już został oddelegowany do testowania. Z takim podejściem mamy kilka problemów. Pierwszy problem widoczny gołym okiem to odpowiedź na pytanie “Czy przyrost produktu w Sprincie jest Ukończony?” Można też spytać czy to jest “done Done”. Odpowiedź jest przecząca. Jeśli nie było testów akceptacyjnych w Sprincie, to oczywiście nie można powiedzieć, że funkcjonalność została ukończona i nadaje się do wdrożenia na produkcję. Jeżeli robimy coś poza Sprintem, to tracimy przejrzystość (ang. transparency) co jest wykonane a co nie. Mamy zatem realny problem. Problemy, które wyjdą później to jakość przeprowadzonych testów i tak zwana późna cofka, która męczy Zespół Developerski. Wynika to z tego, że osoby z łapanki nie wykonają dobrych testów i będą je robić w zrywach, kiedy będą naciskani. Podobnie jak w rozwiązaniu Interesariusze robią UAT w Sprincie dojdą tutaj problemy związane z wykonywaniem testów przez osoby spoza Zespołu Developerskiego.

Ekstra Sprint na UAT

Jeśli nie gdzieś boczkiem, tak jak w poprzedniej opcji, to może rozwiążmy bardziej formalnie problem tego, że nie mieścimy się z testami UAT w Sprincie. Na przykład robimy trzy SPrinty “zwykłe” i jeden Sprint UAT przed każdym wydaniem. Oficjalny specjalny Sprint na testy UAT brzmi jak dobre, formalne rozwiązanie problemu, jakiego żaden PM by się nie powstydził. Dokładanie specjalnego Sprintu na testy UAT to równie dobry pomysł jak specjalne Sprinty o nazwach Stabilization, Hardening, Release. Dlaczego? Ponieważ wszystkie te Sprinty, oznaczają jedno, nie jesteś w stanie dostarczyć done Done Przyrostu Produktu w ramach Sprintu. Jakie są negatywne konsekwencje Sprintów UAT? Zespół Developerski nie będzie się bardzo starał w Sprincie jeśli wiadomo, że jest jeszcze jakiś etap testów, który wychwyci błędy. Zatem jakość będzie nawet gorsza niż w przypadku zupełnego braku UAT. Wykrywanie błędów na ostatnią chwilę przed wydaniem na produkcję jest niezwykle ryzykownym przedsięwzięciem. Co jeśli znajdziemy coś poważnego i nie będzie czasu na naprawę? Błędy zgłaszane w Sprincie mogą dotyczyć PBI (ang. Product Backlog Item) (element Rejestru Produktu) dawno zrealizowanych. Więc dużo wysiłku pójdzie na wyśledzenie przyczyn błędów. Uderzy nas też typowa konsekwencja późnego naprawiania błędów. Usuwanie takich błędów może wiązać się z rozwiązywaniem wielu zależności nadbudowanych na funkcjonalności do poprawy.

Bez UAT

A może by tak nie robić UAT? Zastanówmy się. Co najgorszego może się stać? Po wdrożeniu Przyrostu Produktu na produkcję dostaniemy feedback, że coś mogłoby działać inaczej, albo czegoś brakuje. No i co? Informacja zwrotna trafia na Product Backlog i Product Owner odpowiednio przydziela porządek na liście. Kiedy nadejdzie kolej, nowe elementy mogą zostać zrealizowane w Sprincie. Czy nie o to chodzi w Scrum?

Podsumowanie

Wykonywanie testów UAT w Scrum jest pewnym rozwiązaniem przed jakim staje organizacja przechodząca transformację Agile. Jak z podobnymi zaszłościami z przeszłości należy zastanowić się po co to robimy. Jednym z wyjść jest rezygnacja z testów UAT. Co najgorszego może się wydarzyć? Jeśli już stwierdzisz, że w Twoim kontekście testy UAT są potrzebne, to powinny mieścić się Sprintach. Przestawiłem różne opcje pomiędzy realizacją UAT w Sprintach, a zupełnym brakiem. Wszystkie sprawdzałem w praktyce i to są moje doświadczenia. Sprawdź co najlepiej będzie działało w Twoim środowisku.