Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Rola testera w projektach zwinnych: nowe wyzwania Lucjan Stapp Politechnika Warszawska Stowarzyszenie Jakości Systemów Informatycznych

Podobne prezentacje


Prezentacja na temat: "Rola testera w projektach zwinnych: nowe wyzwania Lucjan Stapp Politechnika Warszawska Stowarzyszenie Jakości Systemów Informatycznych"— Zapis prezentacji:

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

2 Kraków 6 marzec 20142/52 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 ® Dictionary Working Group; Członek ISTQB ® Exam Working Group; Współpracownik zespołu ISTQB ® przygotowującego sylabus Agile tester Lucjan Stapp

3 Kraków 6 marzec 20143/52 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 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah). Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania.

4 Kraków 6 marzec 20144/52 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ć: Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej. Ludzi i ich wzajemne interakcje (współdziałanie) ponadprocedury i narzędzia Działające oprogramowanienadwyczerpującą dokumentację Współpracę z klientemnadnegocjację umów Reagowanie na zmianynad realizowanie planu agilemanifesto.org

5 Kraków 6 marzec 20145/52 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), Samoorganizujący się, samowystarczalny zespół profesjonalistów, Małe zespoły (do 10 osób), Nieformalna komunikacja – w cztery oczy, Regularna adaptacja (inspect and adapt). Manifest Agile agilemanifesto.org

6 Kraków 6 marzec 20146/52 Manifest Agile Metodologie zwinne (miedzy innymi): eXtreme Programming XP, Scrum, Kanban, Lean Software Development, Dynamic Systems Development Method, Adaptive Software Development, …... eXtreme Programming XP

7 Kraków 6 marzec 20147/52 Manifest 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).

8 Kraków 6 marzec 20148/52 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. Manifest Agile

9 Kraków 6 marzec 20149/52 Lepsze wskaźniki ekonomiczne. 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. Manifest Agile

10 Kraków 6 marzec 201410/52 Siła trzech (przedstawiciel biznesu +developer + tester). Podejście cały zespół Cały zespół jest zaangażowany w konsultacje oraz 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. Jak poprawiamy jakość?

11 Kraków 6 marzec 201411/52 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 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. Jak poprawiamy jakość?

12 Kraków 6 marzec 201412/52 Siła trzech. Jak to uzyskać: Codzienne pięciominutówki, Coaching, Wizualna prezentacja danych o jakości produktu. Jak poprawiamy jakość?

13 Kraków 6 marzec 201413/52 Retrospektywa Zespół

14 Kraków 6 marzec 201414/52 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.

15 Kraków 6 marzec 201415/52 Budowanie zespołu Nie ma podziału na testerów i deweloperów Testerzy powinni być wbudowani w zespół Ale: Zespół Ilu członków zespołu naprawdę koncentruje 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??

16 Kraków 6 marzec 201416/52 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 Historyjka użytkownika

17 Kraków 6 marzec 201417/52 Card Conversation C onfirmation Historyjki są napisane na fiszkach. Fiszki mogą mieć adnotacje z estymatą, notatkami itd. Szczegóły Historyjki wychodzą na jaw podczas rozmowy z klientem / właścicielem produktu. Testy akceptacyjne potwierdzają poprawność implementacji historyjki. REQUIREMENT (Ron Jeffrie) Historyjka użytkownika

18 Kraków 6 marzec 201418/52 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 INVEST Historyjki użytkownika Bill Wake, INVEST in Good stories, and SMART Tasks

19 Kraków 6 marzec 201419/52 Historyjka użytkownika 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 INVEST – T estowalna Testy koncentrują się na prostych problemach

20 Kraków 6 marzec 201420/52 Historyjka użytkownika INVEST –T estowalna ALE Testowanie w podejściu zwinnym powinno być iteracyjne Testerzy muszą (często?) pracować bez pełnej dokumentacji Testerzy powinni być elastyczni.

21 Kraków 6 marzec 201421/52 Podstawowe czynności testerskie w projekcie zwinnym Testowanie w projektach zwinnych Początek projektu Planowanie wydania Planowanie iteracji Zrozumienie biznesowych podstaw projektu Szacowanie historyjek; dopytywania: A co, jeśli…? 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

22 Kraków 6 marzec 201422/52 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

23 Kraków 6 marzec 201423/52 Testowanie w projektach zwinnych PRAWDOPOBIEŃSTWOPRAWDOPOBIEŃSTWO WPŁYW II IV I III N W Ś N W Ś Musimy Powinniśmy Możemy Olewamy Koncentracja na testach jednostkowych Koncentracja na testach akceptacyjnych Tester powinien móc rozróżnić pomiędzy tym co krytyczne, co poważne, co istotne, a co jest chciejstwem Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne

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

25 Kraków 6 marzec 201425/52 Testowanie w projektach zwinnych 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. Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne

26 Kraków 6 marzec 201426/52 Ale …… Braki wiedzy, Zbyt mały nacisk na testy akceptacyjne end-to-end Testowanie w projektach zwinnych

27 Kraków 6 marzec 201427/52 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 http://www.rbcs- us.com/images/documents/Measuring-Defect-Potentials-and-Defect-Removal-Efficiency.pdf 2 http://www.rbcs-us.com/images/documents/ Warto wiedzieć

28 Kraków 6 marzec 201428/52 Testowanie jednostkowe jest ograniczone w kwestii wykrywania błędów. Wniosek: testowanie jednostkowe pomaga, głównym filtrem do zapobiegania nadmiernym usterkom pozostają testy systemowe. Warto wiedzieć

29 Kraków 6 marzec 201429/52 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 http://www.atlassian.com/software/clover / 2 Jester – narzędzie wspomagające JUnit – darmowe http://sourceforge.net/projects/jester/ Warto wiedzieć

30 Kraków 6 marzec 201430/52 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ą. Warto wiedzieć

31 Kraków 6 marzec 201431/52 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 przebiegach – 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. Warto wiedzieć

32 Kraków 6 marzec 201432/52 Testowanie w projektach zwinnych 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. Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne

33 Kraków 6 marzec 201433/52 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 Rozwiązania

34 Kraków 6 marzec 201434/52 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. Rozwiązania

35 Kraków 6 marzec 201435/52 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. Rozwiązania

36 Kraków 6 marzec 201436/52 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. Rozwiązania

37 Kraków 6 marzec 201437/52 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 Rozwiązania Szefostwo Zespół zwinny Testy wewnętrzne Niezależny zespól testowy

38 Kraków 6 marzec 201438/52 Rozwiązania Wydanie+ zmiany Niezależny zespól testowy k-ta iteracja (k+1) iteracja Nowe historyjki ( zmiany + usterki ) Wydanie+ zmiany Testy wewnętrzne testy zewnętrzne Akceptacyjne UAT Eksploracyjne Niefunkcjonalne Oparte na scenariuszach (end-to-end) Nowe historyjki ( zmiany + usterki ) Rozwiązanie 2 plus

39 Kraków 6 marzec 201439/52 PODEJŚCIE ZWINNE == SUKCES?? PYTANIE

40 Kraków 6 marzec 201440/52 Sukces?? Galery a łodzie Wikingów Podstawowy napęd: wiosła, wspomagane żaglem

41 Kraków 6 marzec 201441/52 Sukces ?? Ekspansja wikingów pomiędzy 8 a 11 wiekiem

42 Kraków 6 marzec 201442/52 Sukces?? Średnia łódź Wikingów – drakkar: załoga 50- 60 wojowników Podstawowy napęd: wiosła, wspomagane żaglem TYLKO wolni ludzie

43 Kraków 6 marzec 201443/52 Sukces?? 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.

44 Kraków 6 marzec 201444/52 Sukces ?? ALE Ekspansja Wikingów to okres od połowy VIII wieku do wieku XII Galery były używane od VII wieku przed Chrystusem do XVIII wieku naszej ery Handel i transport to galery, a NIE długie łodzie Wikingów

45 Kraków 6 marzec 201445/52 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. Podsumowanie

46 Kraków 6 marzec 201446/52 Testerzy w zespołach zwinni powinni: mieć pozytywne nastawienie do pozostałych członków zespołu być zorientowani na rozwiązywanie problemów wykazywać krytyczne zorientowane na jakość sceptyczne myślenie o produkcie aktywnie uzyskiwać potrzebne informacje od interesariuszy ( raczej NIE polegać na pierwotnej spisanej dokumentacji) dokładnie oceniać i raportować wyniki testów, postęp testów i jakość produktu współpracować nad testowalnością historyjek użytkownika, koncentrując się na kryteriach akceptacji, razem z przedstawicielami użytkowników i innymi interesariuszami szybko reagować na zmiany modyfikacja, poprawianie, dodawanie nowych przypadków testowych Podsumowanie

47 Kraków 6 marzec 201447/52 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Ę Podsumowanie

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

49 Kraków 6 marzec 201449/52 REKLAMA Zostań Certyfikowanym Testerem Zwinnym GA ISTQB ® w końcu miesiąca zaaprobuje (?) Sylabus rozszerzenia poziomu podstawowego: Tester zwinny Polska wersja – przed wakacjami (prace już trwają) o poszukujemy chętnych do pracy przy polskiej wersji Egzaminy –po wakacjach Zapraszamy!!

50 Kraków 6 marzec 201450/52 REKLAMA Zapraszamy na TESTWAREZ 2014 Hasło konferencji: Mobilis in Mobili ruchome w ruchomości* *dewiza kapitana Nemo z Dwadzieścia tysięcy mil podmorskiej żeglugi

51 Kraków 6 marzec 201451/52 REKLAMA Zapraszamy na TESTWAREZ 2014 Mobilis in Mobili Kiedy: koniec września Gdzie: 1 dzień – Gdynia (na lądzie) Wieczorem – impreza na promie; płyniemy do Szwecji 2 dzień – na promie; wracamy ze Szwecji Liczba miejsc ograniczona (<=292); kilkanaście jest już zajętych (organizatorzy ) Więcej na www.testwarez.pl

52 Kraków 6 marzec 201452/52 Dzięki za uwagę PYTANIA MILE WIDZIANE


Pobierz ppt "Rola testera w projektach zwinnych: nowe wyzwania Lucjan Stapp Politechnika Warszawska Stowarzyszenie Jakości Systemów Informatycznych"

Podobne prezentacje


Reklamy Google