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

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® Dictionary Working Group; Członek ISTQB® Exam Working Group; Współpracownik zespołu ISTQB® przygotowującego sylabus „Agile tester”

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.

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) ponad procedury i narzędzia Działające oprogramowanie nad wyczerpującą dokumentację Współpracę z klientem negocjację umów Reagowanie na zmiany realizowanie planu agilemanifesto.org

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), 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). agilemanifesto.org

Manifest Agile Metodologie zwinne (miedzy innymi): eXtreme Programming XP, Scrum, Kanban, Lean Software Development, Dynamic Systems Development Method, Adaptive Software Development, …... eXtreme Programming XP

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).

Manifest Agile Wyższa jakość. Ulepszone projekty. 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 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.

Jak poprawiamy jakość? 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ść? 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ść? Siła trzech. Jak to uzyskać: Codzienne „pięciominutówki”, Coaching, Wizualna prezentacja danych o jakości produktu.

Zespół Retrospektywa

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.

Zespół Budowanie zespołu Nie ma podziału na testerów i deweloperów Testerzy powinni być wbudowani w zespół Ale: 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??

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

Historyjka użytkownika REQUIREMENT (Ron Jeffrie) Card Conversation Confirmation 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.

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

Historyjka użytkownika INVEST –Testowalna 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

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.

Podstawowe czynności testerskie w projekcie zwinnym 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 Tworzenie i wykonywanie testów dla każdej historyjki, Tworzenie i wykonywanie testów funkcjonalnych, Automatyzacja testów, Szybkie testy manualne Tworzenie i testowanie w trójkach: deweloper, przedstawiciel biznesu oraz tester Każda iteracja Podstawowe czynności testerskie w projekcie zwinnym

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 współpraca właściciela produktu zaprojektować odpowiednie przypadki testowe oceniać wynik z testów właściwe – zrozumiałe dla interesariuszy projektu – raportowanie

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

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

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.

Testowanie w projektach zwinnych Ale …… Braki wiedzy, Zbyt mały nacisk na testy akceptacyjne „end-to-end”

Warto wiedzieć Ale …… Testy jednostkowe (włączając TDD) mają ograniczoną efektywność wykrywania usterek : Capers Jones1 wyliczył, że średnia efektywność testów jednostkowych jest w przedziale 25 - 30%. A Rex Black2 (rynek amerykański ) wyliczył, że dobre testy systemów robione przez NIEZALEŻNE zespoły testowe osiągają efektywność na poziomie 85%. 1Capers 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ć 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ć Podejście “testuj natychmiast po” Popularność narzędzi do badania pokrycia kodu, takich jak np. Clover1 i Jester2 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ć 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ć 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.

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.

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

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.

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.

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.

Niezależny zespól testowy 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

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

PODEJŚCIE ZWINNE == SUKCES?? PYTANIE PODEJŚCIE ZWINNE == SUKCES??

Sukces?? Galery a łodzie Wikingów Podstawowy napęd: wiosła, wspomagane żaglem Man with drum dictates the rate

Ekspansja wikingów pomiędzy 8 a 11 wiekiem Sukces ?? Slaves on galleys are NOT interesting in goals, Vikings are. When they went to other countries they dreamed about new spoils, when they returned back, they knew that their families, fellows etc. waited for them with revel (beer, bear paw,…) Glory, girls, beer,… Ekspansja wikingów pomiędzy 8 a 11 wiekiem

Sukces?? Średnia łódź Wikingów – drakkar: załoga 50- 60 wojowników Podstawowy napęd: wiosła, wspomagane żaglem TYLKO wolni ludzie Man with drum dictates the rate

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. Man with drum dictates the rate

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

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.

Podsumowanie 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 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Ę

Wyzwanie dla testerów zwinnych: 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 Fail – ulegać awarii *d’Amico V. The state of Agile

Zostań Certyfikowanym Testerem Zwinnym 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ą) poszukujemy chętnych do pracy przy polskiej wersji Egzaminy –„po wakacjach” Zapraszamy!!

Zapraszamy na TESTWAREZ 2014 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

Zapraszamy na TESTWAREZ 2014 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

Dzięki za uwagę PYTANIA MILE WIDZIANE