Microsoft PowerPoint - wyklad

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

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

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ą ….)