ݺߣ

ݺߣShare a Scribd company logo

Zapewnienie jakości w Scrum

•
•
Krystian Kaczor
Krystian Kaczor

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

1 of 36
Testwarez 2010 © Krystian Kaczor 2010
 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
Zapewnienie jakości w Scrum
 Iteracje  Przejrzystość  Prostota  Refactoring  Działający produkt na koniec każdej iteracji 4© Krystian Kaczor 2010
 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
 Oprogramowanie jest:  dostarczone na czas,  zintegrowane,  przetestowane.  Spełniona jest definicja DONE  Biznes akceptuje wynik Sprintu  Produkt w po iteracji jest potencjalnie dostarczalny
 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
 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
 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ą.
 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)
1. Bug-fix (naprawa nowych błędów) 2. Przegląd kodu 3. Nowy kod
 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,
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
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
 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
A good user story is:  Independent  Negotiable  Valuable  Estimable  Sized Appropriately  Testable 16© Krystian Kaczor 2010
 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
 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
 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
 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
 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
 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
 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© Krystian Kaczor 2010 Wybór produktu Stworzenie zamówienia Zapisanie zamówienia w bazie Wysyłka Raport
25© Krystian Kaczor 2010 Projekt Architektura Testy Akceptacyjne Kod Integracja Baza danych
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
Zapewnienie jakości w Scrum
Zapewnienie jakości w Scrum
 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© Krystian Kaczor 2010
31© Krystian Kaczor 2010
32© Krystian Kaczor 2010
33© Krystian Kaczor 2010
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
Polecam 35
Dziękuję krystian.kaczor@qagile.pl @krystian_kaczor www.qagile.pl Krystian Kaczor 36

More Related Content

Zapewnienie jakości w Scrum

  • 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
  • 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