Błędy do usunięcia

Kluczowym elementem wdrożenia mającym bezpośredni wpływ na satysfakcję przyszłych użytkowników systemu informatycznego jest faza testów. Niestety, nie jest to jeszcze wiedza dla wszystkich oczywista.

Kluczowym elementem wdrożenia mającym bezpośredni wpływ na satysfakcję przyszłych użytkowników systemu informatycznego jest faza testów. Niestety, nie jest to jeszcze wiedza dla wszystkich oczywista.

Pomimo różnorodności stosowanych nazw, w procesie testowania i odbioru tworzonego oprogramowania można wyróżnić cztery zasadnicze rodzaje testów: testy producenta lub dostawcy (wewnętrzne), testy funkcjonalne, akceptacyjne i integracyjne.

W ramach testów producenta lub dostawcy grupa programistów dokonuje wewnętrznego odbioru aplikacji przed dostarczeniem ich do testów użytkownika. Testy funkcjonalne umożliwiają zespołowi testowemu odbiorcy (w tym przedstawicielom użytkowników końcowych) zweryfikowanie zgodności dostarczonej funkcjonalności ze specyfikacją wymagań.

Testy akceptacyjne weryfikują kompletne moduły lub całe oprogramowanie pod względem funkcjonalnym wraz z weryfikacją możliwości wykonania poszczególnych czynności przez użytkowników końcowych zgodnie z ich profilami uprawnień. Ponadto na tym etapie weryfikowana jest konwersja danych z istniejących systemów oraz sprawdzane są interfejsy.

Testy integracyjne stanowią ostatnią fazę testów przed przystąpieniem do wdrożenia pilotowego i mają za zadanie weryfikację całości systemu - wszystkich jego modułów funkcjonalnych, interfejsów, konwersji danych, uprawnień, a także wydajności systemu w warunkach jak najbardziej zbliżonych do rzeczywistych. Ostatnim etapem testów integracyjnych jest Próba Generalna Weekendu Konwersyjnego (PGWK). Odbywa się ona najpóźniej w ostatni weekend przed terminem rzeczywistej konwersji. Warunkiem przystąpienia do PGWK jest pozytywne zakończenie ostatniego etapu testów integracyjnych - testowych przetworzeń kolejnych dni operacyjnych skonwertowanej bazy. W czasie Próby Generalnej monitorowane są: czas realizacji zadań, odchylenia od planu oraz powody odchyleń.

Do każdego rodzaju testu (oprócz testów wewnętrznych producenta) ustalane są z dostawcą odrębne kryteria akceptacji i odbioru, przygotowywane scenariusze i określany jest sposób raportowania błędów. Najczęściej stosowanym kryterium akceptacji jest usunięcie wszystkich błędów krytycznych zgłoszonych do dostawcy. Praktyka pokazuje, że pozostawienie dużej liczby błędów niekrytycznych w systemie po jego odebraniu, zmniejsza znacząco motywację dostawcy do ich usunięcia, zwłaszcza że to właśnie z procedurą akceptacji testów związane są płatności dla dostawców.

Z powyższych powodów bardzo ważne jest ustalenie przed rozpoczęciem procesu testowego właściwych kryteriów odbioru. W ramach takich uzgodnień należy zdefiniować możliwe rodzaje zgłaszanych błędów, ich wagę wraz z dokładnym opisem każdej kategorii błędów, określić możliwe stany zgłaszanych problemów (błędów), diagram przepływu pomiędzy stanami, zakładane czasy na weryfikację, poprawki i testowanie poprawek, harmonogram dostarczania poprawek oraz czas na ich retestowanie. Ponadto należy zdefiniować kryteria odbioru aplikacji i dopuszczenia do produkcyjnego wykorzystania systemu.

W przypadku istnienia błędów krytycznych w wyjątkowych sytuacjach komitet sterujący projektu może podjąć decyzję o przejściu do kolejnych etapów testów z zastrzeżeniem usunięcia błędów w określonych terminach. Wiąże się to najczęściej z decyzją o wstrzymaniu części płatności.

W ramach organizacji projektu powinien powstać zespół testowy złożony zarówno z przedstawicieli zespołu wdrożeniowego odpowiedzialnego za przygotowanie wymagań, jak i przedstawicieli użytkowników końcowych systemu. Zespół testowy posiada na ogół własnego lidera podległego bezpośrednio kierownikowi projektu.

Podczas całego procesu testowania systemu należy położyć szczególny nacisk na dokumentowanie przebiegu testów. Dokumentacja taka jest jednym z ważniejszych argumentów podczas rozstrzygania sporów dotyczących odbiorów i płatności.

Wdrażanie z problemami

Najczęściej pojawiające się problemy podczas procesu testów oprogramowania chciałbym omówić na przykładzie doświadczeń z wdrożeń w bankach. W ostatnich latach mieliśmy w polskiej bankowości do czynienia z wymianą systemów oddziałowych na systemy centralne. Projekty wdrożeń scentralizowanych systemów bankowych były jednymi z największych zarówno pod względem budżetów, liczby zaangażowanych ludzi, jak i stopnia skomplikowania wdrażanych rozwiązań.

Pierwszym problemem, który dość często występował podczas wdrożeń, było przekazanie całego procesu wdrożeniowego, w tym także testów odbiorczych, departamentom informatyki. W efekcie użytkownicy końcowi systemów mieli okazję zetknąć się z systemem dopiero po jego wdrożeniu, co często powodowało szok wynikający z dysproporcji między oczekiwaniami a wdrożonym zakresem funkcjonalnym.

Innym problemem było przerzucenie na dostawcę całkowitej odpowiedzialności za przygotowanie skryptów i scenariuszy testowych. Wychodzono z założenia, że dostawca zna lepiej system, więc lepiej je opracuje. W rezultacie zespoły testowe odbiorcy otrzymywały tylko taką część skryptów, która obejmowała wygodne dla producenta scenariusze i przypadki, bardzo często niepokrywające pełnego spektrum procesów zachodzących w danym banku.

Właściwie w każdym wdrożeniu miałem okazję spotkać się z problemem dotyczącym klasyfikacji błędów oraz zarządzaniem bazą błędów. Zespoły testowe bardzo często stosowały własne interpretacje poziomu krytyczności błędów, co w przypadku bieżącego braku nadzoru koordynatorów (liderów zespołów testowych) prowadziło do wypaczenia sytuacji w procesie testowym. Z drugiej strony dostawcy bardzo często zaniżali poziom ważności błędów lub zamykali je w bazach bez porozumienia z koordynatorami odbiorców.

Samo pojęcie błędu też powodowało wiele nieporozumień i sporów. Dobrym zwyczajem jest posługiwanie się pojęciem ZGŁOSZENIA, zamiast błędu. Pozwala to na określenie, jaka część zgłaszanych problemów jest faktycznie błędami rozumianymi jako niezgodność systemu z dokumentacją i wynegocjowanym zakresem funkcjonalnym, jaka część to błędy użytkowników (takie też się zdarzają), jaka część wynika np. ze zmiany formy obsługi w nowym systemie i nie jest błędem, ale oczekiwanym prawidłowym funkcjonowaniem systemu, a jaka część zgłoszeń jest żądaniami zmiany systemu ponad oferowaną i dostarczaną funkcjonalność. Problemy pojawiające się przy negocjacji żądań zmian i odpłatności za nie stanowią jeden z najpoważniejszych problemów podczas całego procesu wdrożeniowego.

Ostatni z problemów dotyczy błędów regresyjnych. Z różnych powodów w przetestowanym już pozytywnie oprogramowaniu pojawiają się ponownie błędy, które już były poprawione lub błędy zupełnie nowe.

Piotr Malec jest prezesem Polskiego Oddziału Project Management Institute (PMI Warsaw Poland Chapter). Pracuje jako dyrektor Sektora Bankowego w Unisys Polska. Artykuł jest zredagowanym abstraktem wystąpienia na III Konferencji Jakości Systemów Informatycznych.


TOP 200