Zarz¹dzanie Testowaniem Oprogramowania

Zarządzanie Testowaniem
Oprogramowania
Prowadzący:
Remigiusz Gadecki
Rafał Potocki
Agenda
1. Planowanie zadań
•
•
•
•
•
2.
3.
4.
5.
6.
7.
Plan testów
Podział zadań
Planowanie zasobów
Harmonogram
Produkty w procesie testowania
Przeprowadzanie testów
Kontrola postępu prac
Zarządzanie zgłoszeniami defektów
Zarządzanie środowiskami
Szef testów
Testalia
1
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
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
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
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
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
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
Plan testów
Cel: organizacja 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ść:
Procedury i przypadki testowe:
•
•
•
•
•
•
•
•
•
•
Cel i zakres testów
Rodzaje testów
Metody i kryteria oceny testów
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
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
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
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
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
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
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
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
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
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
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
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
Narzędzia do zarządzania defektami
Podstawowe funkcje:
•
•
•
•
•
Śledzenie defektów
Klasyfikacja
Filtrowanie/Grupowanie
Raporty
Śledzenie zmian w oprogramowaniu
Funkcje dodatkowe
•
•
•
•
Notyfikacje e-mailowe
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
Przykładowe narzędzia
Najbardziej znane i najczęściej uŜywane narzędzia do
zarządzania zgłoszeniami:
• BUGZILLA – www.bugzilla.org
• GFORGE – www.gforge.org
Komercyjne:
• IBM Rational Clear Quest
• HP Test Director
HP Quality Center - Test Director
21
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
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
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
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
• http://en.wikipedia.org/wiki/Test_management_approach
• Metoda punktów funkcyjnych:
www.ploug.org.pl/konf_01/materialy/pdf/magiera.pdf
• SJSI: www.sjsi.org
25
Dziękujemy
26