Jan Sabak Szkoła Główna Handlowa października 2011

Transkrypt

1 Jan Sabak Szkoła Główna Handlowa października 2011

2 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 3

4 Testowanie to wykonywanie oprogramowania z intencją znalezienia błędu. Glenford Myers Sztuka testowania oprogramowania 4

5 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

6 wymagania - 20% projekt - 27% kod - 33% dokumentacja - 14% regresja - 6% Capers Jones 6

7 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

8 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 9

10 Podział na dwie role Wydobycie wymagań do systemu obsługi konferencji 10

11 Sprawdzenie testowalności wymagań 11

12 12

13 analiza i projektowanie implementacja i wykonanie ocena i raportowanie zamknięcie testu planowanie i nadzór 13

14 14

15 15

16 identyfikacja celu testowania planowanie zakresu testów ocena ryzyka planowanie metodyki testowania wdrożenie strategii testowania 16

17 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

18 pomiary i ich analiza monitorowanie postępu prac podejmowanie decyzji podejmowanie działań naprawczych 18

19 przeglądanie podstawy testów ocena testowalności wymagań i systemu projektowanie testów projektowanie środowiska testowego 19

20 Tworzenie przypadków i scenariuszy testowych danych testowych skryptów automatyzujących testy Weryfikacja środowiska testowego 20

21 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

22 Inwentaryzacja sprawdzenie wydań oprogramowania zamknięcie incydentów utworzenie zgłoszeń zmian do niezamkniętych incydentów udokumentowanie akceptacji oprogramowania

23 Archiwizacja testaliów projektu testów skryptów testowych środowiska testowego Przekazania testaliów do zespołu serwisowego Analiza wniosków z testowania

24 24

25 1. Modele wytwarzania oprogramowania 2. Poziomy testowania 3. Rodzaje i cele testowania 4. Testowanie w fazie utrzymania 25

26 26

27 Analiza wymagań Projektowanie funkcjonalne Projektowanie techniczne Wykonanie Działanie operacyjne 27

28 Studium wykonalności Wykonanie Analiza Działanie operacyjne P. techniczne P. funkcjonalne 28

29 prototypowanie Rapid Application Development Rational Unified Process metodyki zwinne (np. XP) 29

30 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

31 Testy akceptacyjne Analiza wymagań Testy systemowe Projektowanie funkcjonalne Testy integracyjne Projektowanie techniczne Testy modułowe Wykonanie 31

32 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

33 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 34

35 testy modułowe testy integracyjne wewnętrzne testy systemowe testy integracyjne zewnętrzne testy akceptacyjne 35

36 Testy modułowe Testy najmniejszych wyodrębnionych jednostek funkcji klas pakietów modułów funkcjonalnych podsystemów programów 36

37 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

38 Testy modułowe Testy strukturalne Mogą być automatyzowane Weryfikują rozwiązanie, a nie walidują Mogą być zaprojektowane i zaimplementowane przed wyprodukowaniem oprogramowania 38

39 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

40 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

41 Testy systemowe Wykonywane przez niezależny zespół testowy Testy czarnoskrzynkowe Testy funkcjonalne i pozafunkcjonalne Środowisko testowe powinno być zbliżone do środowiska produkcyjnego 41

42 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

43 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

44 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

45 Testy akceptacyjne Testy mające na celu formalne zaakceptowanie przekazywanego produktu przez klienta 45

46 Testy akceptacyjne testy akceptacyjne użytkowników operacyjne testy akceptacyjne testy zgodności z kontraktem alfa i beta testy 46

47 Testy akceptacyjne wykonywane przez użytkowników biznesowych walidacja systemu testy przydatności biznesowej testy użyteczności 47

48 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

49 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

50 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

51 Zaplanuj testy w projekcie tworzenia aplikacji do obsługi konferencji 51

52 52

53 53

54 funkcjonalność efektywność (wydajność) użyteczność bezpieczeństwo 54

55 Wymagania niefunkcjonalne powinny być testowalne Dla wymagań niefunkcjonalnych powinny istnieć miary Dla miar powinny istnieć progi akceptacji 55

56 Goal poziom strategiczny Poziomy: aktualny akceptowalny pożądany najwyższy osiągalny Question poziom operacyjny Metric poziom ilościowy 56

57 Wybierz dwa wymagania niefunkcjonalne dla aplikacji do obsługi konferencji Zaproponuj miary i progi przydatne w kontroli spełnienia tych wymagań 57

58 58

59 59

60 60

61 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

62 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

63 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

64 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

65 1. Identyfikator 2. Cel 3. Wymagania specjalne 4. Kroki procedury 65

66 Zapisywanie wyników Przygotowanie Start Wykonanie Pomiary Wstrzymanie Restart Zakończenie Przywrócenie środowiska testowego Plany awaryjne 66

67 1. Identyfikator 2. Przekazywane elementy 3. Lokalizacja 4. Status 5. Zatwierdzenie 67

68 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

69 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

70 Raport incydentu powinie pozawalać na znalezienie i poprawienie przyczyny tego incydentu Raport incydentu powinien być kompletny zwięzły dokładny obiektywny 70

71 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

72 Według podanego scenariusza napisz zgłoszenie błędu 72

73 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 74

75 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

76 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

77 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

78 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

79 Dodatkowe wartości ilościowe $ zaoszczędzone na obsłudze w call center $ zredukowanego ryzyka przez zdane testy $ wartość informacji (przez zredukowanie ryzyka niepowodzenia projektu) Dodatkowe wartości jakościowe Zaufanie do wdrożenia Brak zwrotów 79

80 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

81 Dr. Matthias Hamburg, Alexander van Ewijk Sogeti Deutschland GmbH 81

82 82

83 testy eksploracyjne TDD BDD i ATDD Testing as a Service 83

84 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

85 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

86 czyste scenariusze testowe niedokładne scenariusze testowe fragmentaryczne przypadki testowe zamówienia na testy role testy eksploracyjne freestyle 86

87 heurystyki szybkiego osiągnięcia pokrycia aktywne czytanie materiałów ataki listy awarii listy ryzyk projektowych scenariusze modele 87

88 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

89 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

90 Zamówienie na testy Imię i nazwisko testera Data i czas rozpoczęcia Podział na zadania Pliki danych Notatki Problemy Defekty 90

91 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

92 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ł # wyk. skryptów # 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

93 Technika pisania oprogramowania Zasada Najpierw przetestuj Wykorzystywana na poziomie testów modułowych Pozwala programiście lepiej przemyśleć co ma napisać 93

94 94

95 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

96 Przykłady Wymagania Testy Sprawdzają 96

97 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

98 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