Dokumentacja testowa systemu informatycznego

System informatyczny obsługi firmy doradztwa podatkowego

Wersja pierwsza

ZESPÓŁ WYTWÓRCZY 3/2010/GB

Stanowisko	Imię i Nazwisko	Zrealizowane zadania
Kierownik projektu / Zamawiający	Justyna Sokołowska	Zarządzanie, formatowanie dokumentu, wstęp, badania prognostyczne
Zamawiający / Tester akceptacyjny	Michał Szałwiński	Audyt, strategia białej i czarnej skrzynki
Analityk / Projektant	Bartłomiej Sujkowski, Marcin Szczepaniak	Wykorzystane narzędzia, podsumowanie, przyszłe wersje, korekta Co podlega testowaniu, Testy akceptacyjne
Analityk / Tester wewnętrzny	Paweł Stempień	Przypadki testowe i scenariusze
Projektant / Tester wewnętrzny	Damian Sulej	Drzewa błędów, pomoc w przypadkach testowych

PROWADZĄCY

Grzegorz Bliźniuk

Warszawa, 2010

Spis treści:

 

1. Wstęp

2. Badania prognostyczne

3. Weryfikacja i walidacja

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

1. Co podlega testowaniu

2. Przypadki testowe i scenariusze

3. Drzewo błędów

4. Testowanie dynamiczne

5. Zespół oceniający i testy akceptacyjne

5. Audyt

6. Wykorzystywane narzędzia

7. Podsumowanie

1. Wstęp

Niniejszy dokument stanowi wprowadzenie do fazy testów systemu informatycznego dla biura doradztwa podatkowego „jussoko-team”. Definiuje testy prognostyczne realizowane przez kolejne kroki procesu tworzenia oprogramowania oraz testy przeprowadzane w końcowej fazie implementacji. Jako, że proces wytwórczy przebiega w modelu V, każdy etap posiada oddzielne poziomy testowania oraz system oceniania.

Nie można zakładać, że system nie posiada błędów. Zatem naszym zadaniem podczas fazy testowania jest znalezienie jak największej ilości błędów. Minimalizując tym samym ich liczbę w systemie oraz ewentualne koszty ich naprawy po wprowadzeniu systemu do obiegu.

2. Badania prognostyczne

Ważne jest by już na etapie definiowania wymagań upewniać się o poprawności założeń. Należy robić to również na późniejszych etapach projektu. Dzięki temu system będzie zawierał mniejszą liczbę błędów. Badania prognostyczne polegają na badaniu systemu bez przeglądanie kodu. Badania tego typu są stosunkowo niedrogie. Pomagają uniknąć powstawania części błędów oraz wykrywają już istniejące. Im wcześniej błąd zostanie wykryty tym mniejsze koszty będzie trzeba ponieść by go usunąć. Również samo wyeliminowanie go będzie łatwiejsze oraz będzie odgrywał mniejszy wpływ na inne elementy systemu.

Testy te polegają na badaniu modelu, który może być nie do końca zgodny z modułami ostatecznie zaimplementowanymi. W związku z tym należy do nich podchodzić z lekkim dystansem.

Badania prognostyczne będą przede wszystkim obejmować wszelkie wymagania funkcjonalne oraz niefunkcjonalne, które zostały postawione w projektowanym systemie w fazie analizy i projektu, wraz z ich zgodnością ze specyfikacją oraz stopniowe ich implementowanie. Testy polegają na próbach modyfikacji kodu pisanego na bieżąco, rozpoznawaniu funkcjonalności testowanego kodu oraz zaprojektowaniu końcowych testów. Sprawdzamy również, czy w specyfikacji nie występują konflikty uniemożliwiające zaimplementowanie funkcjonalności w sposób zgodny z postawionymi wymaganiami.

Testowaniu podlegają własności statyczne oraz dynamiczne. Przede wszystkim należy zwrócić uwagę na wymianę informacji pomiędzy funkcjami, między którymi zaprojektowano przepływ informacji. Należy również sprawdzić czy informacje nie „wyciekają” do świata zewnętrznego.

3. Weryfikacja i walidacja

Weryfikacja polega na wykonaniu całościowego przeglądu, inspekcji, sprawdzania oraz audytowania. Zatem sprawdzamy i udokumentowujemy czy składowe, usługi oraz dokumenty są zgodne z wcześniej ustalonymi wymaganiami. Określamy czy system w swoich poszczególnych fazach rozwoju jest zgodny z początkowymi założeniami tej fazy, a przede wszystkim założonymi w fazie specyfikacji. Częścią weryfikacji są badania prognostyczne.

Końcowym etapem procesu wytwórczego jest walidacja. Sprawdzana jest wtedy zgodność z wymaganiami oraz wystawiany jest atest systemu.

Poszczególne elementy systemu informatycznego biura doradztwa podatkowego „jussoko-team” są różnorodne. Założenia, głównie funkcjonalne, musza być weryfikowane oddzielnie, przez odpowiednią część zespołu oceniającego. Wszelkie wymagania są zawarte w dokumentacji specyfikacji.

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

1. Co podlega testowaniu

a) testowanie bazy danych

W bazach danych należy zwrócić szczególną uwagę na kwestie bezpieczeństwa, dlatego głównym celem tego etapu jest sprawdzenie zabezpieczeń. Należy przetestować wszystkie możliwe kanały, którymi dane mogą dostać się w niepowołane ręce. Ważną kwestią jest również przetestowanie przydzielania uprawnień poszczególnym użytkownikom systemu, do korzystania z danych zawartych w bazach danych. Nadawanie odpowiednich uprawnień jest bardzo ważne, biorąc pod uwagę możliwości wprowadzania zmian w bazie danych. W celu zabezpieczenia przed nieumyślnymi zmianami w skutek awarii systemu lub ingerencji użytkowników, należy przetestować działanie modułu tworzącego kopie zapasowe. Bazy należy sprawdzić pod względem ich budowy, tak aby zmniejszyć do minimum występowanie redundancji przechowywanych danych. Kolejnym krokiem w testowaniu baz danych będzie sprawdzenie ich wydajności oraz możliwości jednoczesnego korzystania z tych samych danych przez kilku użytkowników systemu.

b) testowanie aplikacji przeznaczonej dla klienta

Ten etap wymaga przede wszystkim przetestowania współpracy pomiędzy aplikacją klienta, a bazą danych, systemem eksperckim oraz systemem bankowym. Należy zadbać o to, by klientowi były wyświetlane odpowiednie dane w odpowiedniej formie. Sprawdzeniu powinny podlegać również wszystkie moduły dostępne z poziomu aplikacji klienta, oraz sterowanie poszczególnymi elementami systemu informatycznego.

Aplikacja przeznaczona dla klientów jest szczególnie narażona na ataki. Szczególnie należy zwrócić tu uwagę na uwierzytelnianie użytkowników, aby zmniejszyć ryzyko dostępu do systemu przez niepowołanych użytkowników. Należy zbadać również możliwości wykonywania skryptów na stronie, aby zabezpieczyć się przed atakami mającymi na celu kradzież danych użytkowników systemu lub możliwością zakładania wielu kont w bardzo krótkim czasie przez stworzone do tego celu automaty.

100. testowanie panelu konsultanta

Dla panelu konsultanta należy przede wszystkim zbadać poprawność działania kanałów komunikacji z klientem. Jest to główny moduł na którym będzie pracował konsultant, dlatego niezwykle ważne jest aby mógł on z poziomy swojego panelu korzystać z telefonu lub e-maila. Konsultant musi mieć również wgląd do dokumentów utworzonych przez klientów, dlatego koniecznym będzie sprawdzenie poprawności przesyłania ich pomiędzy bazą, a konsultantem oraz klientem i konsultantem.

500. testowanie panelu administratora

Administrator ma największe uprawnienia spośród wszystkich użytkowników. On jako jedyny może zmieniać większość elementów systemu. Szczególnie ważne są zmiany we wszelkiego rodzaju bazach danych, dlatego niezwykle istotny jest tu moduł odpowiedzialny za tworzenie kopii zapasowych danych. Należy przetestować go zarówno pod względem wydajności jak i niezawodności, aby możliwe było odtworzenie danych po awarii systemu lub ingerencji jednego z użytkowników. Należy też bardzo dokładnie sprawdzić poprawność działania wszelkich modułów służących do dodawania, usuwania lub zmiany danych, aby mieć pewność że operacje te dotyczą właściwych danych. Testy mające na celu sprawdzenie jak system reaguje na wprowadzanie niestandardowych danych ograniczają możliwość popełnienia błędów przez administratora, co w przyszłości będzie skutkowało większą niezawodnością systemu.

e) testowanie modułu współpracującego z systemem bankowym

Moduł ułatwiający dokonywanie przelewów jest elementem w którym trzeba zatroszczyć się o szczególne zabezpieczenia. Przesyłanie danych dotyczących kont bankowych jest szczególnie narażone na ataki, dlatego niezwykle ważnym jest sprawdzenie, czy system prawidłowo szyfruje dane i czy zostały wykluczone wszelkie możliwości podsłuchu. Kluczowa także jest poprawność przesyłanych danych, aby nie doszło do przekłamań kwot oraz innych danych potrzebnych przy dokonywaniu przelewu. Niezwykle istotne jest też rejestrowanie wszelkich prób nieprawidłowego uzyskania dostępu do tego modułu, aby możliwe było natychmiastowe reagowanie w przypadku prób uzyskania nieautoryzowanego dostępu.

f) testowanie systemu eksperckiego

System ekspercki zawiera zbiór pytań umożliwiających zidentyfikowanie problemu klienta oraz doradzenie mu odpowiedniego rozwiązania. Należy więc sprawdzić sposób doboru reguł przez mechanizm wnioskowania oraz działanie każdej reguły w różnych konkretnych przypadkach wymagających decyzji, rady czy opinii. Mechanizm należy przetestować pod względem łatwości obsługi oraz jednoznaczności odpowiedzi, tak aby użytkownik słabo zaznajomiony z systemem oraz prawem podatkowym nie miał problemu z ustaleniem odpowiedzi na poszczególne pytania. Zmniejszy to możliwość przekazania do konsultanta problemu, który mógłby zostać rozwiązany za pomocą systemu eksperckiego.

1. Przypadki testowe i scenariusz

Scenariusze te zdefiniują kolejność testów oraz sekwencje czynności, które należy wykonać na systemie, aby sprawdzić konkretną jego część. Dane wyjściowe jednego przypadku testowego są danymi wejściowymi kolejnego w scenariuszu.

Przypadki testowe określają dane wejściowe oraz spodziewane wyniki działania witryny dla konkretnego przypadku.

a) Logowanie/rejestracja do systemu.

Nazwa	Wejście do formularza rejestracji
Stan początkowy	Strona główna witryny internetowej
Dane wejściowe	Kliknięcia
Warunki testu	Kliknięcie na przycisk logowania/rejestracji następnie linku "rejestracja"
Dane wyjściowe	Poprawnie wyświetlony pusty formularz rejestracji

 

Nazwa	Błędne wpisywanie danych rejestracyjnych
Stan początkowy	Pusty formularz rejestracyjny
Dane wejściowe	Błędne Dane użytkownika
Warunki testu	Poprawne wpisanie błędnych danych użytkownika w miejsca do tego przeznaczone
Dane wyjściowe	Wyświetlony komunikat o błędzie oraz oznaczenie w formularzu miejsc z błędami

Nazwa	Niepełne wpisywanie danych rejestracyjnych
Stan początkowy	Pusty formularz rejestracyjny
Dane wejściowe	Niepełne Dane użytkownika
Warunki testu	Niepoprawne wpisanie danych użytkownika
Dane wyjściowe	Wyświetlony komunikat o błędzie oraz oznaczenie w formularzu miejsc nieuzupełnionych

 

Nazwa	Wpisywanie danych rejestracyjnych
Stan początkowy	Pusty formularz rejestracyjny
Dane wejściowe	Dane użytkownika
Warunki testu	Poprawne wpisanie danych użytkownika w miejsca do tego przeznaczone
Dane wyjściowe	Poprawnie wyświetlony wypełniony formularz rejestracji, wysłany mail na podany w formularzu adres

Nazwa	Błędne wpisanie danych logowania
Stan początkowy	Pusty formularz logowania
Dane wejściowe	Błędny login oraz hasło
Warunki testu	Wpisanie błędnego loginu i hasła do formularza
Dane wyjściowe	Poprawnie wyświetlane dane wpisane do formularza

 

Nazwa	Błędne logowanie
Stan początkowy	Błędnie wypełniony formularz logowania
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk logowania/rejestracji
Dane wyjściowe	Komunikat o błędnych danych logowania i wyświetlenie pustego formularza logowania

 

Nazwa	Logowanie z pustym formularzem
Stan początkowy	Pusty formularz logowania
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk logowania/rejestracji
Dane wyjściowe	Komunikat o braku danych logowania i wyświetlenie pustego formularza logowania

 

Nazwa	Poprawne wpisywanie danych logowania
Stan początkowy	Pusty formularz logowania
Dane wejściowe	Login oraz hasło
Warunki testu	Wpisanie loginu i hasła do formularza
Dane wyjściowe	Poprawnie wyświetlane dane wpisane do formularza

 

Nazwa	Logowanie
Stan początkowy	Wypełniony formularz logowania
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk logowania/rejestracji
Dane wyjściowe	Komunikat o zalogowaniu użytkownika

b) Modyfikowanie bazy danych przez administratora

Nazwa	Podgląd wpisów w bazie danych
Stan początkowy	Użytkownik zalogowany na koncie administratora w panelu administracyjnym
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie podglądu bazy danych
Dane wyjściowe	Listing wpisów w bazie danych

Nazwa	Edycja wpisu w bazie danych
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Zmodyfikowane dane
Warunki testu	Kliknięcie konkretnego wpisu i modyfikacja danych oraz zaakceptowanie
Dane wyjściowe	Poprawnie modyfikowany listing wpisów w bazie danych

Nazwa	Błędne dodanie użytkownika
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Błędne dane użytkownika
Warunki testu	Wpisanie błędnych danych do nowego wpisu w bazie danych oraz akceptacja
Dane wyjściowe	Komunikat o błędnym wpisaniu danych do nowego wpisu oraz wyświetlenie listingu wpisów

Nazwa	Błędne - puste - dodanie użytkownika
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Kliknięcie
Warunki testu	Akceptacja nowego pustego wpisu
Dane wyjściowe	Komunikat o braku danych w nowym wpisie oraz wyświetlenie listingu wpisów

 

Nazwa	Dodanie użytkownika
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Dane użytkownika
Warunki testu	Wpisanie danych do nowego wpisu w bazie danych oraz akceptacja
Dane wyjściowe	Komunikat o udanym dodaniu nowego wpisu oraz wyświetlenie listingu wpisów

Nazwa	Modyfikacja użytkownika
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Zmodyfikowane dane o użytkowniku
Warunki testu	Modyfikacja danych we wpisie istniejącym w bazie danych oraz akceptacja
Dane wyjściowe	Komunikat o udanej modyfikacji wpisu oraz wyświetlenie listingu wpisów

Nazwa	Usunięcie użytkownika
Stan początkowy	Listing wpisów w bazie danych
Dane wejściowe	Kliknięcie
Warunki testu	Żądanie usunięcia wybranego wpisu w bazie danych oraz akceptacja
Dane wyjściowe	Komunikat o udanym usunięciu wpisu oraz wyświetlenie poprawnie zmodyfikowanego listingu bazy danych

c) Weryfikacja dokumentu

Nazwa	Wejście do formularza dokumentu
Stan początkowy	Strona główna witryny internetowej
Dane wejściowe	Kliknięcia
Warunki testu	Kliknięcie na przycisk dokumentu
Dane wyjściowe	Poprawnie wyświetlony pusty formularz dokumentu

Nazwa	Błędne wpisywanie danych dokumentu
Stan początkowy	Pusty formularz dokumentu
Dane wejściowe	Błędne Dane do Dokumentu
Warunki testu	Wpisanie błędnych danych dokumentu w miejsca do tego przeznaczone
Dane wyjściowe	Wyświetlony komunikat o błędzie oraz oznaczenie w formularzu miejsc z błędami

Nazwa	Niepełne wpisywanie danych dokumentu
Stan początkowy	Pusty formularz dokumentu
Dane wejściowe	Niepełne Dane do Dokumentu
Warunki testu	Niepoprawne wpisanie danych dokumentu
Dane wyjściowe	Wyświetlony komunikat o błędzie oraz oznaczenie w formularzu miejsc nieuzupełnionych

 

Nazwa	Wpisywanie danych dokumentu
Stan początkowy	Pusty formularz rejestracyjny
Dane wejściowe	Dane do dokumentu
Warunki testu	Poprawne wpisanie danych dokumentu w miejsca do tego przeznaczone
Dane wyjściowe	Poprawnie wyświetlony wypełniony formularz dokumentu

Nazwa	Dodanie dokumentu do bazy danych
Stan początkowy	Wypełniony formularz rejestracyjny
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie przycisku dodającego dokument do bazy danych
Dane wyjściowe	Komunikat o udanym dodaniu dokumentu do bazy danych, wyświetlenie podglądu wypełnionego formularza

 

Nazwa	Edycja dokumentu
Stan początkowy	Podgląd dokumentu
Dane wejściowe	Kliknięcia i edytowane dane do dokumentu
Warunki testu	Kliknięcie przycisku edytującego formularz dokumentu, zmiana w nim danych oraz akceptacja
Dane wyjściowe	Komunikat o udanej edycji dokumentu, wyświetlenie podglądu wypełnionego formularza

Nazwa	Usunięcie dokumentu
Stan początkowy	Podgląd dokumentu
Dane wejściowe	Kliknięcia
Warunki testu	Kliknięcie przycisku usuwającego dokument oraz akceptacja
Dane wyjściowe	Komunikat o udanym usunięciu dokumentu

d) Problem niestandardowy

Nazwa	Wejście do formularza pomocy
Stan początkowy	Strona główna witryny internetowej
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk „Pomoc”
Dane wyjściowe	Poprawnie wyświetlony pusty formularz pomocy

Nazwa	Niepełne wpisanie danych do formularza pomocy
Stan początkowy	Pusty formularz pomocy
Dane wejściowe	Niepełne dane w formularzu
Warunki testu	Niepoprawne wpisanie danych do formularza
Dane wyjściowe	Wyświetlony komunikat o braku tematu lub opisu

Nazwa	Błędne wpisanie danych
Stan początkowy	Pusty formularz pomocy
Dane wejściowe	Wypełniony formularz poprzez wpisanie tematu i opisu
Warunki testu	Wpisanie niedozwolonych znaków w temacie bądź opisie
Dane wyjściowe	Wyświetlony komunikat o wpisaniu niewłaściwych znaków

Nazwa	Wpisanie poprawnych danych do formularza
Stan początkowy	Pusty formularz pomocy
Dane wejściowe	Wpisanie tematu i opisu problemu
Warunki testu	Poprawnie wpisane dane w miejsca do tego przeznaczone
Dane wyjściowe	Kompletne dane wpisane do formularza, tj temat wraz z opisem

Nazwa	Wysyłanie problemu do konsultanta
Stan początkowy	Wypełniony formularz ze zdefiniowanym problemem
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk „Wyślij”
Dane wyjściowe	Wyświetlony komunikat o poprawności danych oraz o wysłaniu maila do odpowiedniego konsultanta

Nazwa	Nieudana próba wysłania problemu do konsultanta
Stan początkowy	Wypełniony formularz ze zdefiniowanym problemem
Dane wejściowe	Kliknięcie
Warunki testu	Kliknięcie na przycisk „Wyślij”
Dane wyjściowe	Wyświetlony komunikat o nieudanej próbie wysłania maila do konsultanta, możliwość ponownego przesłania maila.

2. Drzewo błędów

Kolejne warstwy systemu charakteryzują się podatnością na wszelkiego rodzaju błędy. Takie błędy są najbardziej szkodliwe gdyż bardzo trudno jest je odnaleźć. Ich prawidłowa diagnoza może doprowadzić do rozwiązania usterek, które są powodem danego błędu. Na szukanie tego typu błędów należy poświęcić najwięcej czasu. Poniższe drzewa błędów przedstawiają możliwe przypadki dla poszczególnych interfejsów. Obiekty znajdujące się na „czubku” drzewa (korzeń) to jedne z możliwie niebezpiecznych sytuacji. Za zdarzenia pośrednie odpowiadają wierzchołki drzewa, które mogą doprowadzić do zdarzeń znajdujących się w wierzchołkach wyższego poziomu.

1. Logowanie/rejestracja do systemu

2. Modyfikowanie bazy danych przez administratora

3. Weryfikacja dokumentu

4. Problem niestandardowy

1. Testowanie dynamiczne

Testowanie dynamiczne odbędzie się wykorzystując strategię białej i czarnej skrzynki.

Posługując się strategią białej skrzynki poddamy weryfikacji logikę wewnętrzną oprogramowania. Metoda ta odbywa się w oparciu o znajomość kodu źródłowego testowanego programu. Śledząc krok po kroku działanie określonych fragmentów programu będziemy szukać specjalnych przypadków mogących powodować błędy. Do przeprowadzenia testów będzie potrzebne przygotowanie odpowiednich danych testowych. Dzięki programom usprawniającym testowanie, sprawdzeniu będzie podlegała każda procedura. 

Metoda czarnej skrzynki odbywa się w oparciu jedynie o znajomość interfejsów konkretnych modułów czy funkcji programu /systemu. System traktujemy jako czarną skrzynkę, która działa w nieznany sposób. Testuje ogólną funkcjonalność i poprawność działania. Test będzie realizowany poprzez sprawdzenie prawidłowej pracy bez przeglądania kodu źródłowego programu. Powinien być przeprowadzony przez osoby niezaangażowane bezpośrednio w proces tworzenia kodu. Tą strategią należy objąć cały zakres danych wejściowych.

2. Zespół oceniający i testy akceptacyjne

Testy akceptacyjne, to testy, których celem jest uzyskanie formalnego potwierdzenia wykonania oprogramowania odpowiedniej jakości. Polegają przede wszystkim na sprawdzeniu zgodności ze specyfikacją wymagań. Testy te przeprowadzane są przez specjalistów firmy tworzącej projekt, zamawiającego, niezależnych specjalistów oraz grupę osób reprezentującą użytkowników systemu.

Specjaliści firmy tworzącej projekt to osoby z wyższym wykształceniem informatycznym, które brały udział przy tworzeniu projektu. Będą oni badać system przede wszystkim pod kątem poprawności sposobu działania. Będą to aspekty logiki wewnętrznej oprogramowania.

Reprezentanci firmy zamawiającej system to osoby charakteryzujące się biegłą obsługą komputera, lecz nie posiadające wykształcenie informatycznego. Testowane przez nich będą przede wszystkim elementy systemu przeznaczone do wykorzystania przez pracowników firmy. Przeprowadzone zostaną również badania dotyczące czasu jaki potrzebują takie osoby na przyswojenie obsługi odpowiednich elementów systemu. Sprawdzenie będzie podlegała zgodność systemu z założeniami postawionymi przy składaniu zamówienia.

Niezależni specjaliści tworzą grupa niezwiązana z firmą wykonawcy, ani zamawiającego. Są to osoby pracujące w innych firmach tworzących podobne systemy, mające doświadczenie przy projektach podobnego typu. Ich praca będzie polegała na zbadaniu kodu pod względem poprawności działania oraz jego przejrzystości, tak aby mógł być w przyszłości rozwijany przez niezależnych programistów.

Najważniejszą grupę będą stanowili przyszli użytkownicy systemu. Są to osoby w różnym wieku, posiadające różne wykształcenie. Ich zadanie będzie polegało na sprawdzeniu poprawności działania wszelkich funkcji dostępnych z poziomu klienta. Ważnym aspektem będzie również sprawdzenie wygody użytkowania i intuicyjności w korzystaniu z dostępnym opcji.

5. Audyt

   System informatyczny obsługi firmy doradztwa podatkowego jest dużym projektem, dlatego koniecznością jest zlecenie przeprowadzenia obiektywnego audytu. Audyt ma  być zgodny z normą ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”, a jego głównym celem jest niezależny przegląd i ocena jakości oprogramowania. Ponadto zapewnienie zgodności z wymaganiami na oprogramowanie, specyfikacją, generalnymi założeniami, normami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami.

Audytorem będzie Polskie Stowarzyszenie Audytu. Audytowi podlegać będzie stan ukończenia projektu oraz zgodność z postawionymi założeniami. Dodatkowo weryfikacji zostaną poddane  możliwości  systemu,  jego bezpieczeństwo (zarówno czynnik techniczny jak i ludzki) i wygoda użytkowania. W audycie zostaną zamieszczone także oceny czy wykonywane prace oraz sposób ich wykonywania są prawidłowe, weryfikacja użytych technik, sprawdzenie opracowanych rozwiązań, a także oszacowanie czy sposób zarządzania projektem może odnieść 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. Zagadnienia dotyczące płatności i ich poufności będą także podlegały przedstawicielom bankowym i sektora operacji kartowych.

System nie ma charakteru specjalnego więc dokonywanie dodatkowych inspekcji nie jest potrzebne.

6. Wykorzystywane narzędzia

Podczas wykonywania testów będziemy posługiwać się odpowiednimi do tego narzędziami. Wykażą one słabe strony stworzonego oprogramowania oraz pozwolą usunąć ewentualne błędy. Zastosowanie tych narzędzi oraz przeprowadzenie za ich pomocą testów znacznie pomoże w zwiększeniu niezawodności oprogramowania.

Do tego celu użyjemy analizatora przykrycia kodu, który umożliwi wykrycie martwego kodu, kodu, który jest wykorzystywany tylko w bardzo specyficznych sytuacjach np. dane wejściowe, oraz pokaże która część kodu jest najczęściej wykonywana, co może być przyczyną wąskiego gardła w programie.

Wybrany przez nas analizator jest dobrany odpowiednio do środowiska rozwoju oprogramowania, dzięki czemu mamy pewność wiarygodności uzyskanych wyników prowadzonych za jego pomocą testów.

Następnie ustalimy reguły oraz metody pracy jakie będą realizowane w wyniku wystąpienia różnego rodzaju zdarzeń. Wszystkie przypadki wystąpienia błędów będą zgłaszane do osoby odpowiadającej za przydzielanie zadania usunięcia usterki. Zespół testujący będzie informowany o każdym poprawionym błędzie. Po jego usunięciu zespół ten testował będzie poprawione wersje aplikacji.

Do udokumentowania oraz zarządzania testów użyjemy programu TestMenager, który usprawni testowanie. Przeprowadzimy również testy wydajności oprogramowania za pomocą programu TestQuantify. Będziemy również wykonywać automatyczne testy, aby przyspieszyć fazę testową i do tego wykorzystamy aplikację TestFactory.

7. Podsumowanie

Testowanie oprogramowania jest ważną częścią jego tworzenia. Pozwala wykryć i naprawić błędy jeszcze przed oddaniem aplikacji do użytku. Niestety poprzez testy nie możemy nigdy wykluczyć powstawania wszystkich błędów. Część z nich zostanie wykryta dopiero podczas eksploatowania aplikacji przez jej użytkowników, którzy de facto są najszerszą grupą testerów danego oprogramowania. Dlatego też skupiamy się na najważniejszych miejscach w aplikacji, tak aby podczas jej użytkowania nie występowały błędy krytyczne. Nie oznacza to braku testów innych funkcji. Oprogramowanie jest przez nas testowane w każdy sposób, nawet podczas prób irracjonalnego sposobu korzystania z niego ( niepoprawne dane itp.).

Jeżeli chodzi o przyszłość danego oprogramowania oczywistym jest prowadzenie wsparcia technicznego, usuwania zgłaszanych przez jego użytkowników błędów oraz aktualizacji i modernizacji w zależności od potrzeb.

Przykładamy szczególną uwagę do poprawnego działania naszych aplikacji, oraz rozwijania ich w przyszłości.

System informatyczny obsługi firmy doradztwa podatkowego

Strona 9 z 16

---