Rola testów w metodykach zwinnych łatwiej czy trudniej? Lucjan Stapp Wydział MiNI Politechnika Warszawska L.Stapp@mini.pw.edu.pl
o mnie Pracownik naukowy Politechniki Warszawskiej; Autor ponad 40 publikacji, w tym 10 o różnych problemach związanych z testowaniem i zapewnieniem jakości; Kierownik i członek zespołów Zapewnienia Jakości w kilkunastu projektach; ostatnio (wrzesień 2009 - luty 2011) kierownik polskiego zespołu w dużym projekcie europejskim OneLab2: An Open Federated Laboratory Supporting Network Research for the Future Internet. Zwolennik zwinnych metodologii, zwłaszcza w testowaniu; Członek - założyciel Stowarzyszenia Jakości Systemów Informatycznych, aktualnie wiceprezes SJSI Slajd 2/53
Program wystąpienia 1. Agile Manifesto 2. extreme Programming 3. Scrum 4. Podejście zwinne a klasyczne poziomy testów Slajd 3/53
1. Agile manifesto Manifest Agile (pełna nazwa Manifest Zwinnego Wytwarzania Oprogramowania, oryginalne nazwy: Agile Manifesto, Manifesto for Agile Software Development) deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana na spotkaniu, które miało miejsce w dniach 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah). Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. Slajd 4/53
1. Agile manifesto Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać: Ludzi i ich wzajemne interakcje (współdziałanie) Działające oprogramowanie Współpracę z klientem ponad procedury i narzędzia nad wyczerpującą dokumentację nad negocjację umów Reagowanie na zmiany nad realizowanie planu Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej. agilemanifesto.org/iso/pl Slajd 5/53
1. Agile manifesto TYLKO podejście iteracyjne przyrostowe Wynikiem każdej iteracji jest program wykonywalny Slajd 6/53
1. Agile manifesto Cechy podejścia Agile (1/2) Iteracyjne i przyrostowe (ewolucyjne) podejście do wytwarzania oprogramowania Przejrzystość, Prostota, Częsty refactoring, Działający produkt na koniec każdej iteracji, Slajd 7/53
1. Agile manifesto Cechy podejścia Agile (2/2) Zmiana wymagań jest możliwa i dopuszczalna, Samoorganizujący się, samowystarczalny zespół profesjonalistów, Małe zespoły, Nieformalna komunikacja w cztery oczy, Regularna adaptacja (inspect and adapt). Slajd 8/53
1. Agile manifesto Do metodyk zwinnych należą (m.in.): Programowanie ekstremalne (extreme Programming XP), Scrum, Kanban, Dynamic Systems Development Method, Adaptive Software Development,... Slajd 9/53
1. Agile manifesto Na co zwraca uwagę development: 6 6 0,4 2,3 4,9 2,7 1,8 5,6 3,9 3 0,8 0,8 0,2 0,8 4 4,4 Wyniki z Badania Sukcesu Projektu przeprowadzonego w 2008 r. przez Dr. Dobb Journal, pokazują, że zespoły zwinne są bardziej efektywne w dostarczaniu pożądanej funkcjonalności, niż zespoły tradycyjne. Jakość Funkcjonalność ROI (pieniądze) Harmonogram Ad-hoc Kaskada Metoda iteracyjna Agile Slajd 10/53
1. Agile manifesto Wyższa jakość. Podejścia zwinne dają w wyniku wyższą jakość, niż podejścia tradycyjne, najprawdopodobniej z powodu zwiększonej współpracy wewnątrz zespołu oraz wcześniejszego i intensywniejszego testowania podczas cyklu życia. Ulepszone projekty. Strategie architektury i projektowania Agile są z natury ewolucyjne. W połączeniu z wyższymi poziomami współpracy wykazywanymi przez zespoły zwinne, daje lepsze rezultaty w porównaniu do podejść bardziej tradycyjnych. Architektura i projektowanie są tak ważne dla zespołów Agile, że wykonują te czynności podczas całego cyklu życia, nie tylko podczas wczesnych faz cyklu. Slajd 11/53
1. Agile manifesto Lepsze wskaźniki ekonomiczne. Zespoły Agile dają większy zwrot z inwestycji, niż zespoły tradycyjne. Wynika to z krótszego cyklu informacji zwrotnej w podejściach zwinnych. Zespoły zwinne pracują mądrzej, nie ciężej, często dostarczają funkcjonalność wcześniej, tym samym dając krótszy czas do dostarczenia wartości i większy zysk. Slajd 12/53
1. Agile manifesto Wiara Badanie Zastosowania Agile z roku 2008 wykonane przez DDJ odkryło również, że ludzie wierzą w to, iż zespoły Agile produkowały wyższą jakość, niż zespoły tradycyjne, powodując większą satysfakcję udziałowców i dostarczając wyższe poziomy produktywności. Slajd 13/53
Program wystąpienia 1. 2. Agile Manifesto extreme Programming 3. Scrum 4. Podejście zwinne a klasyczne poziomy testów Slajd 14/53
Jedną z popularnych, zwinnych metodyk tworzenia systemów informatycznych na zamówienie jest extreme Programming (XP). 2. extreme Programming Slajd 15/53
Podstawowe zasady XP na pierwszy rzut oka wydają się dziwne, jednak mają głęboki sens. Planowanie 4.2 extreme Programming Scenariusze użycia; Małe a częste przyrosty; Planowanie poprzedza prace w każdej z iteracji; Planowanie na poziomie przyrostów (release); Mierzenie postępów prac; Projekt podzielony na iteracje; Okresowa zamiana ról osób w zespole; Spotkanie (na stojąco) rozpoczyna każdy dzień; Naprawiajmy XP, gdy nie pasuje do sytuacji. Slajd 16/53
2. extreme Programming Podstawowe zasady XP na pierwszy rzut oka wydają się dziwne, jednak mają głęboki sens. Kodowanie Klient powinien być zawsze dostępny; Kod musi być tworzony zgodnie z uzgodnionymi standardami; Testy modułów powinny być przygotowane przed rozpoczęciem kodowania (TDD); Programowanie powinno odbywać się w parach; Tylko jedna para powinna w danej chwili integrować nowe moduły z resztą systemu; Częsta integracja; Cały kod systemu jest własnością całego zespołu; Nie optymalizujmy na zapas; Brak nadgodzin; Slajd 17/53
2. extreme Programming Podstawowe zasady XP na pierwszy rzut oka wydają się dziwne, jednak mają głęboki sens. Testowanie Każdy fragment kodu musi być poddany testom modułowym; Kod musi przejść pomyślnie testy modułów, zanim opuści środowisko rozwojowe; Gdy zostanie znaleziony błąd, powinien być stworzony obejmujący go test; Testy akceptacyjne są wykonywane często, wyniki powinny być dostępne dla wszystkich. Slajd 18/53
2. extreme Programming Zasady XP pozwalają budować oprogramowania o zadowalającej jakości (good enough quality). Slajd 19/53
Program wystąpienia 1. Agile Manifesto 2. extreme Programming 3. Scrum 4. Podejście zwinne a klasyczne poziomy testów Slajd 20/53
3. Scrum Scrum to metodyka prowadzenia projektów. Nazwa "scrum" wywodzi się z terminu występującego w grze rugby, tłumaczonego powszechnie jako "młyn Wymyślili Hirotaka Takeuchi i Ikujiro Nonaka, sformalizował Ken Schwaber. Slajd 21/53
3. Scrum Daily scrum Slajd 22/53
3. Scrum Slajd 23/53
3. Scrum Kompozycja historyjki (User Story) Elementy historyjki (User Story) Jako (konkretny użytkownik systemu) chcę (pożądana cecha lub problem, który trzeba rozwiązać) bo wtedy/ponieważ (korzyść płynąca z ukończenia zadania). Określenie warunków satysfakcji klienta na ogół podane w formie testów akceptacyjnych Slajd 24/53
A good user story is: Independent Negotiable Valuable Estimable Sized Appropriately Testable 3. Scrum INVEST Slajd 25/53
3. Scrum INVEST Independent Niezależna Historyjka nie zachodzi na inne, dzięki czemu możemy je zaimplementować w dowolnej kolejności, Łatwiej takie historyjki oszacować i zaplanować, Możemy zmienić priorytet bez ingerowania w inne historyjki. INVEST Negotiable - Negocjowalna Historyjka nie jest kontraktem na wykonanie dokładnie określonej pracy, Nadal pozostaje wystarczająco dużo elastyczności, żeby doprecyzować szczegóły z klientem, Pokrywa tylko koncepcję, nie określa rozwiązania problemu. Slajd 26/53
3. Scrum INVEST Valuable- Wartościowa Historyjka przedstawia wartość dla klienta, nie dla dewelopera, Wymagania techniczne powinny być zapisane w sposób odzwierciedlający korzyści dla klienta, W przypadku rozbicia historyjki na mniejsze, każda część musi nadal przedstawiać wartość dla klienta. INVEST Estimable - Dająca się oszacować (Czas + zasoby) Szacowanie nie musi być bardzo dokładne, ale Historyjka jest na tyle dobrze sformułowana, że można ją oszacować (przypisać do niej estymatę). Slajd 27/53
3. Scrum INVEST Sized Appropriately Odpowiedniej wielkości Dająca się zrealizować z jednym okresie realizacji (sprint) Slajd 28/53
3. Scrum INVEST Testable - testowalna Dająca się w miarę prosto przetestować Nie oczekujmy jednak żadnych super- specyficznych przypadków testowych, takich jak np. World wide transaction system for an international bank A fish trade company in Japan makes a payment to a vendor on Iceland. It should have been a payment in Icelandic Kronur, but it was done in Yen instead. The error is discovered after 9 days and the payment is revised and corrected, however, the interest calculation (value dating) From a talk by Hans Buwalda Slajd 29/53
3. Scrum Testowanie w Scrum Testowanie w Scrum musi być iteracyjne. Testerzy w Scrum nie mogą polegać na posiadaniu kompletnej specyfikacji. Testerzy w Scrum muszą być elastyczni. Slajd 30/53
3. Scrum Rozpoczęcie projektu Czytanie dokumentacji, zrozumienie istoty projektu Planowanie release u Szacowanie historyjek; pytanie: Co by było, gdyby? Planowanie sprintu Walidacja warunków satysfakcji, dodawanie nowych Każdy sprint Tworzenie i testowanie kodu w parach: developer i tester Napisz i wykonaj testy dla poszczególnych historyjek Napisz i wykonaj testy funkcjonalne Automatyzuj testy Testuj eksploracyjnie Podstawowe aktywności testerskie w Scrum Slajd 31/53
3. Scrum Budowa zespołu Podejście kompletny zespół jest wyraźnie odmienne od postępowania w zespołach tradycyjnych. W zespołach tradycyjnych specjaliści programiści piszą kod, a następnie przekazują wytwór swej pracy do specjalistów -testerów, którzy następnie go testują i raportują incydenty (tzn. podejrzewane defekty) z powrotem do programistów. Slajd 32/53
3. Scrum Budowa zespołu Zgodnie z podejściem kompletnego zespołu testerzy są wbudowani w zespół developerski i aktywnie uczestniczą we wszystkich aspektach projektu. Zespoły Agile odchodzą od tradycyjnego podejścia, w którym ktoś ma pojedynczą specjalizację, na której się skupia do podejścia, w którym ludzie dążą do stania się specjalistami ogólnymi, z szerszym zakresem umiejętności. Członkowie zespołu chcą pracować razem i uczyć się od siebie nawzajem, by stać się lepszymi w miarę upływu czasu Slajd 33/53
3. Scrum Budowa zespołu Wady podejścia Kompletny zespół Myślenie grupowe członkowie zespołu myślą podobnie i nie widzą pewnego typu problemów Brak w zespole potrzebnych umiejętności Znajomość biznesu Brak wiedzy, jakie umiejętności są naprawdę potrzebne Zbyt mały nacisk na testy akceptacyjne Slajd 34/53
Program wystąpienia 1. 2. Agile Manifesto extreme Programming 3. Scrum 4. Podejście zwinne a klasyczne poziomy testów Slajd 35/53
4.Podejście zwinne a klasyczne Testy akceptacyjne Product owner ; Akceptacja przyrostów Testy systemowe Testy integracyjne wewnętrzne Podejście przyrostowe Częste build y czas Testy modułowe Test Driven Development Slajd 36/53
4.Podejście zwinne a klasyczne Testy modułowe Test Driven Development Dwa cele: sposób przemyślenia problemu przed stworzeniem kodu (bardziej specyfikacja niż walidacja), technika programistyczna zwiększająca poprawność tworzonego kodu. Slajd 37/53
4.Podejście zwinne a klasyczne Testy modułowe Test Driven Development Silne wsparcie narzędziowe: rodzina narzędzi Xunit wbudowane (częściowo) w środowiska programistyczne : - Eclipse -.NET - NetBeans Slajd 38/53
4.Podejście zwinne a klasyczne Testy integracyjne wewnętrzne Częste build y Podejście przyrostowe. Częsta integracja (continuous integration) Nowa funkcjonalność jest akceptowana po pełnych testach regresji Slajd 39/53
4.Podejście zwinne a klasyczne Testy systemowe Podejście przyrostowe Podejście przyrostowe. Ostatni przyrost gotowy system Pełne testy regresji przetestowany system Slajd 40/53
4.Podejście zwinne a klasyczne Testy akceptacyjne Product owner ; Akceptacja przyrostów Product owner jako reprezentant odbiorcy Akceptacja przyrostów. Wszystkie przyrosty zaakceptowane Akceptacja systemu Slajd 41/53
4.Podejście zwinne a klasyczne Ken Beck 1 stwierdził, że testowanie jednostkowe wykonywane przez programistów ewentualnie może uczynić zbędną rolę niezależnego zespołu testowego w wykrywaniu defektów, przekształcając testowanie w rolę podobną do roli analityka biznesowego. 1 www.soft.com/qualweek/qw2001/papers/2q.html Slajd 42/53
4.Podejście zwinne a klasyczne ALE Testowanie jednostkowe jest ograniczone w kwestii wykrywania błędów. Capers Jones 1 odkrył, że średnia efektywność usuwania defektów dla testowania jednostkowego wynosi 25-30%. Wg Rexa Blacka 2 (badania dla rynku amerykańskiego) dobre testowanie systemowe wykonanie przez niezależny zespół testowy osiąga około 85% efektywności wykrywania defektów. 1 Capers Jones: MEASURING DEFECT POTENTIALS AND DEFECT REMOVAL EFFICIENCY http://www.rbcs-us.com/images/documents/measuring-defect-potentials-and- Defect-Removal-Efficiency.pdf 2 http://www.rbcs-us.com/images/documents/ Slajd 43/53
4.Podejście zwinne a klasyczne Testowanie jednostkowe jest ograniczone w kwestii wykrywania błędów. Wniosek: testowanie jednostkowe pomaga, głównym filtrem do zapobiegania nadmiernym usterkom pozostają testy systemowe. Slajd 44/53
4.Podejście zwinne a klasyczne Z badań R. Blacka wynika też, że - pod pozorem zarówno prawdziwych, jak i nie bardzo prawdziwych wymówek - wielu programistów nie tworzy automatycznych testów jednostkowych, a w niektórych przypadkach nie wykonuje w ogóle żadnego testowania jednostkowego. Krótkie okresy wykonywania testów w sprintach Agile w porównaniu do projektów sekwencyjnych - powodują, że stopień zniszczenia spowodowany przez jedno- lub dwudniową blokadę postępu testowania z powodu wysoce awaryjnego kodu jest wyższy, niż w projektach klasycznych. Slajd 45/53
4.Podejście zwinne a klasyczne Podejście testuj natychmiast po Developerzy o wiele częściej piszą nieco kodu, a następnie jeden (lub więcej) testów do walidacji. TDD wymaga bardzo wysokiego poziomu autodyscypliny Pisanie testy bezpośrednio po tym, jak napisano kod produkcyjny (innymi słowy testujesz natychmiast po ), jest prawie tak dobre jak TDD; problem pojawia się, gdy testy powstają po kilku dniach czy tygodniach o ile w ogóle powstają. Slajd 46/53
4.Podejście zwinne a klasyczne Podejście testuj natychmiast po Popularność narzędzi do badania pokrycia kodu, takich jak np. Clover 1 i Jester 2 wśród programistów Agile jest wyraźną oznaką tego, że wielu z nich naprawdę przyjmuje podejście testuj po. Te narzędzia ostrzegają, że istnieje kod, który nie ma pokrywających go testów 1 Clover narzędzie do pokrycia kodu w Javie, płatne http://www.atlassian.com/software/clover/ 2 Jester narzędzie wspomagające Junit darmowe http://sourceforge.net/projects/jester/ Slajd 47/53
4.Podejście zwinne a klasyczne Moje wcześniejsze komentarze odnośnie testowania jednostkowego i wykresy ograniczeń efektywności testowania jednostkowego, które przytaczałem z prac Capera Jonesa, powodują, że zaczynam być sceptyczny odnośnie tego, że zobaczymy istotnie wolny od błędów kod dostarczony zespołom testowym, niezależnie od tego, jaki jest model cyklu życia ale cieszyłbym się pracując w projektach, w których ktoś dałby radę udowodnić mi, że się mylę. Rex Black Slajd 48/53
4.Podejście zwinne a klasyczne Wady podejścia agile uprawniony użytkownik (Product owner) członek zespołu brak niezależnego spojrzenia testera - testy modułowe + testy integracyjne nie muszą pokrywać zakresu aplikacji brak testów integracyjnych zewnętrznych nie muszą być (nie są) dobrze opisane w user stories Slajd 49/53
4.Podejście zwinne a klasyczne Rozwiązanie: Dwa poziomy testowania: Testowanie wewnętrzne wewnątrz zespołu wytwarzającego Testowanie zewnętrzne - niezależny zespół testowy Slajd 50/53
4.Podejście zwinne a klasyczne Typowe zadania niezależnego zespołu testowego Odkrycie miejsc, w których system się psuje. Bardziej złożone formy testowania: Testy niefunkcjonalne. Testowanie akceptacyjne (gra końcowa) Testowanie akceptacyjne z punktu widzenia użytkownika. Wsparcie produkcji. Slajd 51/53
5. Poziomy testów a podejście zwinne Release nr k Release nr k+1 Testowanie wewnętrzne TDD Story zmian (defekty) Story zmian (defekty) Niezależny zespół testowy Testowanie zewnętrzne Akceptacyjne Przez użytkownika Eksploracyjne Niefunkcjonalne Scenariuszowe Slajd 52/53
Dziękuję za uwagę. Slajd 53/53