Más contenido relacionado La actualidad más candente (20) Similar a TGT#17 - Efektywne testy oprogramowania w środowisku Scrumowym - Marcin Kubecki (20) Más de Trójmiejska Grupa Testerska (20) TGT#17 - Efektywne testy oprogramowania w środowisku Scrumowym - Marcin Kubecki2. 2
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Marcin Kubecki
Ekspert ds. zapewnienia jakości
i testowania oprogramowania
Oto JAParę słów o mnie
Autopromocja
4. 4
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
PROCES SCRUMOWY
Role
Scrum Master
Product Owner
Development Team
Max 9
Artefakty
Product Backlog
- Wymagania (np. User Stories)
- Defekty itp.
- Priorytetyzowany przez PO
- Każdy może dodawać do PB
- Zakres produktu
Sprint Backlog
- Lista zadań na najbliższy Sprint
- Zarządzany przez Zespół deweloperski
- Estymowany przez Zespół deweloperski
- Każdy z członków Zespołu może zająć się
dowolnym zadaniem
Sprint Goal
- Określony cel, do którego zobowiązuje się
Zespół
- Zadania ze Sprint Backloga odzwierciedlają
cel Sprintu
- PO może przerwać Sprint, jeśli CEL się
zdezaktualizuje
Sprint Planning
- Określenie celu sprintu
- Podział na zadania na najbliższe dni
- Estymacja zadań
- Określenie, co uda się zrobić w tym Sprincie
Zdarzenia
Daily Scrum
- Max 15 min
- Te same miejsce i czas rozpoczęcia
- Odpowiedzi na 3 pytania
- Wstęp do rozwiązywania problemów
Sprint Review
- Przedstawienie tego, co udało się zrobić
- Omówienie zakresu prac na kolejny Sprint
- Wyznaczenie ścieżki pracy
Sprint Retrospective
- Proces ciągłego doskonalenia
- Omówienie „dobrych” i „złych” rzeczy,
które wydarzyły się w trakcie Sprintu
Proces
Product
Increment
Product
Backlog
Sprint Planning
Daily Scrum
Work
Sprint Review
Sprint
Retrospective
Product
Backlog
Sprint Goal
Sprint Backlog
Impediments
List
5. 5
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
ZŁOTA ZASADA #0:
Efektem Sprintu ma być
DZIAŁAJĄCY WARTOŚCIOWY
PRZYROST FUNKCJONALNOŚCI
gotowy do potencjalnego wdrożenia
6. 6
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Gdzie pojawia się Rola testera w Scrumie ?
W Scrumie nie ma
dedykowanej roli
testerskiej
7. 7
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Czy na pewno tester nie jest potrzebny
w Zespole Scrumowym?
Czy programiści
przeprowadzą
poprawnie testy
akceptacyjne?
Czy programiści
dobrze
zweryfikują
swoją pracę?
Czy wystarczy
przeprowadzić
UNIT-TESTY?
Co z wymaganiami
niefunkcjonalnymi?
Kto stworzy /
utrzyma testy
automatyczne
wysokiego poziomu?
Kto przeprowadzi
ostateczne testy „User
Stories” na podstawie
testów akceptacyjnych
i doświadczenia
9. 9
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
TEAM
Analityk
Programista UI
Programista
baz danych
Tester
Jak w takim modelu
odbywają się testy
i co robi tester?
Tworzy AC razem
z Product Ownerem
/ klientem
Tworzy testy
automatyczne
Opracowuje
scenariusze
testowe
Dba
o środowiska
testowe
Bierze udział
w spotkaniach
Scrumowych
Współpracuje
z klientem
Wykonuje testy
(różnego poziomu)
ZŁOTA ZASADA #1:
To, że tester jest w Zespole,
NIE ZWALNIA innych członków Zespołu
od testowania
10. 10
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
AKTYWNOŚCI TESTERA
Sprint
Planning
Daily Scrum Sprint Review
Sprint
Retrospective
Estymacja nakładu
potrzebnego na
testowanie
Planowanie testów
Wsparcie
w doprecyzowaniu
kryteriów akceptacji
Co testowałem w dniu
wczorajszym + efekty
testów
Co będę testował w dniu
dzisiejszym
Przeszkody
uniemożliwiające
przeprowadzenie testów
Identyfikacja ryzyka
związanego z testami
Rozmowa
z interesariuszami celem
identyfikacji oczekiwań
co do jakości
Identyfikacja problemów
z punktu widzenia
testera
Usprawnienie procesu
testowego
Aktualizacja DoD
11. 11
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
• Odpowiedzialność za rozwój testów automatycznych (szczególnie wysokiego poziomu)
• Przegląd rezultatów testów i raportowanie wyników pracy interesariuszom
• Przeprowadzanie testów niefunkcjonalnych
• Wspieranie Product Ownera przy przeprowadzaniu testów akceptacyjnych
• Wspieranie tworzenia kryteriów akceptacji przy współpracy z użytkownikiem i Product Ownerem
Aktywności testera
SPRINT
13. 13
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
TEAM
Analityk
Programista UI
Programista
baz danych
Kogo tutaj brakuje?
Jak w takim modelu
odbywają się testy?
Nikogo
Programiści testują
sobie… wzajemnie…
TDD
ZŁOTA ZASADA #2:
To, że nie ma testera,
NIE ZNACZY, że nie należy testować
14. 14
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
PRZYPOMNIENIE !!!
Efektem Sprintu ma być
DZIAŁAJĄCY WARTOŚCIOWY
PRZYROST FUNKCJONALNOŚCI
gotowy do potencjalnego wdrożenia
15. 15
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Co to znaczy „GOTOWY DO
POTENCJALNEGO WDROŻENIA” ?
Kryteria DoD – Definition of Done
16. 16
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Definition of Done - nasza definicja,
kiedy uznajemy, że przyrost jest
zakończony i nadaje się do potencjalnego
wdrożenia
KAŻDY ZESPÓŁ
POWINIEN MIEĆ
WŁASNĄ DEFINICJĘ
DoD
17. 17
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Product Backlog
US #1
US #2
US #3
Kryteria akceptacji
Kryteria akceptacji
Kryteria akceptacji
Sprint Backlog
US #1
TASK #1
TASK #2
US #2
TASK #1
TASK #2
US #3
TASK #1
TASK #2
DoD
DoD obejmuje
długość jednego
Sprintu (później
zakres DoD może
zostać zmieniony)
DoD definiuje
PO + Zespół
DoD jest
dyskutowana /
modyfikowana
podczas Sprint
Retrospective
18. 18
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
SPRINT NR #N
Definition of Done #1
• Dokumentacja do nowej / zmodyfikowanej
funkcjonalności została utworzona
• Utworzono testy jednostkowe dla krytycznej
funkcjonalności systemu określonej przez PO
oraz Zespół
• Wszystkie błędy krytyczne w systemie zostały
naprawione oraz zweryfikowane
• Testy GUI przeprowadzone na IE, Firefox,
Chrome w wersjach xxx
• Utworzony kod został opisany komentarzem
zgodnie ze standardem
19. 19
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Definition of Done #2
• Kod został umieszczony w repozytorium
• Formatki zbudowane zgodnie ze standardem
opisanym w dokumencie „X”
• Wykonano testy regresyjne
• Code Review został przeprowadzonySPRINT NR #N
20. 20
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Wspólnie zdefiniować
podstawowy zakres
obowiązujący DoD
Korzystać z DoD
w trakcie Sprintu
(spisywać uwagi,
zastrzeżenia)
Przeglądać uwagi,
redefinicja DoD
22. 22
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Kryteria akceptacji
Przeprowadzenie testów w oparciu o kryteria akceptacji powinno
dać odpowiedź na pytanie, czy wymaganie zostało
zaimplementowane w sposób poprawny i czy spełnia
oczekiwania użytkownika / klienta
23. 23
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Po co pisać kryteria akceptacji?
Pozwalają wyznaczyć granicę / zakres testów i prac
Uwypuklają cechy wymagań (np. US)
Pozwalają zweryfikować poprawność wymagania i dowiedzieć się, jakie są oczekiwania klienta
Pomagają zbudować „właściwy” system
Pozwalają „wychwycić” atrybuty niefunkcjonalne
24. 24
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Jak pisać kryteria akceptacji ?
• Najlepiej pisać z punktu widzenia użytkownika końcowego
• Zawierać oczekiwany rezultat
• Wykorzystywać prosty język nietechniczny
• Unikać słów, które mogą zostać źle zinterpretowane
Powinno
Zazwyczaj
„Dobrze”
W szczególnych
przypadkach
25. 25
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Product Owner tworzy „zarys”
kryteriów akceptacji jeszcze przed
Sprint Planning
Podczas Sprint Planning kryteria są
dyskutowane z zespołem
i dostosowywane do potrzeb
Podczas pielęgnacji PB (Backlog
Refinent) kryteria akceptacji są
dodawane, modyfikowane,
dyskutowane
Finalne kryteria akceptacji są
tworzone pod każde wymaganie
26. 26
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Jako <rola> chcę
<potrzeba> po to,
aby <korzyść>
User Stories Kryteria akceptacji
• …………………………………………
• …………………………………………
• …………………………………………
• …………………………………………
• …………...........................................
• …………………………………………
• …………………………………………
• …………………………………………
• …………………………………………
• …………………………………………
27. 27
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Jako użytkownik serwisu
mogę skorzystać
z funkcjonalności
przypominania hasła
po to, aby móc
korzystać z serwisu
w przypadku
zapomnienia hasła
US #1 – Przywrócenie hasła
Kryteria akceptacji #US1
• Po wpisaniu zarejestrowanego adresu
email i kliknięciu w przycisk
„Przypomnij hasło”, otrzymuję link na
zarejestrowany adres email,
za pomocą którego mogę nadać nowe
hasło
• Zweryfikować, czy link do nadania
nowego hasła działa maksymalnie
przez 4h
• Zweryfikować, czy przypomnienie
hasła działa tylko dla zarejestrowanych
kont (w przypadku próby
przywrócenia hasła dla
niezarejestrowanego konta, wyświetla
się komunikat xxxx)
• Zweryfikować, czy można zalogować
się na konto z nowym hasłem
28. 28
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Jako użytkownik systemu
obiegu dokumentów chcę
móc dodać dowolny plik
do dowolnego
utworzonego dokumentu
po to, aby móc rozszerzyć
funkcjonalność obsługi
dokumentów
US #2 – Dodawanie pliku do
utworzonego dokumentu
Kryteria akceptacji #US2
• Sprawdzić możliwość dodawania
plików .TXT, .PDF, .DOC
• Maksymalny rozmiar pliku to 15MB. Po
przekroczeniu rozmiaru system
powinien wyświetlić komunikat błędu
o przekroczeniu dopuszczalnego
rozmiaru
• System powinien automatycznie
zmieniać nazwę pliku (dodać 1 itd.
w przedrostku), jeśli dodajemy ten sam
plik
• Zweryfikować możliwość dodania
większej ilości plików (maksymalnie 20)
za jedną operacją (uwaga - więcej niż
1 plik do dodania)
29. 29
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Tester oprócz zdefiniowanych testów
akceptacyjnych powinien przeprowadzić
testy eksploracyjne
NALEŻY UWZGLĘDNIĆ
W SZACUNKACH
30. 30
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Tester MOŻE / POWINIEN wybrać część
testów akceptacyjnych i stworzyć dla
nich testy automatyczne
32. 32
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Repozytorium
(GIT, SVN itp.)
JENKINS DEV
PROD
TEST
Klient 1
Windows 10
IE
Klient 2
Windows 10
Firefox
Klient 3
Windows 7
Chrome
SONAR
TestLink
Selenium
Commit
Unit Test
33. 33
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Czy w Scrumie powinno się ”marnować” czas
na raportowanie defektów?
… PRZECIEŻ PRACUJEMY W JEDNYM
ZESPOLE
36. 36
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
Mamy Scrum, ale …
• Nasze Daily Scrum odbywają się raz w tygodniu - to w zupełności wystarcza
• Nie robimy Sprint Retrospective, bo przecież wszystkie problemy załatwiamy na bieżąco
• Nie robimy Daily Scrum, gdyż i tak siedzimy w jednym pokoju
• Nie robimy testów, bo nie mamy dedykowanego testera
• Nie mamy SM i PO, ponieważ nie mamy pieniędzy, aby zatrudnić odpowiednie osoby
• Nie mamy opracowanej DoD
• Nie mamy kryteriów akceptacji
• Na koniec Sprintu nie mamy użytecznego przyrostu
37. 37
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
„Zwykle, gdy ktoś usuwa jeden z podstawowych
elementów Scruma, robi tak ponieważ ten element obnaża
aspekty rzeczywistości, których nikt nie chce zauważać”
(K.Schwaber)
38. 38
www.testpro.pl
© 2017 Marcin Kubecki. Wszystkie prawa zastrzeżone.
ZŁOTA ZASADA #3:
„GRAMY” do jednej bramki,
nie w różnych zespołach.
Tester, analityk, deweloper itd.
mają jeden cel:
STWORZYĆ WARTOŚCIOWY
PRODUKT WYSOKIEJ JAKOŚCI