Testy w Scrum? To jak wkładanie kija w mrowisko. Przecież zespoły tylko robią robotę, a testuje klient, zewnętrzni testerzy albo w ogóle ktoś jeszcze inny. Tylko czy tak naprawdę powinno być i czy to jest dobry pomysł?
Co robimy w Sprintach?
„Każdy kolejny Increment rozbudowuje wszystkie wcześniejsze, jest też skrupulatnie weryfikowany po to, aby zapewnić, że wszystkie Incrementy są do siebie dopasowane. Aby dostarczyć wartość, Increment musi być użyteczny.” – Scrum Guide 2020
Pisaliśmy już o różnicach pomiędzy potencjalnie wdrażalnym, a użytecznym, warto jednak przypomnieć to i owo. „Potencjalnie wdarżalny Przyrost„, jak to się kiedyś mówiło, to taki, który możemy udostępnić naszym użytkownikom (np. wypuszczając nową wersję naszego oprogramowania) i nic złego się nie stanie. To znaczy, że nie będzie w nim błędów, pogorszenia działania, ani innych negatywnych konsekwencji. W najgorszym razie nic się nie zmieni, przynajmniej z perspektywy użytkowników biznesowych.
„Użyteczny” i „wartościowy” Przyrost to taki, który faktycznie coś nam daje. Dostarcza nam nieco więcej niż li tylko kolejny numer wersji. A to pośrednio znaczy też, że nie pogarsza sytuacji – nie wprowadza nowych błędów, ani nie psuje starszych funkcjonalności. Czyli, można założyć, że jest też przetestowany i działa. Tymczasem wiele Zespołów Scrumowych albo nie testuje, albo sprawdza swoje rozwiązanie pobieżnie, a potem liczy na testy UAT u klienta lub proces testowania w specjalnym osobnym zespole testerskim.
Pierwsze pytanie: to jaki jest ten Przyrost? Czy jest użyteczny, potencjalnie wdrażalny i wartościowy? A może „nie wiemy jaki jest, póki go nie przetestujemy”? Po drugie, czy to co powiedzieliśmy, że jest skończone (ang. done) jest naprawdę skończone? Nigdy już do tego nie wrócimy? Czy też może jak wrócą błędy od zewnętrznych testerów to znów rozgrzebiemy temat, o którym już powiedzieliśmy, że jest done?
Jeżeli nie możemy powiedzieć, że do skończonej pracy nigdy już nie wrócimy, to nie jest ona skończona! Owszem, błędy się zdarzają. Tak samo jak przeróbki, optymalizacje czy naprawy niespodziewanych awarii. Tyle, że to coś zupełnie innego niż „prawie zrobiliśmy, jeszcze tylko klient musi przetestować” lub „prawie zrobiliśmy, ale czekamy na akceptację PO”. Bo co jeśli nie zaakceptuje, nie odbierze albo znajdzie jakieś błędy? Czemu my ich nie znaleźliśmy? I jak wtedy mamy planować swoje prace? Co możemy uznać za skończone, a co czeka na nas w zawieszeniu i może wróci do nas dokładając nam pracy?
Konsekwencje „Prawie Zrobionego”
Jeżeli Scrum Team powiedział, że zrobił, to zrobił i jest zrobione. Product Owner nie akceptuje wymagań. Skoro zespół zrobił, to znaczy, że jest to zgodne z naszą Definition of Done i już nigdy więcej nie wrócimy do tego tematu. Cokolwiek mniej niż „jest skończone, zrobione i zapominamy o tym kawałku” to Almost Done. A takie zadania i wymagania wrócą do nas i będą nas prześladować.
Powiedzmy to sobie jeszcze raz: oddawanie do testów nie wystarczy. Nie tylko dlatego, że „nikt Ci tak nie przetestuje, jak użytkownicy Ci przeużywają”, ale przede wszystkim, że zupełnie inaczej pracujemy nad czymś, co mamy tylko oddać do testów, a inaczej nad rozwiązaniem, które ma działać docelowo. I to wcale nie przez nasze lenistwo czy celowe zadowalanie się niższą jakością. Taka jest cecha naszego umysłu, że skupiamy się na tym, co jest faktycznie potrzebne i analizujemy przypadki, które faktycznie wystąpią.
W Scrumie testy muszą być robione w Sprintach, przez Scrum Teamy. Nie ma innego wyjścia. Mówiliśmy o tym na naszym kanale na YouTube w filmie o QA i testach. Przede wszystkim oznacza to, że potrafimy powiedzieć, że nasze rozwiązanie działa. Przydałoby się też być pewnym, że przy okazji nie popsuliśmy niczego innego. Fajnie byłoby, gdybyśmy też potrafili sprawdzić przypadki brzegowe i różnego rodzaju dane – najlepiej pochodzące z rzeczywistego systemu.
W świecie tworzenia oprogramowania zwykle znaczy to zarówno testy automatyczne, unit testy, testy regresji, ale też testy manualne i weryfikację rozwiązania w warunkach jak najbliższych rzeczywistości. Continuous Delivery wspomaga nas w tym, oczekując ciągłego utrzymywania naszego produktu w stanie wdrażalnym. Podejścia takie jak feature flagi/feature toggle czy trunk-based development nam w tym pomagają. Ale tak naprawdę temat testów jest o wiele bardziej szeroki niż post na naszym blogu. Specyfika zależy od konkretnej firmy, technologii i podejścia.
Praktyka pokazuje jednak, że w przypadku większości rozwiązań musimy mieć potężną bibliotekę testów automatycznych, żeby utrzymywać nasze rozwiązanie w stanie wdrażalnym. Oraz, żebyśmy byli pewnie, że jak powiemy „done” to jest „done” i już nie będziemy do tego wracać. A testy UAT u klienta to już tylko formalność, z której co najwyżej wrócimy z pierdołami do poprawienia, ale nie z rzeczami funkcjonalnymi.
Właściwy podział pracy
„Podział pracy” kojarzy nam się z tym, co kto robi. I tu czyha na nas pułapka. Bardzo często przeradza się to w przypisywanie rzeczy analitycznych do analityków, testerskich do testerów, itd. To powoduje rozmycie odpowiedzialności i zabicie poczucia pracy zespołowej. Nie mamy już jednego Produktu, tylko każdy z nas ma „swoje” zadania.
Tu jedna mała uwaga. Widziałem też wiele takich zespołów, w których był ścisły podział pracy. I działał. To znaczy testerzy testowali, programiści programowali, itd. Tylko tam wszyscy czuli pracę zespołową, nie było indywidualnego traktowania „swoich” zadań, ale skupienie na tym, żeby dojechały całe funkcjonalności. Wymagania, a nie zadania. Były to też bardzo dojrzałe Zespoły Scrumowe, które wiedziały na czym to wszystko polega. Żaden ScrumBut, tylko prawie-że podręcznikowy czysty Scrum. Czyli może to działać, o ile wiemy co robimy.
Jeśli jednak dopiero zaczynamy naszą przygodę ze zwinnością, to musimy zmusić się do tego, żeby niektóre rzeczy robić inaczej. Bo nie mamy w tym praktyki, bo nie jest to dla nas naturalne. I gadanie o tym, że „ta funkcjonalność zajmie nam dwa miesiące do zrobienia i nie da jej się podzielić” jest poddaniem się już na samym początku. Tak samo „u nas się tego nie da przetestować wewnątrz zespołu” będzie nam szkodziło i psuło nasze postrzeganie tego, co jest zrobione.
Działając w ten sposób mówimy „Weźmy coś do Sprintu, a ile zrobimy to już się zobacz.” Jest to zaprzeczenie podejścia zwinnego. Może wcale nie jest ono dla nas? A może faktycznie nie da się podzielić tego wymagania (spoiler alert: da się). Może nie da się albo nie umiemy testować małych kawałków naszej pracy w zespołach? Jeżeli tak jest to nie udawajmy, że pracujemy scrumowo.
Żeby móc testować nasze funkcjonalności wewnątrz Scrum Teamów musimy a) mieć małe, ściśle sprecyzowane kawałki do testowania b) właściwie zbudowane zespoły, które potrafią coś wytworzyć i sprawdzić, że to działa c) posiadać jakiś sposób na upewnienie się, że robiąc nowe nie zepsuliśmy starego (regresja). Reszta to detale. Technologia, proces wytwórczy, itp. to ważne szczegóły, które mogą nam pomóc albo przeszkodzić. Ale wszystko zaczyna się od naszego podejścia i pytania: czy to, co wychodzi z Zespołów Scrumowych jest gotowe i przetestowane?
Jeżeli szukasz porad o tym, jak właściwie dzielić wymagania oraz praktycznych informacji o tym, jakie korzyści możemy mieć z płynniejszej pracy nad mniejszymi rzeczami, zapraszamy na nasze szkolenia i warsztaty. Polecamy także naszą listę mailingową, na której organizujemy szkolenia otwarte i weekendowe. Takie jak np. Weekend ze Zwinnymi Wymaganiami, który odbył się kilka miesięcy temu. A wkrótce ogłosimy kolejne terminy.
