Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania defektów; - presja na zakończenie implementacji; - brak testów integracyjnych;
Liczba defektów Testujemy dedykowanymi zasobami (ang. agile testers) Dystrybucja defektów I 4 35 3 25 2 25 2 15 1 5 3 6 9 12 15 18 21 24 27 3 33 36 39 42 Tygodnie (3 tygodnie - 1 sprint) 15 1 5 Rozwój produktu Testy systemowe Faza stabilizacji
Rozłożenie pracy pomiędzy wszystkich członków.
Rozłożenie pracy pomiędzy wszystkich członków. Założenie: I sprint:
Rozłożenie pracy pomiędzy wszystkich członków. Założenie: I sprint: III sprint:
Rozłożenie pracy pomiędzy wszystkich członków. - testowanie staje sie rolą rotacyjną; - brak projektowania i przeglądania testów; - niska jakość testów; - brak feedbacku; - przepychanie nie skończonych zadań; - nietestowanie wymagań; - zaniżony priorytet testów; - brak testów integracyjnych; - waterfalliki ; - nie logowanie defektów; - brak wczesnego testowania; - wspólne standupy - ten sam manager;
Liczba defektów Rozłożenie pracy pomiędzy wszystkich członków. 5 45 4 35 3 25 2 15 1 5 Dystrybucja defektów II 3 6 9 12 15 18 21 24 27 3 33 36 39 42 Tygodnie (3 tygodnie - 1 sprint) 3 25 2 15 1 5 Rozwój produktu Testy systemowe Faza stabilizacji
Interesariusz to osoba zainteresowana sukcesem lub porażką naszego projektu.
Jakie są oczekiwania i cele kluczowych interesariuszy? Interesariusz Oczekiwania Cele Zespół programistów Kierownik projektu Testerzy systemowi pomoc osób testujących przy prewencji defektów, szybki feedback po każdym sprincie, dostarczenie przetestowanych wymagań przed sprintem, analiza ryzyka produktu Brak konfliktów pomiędzy programistami a testerami, owocna współpraca na linii: programiści, testerzy i architekt, monitorowanie ryzyka produktowego, otrzymywanie raportów po każdym sprincie, oprogramowanie spełnia bramki jakości Dostarczony system nie będzie zawierać blokujących defektów i krytycznych awarii, środowisko będzie znane i ustalone, itd. Dostarczenie oprogramowania na czas z mniejszą liczbą błędów niż poprzednio, rozwój zawodowy itd. Dostarczenie projektu na czas i w ramach budżetu z wysokim poziomem jakości, premie za przechodzenie przez bramki jakościowe, terminowe przejście przez wszystkie kamienie milowe Wykrycie maksymalnie 5% defektów z całości po zakończeniu fazy testów systemowych.
- oddzielne standupy; - osobne procesy pracy; - testowanie wymagań; - różni managerowie; - wspólny cel; - analiza ryzyka produktowego; - rzeczywisty feedback po każdym sprincie; - prewencja defektów;
Sprint n Sprint n +1 Testowanie wymagań do sprintu n tydzień 3 Analiza ryzyka Walidacja Analiza i projektowanie Testowanie wymagań do sprintu n +1 Wykonanie testów ze sprintu n-1. tydzień 2 Implementacja testów tydzień 1 tydzień 3 Przegląd ryzyk i retrospektywa Planowanie iteracji Wprowadzenie do zadań sprintu n. Przegląd ryzyk i retrospektywa
Liczba defektów 4 35 3 25 2 15 1 5 Dystrybucja defektów III 3 6 9 12 15 18 21 24 27 3 33 36 39 42 Tygodnie (3 tygodnie - 1 sprint) 2 18 16 14 12 1 8 6 4 2 Rozwój produktu Testy systemowe Faza stabilizacji
5 25 5 25 5 25 45 4 35 3 25 2 15 1 5 3 6 9 12 15 18 21 24 27 3 33 36 39 42 2 15 1 5 45 4 35 3 25 2 15 1 5 3 6 9 12 15 18 21 24 27 3 33 36 39 42 2 15 1 5 45 4 35 3 25 2 15 1 5 3 6 9 12 15 18 21 24 27 3 33 36 39 42 2 15 1 5 4-45% 7-75% 27-32% 58-63% 61-66% 82-87% www.zarzadzaj-soba.pl
5 45 4 35 3 25 2 15 1 5 3 6 9 12 15 18 21 24 27 3 33 36 39 42 25 2 15 1 5 - skuteczna prewencja defektów; - testy prioretyzowane wg. ryzyka - dobry feedback po każdym sprincie; - wczesne testowanie; - testy integracyjne; - jest czas na zastosowanie akcji poprawczych; - lepsze zrozumienie produktu; - ekspertyza środowiska testowego; - efektywna komunikacja; - lepszy monitoring postępu prac i jakości w projekcie;
Identyfikacja odbywa się na początku każdego sprintu i polega na zebraniu wszystkich Funkcjonalności, które mają być zaimplementowane w trakcie pojedynczego sprintu.
Ocena ryzyka prowadzone przez 8 osób (4 grupy po dwie osoby) reprezentujących każdy z punktów widzenia tj. programistów, architekta, testerów, testerów systemowych i kierownika projektu. Każde zadanie jest oceniane w skali od 1 do 5 (5 najwyższy poziom ryzyka) pod kątem prawdopodobieństwa wystąpienia błędu oraz wpływu na system w przypadku awarii.
Reakcja na ryzyko wraz ze wzrostem poziomu ryzyka rośnie czas oraz zasoby które są Przypisywane do wybranego zadania, np. dla 5 : - bardzo szczegółowa analiza i pomoc przy projektowaniu; - przypadki testowe wymyślane heurystycznie np. 6-3-5; - powtarzanie testów z większą częstotliwością; - testing dojo; - dokładne testy eksploracyjne i integracyjne; Monitorowanie oceby ryzyk dla pojedynczego sprintu są przeglądane pod koniec tego sprintu.
Testing Dojo a efektywność? Wiedza Efektywność
Wiedza Efektywność