Zarządzanie Testowaniem Oprogramowania

Transkrypt

1 Zarządzanie Testowaniem Oprogramowania Prowadzący: Remigiusz Gadecki Rafał Potocki Agenda 1. Planowanie zadań Plan testów Podział zadań Planowanie zasobów Harmonogram Produkty w procesie testowania 2. Przeprowadzanie testów 3. Kontrola postępu prac 4. Zarządzanie zgłoszeniami defektów 5. Zarządzanie środowiskami 6. Szef testów 7. Testalia 1

2 Cel planowania testów Określenie zakresu, metodyki, zasobów i harmonogramu testowania Zidentyfikowanie przedmiotów testowania, funkcji do przetestowania, czynności, które trzeba wykonać oraz osób odpowiedzialnych za kaŝdą z nich Zidentyfikowanie ryzyka związanego z planem IEEE 829 (Standard for Software Test Documentation) Plan testów Plan testów to waŝny dokument kształtujący proces testowania w projekcie stanowi podstawę do organizacji testowania w projekcie Jest to dokument podrzędny wobec Planu projektu oraz informacji dotyczących jakości Nie moŝe być dokumentem oderwanym od rzeczywistości 2

3 Podział zadań Przygotowanie Test Planu Projektowanie testów Przygotowanie środowiska testowego Wykonanie testów Wykonanie retestów Zarządzanie defektami Przygotowanie raportu z testów Przykład: wykonanie testów Testy integracyjne Testy integracyjne modułu SprzedaŜ i Zarządzanie klientami Testy integracyjne modułu Magazyn i SprzedaŜ Testy funkcjonalne Testy modułu Zarządzanie klientami testy funkcji dodawanie klienta testy funkcji edycja klienta Testy modułu SprzedaŜ Testy niefunkcjonalne testy wydajnościowe przegląd interfejsu uŝytkownika 3

4 Szacowanie pracochłonności testowania Testy stanowią 10 30% pracochłonności całego projektu informatycznego Średnio stanowią 50% pracochłonności etapu implementacji pracochłonność = czas * ilość zasobów jednostka: osobogodzina, osobomiesiąc, Przykład: budŝet projektu: 800 osobogodzin maksymalny czas wykonywania testów: 1 miesiąc (176 godzin) pracochłonność testowania: 352 osobogodziny Wymagane zasoby = pracochłonność / czas = 352 / 176 = 2 Planowanie potrzebnych zasobów Do planowania zasobów wykorzystuje się jedną z metod szacowania kosztów wytwarzania oprogramowania. Najbardziej popularne metody: metoda delficka nazywana panelem ekspertów, bazuje na wiedzy i doświadczeniu osób, które zetknęły się juŝ z danym problemem metoda punktów funkcyjnych - oparta na szacowaniu pracochłonności testowania róŝnych elementów projektowanej aplikacji 4

5 Planowanie czasu / harmonogram Tworzenie harmonogramu: Polega na określeniu dat podstawowych działań w ramach czasowych projektu NaleŜy pamiętać o określeniu kamieni milowych: Przykład: rozpoczęcie i zakończenie etapu testowania, testy akceptacyjne, itp.. Harmonogram testów Harmonogram w postaci wykresu Gantta powinien mieć trend liniowy. 5

6 Harmonogram testów Dobrze przygotowany harmonogram testów powinien być zbliŝony do wodospadu: Na początku leniwy W środkowym okresie gwałtowny Na końcu powinien się uspokajać W praktyce ostatnie z etapów testów wymagają (w około 95% przypadków) zaangaŝowania maksymalnej liczby zasobów. Produkty procesu testowania Testowanie jako proces Produkty wejściowe wyjściowe Proces testowania 6

7 Produkty wejściowe ZaleŜne od cyklu produkcyjnego Stanowią podstawę do oceny jakości Przykłady: Specyfikacja wymagań Modele i diagramy wg stosownych metodyk (strukturalnych, obiektowych) Specyfikacje i opisy Kod oprogramowania Środowisko testowe Produkty wyjściowe Zarządcze Plan testów Protokoły Merytoryczne Projekty testów Dane testowe Dzienniki Raporty 7

8 Cel: organizacja testów Plan testów Zakres: Struktura organizacyjna zespołu testów Wymagane kompetencje członków zespołu Rodzaje testów Zadania testowe Harmonogram Środowisko testowe Zarządzanie błędami Standardy i normy Techniki i Narzędzia MoŜliwe ryzyka Kryteria i Metryki IEEE 829 (Standard for Software Test Documentation) Projekt testów Cel: uporządkowane przygotowanie testów Projekt testów zawartość: Cel i zakres testów Rodzaje testów Metody i kryteria oceny testów Procedury i przypadki testowe Procedury i przypadki testowe: Cel procedury Parametry środowiska testowego Scenariusz testowy Sprawdzenie wyników Przypadki testowe Dane testowe IEEE 829 (Standard for Software Test Documentation) 8

9 Dziennik testów Cel: zapis prac i wyników Zawartość: Testowany produkt Osoby przeprowadzające test Data i miejsce przeprowadzenia testu Zapis zdarzeń (Numer procedury i przypadku testowego, wynik testu, informacje o znalezionych błędach, załączniki) Protokół testów Cel: Podsumowanie wyników testów / zakończenie etapu testowania w projekcie Zawartość: Testowany produkt Końcowy raport z testów Wynik testów (pozytywny/negatywny, błędy) Decyzja: Odbiór Odbiór warunkowy Niedopuszczenie produktu IEEE 829 (Standard for Software Test Documentation) 9

10 Przeprowadzenie testów Motto: Testowanie jest procesem wykonywania oprogramowania z intencją znalezienia błędów. Proces wykonania testów Wykonanie przypadków testowych weryfikacja/ustawienie warunków początkowych wykonanie testu weryfikacja wyników testu zaraportowanie ewentualnych defektów zapisanie wykonania testu w dzienniku testów ustawienie środowiska testowego do stanu z przed warunków początkowych Przygotowanie raportu z testów Przygotowanie protokołu z testów 10

11 W skład wyniku testów wchodzą: Znalezione i zgłoszone defekty Wypełniony dziennik testów Przygotowany raport z testów Przygotowany protokół z testów Kontrola postępu prac - cel Sprawdzenie stanu wykonania zaplanowanych prac Sprawdzenie stanu zasobów 11

12 Kroki kontroli postępu prac Zgromadzenie informacji o stanie wykonania i jakości prowadzonych prac Oszacowanie zaangaŝowania zasobów podczas analizowanego okresu Sprawdzenie czy zaplanowane prace mogą być zakończone na czas i w zaplanowanym budŝecie Uaktualnienie planu testów (planu projektu) Zidentyfikowanie spraw, które wymagają szczególnej uwagi Jak dobrze kontrolować? Dostosować poziom i częstotliwość kontroli do faz projektu i wykonywanych prac Dostosować formę kontroli do złoŝoności projektu Sprawdzić, czy posiadane informacje są aktualne, uŝyteczne i dokładne Obiektywnie oceniać ilość czasu i pracy jaka została do zakończenia zadania Nie raportować więcej niŝ faktycznie jest wykonane 12

13 Zarządzanie zgłoszeniami problemów (defektów) Pomyłka (błąd człowieka, maszyny) Usterka, Defekt (wadliwy kawałek kodu źródłowego lub sprzętu) Awaria (wadliwy kawałek kodu jest wykonany i prowadzi do niepoprawnego działania systemu) 13

14 Zainteresowani zgłoszeniami defektów Testerzy Programiści Kierownik/Szef testów Kierownik projektu Klient Po co śledzenie defektów? Przekazywanie informacji Podstawa do podejmowania decyzji Informacja o stanie projektu/produktu Wczesna identyfikacja zagroŝeń Dane do analizy projektowej Dane do udoskonalania funkcjonalności 14

15 Zarządzanie defektami Skuteczne zarządzania defektami zaleŝy od: Decyzji jakiego narzędzia uŝywamy śledzenie przy uŝyciu papieru i ołówka istniejącego w firmie (czy pasuje?) zakupionego (dostrojonego do potrzeb) wyprodukowanego w ramach projektu Odpowiedzialności kierownika projektu czy szefa testów Typowe problemy Brak procedur: ogólny chaos Czy Testerzy są łowcami programistów? Niejasny status: Co teraz z tym błędem? Brak wsparcia dla potrzebnych statystyk Nieznajomość narzędzi lub procedur Procedury/narzędzia niedostosowane do potrzeb i wielkości projektu Brak odpowiedniego forum decyzyjnego Problemy na styku produktu środowiska 15

16 Cykl Ŝycia zgłoszenia defektu Odrzucony Znaleziony Przydzielony Naprawiony Zamknięty OdłoŜony Krytyczność defektu 1/3 Definicja krytyczności defektu: Jest to klasyfikacja defektu na podstawie oceny stopnia wpływu tego defektu na działanie SUT (Software Under Testing Aplikacja w fazie testów). IEEE Std 729 W wielu opisach pokrywa się to z pojęciem dokuczliwości defektu. 16

17 Krytyczność defektu 2/3 Określenie poziomu krytyczności defektu dokonuje się na podstawie odpowiedzi na kilka pytań: Czy moŝna ominąć defekt i kontynuować testowanie? Czy aplikacja moŝe pracować niezawodnie z defektem? Który fragment aplikacji jest odpowiedzialny za wystąpienie defektu? JeŜeli defekt został usunięty, co zmieniono podczas jego usuwania? Krytyczność defektu 3/3 Określa się następujące poziomy defektu: Krytyczny (dokuczliwość skrajna) PowaŜny (dokuczliwość duŝa) Średni (dokuczliwość średnia) Mały (dokuczliwość niewielka) Uwaga (dokuczliwość nieznana) 17

18 Krytyczność defektu (opis) Krytyczny defekt powoduje niewłaściwe działanie całego systemu lub uniemoŝliwia jego działanie. UŜytkownik nie moŝe go wykorzystać, PowaŜny defekt nie właściwego działania aplikacji, ale powoduje podawanie przez system błędnych, niekompletnych lub niespójnych wyników, albo utrudnia wykorzystywanie/testowanie aplikacji. UŜytkownik moŝe wykonywać niektóre funkcje, Średni pewien fragment całego systemu nie działa w ogóle lub nie działa prawidłowo. UŜytkownik nie moŝe wykonywać niektórych funkcji, Mały defekt nie powoduje niewłaściwego działania całego systemu ale utrudnia wykorzystanie/testowanie. PoŜądane wyniki działania są łatwo uzyskiwane w inny sposób. MoŜna wykonywać większość operacji. Uwaga defekt jest wynikiem nie zastosowania się do standardu, albo jest związany z estetyka systemu lub jest Ŝądaniem ulepszenia systemu itp. Priorytet defektu 1/2 Z klasyfikacji poziomu dokuczliwości (krytyczności) defektu powinien wynikać priorytet defektu (poziom odpowiedzialności) w celu określenia terminu poprawy. Istnieją jednak uzasadnione wyjątki, dlatego teŝ priorytet powinien być określany osobno, podczas analizy powstałych defektów. 18

19 Priorytet defektu 2/2 Poszczególne poziomy priorytetów: Natychmiast dalsze testowanie nie jest moŝliwe bez usunięcia błędu. Systemu nie moŝna uŝywać bez usunięcia błędu. NaleŜy wykonać nową wersję, Jak najszybciej błąd musi zostać usunięty jak najszybciej poniewaŝ utrudnia budowę i/lub testowanie. Testowanie aplikacji będzie znacznie utrudnione dopóki błąd nie zostanie usunięty. Błąd powinien być usunięty w najbliŝszej wersji, Normalny błąd naleŝy usunąć w zwykłym trybie podczas dalszej budowy. MoŜe on zostać usunięty w następnej wersji, Niski błąd utrudnia pracę i powinien zostać usunięty w miarę moŝliwości, OdłoŜony poprawa błędu moŝe zostać odłoŝona w czasie. Typowe raporty Lista defektów Według statusów Według krytyczności Według priorytetów Według produktów Według testerów Raporty czasowe 19

20 Narzędzia do zarządzania defektami Podstawowe funkcje: Śledzenie defektów Klasyfikacja Filtrowanie/Grupowanie Raporty Śledzenie zmian w oprogramowaniu Funkcje dodatkowe Notyfikacje owe Dołączanie zrzutów ekranowych Dołączanie plików Profilowany dostęp dla uŝytkownika Podstawowe elementy zgłoszenia Id Krótki opis DłuŜszy opis Moduł/Wersja oprogramowania Autor zgłoszenia Aktualny właściciel zgłoszenia Status Historia zmian Załącznik Powiązania z innymi błędami inne 20

21 Przykładowe narzędzia Najbardziej znane i najczęściej uŝywane narzędzia do zarządzania zgłoszeniami: BUGZILLA GFORGE Komercyjne: IBM Rational Clear Quest HP Test Director HP Quality Center - Test Director 21

22 Zarządzanie środowiskami RóŜnice między środowiskami Środowisko produkcyjne Celem istnienia środowiska produkcyjnego jest uruchomienie i udostępnienie na nim aplikacji z rzeczywistymi danymi oraz obsługa uŝytkowników. Środowisko rozwojowe/testowe Celem istnienia środowiska rozwojowego jest produkcja oprogramowania oraz naprawianie defektów. Środowisko programistyczne Celem istnienia środowiska programistycznego jest prowadzanie na nim róŝnego typu testów oraz prac prowadzonych przez programistów. 22

23 Utrzymanie środowisk Sprzęt Podobieństwo do środowiska produkcyjnego BudŜet, odpowiedzialność, utrzymanie między projektami Utrzymanie Zarządzanie konfiguracją Instalowanie narzędzi, sterowników Prawa dostępu, dostęp do danych (wiele projektów) Bezpośredni dostęp Programiści, testerzy co i na jakich zasadach ( logi )? Szef testów Kierownik Testów, Test Manager 23

24 Szef testów Szef testów to człowiek odpowiedzialny nie tylko za obsługę problemów testowych Często szef testów jest równorzędnym partnerem dla szefa projektu, a nie tylko jego pomocnikiem Powinien on mieć autonomię w zakresie swoich zadań Szef testów spojrzenie z zewnątrz Opiekun jakości Ktoś kto pilnuje, Ŝeby testy przeprowadzone były na czas, ograniczonymi zasobami i aby były wykryte wszystkie błędy W konsekwencji eliminuje kryzysy, opóźnienia itd. Zadania szefa testów W uproszczeniu jego zadania i zakres odpowiedzialności to: Planowanie testów Pozyskiwanie właściwych zasobów Ocena skuteczności wykonania testów Jest rzecznikiem konieczności testowania Będąc kierownikiem testów jesteśmy partnerem Project Managera, dlatego powinniśmy: Dobrze rozumieć podstawowy cel projektu Mieć dobrą komunikację wewnątrz i poza zespołem Być elastycznym wobec róŝnych aspektów procesu projektowego Mieć umiejętności techniczne, interepersonalne, koncepcyjne, analityczne, polityczne 24

25 Testalia Dokumentacja (plany, specyfikacje, raporty, logi, zgłoszenia) Dane testowe (wejściowe i oczekiwane poprawne wyniki) Pliki konfiguracyjne Programy do testów automatycznych Platforma testowa (sprzęt, inne oprogramowanie, sieć) Literatura The Art of Software Testing Glenford J. Meyers Metodyka wprowadzania oprogramowania na rynek Michael E. Bays Metoda punktów funkcyjnych: SJSI: 25

26 Dziękujemy 26