blog.testowka.pl

Jakiś czas temu skontaktował się ze mną Krystian Kaczor z ciekawą propozycją – wymiany postami na naszych blogach. Po wstępnej analizie tego co Krysitan ma u siebie na blogu doszedłem do wniosku, że w wielu aspektach dotyczących zarządzania projektami oraz testowania mamy bardzo podobne zdanie więc nie pozostało mi nic innego jak tylko zgodzić się na propozycję Krystiana. Efekt poniżej.

Gra w golfa a Scrum

Tytuł tego artykułu przyciągnął Twoją uwagę i obiecuję, że się nie rozczarujesz. Najpierw zarysuje krótki wstęp, a potem dowiesz się ile ogólnych zasad takich jak te z gry w golfa możesz zastosować na swoim projekcie. Proszę o chwilkę cierpliwości.

Wprowadzenie

Kolega z zespołu zaczął grać w golfa. Niespodziewanie okazuje się, że to przestał być drogi sport i nie potrzeba być członkiem klubu. Oczywiście do golfa trzeba mieć partnera, więc kolega zaczął namawiać mnie do towarzyszenia w jego ćwiczeniach. Okazało się, że uderzenie piłki wcale nie jest takie łatwe, a kontrola jej lotu to już wyższy poziom wtajemniczenia. Często rozmawiamy na ten temat i ostatnio zaskoczyły mnie dwie wskazówki przekazane przez jednego z trenerów.

2 uniwersalne wskazówki, które wykorzystasz w Scrum

• “Nie skupiaj się na piłce, tylko na uderzeniu (tzw. swing). Piłka jest tylko wskaźnikiem. Piłka Ci pokaże jak na prawdę uderzyłeś.”
• “Gdybyś nie widział przeszkody wodnej, posłałbyś piłkę dalej bez żadnego wysiłku.”

#1 Nie skupiaj się na piłce

To jest blog o projektach prowadzonych przy użyciu metod zwinnych, o projektach agile. Czasami poruszam też temat testowania oprogramowania i agile testing. Pytasz pewnie siebie “Co ma z tym wspólnego golf?”

Spójrzmy najpierw na pierwszą radę, w skrócie “Nie skupiaj się na piłce”. Jeżeli dobrze opanujesz uderzenie, nie będziesz musiał skupiać się na piłce, bo zawsze uderzysz tak samo i będziesz wiedział gdzie piłka powinna polecieć. Kontrolując obrót ciała i układ rąk, wiesz gdzie znajdzie się kij w decydującym momencie. Piłka tylko pokaże, jak wykonałeś ruch i oceniłeś warunki środowiska. Skup się, bądź tu i teraz i wykonaj uderzenie jak najlepiej potrafisz. Często początkujący gracze skupiają się na tym, żeby “przyłożyć” w piłkę jak najsilniej. Czasem trafią, czasem nie, ale na pewno nie potrafią posłać piłki dwa razy w to samo miejsce.
Czy nie jest tak samo z Sprint Burndown? Spójrzmy na powszechne błędy.

• Często zespoły, zwłaszcza te wdrażające Scrum skupiają się na idealnym Sprint Burndown.
• Project Manager albo Scrum Master naciskają na członków zespołu, żeby zaniżyli ilość oszacowanej pracy dla zadania.
• Nowe zadania i zgłaszane defekty nie mają estymat, bo przecież to może zepsuć wykres Sprint
• Zapomina się o koncepcji “ideal day” i oczekuje się rejestrowana 8 godzin pracy w zadaniach każdego dnia. Bo przecież “za 8 godzin im płacimy” i pojemność Sprintu została określona poprzez pomnożenie ilości dni roboczych w Sprincie przez 8h.

No i czasem uda się, że te dwie linie Sprint Burndown i Ideal Sprint Burndown spotkają się na koniec Sprintu. Ale jednak Product Owner nie będzie zadowolony, wyjdzie na jaw kilka defektów, kilka niedokończonych zadań i w kolejnym Sprincie Burndown będzie wyglądał dużo gorzej. A może Sprint Burndown zejdzie do zera, a część zadań nie będzie DONE. Dlaczego? Bo skupiasz się na piłce a nie na technice. Jeżeli nauczysz się dobrze planować i szacować oraz pozwolisz zespołowi zorganizować prace, to Sprint Burndown będzie to obrazował. Sprint Burndown to tylko wykres i nie jest celem sam w sobie. Jest tylko narzędziem. Tak samo jak piłka pokazuje Ci jak uderzyłeś, tak Sprint Burndown pokazuje Ci jak Zespół oszacował zadania i jak idzie ich wykonywanie. Te same zasady dotyczą drugiego burndownu, Release Burndown.

#2 Skup się na celu, nie na przeszkodach

Jak zapewne orientujesz się na polu golfowym są umieszczone przeszkody takie jak piasek czy woda. Trzeba je pokonać na drodze do dołka. Często gracz tak bardzo skupia się na tym, żeby nie trafić w przeszkodę, że w końcu w nią trafia. To może mieć podstawy w jednym z podstawowych założeń NLP – mózg nie rozpoznaje słowa “nie”. Jest ono sztuczne i nie ma przypisanego obrazu, filmu dźwięku itd., które by określały co to jest “nie”. Dlatego jeżeli napiszę: “Nie wyobrażaj sobie zielonego ogra pożerającego autobus”, to pewnie właśnie zrobiłeś na odwrót. Fakt jest taki, że początkujący gracz wybija piłkę na odległość przynajmniej 80 metrów. Woda jest 50 metrów przed nim, więc ma 30 metrów zapasu. Wystarczy skupić się na dołku i piłka nie wpadnie do wody.
Na projektach agile czasem skupiamy się na przeszkodach, zamiast na celu. Skupiamy się, żeby:

• nie mieć żadnych defektów,
• zautomatyzować wszystkie przypadki testowe,
• architektura była jak najbardziej elastyczna,
• interfejs użytkownika był doskonały

i w efekcie mamy nieudany Sprint.
Często początkujące zespoły dopada bezlitosne prawo Parkinsona, które w skrócie polega na tym, że na wykonanie zadania zużyjesz tyle czasu, ile masz dostępne. Bardzo dobrze widać to przy każdego rodzaju pracach zaliczeniowych. Student odda pracę dopiero przy końcu terminu, a nawet wykona tę pracę dopiero blisko terminu, albo dołoży różne, nie wymagane w specyfikacji, żeby wypełnić czas. Kolejnym z powszechnych błędów jest realizowanie łatwiejszych zadań na początku i odkładanie tych trudniejszy, mniej przyjemnych na później, nazywa się to zjawisko prokrastynacją. W efekcie dochodzi sytuacji, że odkładana zadania okazują się trudniejsze niż przewidziano, albo powodują pewne problemy, których rozwiązanie wymaga czasu, którego na koniec Sprintu już nie mamy.

Jak sobie z tym radzić? Skupiaj się na celu. Skup się na zrealizowaniu celu Sprintu, gola i dostarczeniu wartości biznesowej. Omijanie przeszkód i rozwiązywanie problemów jest częścią gry i przyjdzie Ci naturalnie, kiedy pamiętasz co chcesz osiągnąć.

“What do you mean Agile?” usłyszałem pół roku temu na rozmowie rekrutacyjnej w firmie w której obecnie pracuje.Agile – zwinny, elastyczny… Jak właściwie mamy rozumieć pojęcie Agile? Czy Agile to brak dokumentacji, brak ustalonych reguł, iteracyjny model wytwarzania oprogramowania, a może to tylko idealistyczny ruch społeczny? Wielu ludzi używa pojęcia Agile ale to słowo samo w sobie nie ma konkretnej definicji.

Spróbujmy może sięgnąć do historii. Pierwszych wzmianek o Agile (lub tym co właściwiej się pod tym pojęciem kryje) możemy doszukać się już w latach 60tych ubiegłego wieku w kontekście przyrostowego modelu wytwarzania oprogramowania. Wzrost popularności i uznanie Agile  jako pełnoprawnej metodyki zarządzania projektami są niewątpliwie powiązane z ogłoszeniem Manifestu Agile w 2001 roku kiedy to czołowi przedstawiciele takich metodyk jak  Scrum, Crystal Clear, Extreeme Programming, spotkali się by na podstawie swych doświadczeń sformułować cztery podstawowe zasady Agile:

1. Ludzie i interakcje ponad procedury i narzędzia.
2. Działające oprogramowanie ponad obszerną dokumentację.
3. Współpraca z klientem ponad negocjację kontraktów.
4. Reagowanie na zmiany ponad podążanie według ściśle ustalonego planu.

Oprócz powyższych filarów manifestu agile sformułowane zostało 12 dodatkowych zasad:

• Zadowolenie klienta szybkie dostarczanie użytecznego oprogramowania.
• Otwartość na zmianę wymagań nawet w późnej fazie developmentu.
• Częste dostawy działającego oprogramowania.
• Działające oprogramowanie jest podstawową miarą postępu projektu.
• Stałe tempo rozwoju oprogramowania.
• Bliska współpraca pomiędzy klientem a zespołem.
• Bezpośrednie rozmowy są najlepszym sposobem wymiany informacji.
• Projekt jest budowany wokół wysoce zmotywowanego,  godnego zaufania zespołu.
• Ciągłe poświęcanie uwagi wysokiej jakości kodu i odpowiedniemu projektowaniu.
• Prostota.
• Samo-organizujące się zespoły
• Regularne dostosowywanie się do zmieniających się okoliczności.

Niemniej jednak powyższe zasady nadal mogą być różnie interpretowane i pozostawiają wiele pola do manewru dla tych, którzy chcieli by się do ruchu Zwinnego Wytwarzania Oprogramowania przyłączyć. Nie ma żadnych zasad przystąpienia do tego ‘elitarnego’ klubu użytkowników Agile – wystarczy się zdeklarować, że powyższe zasady nie są nam obce i staramy się ich przestrzegać w naszej codziennej pracy. Czy to dobrze? Z jednej strony tak – im nas więcej tym lepiej, tym więcej ciekawych pomysłów i rozwiązań, niemniej jednak takie rozproszenie często prowadzi do powstawania ‘potworków’ opartych na zasadach Agile, które niestety próbują się zaadoptować do abstrakcyjnych sytuacji w których nie mają racji bytu.

Zatem co ja mam na myśli, gdy mówię Agile?

Moja interpretacja czterech filarów Agile wygląda następująco:

Ludzie i interakcje ponad procedury i narzędzia. Dla mnie Agile to przede wszystkim ludzie – dobrze zmotywowany zespół ekspertów (lub ludzi którzy dążą do tego by stać się ekspertami), dla którego jakość ma znaczenie, ludzie którzy znają wartość dobrego projektowania, ludzie dla których komunikacja i przekazywanie informacji jest podstawą udanej współpracy, ludzie którzy dobrowolnie biorą odpowiedzialność za to co robią i zdają sobie sprawę z konsekwencji decyzji, które podejmuj, ludzie którzy potrafią także rozmawiać z klientem, samodzielnie uzyskiwać potrzebne informacje, ludzie którzy potrafią zorganizować swoją pracę i współpracę. Procedury, narzędzia, metodyki, proces – czemu nie, ale to ludzie stanowią podstawę. Agile nie wyklucza narzędzi czy procesów, wręcz przeciwnie, XP, Scrum, czy Crystal Clear mają ściśle określone zasady, których przestrzeganie jest wskazane. Jeśli decydujemy się na używanie jakiejś metodyki czy narzędzia – np. Scrum, musimy pamiętać o tym, by używać jej zgodnie z ściśle określonym planem, używać go w celu do którego została stworzona, nie tworzyć potworków, które nie są sprawdzone i mogą doprowadzić do kalectwa procesu, takie postępowanie może wręcz zniechęcić do używania narzędzia czy nawet do samego Zwinnego Wytwarzania Oprogramowania. Po co wynajdywać koło od nowa, skoro można korzystać z tego co zostało już dosyć dobrze sprawdzone i działa.

Działające oprogramowanie ponad obszerną dokumentację. Będę Szczery- czytam dokumentację projektową tylko w ostateczności, uważam to za stratę czasu, jeśli tylko mam dostęp do osoby która daną dokumentację pisała to w pierwszej kolejności wolę porozmawiać i uzyskać potrzebne mi informację bezpośrednio u źródło. Dosyć często już podczas takich rozmów znajdujemy błędy w założeniach (często już zaimplementowane) bez odpalania komputera. Uważam, że efektywność jest nieporównanie większa niż gdybym musiał przedzierać się przez czasem kilkadziesiąt stron dokumentów. Nie mówię, że cała dokumentacja jest zła – warto dokumentować niestandardowe rozwiązania, nowe technologie, albo przynajmniej gromadzić w jednym miejscu referencje do informacji na ich temat. Niewątpliwą zaletą dokumentacji jest to iż wraz z odejściem pracowników wiedza nie ginie. Niemniej jednak utrzymanie aktualnej dokumentacji może nawet przewyższyć koszty samego wytworzenia oprogramowania. Jeśli dbamy o jakość kodu, o to by był jak najbardziej czytelny, o to by stosowane były znane powszechnie wzorce projektowe to nie musimy się martwić o dokumentację – dobrze napisany kod sam się dokumentuje, a testy jednostkowe/funkcjonalne/integracyjne stanowią dokumentację funkcjonalną.

Współpraca z klientem ponad negocjację kontraktów. Agile opiera się na zaufaniu klienta do firmy, zaufaniu managera do zespołu, zaufaniu członków zespołu do siebie na wzajem. Stosy dokumentacji projektowej zawartej w załącznikach do kontraktów stają się niepotrzebne, gdy klient ma pewność tego, że funkcjonalność, której potrzebuje zostanie rzetelnie wyceniona i zaimplementowana z gwarancją wysokiej jakości. Ponadto klient zyskuje możliwość wpływania na projekt w trakcie jego trwania – może nawet zmieniać wymagania. Nie ustala się ceny z góry, co najwyżej obie strony ustalają dopuszczalne widełki. Idealnie do tego typu projektów sprawdza się Scrum, w którym można określić stałą cenę za sprint. Niemniej jednak jak wspomniałem wyżej tutaj też podstawą jest zaufanie.

Reagowanie na zmiany ponad podążanie za ścisłym planem. Szczegółowe planowanie przed rozpoczęciem projektu to strata czasu. Nie jesteśmy w stanie zaplanować szczegółowo przebiegu projektu. Nie możemy przewidzieć interakcji ze światem zewnętrznym, które mogą mieć wpływ na projekt. Niemniej jednak Agile nie odrzuca całkowicie planowania! Dużo bardziej efektywne okazuje się częste planowanie w krótkich etapów projektu – iteracji/sprintów. Dzięki krótszym okresom czasu możemy dokładniej przewidzieć to co się wydarzy – nikt nie jest w stanie dokładnie określić co będzie robił za pół roku, dużo łatwiej jest nam powiedzieć czym będziemy się zajmować za tydzień, a jeszcze łatwiej co planujemy na dzisiaj. Dlatego idealnie sprawdzają się codzienne spotkania typu stand-up, które pozwalają na szczegółowe zaplanowanie pracy w najbliższym dniu, oraz rozliczenie samego siebie z zadań wykonanych od ostatniego spotkania, ponadto jest to świetna okazja do wymiany informacji pozwalająca na bardzo wczesne reagowanie na zmiany zachodzące wokół nas. Możecie mi wierzyć lub nie ale WYMAGANIA SIĘ ZMIENIAJĄ, nie da się zaplanować wszystkiego z góry, dlatego warto korzystać z mechanizmów pozwalających na szybką reakcję.

Dla mnie powyższe zasady są pewną podstawą wokół której możemy dalej rozwijać nasz proces wytwarzania oprogramowania. Agile nie odrzuca wszystkiego innego, z moich doświadczeń wynika że np. idealnie ze zwinnym wytwarzaniem oprogramowania sprawdza się stosowanie wykresów Gant’a czy ustalanie ścieżek krytycznych, albo stosowanie wzorów optymalizacyjnych dla szeregów produkcji. Dodając do tego Continous Improvement możemy osiągnąć na prawdę wiele, niemniej jednak należy pamiętać o tym by zapewnić sobie dobry start do wprowadzania zmian, ale o tym może innym razem.

A Ty co masz na myśli, gdy mówisz “Agile”?

Zapraszam na webinarium które poprowadzę w najbliższą środę (20-10-2010) o godzinie 13.00 w ramach cyklicznych e-seminariów Polskiej Grupy Scrum.

Zapisy na www.scrum.org.pl.

Temat spotkania ponownie związany z automatyzacją testów. Postaram się przybliżyć samą idee automatyzacji oraz zademonstrować kilka dobrych praktyk ułatwiających życie każdego testera. Nie zabraknie również rozwinięcia podstawowych zasad Continous Integration, oraz wskazówek jak testować w projektach Agile’owych.

Zgodnie z informacjami napływającymi z Scrum Alliance oraz Scrum.org Scrum Allicane odebrał Kenowi Schwaberowi Tytuł “Certified Scrum Trainter” co uniemożliwia mu przyznawanie certyfikatów sygnowanych przez Scrum Alliance w tym także CSM. Sytuacja jest o tyle paradoksalna, że to Ken Schwaber utworzył program tej ścieżki certyfikacyjnej. Powodem powyższej decyzji było złamanie przez pana Schwabera jednego z podpunktów umowy CST, który mówi o tym, że będąc trenerem Scrum Alliance nie wolno przeprowadzać szkoleń scumowych nieakredytowanych przez tą organizację. Ken złamał regulamin tworząc nową ścieżkę certyfikacji Professional Scrum Master – Scrum in Depth.

Szkolenie Scrum In Depth zostało utworzone przez Kena głównie po to by wyróżnić osoby posiadające zaawansowaną wiedzę z dziedziny SCRUM, którą nabędą podczas tego szkolenia oraz praktyki/samodzielnej nauki. Kolejnym powodem była ogólna opinia na rynku mówiąca o tym, że certyfikaty CSM tracą na znaczeniu przez to, iż nie wymagały zdawania żadnego egzaminu (obecnie samo przystąpienie do egzaminu CSM już uprawnia do otrzymania tego certyfikatu).

Po szkoleniu Scrum in Depth uczestnicy przystępują do zdawania egzaminu Professional Scrum Master I (który z założenia jest trudniejszy od CSM oraz faktycznie poświadcza o posiadaniu konkretnej wiedzy z dziedziny SCRUM i Agile). Jego zdanie (wynik powyżej 80%)  oznacza przyznanie certyfikatu Professional Scrum Master I. Szkolenie Scrum in Depth oraz zdanie egzaminu PSM I otwierają drogę do dalszej ścieżki certyfikacyjnej sygnowanej przez Scrum.org. Po odbyciu szkolenia i zdaniu egzaminu PSM I każdy uczestnik może przystąpić do egzaminu PSM II.

Ścieżkę egzaminacyjną Professional Scrum Master możemy uznać za równoległą do ścieżki CSM, z tym jednak wyjątkiem, że certyfikaty PSM wymagają ZDANIA trudniejszych egzaminów dzięki czemu mają większe znaczenie na rynku i nie każdy może taki certyfikat otrzymać. Certyfikat PSM II można uznać za równoznaczny z CSP (Certyfied Scrum Practitioner) z Scrum Alliance. Po zdaniu tych dwóch egzaminów istnieje możliwość stania się trenerem Scrum in Depth, wymaga to pozytywnego rozpatrzenia podania przez Kena Schwabera i spełnienia kilku indywidualnie wyznaczanych przez Kena warunków.

Przypomnę może jeszcze jak wygląda ścieżka certyfikacji Scrum Alliance:
Obecnie uczestnicy kończąc szkolenie i przystępując do egzaminu (obecnie wszyscy którzy do niego przystąpią automatycznie go zdają bez względu na wynik) otrzymują certyfikat CSM (Certyfied Scrum Master). Po pewnym okresie czasu (obecnie jest to chyba conajmniej rok) posiadacze CSM mogą ubiegać się o przyznanie certyfikatu CSP (Certyfied Scrum Practitioner) który dostaną na podstawie pozytywnej opinii komisji Scrum Alliance. Po uzyskaniu CSM, CSP, oraz CSPO (Certified Scrum Product Owner) można się ubiegać o nadanie tytułu CST (Certified Scrum Trainer) albo CSC (Certified Scrum Coach), niemniej jednak zasady przyznawania tych tytułów i uprawnień są bardzo płynne i ich spełnienie wymaga posiadania szerokich znajomości wśród wysoko postawionych członków Scrum Alliance oraz innych trenerów, co także było powodem utworzenia oddzielnej ścieżki przez Kena Schwabera. Utrzymanie tych certyfikatów wymaga corocznego uiszczenia opłaty oraz zdawania egzaminów.

Miło mi poinformować, że wśród trenerów Professional Scrum Master znalazł się także Andy Brandt z Code Sprinters.

Scrum to nie filozofia, to nie religia, nawet nie metodologia – to tylko proste narzędzie. Zauważyłem, że wielu ludzi próbuje uczynić ze Scruma jakąś metodologię do wszystkiego. Moim zdaniem Scrum powstał dlatego, że niektórzy mieli już dosyć sformalizowanych metodologii. Miał z założenia być prostym narzędziem oferującym kilka artefaktów, a wszystko inne miało zależeć od wizji i potrzeb użytkowników. Wspomniane artefakty to Backlog, Iteracje, Daily Scrum, Burndown Chart, Scrum Master oraz Product Owner (chyba o niczym istotnym nie zapomniałem). Wszystko inne powstało na potrzeby konkretnych projektów/użytkowników. Scrum miał być narzędziem dla każdego, narzędziem które miało być kompatybilne z różnymi metodologiami i narzędziami.

Dlaczego Scrum staje się rozbudowaną, coraz mniej zrozumiałą metodologią? Wielu użytkowników Scruma z powodzeniem zastosowała go wraz z innymi rozwiązaniami z pod znaku Agile i nie tylko, po czym próbowali swoje sukcesy i spostrzeżenia jak najbardziej uogólnić i przekazać innym. Niemniej jednak to co z tego powstało nie nazwał bym już Scrumem samym w sobie, Scrumem – narzędziem, tylko raczej Scrumem metodologią opartą o Scrum jako narzędzie, a wzbogaconą o wiele artefaktów i rozwiązań z innych metodologii i narzędzi. Należy zatem rozróżniać Scrum od wszystkiego co Scrumopochodne co możemy znaleźć w wielu często interesujących publikacjach i na wielu szkoleniach/konferencjach.

Owszem, takie rozwiązania są często bardzo wartościowe, niemniej jednak zanim wprowadzi się je w życie należy się zastanowić czy na prawdę tego potrzebujemy. Czasem warto stosować sprawdzone wcześniej przez innych rozwiązania, lecz czasem warto też wrócić do korzeni, do podstaw i na nich zbudować własny framework scrumowy idealnie dopasowany do projektu, zespołu oraz warunków.

Scrum Master to praca na pełny etat właśnie dlatego, że jednym z zadani mistrza młyna jest rozwijanie metodologii i eksperymentowanie z nowymi narzędziami by jak najbardziej zwiększyć wydajności i jakość pracy. Ale o tej konkretnie roli Scrum Mastera może innym razem.

I oto nadeszła ta wiekopomna chwila – nasze (Code Sprinters) autorskie narzędzie do zarządzania projektami w metodyce Scrum – Banana Scrum deczekało się wersji 2.0!

Banana Scrum to narzędzie w pełni przystosowane do wymogów Scrum. Aplikacja ta jest idealnym narzędziem nie tylko dla doświadczonych zespołów scrumowych ale także dla tych początkujących. Przejrzystość oraz nazewnictwo zgodne nomenklaturą Scrum pozwalają bardzo szybko poprzez praktykę przyswoić podstawowe zasady Scrum. Oprócz podstawowych funkcjonalności jak Pruduct Backlog, Sprint Backlog, Sprint Planning posiada ono także kilka innych bardzo przydatnych ficzerów jak na przykład Timeline View – ekran, który pozwala w bardzo przystępny sposób zobrazować dotychczasowy przebieg prac nad projektem, a także rozplanować w czasie przyszłe zadania. Do tego wszystkiego za jeden z killer ficzerów można śmiało uznać synchronizacje działań użytkowników w czasie rzeczywistym – zmiany przez nich dokonywane są od razu widoczne na ekranach pozostałych użytkowników – jest to niezwykle przydatne podczas pracy w rozproszonych zespołach.

Jako współtwórca tego narzędzi i pasjonat zwinnych metodologii muszę nieskromnie stwierdzić, że wykonaliśmy kawał dobrej roboty

Co tu dużo pisać – zapraszam do przeglądania wersji demonstracyjnej: demo.bananascrum.com.

W Scrumie istnieją trzy podstawowe role: Członek Zespołu (Team Member), Właściciel Produktu (Product Owner) i Mistrz Scruma (Scrum Master). To właśnie rola tego ostatniego jest najczęściej uważana za najistotniejszą (szczerze nie jestem do końca przekonany czy słusznie).

Należało by się zastanowić czym taki Scrum Master powinien się zajmować. Według mnie taka osoba ma dwa podstawowe zadania:

1. Dbanie o przestrzeganie zasad ustalonych przez zespół.
2. Wsparcie prac zespołu i zapewnienie mu odpowiednich warunków do pracy.

W nawiązaniu do pierwszego podpunktu trzeba pamiętać o kilku podstawowych zasadach narzucanych przez Scruma samego w sobie, po pierwsze zespół jest samo-organizujący się. To zespół ustala zasady, jakie zamierza stosować. Scrum Master nie może narzucać swoich zasad, co najwyżej może proponować na podstawie obserwacji pewne udoskonalenia lub zmiany, ale musi się to spotkać z aprobatą reszty zespołu by można było je wdrożyć. Właśnie tutaj Mistrz Scruma musi wykazać się nie lada zdolnościami interpersonalnymi by zachowując odpowiedni dystansł wymóc na zespole stosowanie przyjętych zasad. Ponadto Scrum Master jest strażnikiem samego procesu co zobowiązuje go do nadzorowania poprawnego przestrzegania praktyk Scrumowych. W tym celu można wykorzystać Scrum Check Listę (o której może innym razem). Dobrym pomysłem jest codzienne sprawdzanie czy wszystko idzie zgodnie z planem by móc jak najwcześniej zareagować na ewentualne problemy i odstępstwa od normy.

Drugi podpunkt porusza problem znacznie trudniejszy do zdefiniowania, gdyż pojęć wsparcia zespołu i zapewnienia odpowiednich warunków nie da się odpowiednio sprecyzować. Co do wspomnianych warunków przypomina mi się pewna historia opowiedziana przez kolegę, który opowiadał o tym jak bezcenny jest widok dwóch managerów przepychających muszlę klozetową . Jest to dość skrajny przykład, niemniej jednak można by to zaliczyć do zapewniania odpowiednich warunków pracy. Bardziej realnym problemem którego rozwiązania powinien podejmować się Scrum Master jest załatwianie dostępu do odpowiednich informacji i pilnowanie klientów by nie mieszali się zbytnio w proces. Rolą Mistrza jest także wyjaśnianie wszelkich niejasności wynikających z niedoprecyzowania wymagań, a także rozwiązywanie konfliktów w zespole dotyczących np. sposobu implementacji danej funkcjonalności.

Ponadto oprócz dwóch powyższych podpunktów Mistrz Scruma powinien także potrafić obserwować zespół i jego reakcję po to by wyciągać trafne wnioski pozwalające na usprawnienie procesu i lepsze wsparcie. Ważne na przykład jest to by Scrum Master potrafił skutecznie motywować swoich współpracowników, by wiedział jakie są ich ambicję i by w miarę możliwości pozwalał im się spełniać w tym co chcą robić.

Z powyższego wynika, że nie każdy może być Scrum Masterem, a już na pewnie nie każdy może być “Dobrym Mistrzem Scruma”. By to osiągnąć trzeba umieć obserwować ludzi, ich zachowania, współprace, zależności etc. Ponadto warto posiadać podstawową wiedzę psychologiczną i socjologiczną. Warto też mieć odrobinę pojęcia na temat różnych innych metodologi zarządzania, niekoniecznie zwinnego, by móc także z nich czerpać pewne pomysły i udoskonalenia. Scrum jest na tyle elastyczny, że pozwala na pewną ewolucję. Każdy zespół może interpretować Scruma na swój sposób i za każdym razem może to być poprawne i prowadzić do sukcesów, ważne by przestrzegać podstawowych zasad. Mistrz Scruma powinien także brać czynny udział w procesie ewolucji i udoskonalania a także przestrzegać by mieścił się on w odpowiednich, bezpiecznych granicach.

Na zakończenie dodam, iż jest to wyłącznie moja subiektywna opinia i interpretacja roli Scrum Mastera w zespole powstała na bazie obserwacji i doświadczeń. W pewnym stopniu pokrywa sie to z teorią Scruma ale chyba raczej nie do końca.

Dawno, dawno temu ktoś próbował mnie usilnie przekonywać, że w ogólnym pojęciu teoria jest jedynie teorią i w praktyce sprawdza się bardzo, na prawdę bardzo rzadko. Po latach własnych życiowych i zawodowych doświadczeń odkryłem, iż teoria to nie taka głupia sprawa. Ostatecznie ktoś te teorie z jakiegoś powodu wymyślił, ktoś zanim je opublikował dokładnie wszystko sprawdził, a jeśli teoria jest popularna to oznacza to, że wielu innym udało się ją z powodzeniem wdrożyć w życie.

Ostatnio postanowiłem lepiej przyjrzeć się Scrumowi. Także w tym przypadku sprawdzają się moje wcześniejsze spostrzeżenia – jeśli chodzi o zastosowanie teorii w praktyce to aby w ogóle było to możliwe podstawowym warunkiem jest stosowanie tej teorii od początku do końca. W efektywnym wykorzystywaniu metodologii nie ma miejsca na odstępstwa od zasad. Ktoś kiedyś te zasady dokładnie opracował i przeważnie wynikają one z wielu prób i błędów. Jeśli oczywiście mamy czas i środki na to by powtarzać czyjeś błędy to czemu nie – jak najbardziej powinniśmy eksperymentować, gdyż eksperymenty to najkrótsza droga do udoskonaleń, lecz jeśli chcemy w szybki i sprawny sposób tworzyć produkty o wysokiej jakości to nie ma mowy o eksperymentowaniu. W takich przypadkach najlepiej sprawdzają się rozwiązania wypróbowane już wcześniej przez innych. Stosując daną metodologię od początku do końca zgodnie z jej wszystkimi zasadami mamy prawie stó-procentową pewność, że jeśli coś idzie nie tak jak powinno to nie jest to wina metodologii lecz jakiegoś innego czynnika – np. źle dobrany zespół, nieodpowiednia technologia.

Niestety w życiu bywa różnie, a problem pojawiają się zawsze. Bez względu na to jak mocno trzymamy się ustalonych zasad i jak dobry mamy zespół, w końcu coś pójdzie nie tak jak powinno. Nawet drobne, z początku niedostrzegalne odstępstwa od normy w dłuższym okresie czasu spiętrzają się i nawarstwiają. Na szczęście Scrum dostarcza nam odpowiednich narzędzi do walki z tym zjawiskiem – najbardziej przydatnym jest retrospekcja. W agile zmienność wymagań, założeń, środowisk etc. jest czymś zupełnie normalnym, tak samo jak problemy z niej wynikające, dlatego też w zwinnym zarządzaniu projektami należy walczyć z problemami jak najwcześniej – gdy tylko zostaną zauważone. Właśnie do wczesnego wykrywania problemów służy retrospekcja.

W retrospekcji uczestniczy cały zespół, który na osi czasu (trwania ostatniego sprintu lub kilku sprintów) zaznacza wszystko to co było lub mogło być istotne i mieć wpływ na przebieg sprintu. Jest to pewna odmiana burzy mózgów, podczas której jak sama nazwa wskazuje wyciąga się wnioski z tego co wydarzyło się w przeszłości. Ważne jest to, by wskazywać nie tylko negatywne rzeczy ale także to co było pozytywne, daje to lepszy pogląd na sytuację w zespole i pozwala na opracowanie lepszych sposobów organizacji zasobów czy motywowania. Z założenia zespół w Scrumie jest samo organizujący się i właśnie dzięki temu podczas retrospekcji jego członkowie sami dochodzą do problemów które napotkali podczas realizacji projektu, a także sami dochodzą do tego jak te problemy rozwiązać i co zrobić by nie powtarzać tych samych błędów w przyszłości. Oczywiście samo przeprowadzenie retrospekcji to nie wszystko, ważne jest by wnioski z niej wyciągnięte zostały utrwalone.

Czasem bywa tak, że wniosków jest bardzo dużo a co za tym idzie potencjalnych usprawnień procesu jest jeszcze więcej. Niestety przeważnie próba poprawienia wszystkiego “na jeden raz” ma małe szanse powodzenia. Rozwiązaniem tego problemu jest odpowiednie kategoryzowanie problemów na te poważne i mniej istotne, można to zrobić np. przy pomocy głosowania, gdzie każdy uczestnik ma do dyspozycji kilka głosów (ich liczba powinna odzwierciedlać ilość problemów, które chcemy w najbliższym czasie rozwiązać). Przy pomocy głosowania ustalamy priorytety.

Po wprowadzeniu poprawek w kolejnym sprincie warto przeprowadzić kolejną retrospekcje by sprawdzić na ile udało się poprawić proces, oraz by ustalić nowe priorytety pozostałych problemów.

Reasumując retrospekcja to narzędzie, które jeśli zostanie wykorzystane w odpowiedni sposób daje nam wiele możliwości i informacji na temat tego jak wygląda praca w naszym zespole. Można by pokusić się o jakąś głębszą psychologiczną analizę tego narzędzia i korzyści z niego płynących, lecz wydaje mi się to nie potrzebne.

Na wstępie chciałbym w skrócie przedstawić podstawowe zasady CI, a może raczej ACI (Automated Continous Integration):

Trzymaj kod w repozytorium
A nawet nie tyle trzymaj co commituj swoje zmiany jak najczęściej, dzięki temu każdy będzie miał możliwość integrowania swoich zmian z Twoimi. Do tego należy także pamiętać o tym aby także updateować jak najczęściej swoje lokalne repozytorium na którym się pracuje aby integrować swoje zmiany z najświeższymi zmianami kolegów.
Cechy dobrego repozytorium to przede wszystkim:
- przejrzysty widok ostatnich zmian
- możliwość tworzenia rozgałęzień i automatycznego łączenia ich
- system powiadomień o zmianach
- łatwa możliwość odwrócenia ostatnich zmian
Osobiście używam GIT i SVN, jak na razie obydwa spełniają większość moich oczekiwań.

Automatyzuj buildy
Buildy powinny być odpalane automatycznie. Do automatyzacji buildów polecam Hudson lub CruiseControll. Warto też wspomnieć o tym co taki build powinien robić, mianowicie powinien:
- odpalać testy jednostkowe
- odpalać inne testy (jeśli są)
- generować raporty z pokrycia kodu testami
- generować raporty z wynikami testów
- wysyłać powiadomienia, zwłaszcza gdy testy nie przechodzą
- powinien być zintegrowany ze środowiskiem RC do którego commity powinny trafiać jedynie, gdy build przechodzi
- powinien generować inne artefakty, które są w danym projekcie potrzebne.

Stosuj TDD
Tak, by to wszystko miało sens potrzebne są testy do kodu, który piszemy. Jak najwięcej testów. Najlepszą praktyką w tej dziedzinie jest TDD – pisanie testów przed napisanie właściwego kodu (ale o tym może innym razem).

Zasada nie zabierania zakiszonego kodu do domu
Każdy programista commituje przynajmniej raz dziennie. Im częściej tym lepiej.

Każdy commit odpala build
Po każdej zmianie kodu powinny być odpalane testy w celu jak najszybszego wykrycia błędów i ich poprawy,a także w celu łatwiejszego wykrycia przyczyny błędu (zazwyczaj należy jej szukać tylko w ostatnim commicie).

Utrzymuj build szybkim
Buildy powinny być jak najszybsze, by niepotrzebnie nie marnować czasu na czekanie, aż build przejdzie. Obecnie rozwiązuje się ten problem w sposób sprzętowy np stosując chmury obliczeniowe do odpalania testów.

Środowisko testowe powinno być bliźniacze do środowiska produkcyjnego
Chociażby dlatego by uniknąć błędów wynikających z różnicy w tych środowiskach.

W każdej chwili powinieneś mieć dostęp do ostatniej stabilnej wersji oprogramowania
Zgodnie ze wspomnianą zasadą Agile, w każdej chwili powinniśmy mieć pod ręką jakąś stabilną wersję oprogramowania teoretycznie gotową do publikacji.

Każdy powinien mieć dostęp do wyników buildów
Na przykład Hudson ma wbudowany ciekawy plugin, który umożliwia graficzna prezentację wyników ostatnich buildów. Tego typu aplikacje mają zazwyczaj także api, które sprzyja tworzeniu własnych rozwiązań do prezentacji efektów testów etc. My w firmie używamy właśnie Hudsona i specjalnego monitora który stojąc w widocznym dla każdego miejscu prezentuje efekty ostatnich commitów.

Automatyczny deployment
Fajny ficzer zwłaszcza w fazie maintenance projektu, gdy zmiany są dosyć często wgrywane na serwer produkcyjny. Istnieją gotowe narzędzia pozwalające na automatyczne deployowanie aplikacji.

Żeby lepiej zrozumieć na czym polega CI należało by się pierw zastanowić po co właściwie coś takiego jak Ciągła Integracja jest nam potrzebne? Najprościej będzie gdy wrócimy do jednego z podstawowych założeń zwinnego zarządzania projektami a mianowicie: “w dowolnym (odpowiednio zaawansowanym) momencie trwania projektu powinniśmy być w stanie dostarczyć ‘jakiś’ produkt, który spełnia pewne założenia i udostępnia pewną funkcjonalność, produkt ten teoretycznie powinien być gotowy do wypuszczenia na rynek”. Idąc dalej tym tropem można łatwo wywnioskować, że aby produkt był gotowy do publikacji musi spełniać pewne kryteria jakości, które powinny zostać przetestowane. By jeszcze lepiej zrozumieć potrzebę ciągłej integracji w projekcie należałoby się zastanowić nad tym w jaki sposób integrować pracę wielu programistów, którzy pracują nad często zazębiającymi się fragmentami kodu. Może aby lepiej zobrazować strukturę problemu posłużę się przykładem w którym zespół projektowy nie wykorzystuje aspektów CI.

Wyobraźmy sobie zespół składający się z pięciorga programistów i dwojga testerów. Zespół ma dostarczyć jakąś określoną aplikację, która ma trzy podstawowe funkcjonalności. Tutaj pojawia się pierwszy problem – jak podzielić pracę? Może niech każdy programista zajmie się pojedynczą funkcjonalnością, a na koniec spróbują zintegrować to wszystko ze sobą (uwierzcie mi są firmy w których taki model wytwarzania oprogramowania jest stosowany na co dzień). No tak tylko, że funkcjonalności jest 3 a programistów pięcioro. Poza tym są jeszcze testerzy, którzy przez większość czasu będą się nudzić. No dobrze – klasyczny model Waterfall zakłada, że testy powinny być przeprowadzane na końcu, więc niech tak będzie. Żeby jeszcze lepiej wszystko zobrazować dodajmy trochę matematyki. Załóżmy, że wykonanie pierwszej funkcjonalności zajmie około 30 roboczogodzin, drugiej 60 roboczogodzin, trzeciej 15 roboczogodzin. Do tego przetestowanie około 1/3 czasu potrzebnego na implementację czyli odpowiednio 10, 20, 5 roboczogodzin (dość optymistyczne, ale realne założenia). Dobrze – prace ruszyły pierwsza po 15 godzinach zostaje ukończona funkcjonalność nr 3, programista który nad nią pracował teraz odpoczywa. Po kolejnych 15 godzinach została ukończona funkcjonalność nr 1, teraz programiści mogą rozpocząć prace nad integracją funkcjonalności 1 i 3, mają na to około 30 godzin. Po 60 godzinach od rozpoczęcia projektu dostarczono funkcjonalność nr 2, którą teraz trzeba jeszcze zintegrować, na tym etapie okazuje się że popełniono kilka błędów w założeniach, czegoś nie ustalono dokładnie etc. wiec integracja potrwa kolejne 20h. W sumie po 80 godzinach pracy dostarczono produkt do testów. Testowanie wraz z poprawkami zajmie około 40h.

Po 120 godzinach pracy mamy gotowy produkt. Przypomnijmy, że dla dwóch programistów nie było pracy, ciężko jest pracować nad jednym kawałkiem kodu na dwóch różnych komputerach. Co najwyżej służyli oni jedynie pomocą swoim kolegom.

A teraz podobny przykład (ten sam problem do rozwiązania) z tym że zespół wykorzysta większość aspektów CI.

Ponieważ wiemy ile szacunkowo zajmą pracę nad każdą z funkcjonalności i wiemy, że funkcjonalność nr 2 zajmie najdłużej pracować nad nią będzie aż troje programistów, dodatkowo programista, który będzie pracował nad funkcjonalnością nr 3 po zakończeniu prac nad nią wesprze kolegę pracującego nad funkcjonalności nr 1. Praca zespołowa jest w pełni możliwa dzięki temu, że zespół korzysta z systemu kontroli wersji, który pozwala na łatwą dystrybucję najaktualniejszego kodu. Dodatkowo testerzy dzięki środowisku, które roboczo nazwiemy RC (Release Candidate) mogą w każdej chwili testować dostarczane funkcjonalności i zgłaszać błędy, które są dużo łatwiejsze do poprawienie we wcześniejszej fazie. Należy też zauważyć, że integracja całości odbywa się od samego początku, gdyż wszystkie zmiany wrzucane są do jednego repozytorium. Czas implementacji wydłuży się zapewne o około 1/3 ze względu konieczność pisania testów jednostkowych (nie jest to wymóg jeśli w zespole są testerzy, jednak dzięki temu ich praca powinna się skrócić o około połowę). Zobaczmy jak to teraz wygląda. Planowane czasy implementacji po uwzględnieniu dodatkowego pisania testów jednostkowych: F1 – 40 roboczogodzin, F2 – 80 roboczogodzin, F3 – 20 roboczogodzin. Testy: T(F1) – 7 roboczogodzin, T(F2) – 14 roboczogodzin, T(F3) – 4 roboczogodziny. Projekt startuje. Po 10 godzinach pracy rozpoczynają się testy dla funkcjonalności nr 2 (wykonuje je jeden tester). Po 16 godzinach od rozpoczęcia rozpoczynają się testy akceptacyjne dla funkcjonalności nr 3, po 20 godzinach od rozpoczęcia ta funkcjonalność jest już gotowa i przetestowana, programista, który nad nią pracował pomaga programiście pracującemu nad funkcjonalnością nr 1 (do jej ukończenia zostało 20 roboczogodzin, podzielone na dwóch daje po 10 godzin). Trzy godziny później rozpoczynają się testy funkcjonalności nr 1. Po kolejnych 7 godzinach funkcjonalność nr 1 jest ukończona i przetestowana – minęło 30 godzin od rozpoczęcia projektu. W międzyczasie po około 27 godzinach od rozpoczęcia projektu zostaje ukończona i przetestowana funkcjonalność nr 2. Wszystko powinno działać i być już zintegrowane, dla pewności testerzy sprawdzą wszystko jeszcze raz – po 8 godzin każdy.

W sumie daje nam to 38 godzin pracy nad projektem, których efektem jest gotowy, przetestowany produkt, którego dodatkowym gwarantem jakości są test jednostkowe. Dodatkowo od pewnego momentu w z środowiska RC mogliśmy pobrać stabilną – przetestowaną wersję aplikacji zapewniającą pewne funkcjonalności. To raczej znacznie lepszy wynik niż poprzednio. Powyższe założenia są trochę naciągane i wyssane z palca, ale uwierzcie mi już kilkukrotnie widziałem nawet dużo bardziej zaskakujące efekty wprowadzenia CI do procesu wytwarzania oprogramowania.

Powyższy wywód jest również pewnego rodzaju odpowiedzią na często stawiane pytanie: “Czy pisać testy jednostkowe?”. Postaram się w przyszłości poszukać (być może samemu przeprowadzić) jakichś badań na temat czasu wytwarzania oprogramowania z i bez. Ogólnie już teraz mogę wnioskując z doświadczenia jednoznacznie stwierdzić, że niemal zawsze automatyzacja testów znacząco przyspiesza pracę nad projektem, a zwłaszcza pracę w fazie maintenance.

Wiele razy słyszałem (z różnych ust), że testerzy są niepotrzebni… Muszę się z tym zgodzić… (!?)

(…teraz strzelam sobie zawodowego samobója )

Jeśli spojrzymy na współczesne metodologie wytwarzania oprogramowanie (mowa głównie o agile) możemy dostrzec zanik roli testera w projekcie. Zwykłe przeklikiwanie się przez aplikację już nie wystarcza by sprostać wymaganiom stawianym przez współczesnych klientów – aplikacje mają być w pełni modyfikowalne i rozwijalne w dowolnym kierunku (i przeważnie są wielokrotnie modyfikowane i rozwijane), popularność zyskuje nawiązanie do prototypowania, gdzie w celu sprawdzenia czy dana aplikacja/serwis zdoła przyciągnąć uwagę klientów, najpierw wypuszcza się jego okrojoną wersję w celu zdobycia informacji na temat zapotrzebowania klientów, a dopiero później rozwija się serwis w kierunku wyznaczonym przez potencjalnych klientów. Gdy w aplikacji następuje wiele częstych zmian zwykłe klikanie staje się mało opłacalne. Jeśli np. mamy  do czynienia z serwisem społecznościowym w którym zmiany są publikowane co tydzień, ilość potrzebnych testów i możliwych scenariuszy jest tak duża, że wymagane jest zatrudnianie coraz więcej testerów.

W większości zwinnych metodologi podstawą są automatyczne testy, czy to unit testy, czy testy integracyjne zasadniczo pisane przez programistów, więc gdzie tu miejsce dla testera? Oczywiście, tester przydaje się do wykonania testów akceptacyjnych, ale to tak na prawdę szybka robota w porównaniu do długości całego cyklu wytwarzania oprogramowania. Na szczęście mało kto zdaje sobie sprawę z konieczność zapewnienia odpowiedniego – maksymalnego (w granicach rozsądku) pokrycia kodu testami (o tym innym razem),  dzięki temu testerzy mają jeszcze co robić… Testy akceptacyjne, testy sprawdzające warunki odbioru produktów będą zawsze potrzebne, więc zawód testera raczej nie zaniknie, zmienią się, zostaną okrojone jedynie jego zadania i kompetencje. Może to trochę czarna wizja przyszłości niemniej jednak jest to wizja prawdopodobna.

W dobie automatyzacji w każdej dziedzinie życia, praca testera też zostanie zastąpiona przez maszyny, testy automatyczne, konkretniej funkcjonalne testy automatyczne. W przypadku aplikacji www testy mogą być wykonywane np. przy pomocy Selenium lub innych narzędzi, gdy mamy do czynienia z aplikacjami desktopowymi np. przy użyciu TestComplete…  Narzędzia tego typu jeszcze do niedawna niedoceniane coraz bardziej zyskują na popularności i zwiększa się ich ilość. Właśnie przeczytałem o czymś co nazywa się AutoIT (ale o tym też innym razem, jak już to wypróbuje). Dlatego w projektach wzrasta rola kogoś określanego mianem Iżyniera Testów, czyli osoba która potrafi programować na tyle by pisać tego typu testy i je utrzymywać, a jednocześnie posiadająca wiedzę nt testowania aplikacji na poziomie umożliwiającym projektowanie odpowiednich scenariuszy i przypadków testowych.

Jak to mówią “potrzeba matką wynalazków”, więc sygnaturka w moim firmowym mailu zmieniła się na SQA & Test Engineer.  Awans? Raczej nie, w sumie od samego początku się tym zajmowałem, ale dopiero podczas jednej z rozmów przy piwie zostało to w pewnym stopniu sprecyzowane. Cytuje Adama: “Wg mnie każdy tester powinien być także inżynierem testów” – po przemyśleniu nie pozostaje mi nic innego jak zgodzić się z tym stwierdzeniem. Podczas ciągłych zmian samo przeklikiwanie się przez aplikację już nie wystarczy, niemniej jednak same testy automatyczne nie są w stanie wszystkiego sprawdzić, a gdy ich ilość osiąga pewną krytyczna masę ich utrzymanie staje się zbyt kosztowne i “testerzy górą”, dlatego Tester i Inżynier Testów w jednym to idealne rozwiązanie.

Pozostaje mi tylko życzyć powodzenia wszystkim testerom, którzy nie zamierzają uczyć się pisania testów. Moje mroczne wizje prawdopodobnie się nie spełnią chociażby dlatego, że znacząca większość projektów nadal jest rozwijana wg. starych metodologi i pewnie jeszcze długo będzie, a metodologie zwinne mało kto potrafi i chce w pełni wykorzystywać.

Na blogu pojawił się jakiś czas temu kurs Selenium. To dopiero początek! W mitycznych wolnych chwilach postaram się go uaktualniać i dopisywać różne ciekawe rzeczy z tym narzędziem powiązane.

Dlaczego oddzielna strona – a dlatego, że jest to narzędzie na tyle rozbudowane, oraz posiadające na tyle dużo możliwości (często trudnych do odkrycia), że warto mu poświęcić osobną stronę. Jeśli chodzi polskojęzyczny Internet ciężko jest znaleźć cokolwiek na ten temat, więc może komuś przyda się to co tutaj zamieszczę… Na razie jest tego niewiele – kilka podstawowych pojęć i sposób instalacji… Wszystko opisuję raczej z pamięci, więc mogą być tam małe błędy… Gdyby ktoś miał jakieś uwagi piszcie na maila… Gdyby ktoś odkrył coś ciekawego w tym narzędziu także proszę o kontakt…

Jak już pisałem Selenium pomimo tego, że jest to Open Source, jest narzędzie niesamowicie rozbudowany, potrafiącym przetestować prawie wszystko co jest w stanie obsłużyć przeglądarka internetowa, a ponadto umożliwia testowanie w różnych środowiskach… Ale o tym wszystkim wkórtce na stronach kursu…

Selenium jest idealnym narzędziem wspomagającym testowanie aplikacji zarządzanych agile’owo. Świetnie sprawdza się w continues integration. Za jego pomocą można łatwo przetestować większość java script na stronie, do których testy jednostkowe są często traktowane po macoszemu. Jeśłi testy są dobrze napisane i zaplanowane ich utrzymanie wcale nie jest tak kosztowne jak by się to wydawało.

“Testowanie wymagań i chodzenie po wodzie jest łatwe pod warunkiem, że są zamrożone”

Planując testy akceptacyjne staram się oprzeć na wymaganiach, które według klienta powinny zostać spełnione by aplikacja była akceptowalna. To jest oczywiste. Jednak co zrobić, gdy wymagania zmieniają się wraz z rozwojem aplikacji, jak to często w projektach Agile’owych i nie tylko bywa? Standardowy model “V” nie nadaje się tutaj do  zastosowania, gdyż zakłada on planowanie testów akceptacyjnych, a co za tym idzie implementację tych testów w odpowiedniej, stosunkowo wczesnej fazie projektu. Przy takim rozwiązaniu gdy testy są wcześnie zaimplementowane a wymagania nie są do końca sprecyzowana (ulegają ciągłym zmianom) utrzymanie testów staje się zbyt kosztowne.

Testowanie zmieniających się wymagań nigdy nie będzie proste i nigdy nie będzie tanie, chociażby  nie wiem jak te testy były zaplanowane i napisane/zrealizowane. Najbardziej optymalnym rozwiązaniem w takiej sytuacji jest powrót do podstaw i rozbicie aplikacji na poszczególne podsystemy o określonych, zawężonych funkcjonalnościach, maksymalnie oddzielone od reszty aplikacji, po czym doprowadzenie kolejno jeden po drugim każdy z tych podsystemów do oczekiwanego akceptowalnego stanu. W innym wypadku wpadniemy w “Cowoboy Coding” z “Bug Huntingiem”, co obrazuje się w sposób następujący: testerzy znajdują błędy w różnych częściach aplikacji, developerzy je poprawiają, dodają nową funkcjonalność psując coś w innym miejscu, testerzy lub automatyczne testy znajdują te błędy, deweloperzy  znów poprawiają psując coś innego i tak w kółko. Nie da się ogarnąć projektu bez zaplanowanej metodologi działania. Wszelkie poprawki i zmiany powinny być z góry zaplanowane i w odpowiedni sposób przetestowane przed wysłaniem ich na serwer, gdzie następują testy integracyjne. Bardzo istotny jest obieg informacji – co, kto i dlaczego robi, oraz co jeszcze ktoś inny będzie musiał  z tym zrobić. W agile testowanie w dużym stopniu opiera się na testach poszczególnych funkcjonalności, które wykluczają większość błędów nie wynikających z problemów integracyjnych.

Słyszałem o aplikacjach powstających metodą “Wielkiego Wybuchu”, która polega na tym, że wszyscy nagle siadają i coś kodują, starając się nie wchodzić sobie w drogę. Zazwyczaj kończy się to wielkim bałaganem, który czasem nawet działa ale nikt nie jest z niego zadowolony. Najgorsze jednak w tym wszystkim jest to, że jeśli przyjdzie zrobić jakąś zmianę, albo poprawić jakieś błędy to nagle okazuje się, że wiele fragmentów kodu jest zduplikowanych, albo zależy od nich zbyt wiele innych części aplikacji.

Rozwiązaniem większości problemów jest skrupulatne planowanie oraz pozostawienie możliwości przyszłego rozwoju dla każdej części aplikacji w każdym możliwym kierunku. Ważnym jest też dobór odpowiedniej metodologii. Dzięki tym rozwiązaniom nawet najbardziej zmienne wymagania nie są nam straszne. Jeśli wymagania się zmieniają, wracamy do odpowiedniej części aplilkacji i ponownie pracujemy nad nią, aż nowe wymagania zostaną spełnione, nie ingerując w inne części projektu.

Przeczytałem kilka publikacji na temat testowania w metodologiach zwinnych, ale jak do tej pory żadna nie oddaje w pełni tego co ja doświadczyłem podczas pierwszego zetknięcia się z testowaniem w Scrum’ie ( o nim samym może innym razem). Jak ogólnie wiadomo Scrum zakłada iteracyjny model wytwarzania oprogramowania, czyli po każdym sprincie (w moim przypadku co dwa tygodnie) powinniśmy mieć przynajmniej jedną nową, w pełni działającą “funkcjonalność”.

Mądre książki podają, że podstawą takiego wytwarzania oprogramowania są automatyczne testy pisane przed rozpoczęciem implementacji właściwego kodu programu – nie zamierzam z tym polemizować, gdyż jest to działka raczej programisty nie testera. Kolejną rzeczą która powinna zostać zrobiona jest tworzenie i aktualizowanie na bieżąco automatycznych testów funkcjonalnych (Selenium, TestComplete, etc.) – słuszne podejście, moje ostatnie doświadczenia potwierdziły istotność takich testów, a konkretnie potwierdził to ich brak. Utrzymanie automatycznych testów funkcjonalnych jest jednak czasochłonne i kosztowne. Przejdźmy więc do testów manualnych. Jak testować w modelu iteracyjnym?

Działając zgodnie z procedurami opisanym tu i ówdzie testowałem każdą nową funkcjonalność z osobna (tutaj znów spostrzegłem potrzebę istnienia automatycznych testów, gdyż nie sposób było przetestować całą aplikację po każdej małej zmianie), przynosiło to dobre efekty, lecz jedynie na krótką metę, ponieważ jeśli chodzi o nowe, właśnie wprowadzone funkcjonalności mogliśmy z dużym prawdopodobieństwem stwierdzić, że działają poprawnie, lecz niestety aplikacja jako całość w zasadzie nigdy (aż do testów akceptacyjnych) nie została przetestowana. I tu pojawia się właśnie rola testów akceptacyjnych, które zostały zostawione na sam koniec. Czy to złe podejście? Moim zdaniem nie do końca, dzięki temu unikamy zbędnego powtarzania się (zakładając, że nie mamy do dyspozycji automatycznych testów funkcjonalnych), testy akceptacyjne w których z konieczności zawierają się także testy integracyjne, mogą zostać przeprowadzone w środowisku praktycznie identycznym z produkcyjnym. Liczba błędów, które udało mi się znaleźć podczas tych testów jest naprawdę znikoma, co ukazuje wyższość zwinnych testów  każdej poszczególnej funkcjonalności i poprawność odizolowania od siebie poszczególnych części kodu aplikacji (co też powinno być/jest niepisaną zasadą Scrum’a). Błędy które znalazłem wynikały głównie ze środowisk na których aplikacja została zainstalowana.

Lecz to jeszcze nie koniec  – jak wiadomo najlepszymi testerami są zwykli użytkownicy, dlatego głośno i stanowczo postuluje za tym, by wszystkie większe projekty agile’owe były wydawana najpierw w wersji BETA i dopiero po zatwierdzeniu przez grupę testowych użytkowników publikowane jako gotowe finalne wersje produktu. Myślę, że nawet koszty obniżenia ceny pierwszej wersji produktu zostaną zrównoważone jego jakością. Spójrzmy na najlepszych/największych Gmail od pięciu lat jest w wersji beta i pewnie jeszcze długo będzie, jest to typowy przykład projektu rozwijanego iteracyjnie w Agile, testowany przez klientów i cieszący się dużą popularnością oraz względną niezawodnością.

O kosztach testowania postaram się napisać innym razem. Konkluzja: pozostawienie integracyjnych testów na sam koniec wydaje się być w miarę rozsądne, oczywiście jeśli mamy na to czas.