Blog

Rozważając implementację testów UAT (User Acceptance Testing) w ramach metody Scrum, istotne jest zrozumienie ich podstawowej idei oraz roli w procesie tworzenia oprogramowania. Testy UAT (User Acceptance Testing) służą weryfikacji, czy system spełnia oczekiwania i wymagania użytkowników końcowych, co jest kluczowe dla sukcesu tradycyjnie pojmowanego projektu gdzie jest z góry wiadome jakie są potrzeby zamawiających. W Scrum, gdzie nacisk kładziony jest na ciągłą dostawę wartości i adaptacyjność,  co umożliwia poszukiwanie najlepszych rozwiązań w sytuacji dużej zmienności i niepewności tradycyjne UAT-y nie mają zastosowania. Czasem jednak wymogi formalne lub inne ograniczenia organizacyjne zmuszają zespoły Scrum do pracy z UAT-ami.

W Scrum Guide, szczególnie w jego edycji z 2020 roku, nie znajdziemy bezpośrednich odniesień do UAT, jednak podkreślana jest konieczność przetestowania każdego przyrostu produktu uznaniem go za ukończony Przyrost (Increment). Odpowiedzialność za to, że Przyrost jest w pełni przetestowany i gotowy do wydania spoczywa na Deweloperach (Develiopers) a pomaga im w tym Definition of Done (DoD). Choć DoD dotyczy technicznego ukończenia Przyrostu to oczywiście kryteria akceptacyjne  także muszą być spełnione dla każdej funkcji, która wchodzi w skład Przyrostu.

Zobaczmy jakie są opcje „wpisania” narzuconych zewnętrznie testów UAT w Scrum:

• Product Owner jako wykonawca UAT: W tym przypadku to Product Owner jako w pewnym sensie reprezentant potrzeb Interesariuszy przeprowadza testy UAT, których owi Interesariusze oczekują. Wymaga to jednak znacznego zaangażowania czasowego i merytorycznego od PO.
• Uczestnictwo interesariuszy: Zaangażowanie bezpośrednich użytkowników lub innych interesariuszy w proces testowania w ramach Sprintu, co jednak może wiązać się z wyzwaniami dotyczącymi dostępności i zaangażowania tych osób a także ich chęci brania udziału w tym procesie.
• Deweloperzy przeprowadzają UAT: Choć może to wydawać się nieco kontrowersyjne, zespoły często włączają elementy UAT do swoich zadań, np. poprzez dopisanie spełnienia UAT do Definition of Done lub kryteriów akceptacji dla wymagań, któych UAT dotyczą . To rozwiązanie wydaje się najbardziej zgodne z duchem Scrum.
• Testy UAT poza Sprintami: Organizowanie osobnych sesji UAT poza cyklem Sprintów, co jednak może prowadzić do utraty przejrzystości (nie wiemy czy Przyrost jest naprawdę ukończony czy nie póki nie nadejdzie czas sesji UAT) oraz opóźnień w dostarczaniu wartości (nie można wydać już technicznie gotowych rzeczy bo czekają na UAT a więc czekając nie przynoszą korzyści).

Warto zaznaczyć, że w dynamicznie zmieniającym się środowisku stosujemy metody Agile takie jak Scrum bo kładą one nacisk na adaptacyjność i ciągłe dostosowywanie się do zmieniających się warunków, a więc i wymagań.  W tej sytuacji tradycyjne podejście do UAT może a nawet powinno wymagać przemyślenia. W 2022 roku coraz częściej wyraźnie widać znaczenie bezpośredniej współpracy z użytkownikami i ciągłego zbierania informacji zwrotnej, co powoduje, że wiele organizacji rezygnuje z formalnych UAT na rzecz dobrze wdrożonych metod zwinnych.

Podsumowując, jeśli już musimy żyć z UAT-ami kluczowe jest znalezienie zrównoważonego sposobu włączenia testów UAT do procesu Scrum, takiego sposobu, który będzie wspierał ciągłe dostarczanie wartości i utrzymywał wysoką jakość produktu, jednocześnie pozostając elastycznym i otwartym na zmiany.

Przeczytaj też artykuł Rafała Markowicza Czy w Agile faza UAT ma sens?