- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Już starożytni mawiali “nihil novi sub sole”. Tak właśnie można określić ISTQB CTFL Agile Extension. Ponad miesiąc temu w moje ręce trafił nowy sylabus ISTQB w pełni zatytułowany Certified Tester Foundation Level Extension Syllabus Agile Tester. Najpierw mogłem zobaczyć wersję beta, która (chyba przez nieuwagę) była dostępna do ściągnięcia jako PDF. Kiedy już uważnie przeczytałem 50 stron tekstu, pozaznaczałem ciekawe fragmenty i zrobiłem adnotacje, 30 czerwca wyszła oficjalna wersja sylabusa. W ten sposób miałem do przeczytania kolejne 50 stron i jeszcze dwie wersje do porównania. Jako jeden z pierwszych zdałem też egzamin ISTQB® Agile Tester Extension exam i otrzymałem certyfikat. Niestety nie był to wynik 100% poprawnych odpowiedzi, ale i tak znacznie powyżej średniej dla egzaminów z ISTQB. O egzaminie napiszę może innym razem. W końcu znalazłem czas, żeby napisać recenzję i szczegółowo najbardziej kontrowersyjne w mojej opinii pomysły prezentowane przez ISTQB. Materiały do Agile Tester są już do pobrania z oficjalnej strony ISTQB.
Wrażenie ogólne
Długo zastanawiałem się nad tym jak najlepiej można krótko podsumować wrażenia po przeczytaniu nowego sylabusa o Agile Testing. Najlepiej pasuje mi określenie łacińskie “nihil novi sub sole”, czyli nic nowego pod słońcem. Otóż elementarz dla Agile Testera omawia najpopularniejsze metody Agile, aspekty pracy z User Story, piramidę testów, kwadranty testowania i Behaviour Driven Development. Na dobrą sprawę jest to zakres książki Agile Testing autorstwa Janet Gregory i Lisy Adkins i jednej z książek Gojko Adzica. Jest to zdecydowanie mało odkrywcza zawartość przekazywana z gracją ISTQB znaną z poprzednich sylabusów. Przedstawiane tutaj pomysły prezentowałem w 2010 na konferencji TestWarez, co można zobaczyć w poprzednim poście. Gdzie zostałem potraktowany z przymrużeniem oka przez osoby, które tworzą/będą tworzyć tłumaczenia Syllabusa po polsku i teraz na pewno bardzo chętnie podpiszą się pod tymi samymi ideami, i będą oferowały odpowiednie szkolenia. Zapamiętałem uwagę jednego z członków SJSI, który powiedział, coś w stylu, że jeśli to moje testowanie w Agile byłoby takie dobre, to nie powinno być w ogóle żadnych błędów w oprogramowaniu. Powiem więcej, wprowadzałem te metody w zespołach Scrum już od 2008 roku. Dostarczam szkolenie omawiające szerszy zakres niż sylabus Agile Testera w formie 2 i 3 dniowej od dobrych 3 lat. O tych samych rzeczach mówi Wiktor Żołnowski i całe grono zagranicznych trenerów. Naprawdę, ten sylabus to nic nowego pod słońcem.
Nowością jest jedynie to, że ISTQB dostrzegło świat Agile. No, ale skoro nawet zatwardziałe PMI wypuściło stosowny certyfikat Agile Certified Practitioner, to czemu się nie przyłączyć. Należy tutaj nadmienić też, że od kilku lat iSQI oferowało 5‑dniowe szkolenie zakończone egzaminem na Certified Agile Tester, ale nie była to zbyt popularna propozycja. Przewagą ISTQB jest oprócz rozpoznawalnej marki, to, że łatwiej i taniej jest wysłać testera na 2‑dniowe szkolenie zakończone egzaminem niż na podobne, ale 5‑dniowe. Oczywiście to 5 dni miało swoje uzasadnienie, tak jak moja propozycja 3‑dniowa. Poza większym zakresem wiedzy, iSQI dawało/nadal daje sporą dawkę praktyki. Ale czy to obchodzi sponsora testera wysłanego na kurs? Czy bardziej interesuje możliwość zdobycia papierka w 2 dni zamiast 5 dni, niższa cena i mniejszy czas przestoju w pracy? Na to odpowiedzcie sobie sami, drodzy czytelnicy. Natomiast nie widzę możliwości, żeby nauczyć kogoś o świecie Agile i o podejściu do testów w tym paradygmacie w ciągu niespełna 2‑dniowego szkolenia z akredytowanych materiałów jeśli uczestnik nie ma żadnej wiedzy i doświadczenia na ten temat. W swojej opinii biorę też pod uwagę styl w jakim szkolenia ISTQB są zwykle prowadzone, czyli czytanie slajdów przerywane wypełnianiem egzaminów próbnych.
Jeszcze parę słów o treści sylabusa Certified Tester Foundation Level Extension Syllabus Agile Tester. Widać bardzo wyraźnie, że osoby o różnej wiedzy i doświadczeniu pisały poszczególne działy. Mamy tutaj bardzo widoczny zakres wiedzy i doświadczenia autorów od rozumienia Agile jako mini-waterfalli do bardzo dobrego rozumienia szczegółowych mechanizmów i praktyk. Pomimo wewnętrznych przeglądów jest to nadal widoczne w ostatniej wersji. Na przykład Retrospective i Continuous Integration jest dużo lepszej jakości niż opis metod Agile. Można powiedzieć, że metody, które określają pewne ramy pracy testera zostały potraktowane po macoszemu i ich opisy są mylące. Praktyki XP są pominięte. Opis Scrum jest wyssany z palca i sprzeczny z tym co jest w Scrum Guide. Oczywiście polecam uzupełnić wiedzę korzystając z mojej książki o Scrum i Agile. Reszta materiału ma swoje wzloty i upadki, ale o tym opowiem bardziej szczegółowo w kolejnych paragrafach.
Szczegóły Agile Testera
Zakres ISTQB Certified Tester Foundation Level Extension Syllabus Agile Tester
Najpierw w ręce wpadła mi beta tego dokumentu z 28 marca 2014 oznaczona jako 1.0 GA version i muszę przyznać, że wersja udostępniona publicznie jako Syllabus 2014, z 31 maja 2014 jest lepszej jakości i zawiera mniej błędów merytorycznych. Na przykład zniknął zapis o przypisywaniu zadań do osób na planowaniu. Nie można też już znaleźć stwierdzenia, że jedna User Story może dotyczyć API, a druga GUI, co oczywiście jest sprzeczne z dostarczaniem wartości biznesowej i dzieleniem User story zgodnie z zasadą tortu weselnego. Zniknęło też zdanie stwierdzające, że BDD to nie jest Acceptance Test Driven Development. Nie skupiajmy się może na głupotach, które zostały skorygowane, ale spójrzmy na te, które zostały.
Sylabus ISTQB zakłada, że w Agile muszą być User Story i to jest jedyny słuszny sposób zapisywania wymagań. Jest to może najpopularniejsza metoda w środowisku Agile, ale na tym poziomie trzymałbym się bardziej ogólnego stwierdzenia.
Czas na kilka konkretów z dokumentu.
“The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum.”
Daily Scrum to nie jest spotkanie statusowe, ale planowanie kolejnego dnia przez Development Team.
“Since the Scrum team, not the product owner”
A od kiedy PO nie jest częścią Scrum Team?
“Scrum Master: […] resolves any violations”
Scrum Master rozwiązuje pogwałcenia zasad? Pierwszy raz widzę takie określenie. ISTQB stwierdziło też, że Scrum Master to coach Zespołu, a przecież jego rola jest znacznie szersza.
“Iterations or sprints are optional in Kanban.”
Jaka jest różnica pomiędzy iteracją a Sprintem? Żadna. Sprint to nazwa iteracji w Scrumie.
“An Agile team considers a task finished when a set of acceptance criteria have been satisfied.”
Nie task, tylko User Story
“While Scrum, in theory, does not allow changes to the user stories after iteration planning, in practice such changes sometimes occur.”
A gdzie to niby jest napisane? Właśnie, że zakres Sprintu może być nadal negocjowany z Product Ownerem w miarę, jak Zespół Developerski wykonuje pracę.
“For example, unit tests may be run each time new software is checked in, while the longer functional tests are run only every few days.”
Nieprawda. Wszystkie testy powinny być uruchamiane przynajmniej raz dziennie w Continuous Integration.
Rozdział “2.1.5 Organizational Options for Independent Testing” określam jako totalny BS i kurczowe trzymanie się tego co ISTQB mówiło w Foundation. Jak Zespół pracujący w Agile może dostarczać Potentially Shipable Increment, jeśli nie ma testerów? Jak można mówić o samowystarczalnym Zespole Scrum, jeśli zależy od zewnętrznego zespołu testerów? Gdzie nieformalna komunikacja w 4 oczy? Każda osoba, która rozumie cykl Tuckmana, czyli jak zachodzi budowanie zespołów, wie, że nie można przypisywać testerów ze Sprintu na Sprint. Należy zauważyć również, że Velocity będzie nieprzewidywalna i nie będzie nadawała się do planowania.
W dalszej części sylabusa jest podane uzasadnienie:
“Agile organizations may encounter some test-related organizational risks:
- Testers work so closely to developers that they lose the appropriate tester mindset
- Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within
the team
- Testers cannot keep pace with the incoming changes in time-constrained iterations”
Tak, jasne, przestaną traktować swoją pracę profesjonalnie i przestaną być transparentni, bo siedzą z developerami. Sorry, ale nie kupuję tych bzdur.
“Testers in Agile teams utilize various methods to record test progress and status, including test automation results, progression of test tasks and stories on the Agile task board, and burndown charts showing the team’s progress. These can then be communicated to the rest of the team using media such as wiki dashboards and dashboard-style emails, as well as verbally during stand-up meetings.”
Jakie dashboard-style emails? Po co to komu? KOMUNIKACJA W CZTERY OCZY!
W “3.1.4 The Role of a Tester” stosowane są określenia Scrum i Sprint zamiast Agile i Iteration.
Each test level has its own definition of done. The following list gives examples that may be relevant for the different test levels.
To jest raczej niefortunne sformułowanie. Zespół z przedstawicielem Biznesu ustala jedno Definition of Done, które obowiązuje dla wszystkich elementów Product Backlog dostarczanych przez Zespół.
“Feature
The definition of done for features, which may span multiple user stories or epics, may include:”
Że niby że Feature jest czymś nadrzędnym do Epic albo User Story? Nie mam pojęcia skąd to zostało zaczerpnięte.
Podsumowanie
Czy da się powiedzieć coś więcej oprócz stwierdzonego na początku nihil novi? Chyba zgodzisz się ze mną, że to dobrze, że ISTQB dostrzegło Agile i chce pomóc testerom odnaleźć się w świecie metod zwinnych osadzając dotychczasową wiedzę z poziomu ISTQB Certified Tester Foundation Level w nowym kontekście oraz łącząc pomysły Janet Gregory, Lisy Crispin i Gojko Adzica. Widzę jednak duże pole do interpretacji i popisu dla trenerów dostarczających szkolenie, jak i dla osób, które samodzielnie chciałyby się nauczyć o testowaniu w Agile czytając sylabusa. Jeśli trener nie będzie miał porządnego doświadczenia w organizacjach, które naprawdę są Agile, to tak przeszkoleni Agile Testerzy będą pasowali do reszty zespołu jak świni siodło. Błędy merytoryczne i nieścisłości powinny zostać jak najszybciej poprawione. Zastanawia mnie czy w kontekście pojawienia się dodatku Agile Tester zmienione zostaną też odpowiednio sylabusy do poziomów Advanced. Zdaje sobie sprawę, że moje sceptyczne podejście do tego dodatku nie osłabi zapędów organizacji do wysłania testerów na to szkolenie, ale może przynajmniej będzie jakaś świadomość jakości treści.
Krystian
Całkiem ciekawy wpis i na pewno warty zanotowania głos w dyskusji. Przy czym nie ustrzegłeś się “błędów merytorycznych” (sorry za uszczypliwość ale nie mogłem się powstrzymać obiecuje ostatnia ;) ).
Zacznę od rzeczy dot. SJSI:
— zobacz widzisz tak w autorach jakieś polskie nazwisko: http://sjsi.org/wp-content/uploads/2014/10/Certyfikowany-tester-zwinny-Sylabus-wersja-2014-PL.pdf (Beata nie reprezentuje Polski ;) ) innymi słowy SJSI nie współtworzyło tego dokumentu a jedynie go tłumaczyło zgodnie z naszą misją
— mówisz cyt.:“jeden z członków”? hmm obecnie jest ok 30 osób z całej polski rozumiem, że ten jeden reprezentuje tych wszystkich ludzi? nawet jakby był z zarządu to nie może tego robić bo SJSI jest cyt.“platformą wymiany doświadczeń” to z naszej misji. Innymi słowy każdy członków ma swoje zdanie, swoje doświadczenia i ma możliwość wypowiedzenia się i wysłuchania w i poza stowarzyszeniem
TestWarez:
— pamiętam Twoją prezentację z TW2010, była na prawdę ciekawa, szkoda, że nie wróciłeś już później do nas, jakby co zapraszamy.
Podsumowanie:
Jak dla mnie idealnie, jakbyś zaczął swój artykuł od podtytułu szczegóły to bo były fajne konkrety na które można by podyskutować. Wcześniejsze uwagi były mocno subiektywne i jak widzisz nie do końca prawdziwe. Tym nie mniej fajna lektura, jak dla mnie z gatunku wyznaję ortodoksyjnie agile czy też dopuszczam odstępstwa.
Sebastian,
Przede wszystkim dziękuję za komentarz. Doceniam czas jaki poświęciłeś.
Blogi maja już to do siebie, że są subiektywne. Nie sądzę, że moja opinia na temat wyssania z palca opisu Scrum jest tylko subiektywna. Więc i w tej części tekstu jest kilka argumentów merytorycznych. Ale jak rozumiem wolałbyś je pominąć. ;)
Co do SJSI, to wyraźnie piszę o zespole tłumaczącym. Byłeś na mojej prezentacji, więc wiesz, kto rzucił zgryźliwą uwagę. To, że go nie wymieniam z nazwiska, to przez grzeczność. Grzeczność nie jest błędem merytorycznym. I jeżeli SJSI jest oficjalnie organizacją reprezentującą ISTQB w Polsce, to podpisuje się pod poglądami ISTQB. Tak zresztą było to podkreślane w wielu naszych kontaktach. I dalej, jeżeli na oficjalnej imprezie SJSI ktoś przedstawia się jako reprezentant SJSI, to reprezentuje poglądy SJSI. Negatywne komentarze i przekręcanie Agile nie padały tylko przy tej okazji, ale także innych. Znowu z grzeczności nie napisze jak i gdzie.
Co do dyskusji merytorycznych. Nie jest to kwestia ortodox czy nie. Syllabus reprezentuje wiedzę, która powinna wynikać ze źródeł w nim wymienionych. Zatem jest to czysta merytoryka, z którą nie można dyskutować. ISTQB daje syllabus jako materiał do nauki na kursach i jako wiedzę, z której egzaminuje. W swojej wypowiedzi próbujesz odciąć SJSI od tego syllabusa jak i sugerujesz, że ten syllabus to tylko z zbiór opinii ludzi wymienionych jako autorzy. Moim zdaniem to coś więcej niż wpis na blogu. To dokument, który wpływa na poglądy i opinie ludzi oraz wyznacza standardy pracy, które wpłyną na jakość pracy i jakość produktów tej pracy. Syllabus określa czym jest Agile Testing, w czym nie jest. To bardzo duża odpowiedzialność. Herezje i babole merytoryczne nie powinny mieć miejsca i do pracy nad czymś takim powinni zostać zaproszeni experci merytoryczni z dziedziny Agile. Jestem pewien, że więcej dyskusji stoczyłem z Jeffem Sutherlandem, Kenem Schwaberem, Mike’em Cohnem, Ronnem Jeffries, Janet Gregory i innymi przy pisaniu swoich książek niż autorzy tego syllabusa.