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

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 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 /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 /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 /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 /52 Retrospektywa Zespół

14 Kraków 6 marzec /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 /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 /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 /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 /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 /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 /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 /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 /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 /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 /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 /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 /52 Ale …… Braki wiedzy, Zbyt mały nacisk na testy akceptacyjne end-to-end Testowanie w projektach zwinnych

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

28 Kraków 6 marzec /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 /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 / 2 Jester – narzędzie wspomagające JUnit – darmowe Warto wiedzieć

30 Kraków 6 marzec /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 /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 /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 /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 /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 /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 /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 /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 /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 /52 PODEJŚCIE ZWINNE == SUKCES?? PYTANIE

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

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

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

43 Kraków 6 marzec /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 /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 /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 /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 /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 /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 /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 /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 /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

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