Prezentacja na temat zapewnienia jakości i testowania w środowisku metod zwinnych, czyli Agil

1. Testwarez 2010
© Krystian Kaczor 2010

2.  Tester/Test Manager/Test Lead
 Certified Scrum Master i Certified Scrum Professional
 Praktyk NLP
 7 lat doświadczenia na projektach w Szwecji, Polsce,
Iranie, Holandii
 Doświadczenie we wszystkich fazach rozwoju
oprogramowania
 Aktywny członek forum goldenline.pl
 Właściciel QAgile
2© Krystian Kaczor 2010

4.  Iteracje
 Przejrzystość
 Prostota
 Refactoring
 Działający produkt na koniec każdej
iteracji
4© Krystian Kaczor 2010

5.  Zmiana wymagań jest możliwa
 Samoorganizujący się, samowystarczalny
zespół profesjonalistów
 Małe zespoły (w Scrum 5-9 osób)
 Nieformalna komunikacja – w cztery oczy
 Regularna adaptacja – inspect and adapt
5© Krystian Kaczor 2010

6.  Oprogramowanie jest:
 dostarczone na czas,
 zintegrowane,
 przetestowane.
 Spełniona jest definicja DONE
 Biznes akceptuje wynik Sprintu
 Produkt w po iteracji jest potencjalnie
dostarczalny

7.  Feedback jest natychmiastowy. Rozmowa
ponad raportowaniem wszystkiego
 Bezpośrednia współpraca z biznesem i
deweloperami
 Brak czasu na ręczne testy regresji
 Testy opisują oczekiwania, wymagania
 Defekty są naprawiane natychmiastowo

8.  Podejście Test Driven
 Testowanie nie powstrzymuje
wypuszczenia produktu na rynek, ale
pozwala na postęp projektu
 Nie ma zespołu testerów, jest Zespół
Scrum
 Tester dostarcza feedback i dodatkowe
informacje

9.  Nie ma punktu przekazania
oprogramowania do testowania,
testowanie jest ciągłe
 Każdy testuje
 Nie ma ‘blaming game’
 Zmieniamy dyscyplinę z biegu
sztafetowego na piłkę nożną.

10.  Każde Story i zadanie są testowalne,
 Kod jest napisany i kompletny,
 Zadanie kompletnie wykonane,
 Przegląd kodu został wykonany,
 Przetestowane,
 Brak błędów w Continuous Integration,
 Brak wyjątków w logach Tomcat’a,
 Udokumentowane (JavaDoc jest
obowiązkowy)

11. 1. Bug-fix (naprawa nowych błędów)
2. Przegląd kodu
3. Nowy kod

12.  Sprawdź wszystkie warunki satysfakcji,
 System Testing,
 Naprawa defektów, ale tylko tych
krytycznych,
 Nie ma nowego kodu i nowych
funkcjonalności,
 UAT,
 Szkolenia dla pracowników,
 Aktualizacja instrukcji dla supportu
 Ostateczna retrospekcja podsumowująca
release,

13. Rozpoczęcie projektu
Planowanie Release’u
Każda Iteracja
Czytanie dokumentacji, zrozumienie projektu
Uczestniczenie w
szacowaniuStory
Pytaj o przykłady, pytaj „ a
co by było gdyby … ?”
TworzenieTest Plan’u
Napisz i wykonaj testy Stories
Napisz i wykonaj testy funkcjonalne
Potwierdź bug-fix
Testowanie w parach z testerami i deweloperami
„Show me”
Automatyzacja testów funkcjonalnych
Uruchomienie testów automatycznych
Exploratory testing
Planowanie Iteracji Tworzenie i szacowanie
zadań testerskich
WalidacjaWarunków
Satysfakcji, dodawanie
nowych

14. Release & Support
End Game
Dodaj swoje uwagi z punktu widzenia testera,
testowania i procesów, wsparcia ze strony
biznesu
WykonajTesty obciążeniowe
WykonajTesty Regresji
Wykonaj UAT
Wykonaj SystemTesting
Przetestuj dokumentację instalacji, supportu
Uczestniczenie w przygotowaniach do Release’u
Uczestniczenie w Release na Produkcję
Uczestniczenie w Retrospekcji
Retrospekcja Iteracji

15.  Elementy User Story
 Jako… (konkretny użytkownik systemu)
 chcę… (pożadana cecha lub problem, który
trzeba rozwiązać)
 bo wtedy/ponieważ… (korzyść płynąca z
ukończenia story)
 Warunki Satysfakcji
 Szczegóły dodane w formie testów
akceptacyjnych
15© Krystian Kaczor 2010

16. A good user story is:
 Independent
 Negotiable
 Valuable
 Estimable
 Sized Appropriately
 Testable
16© Krystian Kaczor 2010

17.  Niezależna
 Story nie zachodzi na inną, dzięki czemu
możemy ją zaimplementować w dowolnej
kolejności
 Łatwiej taką Story oszacować i
zaplanować
 Możemy zmienić priorytet bez
ingerowania w inne Stories
17© Krystian Kaczor 2010

18.  Story nie jest kontraktem na wykonanie
dokładnie określonej pracy
 Nadal pozostaje wystarczająco dużo
elastyczności, żeby doprecyzować
szczegóły z klientem
 Pokrywa tylko koncepcję, nie określa
rozwiązania problemu
18© Krystian Kaczor 2010

19.  Wartościowa
 Story przedstawia wartość dla klienta, nie
dla dewelopera
 Wymagania techniczne powinny być
zapisane w sposób odzwierciedlający
korzyści dla klienta
 W przypadku rozbicia Stories na
mniejsze, każda część musi nadal
przedstawiać wartość dla klienta
19© Krystian Kaczor 2010

20.  Można ją oszacować
 Estymata nie musi być dokładna
 Story jest na tyle dobrze sformułowana,
że można do niej przypisać estymatę
20© Krystian Kaczor 2010

21.  Jeżeli to możliwe Story powinna być jak
najmniejsza
 Story ma rozmiar odpowiedni do
potrzebnego szacowania na poziomie
Projektu, Release, Iteracji
21© Krystian Kaczor 2010

22.  Każda Story bez wyjątku musi być
testowalna
 Test nie koniecznie musi być
zautomatyzowany
 Jeżeli klient/PO nie wie jakie są Warunki
Satysfakcji, czyli nie wie jak przetestować
Story, to znaczy, że jej nie rozumie lub nie
ma właściwej wartości biznesowej
22© Krystian Kaczor 2010

23.  Minimalny wartościowy kawałek
 Stalowa nić
 W 2-tygodniowym Sprincie, Story nie
może być dłuższa niż 3 dni
 Nadal dostarcza pewną wartość
 Jest testowalna
23© Krystian Kaczor 2010

24. 24© Krystian Kaczor 2010
Wybór produktu
Stworzenie zamówienia
Zapisanie zamówienia w bazie
Wysyłka
Raport

25. 25© Krystian Kaczor 2010
Projekt
Architektura
Testy Akceptacyjne
Kod
Integracja
Baza danych

26. 26© Krystian Kaczor 2010
Card Conversation Confirmation
Stories są napisane
na fiszkach
Fiszki mogą mieć
adnotacje z
estymatą,
notatkami itd.
Szczegóły Story
wychodzą na jaw
podczas rozmowy z
Product Ownerem
Testy akceptacyjne
potwierdzają
poprawność
implementacji Story
REQUIREMENT

29.  xUnit testy są podstawową warstwą
 Dostarczają najszybszy feedback
 Najlepszy ROI
 Warstwa środkowa
 Staje się funkcyjnymi testami regresji
 Warstwa GUI
 Może być częściowo zautomatyzowana
 Głownie exploratory testing

30. 30© Krystian Kaczor 2010

31. 31© Krystian Kaczor 2010

32. 32© Krystian Kaczor 2010

33. 33© Krystian Kaczor 2010

34. Uwagi w 2014
• Wcześniejsze slajdy to oryginalna prezentacja
pokazana na konferencji TestWarez w 2010
• Tak zwani eksperci trzymający stwonę ISTQB
próbowali wyśmiać przedstawione pomysły
• Powiedziałem, że podejście ISTQB jest 5 lat za
tym co dzieje się na rynku
• Myliłem się
• ISTQB opublikowało Agile Tester add-on w 2014
(4 lata)
• Porównaj powyższe slajdy z zawartością sylabusa
;)
34

35. Polecam
35

36. Dziękuję
krystian.kaczor@qagile.pl
@krystian_kaczor
www.qagile.pl
Krystian Kaczor
36