Rzeszów, 2007 rok

„Organizacja projektów informatycznych”

Wykład 8 – Planowanie testów i

dokumentowanie

Mariusz Poręba

Kierownik

I Działu Zapewnienia

Jakości

Agenda

Wstęp

Koszt poprawy błędów

Rodzaje testów

Plan testów

Dokumentacja użytkownika

Podsumowanie

Etapy procesu KONTRAKT

Określenie wymagań klienta

Przygotowanie oferty

Przygotowanie umowy

Inicjowanie kontraktu

Planowanie kontraktu

Realizacja kontraktu

Zamknięcie kontraktu

Produkcja oprogramowania w etapie

realizacji KONTRAKTU

Szczegółowa analiza wymagań

Projekt rozwiązania

Kodowanie

Przeglądy kodu i testy modułowe

Testy integracyjne (kontrola jakości)

Instalacja i szkolenie klienta

Testy akceptacyjne (klient)

Serwis oprogramowania (help- desk, gwarancja)

Wstęp

Jaki jest cel testowania oprogramowania ?



znajdowanie błędów przed dostarczeniem
oprogramowania do klienta

Co to jest błąd ?



działania oprogramowania niezgodne ze specyfikacją
funkcjonalną lub projektem



działanie oprogramowania niezgodne z „dobrą
praktyką” oprogramowania



oprogramowanie jest trudne do użycia

Koszty poprawy błędów

Koszty poprawy błędów wykrytych w różnych
fazach produkcji:



Analiza (koszt poprawy specyfikacji)



Projektowanie (koszt poprawy dokumentu
projektowego, specyfikacji)



Programowanie (koszt poprawy kodu lub/i korekta
projektu, specyfikacji)



Testy wewnętrzne (koszt poprawy kodu, projektu,
ponownych testów modułowych)

Koszty poprawy błędów

Koszty poprawy błędów wykrytych w różnych
fazach produkcji (cd.):



Testy integracyjne (koszt poprawy kodu, ponownych
testów modułowych, złożenia wersji, instalacji,
ponownych testów integracyjnych, korekty
dokumentacji)



Wdrożenie u klienta (j.w + koszty wdrożenia/serwisu,
koszty uszkodzenia systemu – akcje naprawcze,
utrata klientów)

Rodzaje testów

Podział testów w procesie produkcji
oprogramowania:



Inspekcja kodu, testy komponentów (testy
wewnętrzne)



Testy funkcjonalne i integracyjne (testy Działu
Kontroli Jakości)



Testy akceptacyjne (testy Użytkownika – docelowego
odbiorcy przed wdrożeniem systemu na produkcję)

Rodzaje testów

Inspekcja kodu

Testy przeprowadzane przez programistów
weryfikujących wizualnie kody źródłowe

Testy komponentów

Testy grupy testerów współpracujących blisko
programistów weryfikujących wytworzone moduły
oprogramowania takich jak procedury, funkcje,
biblioteki itp..

Rodzaje testów

Testy funkcjonalne i integracyjne

Testy wyodrębnionych Działów Kontroli Jakości
zatwierdzających gotowość produktu przed
dostarczeniem do klienta. Testy mają za zadanie
weryfikację całości oprogramowania dostarczanego
do klienta w zakresie funkcjonalnym, interfejsów
pomiędzy systemami, wydajności systemu jak
również odpowiedzialne są za testy regresywne
systemu (testy dotychczasowych funkcjonalności
systemu).

Rodzaje testów

Testy akceptacyjne

Testy prowadzone przez odbiorcę przed wdrożeniem
systemu na produkcję. Weryfikują oprogramowanie
pod względem funkcjonalnym, integracyjnym
wszystkich aplikacji stanowiących całość systemu.
Sprawdzają możliwość wykonania czynności
biznesowych przez użytkowników końcowych (UAT –
User Acceptance Tests)

Plan testów

Plan testów określa zakres prac zespołu
testowego

Planowanie testowania rozpoczyna się już na
etapie tworzenia Planu Projektu gdzie określa
się:



Budżet



Zasoby



Harmonogram

Plan testów

Budżet

Budżet określony na etapie wyceny prac zespołu
testowego. Dobrze zaplanowane testy pozwalają na
precyzyjne oszacowanie kosztów procesu testowego
a w konsekwencji kosztów projektu. Konieczne jest
monitorowanie etapów prac testowych pod względem
dostępnego budżetu.

Plan testów

Zasoby

W celu zapewnienia skutecznych testów należy

odpowiednio dobrać grupę osób, które będą
uczestniczyły projekcie. Zespół testowy powinien
posiadać wiedzę merytoryczną na temat testowanego
systemu. Należy pamiętać o zorganizowaniu
odpowiednich szkoleń przed rozpoczęciem testów.

Organizacja zespołu testowego:



Kierownik Projektu Testowego



Projektant testów



Tester

Plan testów

Harmonogram

Plan testów

Plan testów powinien zawierać:



Cel



Zakres testów



Strategię testów



Scenariusze testowe



Harmonogram



Reguły zgłaszania i raportowania błędów

Plan testów

Zakres testów określa jakie elementy aplikacji
będziemy poddawać testom:

Testy instalacji

Testy administracyjne (konfiguracja aplikacji,
słowniki, użytkownicy, profile)

Testy funkcjonalne (zgodność z wymaganiami)

Testy użyteczności (obsługa interfejsu użytkownika)

Testy interfejsów z systemami zewnętrznymi

Testy wydajnościowe i obciążeniowe

Testy konwersji i migracji danych

Plan testów

Strategia testów określa w jaki sposób będzie
testowane oprogramowanie.



Czy testy będą odbywać się ręcznie czy w części
automatycznie?



Jakie narzędzia do testowania będą wykorzystane?



Jakie metody testowania zostaną wykorzystane?
(czarnej skrzynki, białej skrzynki, analiza wartości
granicznych)

Plan testów

Scenariusze testowe – zbiór przypadków testowych

Przypadki testowe – opis zdarzenia biznesowego
zachodzącego u klienta, które należy przetestować
w dostarczanym oprogramowaniu

Zadanie testowe – szczegółowy opis danych
wejściowych, akcji jakie należy wykonać w
systemie oraz spodziewanych wyników

Plan testów

Plan testów

Reguły zgłaszania i raportowania błędów



Zgłaszane są wszystkie nieprawidłowości



Wszystkie zgłoszenia rejestrowane są w systemie do
ewidencji błędów



Wszystkie zgłoszenia wymagają odpowiedniej
kwalifikacji:

Błąd krytyczny (blokuje możliwość użycia systemu lub
uniemożliwia realizację podstawowych funkcjonalności)

Błąd (ma znaczący wpływ na realizację funkcjonalności
systemu)

Usterka (problemy o minimalnym wpływie na działanie
systemu)

Dokumentacja

Dokumentacja użytkownika



Dokumentacja użytkownika stanowi integralną część
wyprodukowanego oprogramowania.



Dokumentacja jest podstawą do oceny czy system
działa poprawnie czy nie. (definicja błędu na
podstawie umów serwisowych z klientami – działanie
systemu niezgodne z dokumentacją ….)

Dokumentacja

Dokumentacja użytkownika powinna być
tworzona przez dokumentalistów.

Proces tworzenia dokumentacji:



Pisanie dokumentacji rozpoczyna się równolegle z
kodowaniem.



Na podstawie wymagań powstaje pierwsza wersja
dokumentacji.



Podlega weryfikacji przez programistów i testerów w
działach produkcyjnych.



Dokumentacja wraz z oprogramowaniem trafia do
Działów Kontroli Jakości i tam podlega testowaniu.

Podsumowanie

Cel testowania

Koszt poprawy błędu

Rodzaje testów w procesie produkcji

Plan testów (cel, zakres, strategia, scenariusze,
harmonogram, raportowanie błędów)

Dokumentacja użytkownika

Literatura

Ron Paton „Testowanie oprogramowania”
Warszawa 2002

Elfriede Dustin „Effective Software Testing.”
Boston 2002

Glenford J. Myers, „Sztuka testowania
oprogramowania” Gliwice 2005

Kwartalnik Tester, Stowarzyszenie Jakości
Systemów Informatycznych” www.sjsi.org

Model poprawy procesu testowego - Test Process
Improvement (TPI) www.sogeti.nl

Dziękuję za uwagę