Jan Sabak jan.sabak@amberteam.pl Szkoła Główna Handlowa 15 16 października 2011
co to jest testowanie? analityk biznesowy a testowanie proces testowania testy właściwości dokumentacja testowa wartość testowania dla biznesu trendy i nowości 2
3
Testowanie to wykonywanie oprogramowania z intencją znalezienia błędu. Glenford Myers Sztuka testowania oprogramowania 4
ludzie są omylni działają pod presją pracują ze złożonym kodem w skomplikowanej infrastrukturze ze zmieniającymi się technologiami dużą ilością interakcji pomiędzy systemami 5
wymagania - 20% projekt - 27% kod - 33% dokumentacja - 14% regresja - 6% Capers Jones 6
testy modułowe od 15% do 50% testy nowych funkcji od 20% do 35% regresja od 15% do 30% testy systemowe od 25% do 55% testy akceptacyjne od 25% do 35% beta testy (< 10 klientów) 25% do 40% beta testy (>1000 klientów) 60% do 85% 7
nieformalne przeglądy projektu 25% do 40% formalne przeglądy projektu 45% do 65% nieformalne przeglądy kodu 20% do 35% formalne przeglądy kodu 45% do 70% 8
9
Podział na dwie role Wydobycie wymagań do systemu obsługi konferencji 10
Sprawdzenie testowalności wymagań 11
12
analiza i projektowanie implementacja i wykonanie ocena i raportowanie zamknięcie testu planowanie i nadzór 13
14
15
identyfikacja celu testowania planowanie zakresu testów ocena ryzyka planowanie metodyki testowania wdrożenie strategii testowania 16
planowanie potrzebnych zasobów ludzie, narzędzia, środowisko testowe estymacja i harmonogramowanie analizy i projektowania testów wykonania testów i raportowania poprawek określenie kryteriów zakończenia testów 17
pomiary i ich analiza monitorowanie postępu prac podejmowanie decyzji podejmowanie działań naprawczych 18
przeglądanie podstawy testów ocena testowalności wymagań i systemu projektowanie testów projektowanie środowiska testowego 19
Tworzenie przypadków i scenariuszy testowych danych testowych skryptów automatyzujących testy Weryfikacja środowiska testowego 20
sprawdzenie logu testowego określenie czy można zakończyć testy czy potrzebne jest więcej testów czy trzeba zmienić warunki zakończenia utworzenie raportu końcowego
Inwentaryzacja sprawdzenie wydań oprogramowania zamknięcie incydentów utworzenie zgłoszeń zmian do niezamkniętych incydentów udokumentowanie akceptacji oprogramowania
Archiwizacja testaliów projektu testów skryptów testowych środowiska testowego Przekazania testaliów do zespołu serwisowego Analiza wniosków z testowania
24
1. Modele wytwarzania oprogramowania 2. Poziomy testowania 3. Rodzaje i cele testowania 4. Testowanie w fazie utrzymania 25
26
Analiza wymagań Projektowanie funkcjonalne Projektowanie techniczne Wykonanie Działanie operacyjne 27
Studium wykonalności Wykonanie Analiza Działanie operacyjne P. techniczne P. funkcjonalne 28
prototypowanie Rapid Application Development Rational Unified Process metodyki zwinne (np. XP) 29
każda czynność wytwarzania ma odpowiadającą jej fazę testowania każda faza ma określone cele analiza i projektowanie testów powinny rozpoczynać się wraz z rozpoczęciem fazy wytwarzania testerzy powinni uczestniczyć w przeglądach dokumentacji 30
Testy akceptacyjne Analiza wymagań Testy systemowe Projektowanie funkcjonalne Testy integracyjne Projektowanie techniczne Testy modułowe Wykonanie 31
Testy akceptacyjne Analiza wymagań przeglądy, analiza i projektowanie testów Testy systemowe Projektowanie funkcjonalne przeglądy, analiza i projektowanie testów Testy integracyjne Projektowanie techniczne Testy modułowe Wykonanie 32
klient dostawca Analiza wymagań projektowanie testów projektowanie testów Testy systemowe Testy akceptacyjne Projektowanie funkcjonalne Testy integracyjne Projektowanie techniczne Testy modułowe Wykonanie 33
34
testy modułowe testy integracyjne wewnętrzne testy systemowe testy integracyjne zewnętrzne testy akceptacyjne 35
Testy modułowe Testy najmniejszych wyodrębnionych jednostek funkcji klas pakietów modułów funkcjonalnych podsystemów programów 36
Testy modułowe Pierwsze wykonanie testów w projekcie Zwykle testuje programista Pozwalają na największą szczegółowość Bywają lekceważone Często nieudokumentowane 37
Testy modułowe Testy strukturalne Mogą być automatyzowane Weryfikują rozwiązanie, a nie walidują Mogą być zaprojektowane i zaimplementowane przed wyprodukowaniem oprogramowania 38
Testy integracyjne Dwa znaczenia: poprzedzające integrację testy interfejsów test nowej, większej całości Zwykle łączą się z samą integracją: kto testuje, ten łączy i skręca 39
Testy systemowe Testy całego systemu pełnej architektury pełnej funkcjonalności z realistycznymi danymi testowymi Powinny być oparte na wymaganiach Weryfikują i walidują system 40
Testy systemowe Wykonywane przez niezależny zespół testowy Testy czarnoskrzynkowe Testy funkcjonalne i pozafunkcjonalne Środowisko testowe powinno być zbliżone do środowiska produkcyjnego 41
Testy systemowe Narażone na zaniedbania z niższych poziomów Trudność z lokalizacją błędów Prowadzone na końcu projektu (pośpiech) 42
Testy integracyjne Dwa znaczenia: testy interfejsów test nowej, większej całości Testy procesów biznesowych Testy protokołów komunikacyjnych Testy współdziałania ze sprzętem 43
Testy integracyjne Często sprawdzają produkty różnych dostawców Brak specyfikacji interfejsów Zmiany w systemach zewnętrznych Utrudniona komunikacja Utrudnione raportowanie błędów 44
Testy akceptacyjne Testy mające na celu formalne zaakceptowanie przekazywanego produktu przez klienta 45
Testy akceptacyjne testy akceptacyjne użytkowników operacyjne testy akceptacyjne testy zgodności z kontraktem alfa i beta testy 46
Testy akceptacyjne wykonywane przez użytkowników biznesowych walidacja systemu testy przydatności biznesowej testy użyteczności 47
Testy akceptacyjne Testy możliwości wykorzystania systemu w infrastrukturze klienta testy kopii zapasowych testy odtwarzania systemu po awarii testy administracji technicznej testy zabezpieczeń systemu 48
Testy akceptacyjne Testy weryfikujące system Na podstawie kryteriów zawartych w kontrakcie obowiązujących przepisów obowiązujących norm Projekt testów może przygotować klient lub dostawca 49
Testy akceptacyjne Testy produktów na rynek masowy Testy alfa są wykonywane u producenta oprogramowania przez niezależny zespół testowy Testy beta wykonywane są na zewnątrz organizacji producenta 50
Zaplanuj testy w projekcie tworzenia aplikacji do obsługi konferencji 51
52
53
funkcjonalność efektywność (wydajność) użyteczność bezpieczeństwo 54
Wymagania niefunkcjonalne powinny być testowalne Dla wymagań niefunkcjonalnych powinny istnieć miary Dla miar powinny istnieć progi akceptacji 55
Goal poziom strategiczny Poziomy: aktualny akceptowalny pożądany najwyższy osiągalny Question poziom operacyjny Metric poziom ilościowy 56
Wybierz dwa wymagania niefunkcjonalne dla aplikacji do obsługi konferencji Zaproponuj miary i progi przydatne w kontroli spełnienia tych wymagań 57
58
59
60
1. Identyfikator 2. Wstęp 3. Testowane elementy (test items) 4. Funkcje i atrybuty (features) do przetestowania 5. Funkcje i atrubuty poza testami 6. Podejście do testów 7. Kryteria akceptacji lub odrzucenia testowanego elementu 8. Kryteria zatrzymania i wznowienia testów 9. Produkty testowania 61
10. Zadania testowe 11. Wymagania na środowisko testowe 12. Odpowiedzialności 13. Wymagania na zespół testowy wielkość umiejętności 14. Harmonogram 15. Ryzyka i plany awaryjne 16. Zatwierdzenie 62
1. Identyfikator 2. Funkcje i atrybuty do przetestowania 3. Uszczegółowienie podejścia 4. Lista przypadków testowych 5. Kryteria akceptacji/odrzucenia funkcji lub atrybutu 63
1. Identyfikator 2. Elementy testowe 3. Wejścia 4. Wyjścia 5. Wymagania na środowisko testowe sprzęt oprogramowanie inne 6. Wymagania specjalne 7. Powiązania z innymi przypadkami 64
1. Identyfikator 2. Cel 3. Wymagania specjalne 4. Kroki procedury 65
Zapisywanie wyników Przygotowanie Start Wykonanie Pomiary Wstrzymanie Restart Zakończenie Przywrócenie środowiska testowego Plany awaryjne 66
1. Identyfikator 2. Przekazywane elementy 3. Lokalizacja 4. Status 5. Zatwierdzenie 67
1. Identyfikator 2. Opis testowane elementy (z ich wersjami) opis środowiska testowego 3. Wpisy dotyczące testów i zdarzeń opis wykonania testów wyniki procedur informacje o środowisku anomalie identyfikatory raportów incydentów 68
1. Identyfikator 2. Podsumowanie 3. Opis incydentu wejścia oczekiwane wyjścia rzeczywiste wyniki anomalie data i czas krok procedury środowisko próba powtórzenia testerzy obserwatorzy 4. Wpływ incydentu 69
Raport incydentu powinie pozawalać na znalezienie i poprawienie przyczyny tego incydentu Raport incydentu powinien być kompletny zwięzły dokładny obiektywny 70
1. Identyfikator 2. Podsumowanie 3. Rozbieżności 4. Ocena szczegółowa 5. Podsumowanie wyników 6. Ocena elementów testowych 7. Podsumowanie prac 8. Zatwierdzenie 71
Według podanego scenariusza napisz zgłoszenie błędu 72
Symulacja testów akceptacyjnych aplikacji obsługującej konerencje Dwa rzuty kostką pierwszy rzut 1 5 nie ma błędu 6 znaleziono błąd drugi rzut 1 5 waga błędu 6 pomyłka testera 73
74
Mało jest ateistów testowych, większość jest słabo wierząca Większość organizacji uważa testy za wartościowe ale niewielu kierowników potrafi policzyć, opisać i wyrazić tę wartość wielu testerów skupia się na taktyce, a ignoruje problemy strategiczne Trzy zasady wartości biznesowej testowania to co jest mierzone zostaje wykonane to co posiada wartość dostaje fundusze testowanie posiada wartość, którą można zmierzyć 75
W ujęciu ilościowym znajdują błędy do poprawienia znajdują błędy do odłożenia redukują ryzyko przez wykonanie testów dostarczają informacji W ujęciu jakościowym poprawiają reputację przez jakość ułatwiają wdrożenia zwiększają zaufanie chronią przed skutkami prawnymi zmniejszają straty w misjach i ludziach Kierownicy testów powinni rozumieć, które wartości mają zastosowanie w ich projekcie, żeby móc o nich mówić 76
Koszty jakości są sposobem na zmierzenie wartości testowania i jego efektywności Koszty jakości dzielą się na cztery kategorie koszty zapobiegania koszty wykrycia koszty awarii wewnętrznych koszty awarii zewnętrznych Budżet testowy jest częścią kosztów wykrycia i kosztów awarii wewnętrznych Koszty wykrycia i awarii wewnętrznych są zwykle mniejsze niż koszty awarii zewnętrznych, co sprawia że testowanie się opłaca 77
Koszty wykrycia Koszty awarii zewnętrznych Budżet testów $1,000,000 Koszty serwisu $3,000,000 Wartość testaliów po porj. 100,000 Spowodowane błędami 50% Koszty retestów 500,000 Koszty wykrycia netto $400,000 Koszty aw. zewn. netto $1,500,000 Liczba defektów 1,500 Liczba defektów w prod. 500 Koszt wykrycia na defekt $267 Koszt aw.zwn. na defekt $3,000 Koszty awarii wewnętrznych Return on Investment Koszty poprawek 750,000 Liczba defektów wykr. 1,500 Koszty retestów 500,000 Oszczędności na defekt $1,900 Koszty awarii wwn. netto $1,250,000 Zysk netto z testów $2,850,000 Liczba defektów 1,500 Koszty wykrycia netto $400,000 Koszt aw.wwn. na defekt $833 ROI testów 713% 78
Dodatkowe wartości ilościowe $150 000 zaoszczędzone na obsłudze w call center $250 000 zredukowanego ryzyka przez zdane testy $200 000 wartość informacji (przez zredukowanie ryzyka niepowodzenia projektu) Dodatkowe wartości jakościowe Zaufanie do wdrożenia Brak zwrotów 79
Policzyć ROI dla wprowadzenia w firmie przeglądów wymagań ROI = (V b V c ) / V c V b korzyści V c koszty 80
Dr. Matthias Hamburg, Alexander van Ewijk Sogeti Deutschland GmbH 81
82
testy eksploracyjne TDD BDD i ATDD Testing as a Service 83
Równoległe poznawanie produktu poznawanie rynku poznawanie sposobów na wywrócenie produktu poznawanie słabych stron produktu poznawanie sposobów testowania produktu testowanie produktów raportowanie incydentów zalecanie naprawiania problemów tworzenie nowych testów na podstawie doświadczeń 84
Zaprojektowane testy są zaprojektowane lub nagrane wcześniej i mogą być wielokrotnie wykonywane (nawet przez inne osoby) stawiają nacisk na rozliczalność i podejmowanie decyzji Eksploracyjne testy są projektowane i wykonywane w tym samym czasie, często nawet nie są zapisywane stawiają nacisk na adaptowanie się i uczenie 85
czyste scenariusze testowe niedokładne scenariusze testowe fragmentaryczne przypadki testowe zamówienia na testy role testy eksploracyjne freestyle 86
heurystyki szybkiego osiągnięcia pokrycia aktywne czytanie materiałów ataki listy awarii listy ryzyk projektowych scenariusze modele 87
Strategie reaktywne są trudne w zarządzaniu, słabo udokumentowane i nie skalują się SBTM częściowo zaradza tym problemom Sesja testowa podstawowa jednostka pracy testera nieprzerywana skupiona na konkretnym obiekcie testowania skupiona na konkretnym celu testowania (zamówienie na testy) Podczas sesji tworzony jest raport Pozwala na zarządzanie testami i raportowanie, ale nadal nie pozwala na skalowanie 88
Sesja testowa dzieli się na trzy fazy rozpoczęcie sesji projektowanie i wykonanie testów badanie i raportowanie awarii Sesje można powtarzać w zależności od wyniku omówienia sesji 89
Zamówienie na testy Imię i nazwisko testera Data i czas rozpoczęcia Podział na zadania Pliki danych Notatki Problemy Defekty 90
Sesja kończy się omówienie 1-na-1 z kierownikiem testów Kierownik testów przegląda raport poprawia zamówienia wykonuje zmiany na podstawie informacji zwrotnej od testera planuje i szacuje kolejne sesje Sesja powinna być Past-Results-Outlook-Obstacles-Feelings Co przeszło? Co nie przeszło? Jakie błędy? Co było interesujące? 91
Ludzie 7 techników 3 Inżynierów + 1 Mgr Doświadczenie <10 lat w sumie > 20 lat w sumie Rodzaj testów Dokładne skrypty Eksploracyjne SBTM Godz. testów /dzień 42 6 Znalezione błędy 928 (78%) 261 (22%) Skuteczność bł. 22 44 # wyk. skryptów 850 0 # wprow. danych ~5,000-10,000 ~1,000 # spr. wyników ~4,000-8,000 ~1,000 Ten przykład pokazuje testy eksploracyjne połączone z testami zaprojektowanymi testami opartymi na ryzyku. Testy eksploracyjne były bardzo efektywne w przeliczeniu na ilość błędów na jednostkę czasu. Niemniej jednak testy oskryptowane dają dobrą regresję, łagodzenie ryzyka i zaufanie podczas wdrożenia. 92
Technika pisania oprogramowania Zasada Najpierw przetestuj Wykorzystywana na poziomie testów modułowych Pozwala programiście lepiej przemyśleć co ma napisać 93
94
Zasady zidentyfikuj cele różnych interesariuszy zidentyfikuj cechy oprogramowania, które przyczynią się do spełenienia tych celów zaangażuj interesariuszy w proces tworzenia oprogramowania używaj przykładów do opisu zachowania oprogramowania zautomatyzuj testy przykładów żeby mieć szybki feedback i regresję 95
Przykłady Wymagania Testy Sprawdzają 96
Given and when then Jeżeli klient kupił u mnie sweter i mam teraz trzy swetry na stanie to kiedy zwróci mi zakupiony sweter wtedy powinienem mieć cztery swetry na stanie 97
firmy, które specjalizują się w testowaniu testy akceptacyjne wydajnościowe użyteczności bezpieczeństwa rozliczenie wykonanych testów obniżanie kosztów 98