Dokumentacja testów systemu informatycznego

1

KittyTeam

SYSTEM INFORMATYCZNY OBSŁUGI

BIURA PODRÓŻY

Dokumentacja testów (PKN ISO 8492)

Warszawa, 2010

Dokumentacja testów systemu informatycznego

2

Spis treści

1. Wstęp

2. Badania prognostyczne
3. Weryfikacja i walidacja
4. Klasyfikacja błędów i rodzaje testów

4.1. Co podlega testowaniu;
4.2. Przypadki testowe i scenariusze;
4.3. Drzewo błędów;
4.4. Strategia białej i czarnej skrzynki;
4.5. Zespół oceniający i testy akceptacyjne;

5. Audyt
6. Wykorzystywane narzędzia
7. Podsumowanie

7.1. Przyszłe wersje

Status dokumentu

Zespół wytwórczy 9/2010/GB w składzie

Kierownik projektu / Zamawiający

Paulina Turlewicz

Zamawiający / Tester akceptacyjny

Piotr Szela

Analityk / Projektant

Piotr Surma

Analityk / Tester wewnętrzny

Maciej Zarzycki

Projektant / Tester wewnętrzny

Karol Pawłowski

Zmiany w stosunku do wersji poprzedniej

Wersja pierwsza.

Dokumentacja testów systemu informatycznego

3

1. Wstęp

Niniejszy dokument stanowi wprowadzenie do fazy testów systemu informatycznego dla biura

podróży „Husajn”. Definiuje zarówno testy prognostyczne realizowane przez kolejne kroki procesu
tworzenia oprogramowania, jak i testy przeprowadzane w koocowej fazie implementacji. Proces
wytwórczy przebiega w modelu V, stąd każdy etap posiada własne poziomy testowania i system
oceniania.

Celem fazy testów jest znalezienie jak największej liczby błędów w systemie. Im bowiem

wyszukane będzie ich więcej, tym mniej pozostanie nie znalezionych. Niemniej jednak nie wolno
polegad na fakcie, że system będzie całkowicie pozbawiony błędów. Jest to podejście irracjonalne i
mogące stwarzad poważniejsze konsekwencje niż sam fakt istnienia błędu.

2. Badania prognostyczne

Już na etapie analizy i projektu, a nawet definiowania wymagao należy upewniad się o jakości

założeo i wywodów. Badania prognostyczne polegają na badaniu systemu bez wgłębiania się w kod
(którego może de facto jeszcze nie byd). Badania tego typu są stosunkowo tanie do przeprowadzenia
w porównaniu z testowaniem w późniejszych fazach. Testy te zwiększają prawdopodobieostwo
uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów. Im bowiem usterka wykryta
zostanie wcześniej, tym łatwiej ją wyeliminowad i będzie odgrywad mniejszy wpływ na inne elementy
systemu.

Mimo wszystko do testów na tym etapie należy podchodzid z lekką rezerwą, gdyż polegają one na

badaniach modelu, co może zmniejszyd dokładnośd (potencjalna rozbieżnośd z właściwościami
implementacyjnymi), a nawet byd nie do kooca zgodne z modułami ostatecznie
zaimplementowanymi.

W projektowanym systemie badaniom prognostycznym podlegad będzie przede wszystkim

uwzględnienie wszystkich wymagao funkcjonalnych i niefunkcjonalnych (oraz ich zgodnośd ze
specyfikacją) w fazie analizy i projektu oraz stopniowe ich implementowanie. Testy polegają na
eksperymentowaniu z kodem pisanym na bieżąco, rozpoznaniu funkcjonalności testowanego kodu
oraz zaprojektowaniu koocowych testów. Sprawdzamy także, czy nie ma konfliktów w specyfikacji,
które uniemożliwiają zaimplementowanie funkcjonalności w sposób zgodny z wymaganiami.

Należy przebadad zarówno własności statyczne, jak i dynamiczne. Należy zwrócid uwagę na

wymianę informacji pomiędzy funkcjami, między którymi zaprojektowano przepływ informacji.
Trzeba sprawdzid też, czy nadmiarowe informacje nie są widoczne dla świata zewnętrznego.

Dokumentacja testów systemu informatycznego

4

3. Weryfikacja i walidacja

Weryfikując wykonujemy całośd przeglądów, inspekcji, sprawdzania i audytowania. Ustalamy i

dokumentujemy w ten sposób czy składowe, usługi i dokumenty zgadzają się z wyspecyfikowanymi
wymaganiami. Musimy określid, czy system w swoich kolejnych fazach rozwoju spełnia warunki
zakładane podczas startu tej fazy, a przede wszystkim zakładane w fazie specyfikacji. Kolejne dalsze
punkty wyszczególniają poszczególne potencjalne błędy i testy. W skład weryfikacji wchodzą także
badania prognostyczne.

Walidacją będziemy się zajmowad pod koniec procesu wytwórczego. W nim także ostatecznie

sprawdzimy zgodnośd z wymaganiami. Wynikiem tego procesu będzie atest systemu.

Ponieważ poszczególne elementy systemu informatycznego zaprojektowanego dla firmy „Husajn

Travel” są bardzo zróżnicowane, założenia, głównie funkcjonalne, muszą byd weryfikowane
oddzielnie, przez odpowiednią częśd zespołu oceniającego. Wszystkie wymagania (funkcjonalne,
niefunkcjonalne, dziedzinowe) zostały przedstawione w dokumentacji specyfikacji.

4. Klasyfikacja błędów i rodzaje testów

4.1. Co podlega testowaniu

a) Testowanie bazy danych

Tworzona baza danych zostanie przetestowana pod względem bezpieczeostwa oraz dbałości o

niski poziom redundancji (nadmiarowości) przechowywanych danych. Dostęp do wglądu w bazę
danych powinien mied tylko pracownik działu IT, który ma również możliwośd łatwej edycji zawartych
w niej rekordów. W celu zabezpieczenia przed nieumyślnym skasowaniem danych sprawdzamy
funkcjonalnośd i działanie modułu umożliwiającego tworzenie kopii zapasowych. Moduł ten ma
wbudowaną funkcję autowywoływania przed każdą próbą edycji danych. Kopię można ustawid na
wykonywanie backupu całościowego lub przyrostowego. Naszym zadaniem jest zbadanie wszystkich
możliwości obejśd tego modułu oraz miejsc w poszczególnych aplikacjach, które łączą się z bazą
danych, aby zapisane dane dostępowe do bazy były niedostępne do ewentualnego podglądu.

Wykorzystane zostanie także narzędzie do automatyzowania procesu wykonywania zapytao

testowych. W ten sposób system zarządzania bazą danych zostanie „zasypany” dużą liczbą zapytao.
Dzięki temu zbadamy nie tylko poprawnośd, ale także odpornośd systemu na duży ruch.

b) Testowanie aplikacji przeznaczonych dla pracowników

Dzięki aplikacji przeznaczonej dla pracownika, ma on możliwośd dodania oferty, przyjęcia

zamówienia. Testując sprawdzamy odpornośd formularzy na wprowadzane dane. Ewentualne błędy,
przy automatycznym zapisie do bazy danych, mogłyby spowodowad duże konsekwencje. Badamy

Dokumentacja testów systemu informatycznego

5

odpornośd na wprowadzanie danych specyficznych, bądź danych, które w dane pole wprowadzone
byd nie powinne. Tego typu testy dotyczą każdej aplikacji. Należy ponadto sprawdzid, czy dane
przesyłane między biurem a centralą nie ulegają zniekształceniu bądź przekłamaniu. Tutaj także
okazuje się pomocna aplikacja do automatyzowania procesu testowania.

c) Testowanie aplikacji internetowej dla klientów

Klient ma możliwośd zamówienia oferty przez Internet. Jest to aplikacja najbardziej narażona na

ataki z zewnątrz, ponieważ jest dostępna dla praktycznie wszystkich użytkowników. Podobnie jak
przy aplikacji pracowniczej sprawdzaliśmy aplikację w przypadkach wprowadzania złośliwych danych,
które mogą spowodowad incydenty bezpieczeostwa.

Aplikacja WWW jest narażona na specyficzne ataki, chociażby wstrzyknięcia kodu HTML, JS w

formularz i zapisanie ich w bazie. Atak typu XSS (Cross Site Scripting) może dad początek phishingowi
poprzez podmianę strony bądź przekserowanie na stronę osoby atakującej. Sprawdzając każde pole
formularza zabezpieczamy klientów przez kradzieżą tożsamości internetowej, a nawet danych
dotyczących karty płatniczej.

Należy zwrócid uwagę na ataki CSRF (Cross Site Request Forgery), które mogą doprowadzid do

nieświadomego przesyłania przez użytkownika do serwera żądania spreparowanego przez osoby o
wrogich zamiarach. Trzeba sprawdzid mechanizm potwierdzeo przy zamówieniach oraz poprawnośd
generowania tokenów (transparentnych dla użytkownika) przy każdorazowym żądaniu strony. Należy
ograniczyd metodę GET do przesyłania wrażliwych danych.

Trzeba ponadto sprawdzid podatnośd aplikacji Web na ataki Session Poisoning oraz Session

Fixation. Mogą one doprowadzid do przejęcia bądź uszkodzenia sesji użytkownika, a co za tym idzie
uzyskania dostępu do jego konta.

Szczególnie krytycznym z punktu widzenia aplikacji internetowej byłby błąd SQL Injection. Na

przetestowanie strony pod kątem podatności na niego należy przeznaczyd wiele czasu i możliwości.
Trzeba wykorzystad narzędzia wspomagające testy i automatyzujące tworzenie szkodliwych żądao.

Ponadto trzeba się upewnid, że wszystkie pliki, które nie mają byd bezpośrednio dostępne dla

użytkownika znajdują się poza katalogiem public_html serwera.

d) Testowanie modułu przelewów

Moduł przelewów jest jedną ze składowych aplikacji internetowej przeznaczonej dla klientów

oraz podwykonawców. Naszym zadaniem w tej fazie testów jest przetestowanie zabezpieczeo oraz
reakcje na różne dane, które zostaną wpisane nieprawidłowo. Należy także sprawdzid, czy system
banku prawidłowo reaguje na żądania projektowanego systemu, czy nie ma przekłamao w kwotach
przelewów ani przy rozpoznawaniu użytkownika zlecającego przelew.

e) Testowanie aplikacji dla podwykonawców

Dokumentacja testów systemu informatycznego

6

Natychmiastowy kontakt z podwykonawcą jest niezbędny do wykonywania koniecznych zadao

przy realizacji poszczególnych zamówieo. Sprawdzenie automatyzacji działania oraz zabezpieczenie
kanałów komunikacyjnych jest w tym wypadku głównym zadaniem. Musimy sprawdzid co się stanie
przy wyczerpaniu środków do realizacji zadania z jednej lub drugiej strony.

Należy także sprawdzid reakcje na dane niestandardowe oraz potencjalnie niebezpieczne. Trzeba

przetestowad moduł odpowiedzialny za komunikację, czy nie ma zmian w przesyłanych informacjach
oraz czy podwykonawcy mają dostęp tylko do tych danych, do których udzielono im dostępu.

4.2. Przypadki testowe i scenariusze

Przypadki testowe wyróżniamy na podstawie przypadków użycia. Definiują dane wejściowe oraz

wyjściowe dla danego przypadku. Dzięki temu można zweryfikowad poprawnośd działania funkcji
określonej przypadkiem użycia. Wszelkie nieoczekiwane dane wyjściowe mogą oznaczad błąd.
Ponadto uzyskujemy pewien obraz w sytuacjach wprowadzenia niestandardowych danych lub
warunków granicznych.

Scenariusze natomiast ustalają porządek. Przedstawiają sekwencję wykonywanych czynności w

celu sprawdzenia konkretnej części systemu. Dane wyjściowe jednego przypadku testowego są
danymi wejściowymi kolejnego w sekwencji.

a) Strona WWW i biuro

Nazwa

Wybór oferty

Stan początkowy

Dostępny formularz wyboru oferty

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „wyszukaj”

Dane wyjściowe

Identyfikatory pasujących ofert

Nazwa

Złożenie zamówienia

Stan początkowy

Lista ofert

Dane wejściowe

Identyfikator oferty

Warunki testu

Zalogowanie i kliknięcie „zamawiaj”

Dane wyjściowe

Potwierdzenie, informacje o płatności, identyfikator płatności

Nazwa

Opłacenie

Stan początkowy

Złożenie zamówienia

Dane wejściowe

Identyfikator płatności, kwota, bank zamawiającego

Warunki testu

Przejście do strony banku

Dane wyjściowe

Potwierdzenie płatności, numer referencyjny od banku

Nazwa

Złożenie zamówienia specjalnego

Stan początkowy

Formularz zamówienia

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „zamawiaj”

Dane wyjściowe

Potwierdzenie, informacje o płatności, identyfikator płatności

Dokumentacja testów systemu informatycznego

7



Złożenie zamówienia



Złożenie zamówienia specjalnego

b) Centrala

Nazwa

Tworzenie oferty

Stan początkowy

Dostępny formularz tworzenia oferty

Dane wejściowe

Informacje o wycieczce (cel, transport, obiekty, wyżywienie)

Warunki testu

Kliknięcie przycisku „utwórz”

Dane wyjściowe

Identyfikatory nowotworzonej oferty

Nazwa

Rezerwacja fizyczna / finalizacja

Stan początkowy

Złożenie zamówieo specjalnych

Dane wejściowe

Identyfikator zamówienia specjalnego

Warunki testu

Kliknięcie przycisku „potwierdź”

Dane wyjściowe

Potwierdzenie, identyfikator zamówienia

Nazwa

Organizacja finansów dla podwykonawców

Stan początkowy

Zamówione usługi podwykonawców

Dane wejściowe

Identyfikator podwykonawcy, kwota, opis

Warunki testu

Kliknięcie przycisku „opład”

Dane wyjściowe

Potwierdzenie, numer referencyjny przelewu

c) Podwykonawcy

Nazwa

Uaktualnianie danych o środkach podwykonawców

Stan początkowy

Zmiana danych, formularz zmiany danych

Dane wejściowe

Dane dotyczące konkretnego podwykonawcy

Warunki testu

Połączenie z serwerem centrali

Dane wyjściowe

Potwierdzenie

Dokumentacja testów systemu informatycznego

8

Nazwa

Rezerwacja środków podwykonawców

Stan początkowy

Złożone zamówienia

Dane wejściowe

Identyfikator podwykonawcy, środek, czas, cena, inne

Warunki testu

Połączenie z serwerem centrali

Dane wyjściowe

Potwierdzenie, numer rezerwacji

Nazwa

Wymiana danych klientów

Stan początkowy

Złożenie zamówienia wymagającego wymiany danych

Dane wejściowe

Identyfikator wycieczki, podwykonawca, dane klientów (różne w zależności
od działalności i typy wycieczki)

Warunki testu

Połączenie z serwerem centrali, kliknięcie przycisku „wyślij”

Dane wyjściowe

Potwierdzenie



Komunikacja Centrala - Podwykonawcy

d) Zarząd

Nazwa

Zarządzanie pracownikami

Stan początkowy

Panel z wyborem / wyszukaniem pracownika

Dane wejściowe

Identyfikator pracownika, dane

Warunki testu

Wybranie metody dostępu

Dane wyjściowe

Potwierdzenie, dane stare / nowe

Nazwa

Zlecanie wypłat

Stan początkowy

Panel z wyborem / wyszukaniem pracownika

Dane wejściowe

Identyfikator pracownika, kwota

Warunki testu

Kliknięcie przycisku „wypład”

Dane wyjściowe

Potwierdzenie, numer referencyjny przelewu

Nazwa

Raporty / statystyki

Stan początkowy

Panel wyboru kryteriów

Dane wejściowe

Okres, usługa, pracownik, biuro, inne

Warunki testu

Kliknięcie przycisku „generuj”

Dane wyjściowe

Wygenerowany raport

Dokumentacja testów systemu informatycznego

9



Zarządzanie pracownikami

4.3. Drzewa błędów

Wiele błędów propaguje na kolejne elementy systemu. Takie błędy są jednymi z najbardziej

szkodliwych. Często trudno je zidentyfikowad, bo nie wiadomo na pierwszy rzut oka z czego wynikają.
Niemniej prawidłowe zdiagnozowanie może rozwiązad inne usterki, które zostały przez ten błąd
wywołane. Dużo czasu należy przeznaczyd na zdiagnozowanie właśnie tego typu błędów. Przypadki
dla poszczególnych aplikacji przedstawiają poniższe drzewa błędów. Korzeniem drzewa jest jedna z
rozważanych niebezpiecznych sytuacji. Wierzchołkami są sytuacje pośrednie, które mogą prowadzid
do sytuacji odpowiadającej wierzchołkowi wyższego poziomu.

a) Składanie zamówienia (zarówno przez stronę WWW, jak i aplikację biura

Dokumentacja testów systemu informatycznego

10

b) Tworzenie ofert przez centralę

c) Błędy aplikacji podwykonawców

4.4. Strategia białej i czarnej skrzynki;

Wykorzystując strategię białej skrzynki sprawdzimy logikę wewnętrzną oprogramowania.

Wstawiamy kod diagnostyczny i dzięki debuggerom prześledzimy kod programu „krok po kroku”.
Trzeba też przygotowad różne dane testowe i dzięki programom usprawniającym testowanie
sprawdzid każdą procedurę poprzez wywoływanie jej z różnymi parametrami. Każdą możliwą ścieżkę
należy przetestowad przynajmniej jeden raz.

Należy wykorzystad także metodę czarnej skrzynki. Tak określa się sprawdzanie funkcji

oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jakby
wnętrze było niewidoczne. Tą strategią należy objąd cały zakres danych wejściowych. Warto podzielid
dane wejściowe w „klasy równoważności”, co do których można mied przypuszczenie, że będą
produkowad te same błędy. Wynikiem będzie analiza danych wyjściowych – czy są zgodne z
oczekiwaniami.

Dokumentacja testów systemu informatycznego

11

4.5. Zespół oceniający i testy akceptacyjne

Zespół oceniający musi składad się z potencjalnych użytkowników każdego z interfejsów,

niezależnych specjalistów IT, zamawiających – przedstawicieli firmy Husajn Travel oraz kierownika i
sekretarza wykonawczej firmy KittyTeam.

Potencjalni użytkownicy będą oceniad interfejsy pod względem funkcjonalności dla właściwiej

dla siebie dziedziny, z uwzględnieniem zaawansowania technicznego jakim przyszli użytkownicy będą
dysponowad. W tej grupie wyznaczone zostaną po trzy osoby dla każdego z działów – IT, zarządu,
pracowników biur podróży, podwykonawców, centrali i użytkowników strony www.

Reprezentanci z działu IT to osoby z wyższym wykształceniem informatycznym, którym

można powierzyd zarówno możliwośd modyfikacji części kodu aplikacji jak i dostęp do bazy danych.
Będą oni badali odpowiednie funkcjonalności swojego działu, działanie bazy danych oraz
przejrzystośd i klarownośd kodu którym będą dysponowali.

Reprezentanci zarządu, pracowników biur podróży i centrali to osoby z wykształceniem

średnim i wyższym, niekoniecznie biegłe w obsłudze komputera. Będą badad czas jaki potrzebny jest
na naukę obsługi programu, jego łatwośd i przystępnośd oraz raportowad ewentualne błędy.

Częśd zespołu oceniającego działu podwykonawców również będzie się składała z trzech

osób, jednak będą to osoby z trzech różnych dziedzin – przykładowo transportu, wypoczynku i
ubezpieczeo. Będą oni badad spójnośd wersji programu przygotowanych dla ich dziedziny, zasadnośd
odpowiednich funkcji w zestawieniu z realiami, również czas potrzebny na naukę obsługi programu
oraz raportowad błędy.

Zespół oceniający użytkowników strony WWW będzie się składał z losowo wybranych,

niezwiązanych z firmami Husajn Travel, KittyTeam ani z żadną z firm podwykonawców trzech osób w
wieku od 25 do 65 lat, którzy będą badad funkcjonalnośd strony WWW i jej przystępnośd dla
dowolnego użytkownika który zechce skorzystad z oferty Husajn Travel. Będą oni mieli za zadanie
przetestowad wszystkie dostępne funkcje strony, sprawdzid czy jest wygodna w użytkowaniu, czy
występują na niej jakieś błędy itp.

Dodatkowo w zespole oceniającym znajdzie się pięciu niezależnych specjalistów IT,

niezwiązanych z firmami Husajn Travel, KittyTeam ani z żadną z firm podwykonawców, którzy będą
badad kod programu oraz założenia niefunkcjonalne, starając się odpowiedzied na pytanie czy zostały
one zrealizowane, a także czy badany kod jest wystarczająco przejrzysty aby mógł byd przekazany do
przyszłego zespołu działu IT działającego z ramienia firmy Husajn Travel.

Przedstawiciele firmy Husajn Travel będą badali zgodnośd systemu z wymaganiami które postawili
podczas składania zamówienia na system informatyczny, ze szczególnym uwzględnieniem
realizowania funkcji dziedzinowych. Kierownik i sekretarz z firmy KittyTeam będą nadzorowad prace
poszczególnych części zespołu oceniającego, notowad wnioski i kierowad do reszty zespołu
wykonawczego w celu poprawienia ewentualnych błędów w działaniu systemu lub jakiejś jego części.

Dokumentacja testów systemu informatycznego

12

5. Audyt

Projekt dla firmy Husajn Travel jest dużym systemem informatycznym, stąd występuje

koniecznośd zlecenia przeprowadzenia audytu. Ma on byd zgodny z normą ANSI/IEEE Std 1028-1988
„IEEE Standard for Reviews and Audits”. Jego celem jest niezależny przegląd i ocena jakości
oprogramowania, która zapewnia zgodnośd z wymaganiami na oprogramowanie, a także ze
specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz
kontraktowymi i licencyjnymi wymaganiami.

Aby zapewnid obiektywnośd, za jego przeprowadzenie odpowiedzialna będzie niezależna

organizacja, nie mająca żadnych powiązao z firmą KittyTeam, ani z firmą Husajn Travel. Audytorem
bowiem będzie Polskie Stowarzyszenie Audytu. Audytowi podlegad będzie nie tylko stan ukooczenia
projektu, ale przede wszystkim jego zgodnośd z założeniami, możliwości (zasoby, kompetencje,
metody, standardy) oraz bezpieczeostwo (czynnik techniczny oraz czynnik ludzki), jak i wygoda
użytkowania. W audycie zostanie też wykazane czy wykonywane prace oraz sposób ich wykonywania
są prawidłowe, czy użyte techniki oraz opracowane rozwiązania są prawidłowe i prawidłowo
stosowane oraz czy sposób zarządzania projektem umożliwi jego sukces.

Ponadto zostanie zbadana opinia Generalnego Inspektora Ochrony Danych Osobowych

odnośnie zgodności systemu z Ustawą z dnia 29.08.97 r. o Ochronie Danych Osobowych Dz. U. Nr 133
poz. 883. Kwestie związane płatnościami i ich poufnością będą także podlegały przedstawicielom
bankowym i sektora kartowego.

Nie planuje się dokonywania innych inspekcji, gdyż system nie ma charakteru specjalnego, a

koszta przeprowadzenia dodatkowej inspekcji są niewspółmierne do charakterystyki projektu.

6. Wykorzystane narzędzia

Przy wykonywaniu testów posłużymy się kilkoma narzędziami. Pozwolą one w znacznym stopniu

zautomatyzowad naszą pracę. Zmniejsza to czas przeznaczony na testy. Zastosowanie
zaawansowanych narzędzi, zaliczanych do tzw. warsztatu testera, minimalizuje możliwośd
przeoczenia niektórych błędów, co możliwe by było przez tzw. błąd ludzki.

W fazie testów wykorzystujemy m.in. analizator przykrycia kodu. Pozwala to na wykrycie

martwego kodu, kodu, który uruchamiany jest tylko przy niektórych, bardzo specyficznych danych
oraz kodu wykonywanego bardzo często (oznaka wąskiego gardła w programie). Do
zautomatyzowania testów wykorzystujemy środowisko do tworzenia i zarządzania testami. Na
wstępie w systemie kontroli udostępniamy dokumenty zawierające wymagania i scenariusze, pliki z
danymi używanymi do testowania i plan testów. Pozwala to nam na bieżąco orientowad się w sytuacji
oraz w znacznym stopniu zapobiega ewentualnemu chaosowi przy testowaniu aplikacji.

W dalszej kolejności opracowujemy reguły pracy związane z wystąpieniem różnego rodzaju

zdarzeo. Mamy ustalid do kogo należy konkretne zadanie w sytuacjach newralgicznych. Do takich

Dokumentacja testów systemu informatycznego

13

sytuacji na pewno można zaliczyd przypadek błędu i skierowania informacji o tym do osoby
przedzielającej zadanie usunięcia usterki. Informacja o poprawieniu oprogramowania trafia do
zespołu testującego. Zespół, na zmodyfikowanej wersji aplikacji, ponownie uruchamia skrypty
testowe.

Do zarządzania i dokumentowania testów wykorzystujemy między innymi TestManager'a. Do

budowy skryptów automatycznych program Robot. Zaimplementowane w Robot skrypty
uruchamiamy w skonstruowanych w programie TestFactory testach automatycznych. Oczywiście
bardzo ważne w fazie testów jest sprawdzenie zgodności dostarczonej do testów wersji aplikacji z
wymaganiami wypracowanymi we wcześniejszych fazach budowy aplikacji. Purify nadaje się do tego
celu idealnie. Pozwala nam to wykryd ewentualne nieścisłości, które narosły w trakcie pracy nad
kolejnymi etapami.

7. Podsumowanie

Jeśli mielibyśmy rozważyd kryterium zakooczenia testowania, to takiego nie ma. Testowanie

nigdy nie jest zakooczone, gdyż od pierwszej instalacji prototypu oprogramowanie testowane jest
przez użytkownika. Wiele błędów będzie zgłaszanych właśnie po wdrożeniu. Wtedy „test” będzie
przeprowadzad największa grupa „testerów”. Testy zamknięte mają zapewnid to, że po wdrożeniu
minimalizujemy ryzyko wystąpienia usterki o charakterze krytycznym. Praktyczne, zamknięte testy
musimy zakooczyd do kooca grudnia (zgodnie z harmonogramem implementacji w Dokumentacji
Projektowej).

7.1. Przyszłe wersje

W przypadku dokonywanych testów zwracamy szczególną uwagę na najważniejsze funkcje

naszej aplikacji. Za kryterium ważności przyjmujemy ocenę modelowego użytkownika oraz
przewidywaną częstotliwośd używania danej funkcji w stosunku do innych. Wybrane przez nas
funkcje musiały byd jak najlepiej przetestowane i to na nich trzeba skupid największą uwagę. Ma to
ogromne znaczenie, ponieważ przy każdej następnej wersji programu, szkielet najważniejszych
funkcji pozostanie z pewnością taki sam. Nasz zespół testując aplikację, przygotowuje kolejne wersje
oprogramowania. W każdej kolejnej wersji testowej aplikacji zwracamy szczególną uwagę właśnie na
te najważniejsze funkcje, aby użytkownik nie był zdziwiony błędami pojawiającymi się przy używaniu
poznanej z poprzednich wersji funkcjonalności.

Do takich ważnych funkcji zaliczyliśmy moduł składania zamówieo przez Internet oraz

dokonywania płatności. Cały proces zamówienia, w każdej wersji programu jest sprawdzany od
początku do kooca. Sprawdzamy go dla różnych danych, dla ich braku i danych podawanych
ewidentnie źle. Wyobrażamy sobie najbardziej absurdalne pomysły, które mogłyby przyjśd do głowy,
lub po prostu zostad wprowadzone przez użytkownika do formularza zgłoszeniowego. W przyszłych
wersjach programu byd może moduł składania zamówienia będzie się zmieniał, a nawet jeśli się nie
zmieni należy go przetestowad. Jest on zbyt ważny i ma zbyt dużo powiązao w całej aplikacji.
Sprawdzenie wprowadzanych danych oraz wyniku finalizacji zamówienia w bazie danych powinno w
przyszłych testach byd minimum jakie należy wykonad.