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
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 2015 2/52
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 2015 3/52
Przykład historyczny Galery a łodzie Wikingów Podstawowy napęd: wiosła, wspomagane żaglem Warszawa, 25 maj 2015 4/52
Przykład historyczny Średnia łódź Wikingów drakkar: załoga 50-60 wojowników Podstawowy napęd: wiosła, wspomagane żaglem TYLKO wolni ludzie Warszawa, 25 maj 2015 5/52
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 2015 6/52
Przykład historyczny Ekspansja wikingów pomiędzy IX a XI wiekiem Warszawa, 25 maj 2015 7/52
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 2015 8/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. Warszawa, 25 maj 2015 9/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ć: 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 2015 10/52
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 2015 11/52
Manifest Agile Metodologie zwinne (miedzy innymi): extreme Programming XP, Scrum, Kanban, Lean Software Development, Dynamic Systems Development Method, Adaptive Software Development,... Warszawa, 25 maj 2015 12/52
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 2015 13/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. Warszawa, 25 maj 2015 14/52
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 2015 15/52
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 2015 16/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 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 2015 17/52
Siła trzech. Jak to uzyskać: Jak poprawiamy jakość? Codzienne pięciominutówki, Coaching, Wizualna prezentacja danych o jakości produktu. Warszawa, 25 maj 2015 18/52
Zespół Retrospektywa Warszawa, 25 maj 2015 19/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. Warszawa, 25 maj 2015 20/52
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 2015 21/52
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 2015 22/52
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 2015 23/52
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 2015 24/52
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 2015 25/52
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 2015 26/52
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 2015 27/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 Warszawa, 25 maj 2015 28/52
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 2015 29/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 Nie tylko wytwarzanie sterowane testami TDD (PRZYMUS?!) Ale także Acceptance Test Driven Development Behaviour Driven Development } odwrotna piramida testów Warszawa, 25 maj 2015 30/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 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 2015 31/52
Ale Testowanie w projektach zwinnych Braki wiedzy, Często zbyt mały nacisk na testy akceptacyjne end-toend Warszawa, 25 maj 2015 32/52
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 http://www.rbcsus.com/images/documents/measuring-defect-potentials-and-defect-removal-efficiency.pdf 2 http://www.rbcs-us.com/images/documents/ Warszawa, 25 maj 2015 33/52
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 2015 34/52
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 http://www.atlassian.com/software/clover/ 2 Jester narzędzie wspomagające JUnit darmowe http://sourceforge.net/projects/jester/ Warszawa, 25 maj 2015 35/52
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 2015 36/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 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 2015 37/52
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 2015 38/52
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 2015 39/52
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 2015 40/52
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 2015 41/52
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 2015 42/52
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 2015 43/52
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 2015 44/52
PYTANIE PODEJŚCIE ZWINNE == SUKCES?? Warszawa, 25 maj 2015 45/52
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 2015 46/52
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 2015 47/52
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 2015 48/52
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 2015 49/52
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 www.testwarez.pl Warszawa, 25 maj 2015 50/52
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 www.testwarez.pl Warszawa, 25 maj 2015 51/52
Dzięki za uwagę PYTANIA MILE WIDZIANE Warszawa, 25 maj 2015 52/52