Rola testera? w projekcie zwinnych: nowe wyzwania

Transkrypt

1 Rola testera? w projekcie zwinnych: nowe wyzwania Lucjan Stapp Politechnika Warszawska Stowarzyszenie Jakości Systemów Informatycznych L.Stapp@mini.pw.edu.pl L.Stapp@sjsi.org

2 Lucjan Stapp Pracownik naukowo dydaktyczny - Politechnika Warszawska; ISTQB CTAL TM, ISTQB CTAL - TA 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; Członek założyciel, aktualnie vice-prezes Stowarzyszenia Jakości Systemów Informatycznych Członek ISTQB Glossary Working Group; Członek ISTQB Exam Working Group, odpowiedzialny za przykładowe pytania poziomu podstawowego; Współpracownik zespołu ISTQB przygotowującego sylabus Agile tester Warszawa, 25 maj /52

3 Motto Nie jest ważne, czy każdy element jest idealny i najlepszy. Ważne, że zbiór tych elementów działa zawsze tak samo, w powtarzalny sposób. A temu właśnie służą ścisłe procedury. A Ziemiański. Pomnik cesarzowej Achai. Tom IV Warszawa, 25 maj /52

4 Przykład historyczny Galery a łodzie Wikingów Podstawowy napęd: wiosła, wspomagane żaglem Warszawa, 25 maj /52

5 Przykład historyczny Średnia łódź Wikingów drakkar: załoga wojowników Podstawowy napęd: wiosła, wspomagane żaglem TYLKO wolni ludzie Warszawa, 25 maj /52

6 Przykład historyczny Triera - galera z trzema rzędami wioseł Podstawowy napęd: wiosła, wspomagane żaglem Używane były przede wszystkim na Morzu Śródziemnym Załoga to około 170 wioślarzy, 13 marynarzy, sternik, dowódca i czterech jego pomocników oraz muzyk, Do wiosłowania głównie wykorzystywano niewolników, jeńców lub skazańców, tzw. galerników. Warszawa, 25 maj /52

7 Przykład historyczny Ekspansja wikingów pomiędzy IX a XI wiekiem Warszawa, 25 maj /52

8 Przykład historyczny ALE Ekspansja Wikingów to okres od końca VIII wieku do wieku XI (ok. 790 ok. 1050) Galery były używane od VII wieku przed Chrystusem do XVII wieku naszej ery Handel i transport to galery, a NIE długie łodzie Wikingów Warszawa, 25 maj /52

9 Manifest Agile 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, jakie odbyło się w dniach lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah). Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania. Warszawa, 25 maj /52

10 Manifest Agile 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 Warszawa, 25 maj /52

11 Manifest Agile Cechy podejścia zwinnego Iteracyjne i przyrostowe (ewolucyjne) podejście do wytwarzania oprogramowania Przejrzystość, Prostota, Refactoring, Działający produkt na koniec każdej iteracji, Zmiana wymagań jest dopuszczalna (możliwa, wręcz oczekiwana), Samoorganizujący się, samowystarczalny zespół profesjonalistów, Małe zespoły (do 10 osób), pracujący we wspólnej przestrzeni (Agile space) Nieformalna komunikacja w cztery oczy, Regularna adaptacja (inspect and adapt). agilemanifesto.org Warszawa, 25 maj /52

12 Manifest Agile Metodologie zwinne (miedzy innymi): extreme Programming XP, Scrum, Kanban, Lean Software Development, Dynamic Systems Development Method, Adaptive Software Development,... Warszawa, 25 maj /52

13 Wiara czyni cuda? 7,0 6,0 6,0 5,6 6,0 5,0 4,0 3,0 2,0 1,0-0,4 5,0 4,0 4,2 3,9 3,0 2,7 2,3 2,4 1,8 0,8 0,8 0,8 Quality Functionality ROI (money) Schedule Ad-hoc Waterfall Classical Iiterative Agile 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 (skala 0-10). Warszawa, 25 maj /52

14 Wyższa jakość. Podejścia zwinne dają na ogół 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 zwinne są z natury ewolucyjne. W połączeniu z wyższymi poziomami współpracy wykazywanymi przez zespoły zwinne, daje to lepsze rezultaty w porównaniu do podejść bardziej tradycyjnych. Architektura i projektowanie są tak ważne dla zespołów zwinnych, że wykonują te czynności podczas całego cyklu życia, nie tylko podczas wczesnych faz cyklu. Warszawa, 25 maj /52

15 Lepsze wskaźniki ekonomiczne. Manifest Agile Zespoły zwinne dają większy zwrot z inwestycji, niż zespoły tradycyjne. Wynika to z krótszego cyklu reakcji 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. 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. Warszawa, 25 maj /52

16 Siła trzech (przedstawiciel biznesu +developer + tester). Podejście cały zespół Cały zespół jest zaangażowany w konsultacje oraz Jak poprawiamy jakość? spotkania wiedza i umiejętności wszystkich są niezbędne do odniesienia sukcesu. Wszyscy odpowiadają za jakość. Testerzy pracują wspólnie zarówno z przedstawicielami biznesu (właściciel produktu) jak i z deweloperami by zapewnić jakość na wszystkich poziomach testów. Warszawa, 25 maj /52

17 Siła trzech. Z punktu widzenia testera w zespole zwinnym podejście cały zespół oznacza codzienną współpracę zarówno z deweloperami jak i z przedstawicielami biznesu. Testerzy powinni Jak poprawiamy jakość? Przekazywać wiedzę o testowaniu do pozostałych członków zespołu i wpływać na wytwarzanie produktu, Zapewniać - z deweloperami - właściwy poziom integracji, Dbać o poprawne kontakty z użytkownikami. Warszawa, 25 maj /52

18 Siła trzech. Jak to uzyskać: Jak poprawiamy jakość? Codzienne pięciominutówki, Coaching, Wizualna prezentacja danych o jakości produktu. Warszawa, 25 maj /52

19 Zespół Retrospektywa Warszawa, 25 maj /52

20 Zespół Praca zespołowa to podstawowa zasada w wytwarzaniu zwinnym. Wybór właściwych!! ludzi, by dobrze pracując razem skutecznie stworzyli żądany produkt. Warszawa, 25 maj /52

21 Zespół Budowanie zespołu Nie ma podziału na testerów i deweloperów Testerzy powinni być wbudowani w zespól Ale: Ilu członków zespołu naprawdę koncentruje się (= zna się) na problemach jakościowych? (1/10, 2/10???); Myślenie grupowe ma ogół TYLKO pozytywne; Brak dostatecznej wiedzy biznesowej (siła trzech?) Właściciel produktu klucz do biznesu?? Wymagania (historyjki użytkownika) klucz do sukcesu?? Warszawa, 25 maj /52

22 Historyjka użytkownika 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 Warszawa, 25 maj /52

23 Historyjka użytkownika REQUIREMENT (Ron Jeffrie) Card Conversation Confirmation Historyjki są napisane na fiszkach. Fiszki mogą mieć adnotacje z estymatą, notatkami itd. SzczegółyHistoryjki wychodzą na jaw podczas rozmowy z klientem / właścicielem produktu. Testy akceptacyjne potwierdzają poprawność implementacji historyjki. Warszawa, 25 maj /52

24 Historyjki użytkownika INVEST Dobrze stworzona historyjka użytkownika spełnia warunki:: Independent - Niezależna Negotiable - Negocjowalna Valuable - Wartościowa Estimable - Dająca się oszacować (Czas + zasoby) Sized Appropriately - Odpowiedniej wielkości Testable - Testowalna Bill Wake, INVEST in Good stories, and SMART Tasks Warszawa, 25 maj /52

25 INVEST Testowalna Historyjka użytkownika Testy koncentrują się na prostych problemach Zespoły zwinne raczej nie oczekują, że testy akceptacyjne historyjek będą skomplikowane. 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 Warszawa, 25 maj /52

26 Historyjka użytkownika INVEST Testowalna ALE Testowanie w podejściu zwinnym powinno być iteracyjne Testerzy muszą (często?) pracować bez pełnej dokumentacji Testerzy powinni być elastyczni. Warszawa, 25 maj /52

27 Testowanie w projektach zwinnych Początek projektu Zrozumienie biznesowych podstaw projektu Planowanie wydania Szacowanie historyjek; dopytywania: A co, jeśli? Planowanie iteracji Walidacja warunków satysfakcji, dodawanie nowych Każda iteracja Tworzenie i testowanie w trójkach: deweloper, przedstawiciel biznesu oraz tester Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Podstawowe czynności testerskie w projekcie zwinnym Warszawa, 25 maj /52

28 Testowanie w projektach zwinnych Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Tester zwinny powinien móc szybko poznać testowany produkt znać się na dziedzinie produktu, by dokładnie rozumieć wymagania posiadać wiedzę na temat produktu i/lub jego użytkowników, by móc rozróżnić bardziej i mniej krytyczne wymagania o współpraca właściciela produktu zaprojektować odpowiednie przypadki testowe oceniać wynik z testów o właściwe zrozumiałe dla interesariuszy projektu raportowanie Warszawa, 25 maj /52

29 Testowanie w projektach zwinnych P R A W D O P O B I E Ń S T W O W Ś N N Możemy Koncentracja na testach jednostkowych I III Olewamy Ś WPŁYW Musimy II IV Powinniśmy W Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Koncentracja na testach akceptacyjnych Tester powinien móc rozróżnić pomiędzy tym co krytyczne, co poważne, co istotne, a co jest chciejstwem Warszawa, 25 maj /52

30 Testowanie w projektach zwinnych Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Nie tylko wytwarzanie sterowane testami TDD (PRZYMUS?!) Ale także Acceptance Test Driven Development Behaviour Driven Development } odwrotna piramida testów Warszawa, 25 maj /52

31 Testowanie w projektach zwinnych Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Ciągła reakcja zwrotna jest konieczna, a może być uzyskiwana przez tworzenie i zarządzanie odpowiednim zbiorem testów automatycznych. Tester w zespole zwinnym powinien znać się na automatyzowaniu testów, umieć tworzyć (samemu lub z pomocą programistów) zautomatyzowane przypadki testowe. Warszawa, 25 maj /52

32 Ale Testowanie w projektach zwinnych Braki wiedzy, Często zbyt mały nacisk na testy akceptacyjne end-toend Warszawa, 25 maj /52

33 Warto wiedzieć Ale Testy jednostkowe (włączając TDD) mają ograniczoną efektywność wykrywania usterek : Capers Jones 1 wyliczył, że średnia efektywność testów jednostkowych jest w przedziale 25-30%. A Rex Black 2 (rynek amerykański ) wyliczył, że dobre testy systemów robione przez NIEZALEŻNE zespoły testowe osiągają efektywność na poziomie 85%. 1 Capers Jones: MEASURING DEFECT POTENTIALS AND DEFECT REMOVAL EFFICIENCY Warszawa, 25 maj /52

34 Warto wiedzieć Testowanie jednostkowe jest ograniczone w kwestii wykrywania błędów. Wniosek: testowanie jednostkowe pomaga, głównym filtrem do zapobiegania nadmiernym usterkom pozostają testy systemowe. Warszawa, 25 maj /52

35 Warto wiedzieć 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 zwinnych 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 2 Jester narzędzie wspomagające JUnit darmowe Warszawa, 25 maj /52

36 Warto wiedzieć 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 auto-dyscypliny 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ą. Warszawa, 25 maj /52

37 Testowanie w projektach zwinnych Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Nie mamy możliwości, by w sposób ciągły automatyzować wszystkie przypadki testowe. Potrzebujemy technik dostarczających szybkich testów manualnych wspomagających testowanie automatyczne testy eksploracyjne; ataki na oprogramowanie; zgadywanie błędów. Warszawa, 25 maj /52

38 Rozwiązania Rozwiązanie 1: Jeden profesjonalny tester wbudowany w zespól, wykonujący pewien (pełny) zakres testów. ALE istnieje pewne ryzyko utraty niezależności lub braku obiektywnej oceny dostępnej poza zespołem Warszawa, 25 maj /52

39 Warto wiedzieć 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 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. Warszawa, 25 maj /52

40 Rozwiązania Rozwiązanie 2: Dwa poziomy testowania: wewnętrzne wbudowane w zespół zwinny zewnętrzne niezależny zespół testowy, angażowany na żądanie na końcu każdego sprintu. zachowanie niezależności, tacy testerzy mogą dokonywać obiektywnej, bezstronnej oceny oprogramowania. Warszawa, 25 maj /52

41 Rozwiązania Rozwiązanie 2: Ale: nacisk czasowy (opóźnienie o 1 iterację), brak zrozumienia nowych cech produktu związki z interesariuszami biznesowymi i deweloperami często rodzą problemy w tym podejściu. Warszawa, 25 maj /52

42 Rozwiązania Rozwiązanie 2 plus: niezależny zespół testowy = kilku wyspecjalizowanych testerów poza zespołem zwinnym wykonujących czynności długo-terminowe i/lub niebędące w przebiegu jak np. tworzenie narzędzi do automatycznego testowania, wykonanie testów niefunkcjonalnych, tworzenie i wspieranie środowiska testowego wykonanie poziomów testów, które mogą nie mieścić się (czasowo) w iteracji testy integracyjne systemu. Warszawa, 25 maj /52

43 Rozwiązania Rozwiązanie 2 plus: testerzy przydzieleni do zespołu zwinnego na zasadzie długoterminowej umowy, umożliwiającej im podtrzymywać ich niezależność macierzowa struktura organizacyjna Szefostwo Zespół zwinny Testy wewnętrzne Niezależny zespól testowy Warszawa, 25 maj /52

44 Rozwiązania Rozwiązanie 2 plus k-ta iteracja (k+1) iteracja Testy wewnętrzne Nowe historyjki (zmiany + usterki) Nowe historyjki (zmiany + usterki) Niezależny zespół testowy testy zewnętrzne Akceptacyjne UAT Eksploracyjne Niefunkcjonalne Oparte na scenariuszach ( end-to-end ) Warszawa, 25 maj /52

45 PYTANIE PODEJŚCIE ZWINNE == SUKCES?? Warszawa, 25 maj /52

46 Podsumowanie Dodatkowe cechy testera w zespole zwinnym w stosunku do testera w zespole tradycyjnym: znajomość automatyzacji, zwłaszcza: wytwarzanie sterowane testami TDD wytwarzanie sterowane testami akceptacyjnymi ATDD, testowanie białoskrzynkowe. Warszawa, 25 maj /52

47 Podsumowanie Testerzy w zespołach zwinni powinni: współpracować w zespole praca w parach szybko reagować na zmiany modyfikacja, poprawianie, dodawanie nowych przypadków testowych planować i organizować swoja pracę ROZWIJAĆ SIĘ Warszawa, 25 maj /52

48 Podsumowanie Wyzwanie dla testerów zwinnych: fanatyk, maniak, zapaleniec? ciągłe uczenie się z doświadczenia? kiedy? Fail fast Fail often Learn quickly Learn continually Fail cheap Learn inexpensively * Narzędzia, narzędzia, narzędzia, wspomaganie deweloperów *d Amico V. The state of Agile Warszawa, 25 maj /52

49 REKLAMA Zostań Certyfikowanym Testerem Zwinnym W czerwcu 2014 GA ISTQB zaakceptowało Sylabus rozszerzenia poziomu podstawowego: Tester zwinny Od września 2014 istnieje polska wersja o Nie jest idealna uwagi mile widziane Egzaminy zarówno po polsku jak i po angielsku o Obecnie mamy w Polsce około 10 Certyfikowanych Testerów Zwinnych Warszawa, 25 maj /52

50 REKLAMA Zapraszamy na TESTWAREZ 2015 Kiedy: 7 9 października 7 października - warsztaty 8 9 października konferencja 8 października - integracja Gdzie: Hotel Windsor Jachranka koło Serocka Liczba miejsc ograniczona (<=300); kilkanaście jest już zajętych (organizatorzy ) Więcej na Warszawa, 25 maj /52

51 REKLAMA Zapraszamy na TESTWAREZ 2015 Ceny promocyjne do końca czerwca Dlaczego tak drogo? Konferencja jest samofinansująca Brak sponsorów Hotel!!! SJSI wyjdzie na zero przy 250 uczestnikach Więcej na Warszawa, 25 maj /52

52 Dzięki za uwagę PYTANIA MILE WIDZIANE Warszawa, 25 maj /52