Odbiór systemu IT: testy akceptacyjne, kryteria i protokół

Odbiór systemu IT to formalne potwierdzenie, że wykonawca dostarczył to, co obiecał w umowie, sprawdzone testami akceptacyjnymi według scenariuszy i kryteriów uzgodnionych przed rozpoczęciem testów. Dobrze przeprowadzony odbiór kończy się protokołem, listą błędów z terminami poprawek i przekazaniem wszystkiego, czego firma potrzebuje, żeby z systemu korzystać i go rozwijać: kodu, dokumentacji, dostępów i instrukcji. Poniżej opisuję, jak taki odbiór zaplanować, kto powinien testować, jak klasyfikować błędy i co zapisać w umowie, zanim pojawi się pierwszy spór.

Najczęstszy scenariusz wygląda tak: wykonawca ogłasza, że system jest gotowy, zamawiający klika przez kilka ekranów, coś działa, coś nie, a po dwóch tygodniach maili nikt nie wie, czy system został odebrany. Tego da się uniknąć, jeśli odbiór traktuje się jak osobny etap projektu, a nie formalność na końcu.

Czym jest odbiór systemu IT i kiedy zacząć go planować

Odbiór planuje się na początku projektu, a nie w tygodniu wdrożenia. Kryteria, według których system zostanie uznany za gotowy, powinny wynikać z wymagań i trafić do umowy albo do załącznika, zanim zespół napisze pierwszą linijkę kodu.

Ma to też wymiar prawny. Jeśli umowa jest umową o dzieło, art. 643 Kodeksu cywilnego w tekście jednolitym stanowi, że zamawiający jest obowiązany odebrać dzieło, które wykonawca wydaje mu zgodnie ze swoim zobowiązaniem. Spór o odbiór sprowadza się więc często do pytania, czym właściwie było to zobowiązanie. Umowy IT bywają mieszane, z elementami usług i licencji, dlatego konkretne zapisy warto skonsultować z prawnikiem. Ten tekst nie jest poradą prawną.

Z praktyki wykonawcy wynika prosty wniosek: im lepiej opisane wymagania, tym krótszy i spokojniejszy odbiór. Jak przygotować taki opis, pokazałem w tekście o tym, czym powinna być specyfikacja wymagań systemu. Scenariusze testów akceptacyjnych pisze się później prawie wprost z tego dokumentu.

Testy akceptacyjne przy odbiorze systemu IT: kto testuje i na czym

Testy akceptacyjne wykonują ludzie z firmy zamawiającego, którzy na co dzień pracują w danym procesie, na środowisku testowym z danymi zbliżonymi do prawdziwych. Wykonawca testuje wcześniej i osobno. Testy akceptacyjne mają sprawdzić, czy system wspiera pracę firmy, a nie czy programista dobrze zrozumiał własny kod.

Przed startem testów ustal kilka rzeczy:

• Kto testuje: imiennie, z każdego działu, którego dotyczy system, wraz z czasem zarezerwowanym w kalendarzu na testy.
• Na czym: środowisko testowe odseparowane od produkcji, z kopią lub próbką danych, w razie potrzeby zanonimizowaną.
• Jak długo: okno testowe zapisane w harmonogramie i w umowie, z terminem na poprawki i ponowne testy.
• Gdzie zgłaszać błędy: jedno narzędzie, a nie mail, telefon i komunikator jednocześnie.
• Kto decyduje: jedna osoba po stronie zamawiającego, która rozstrzyga, czy zgłoszenie to błąd, czy nowe wymaganie.

Ostatni punkt jest najważniejszy. W trakcie testów użytkownicy zgłaszają nie tylko błędy, ale też pomysły, co można zrobić lepiej. To naturalne, ale pomysł nie blokuje odbioru, tylko trafia na listę zmian do wyceny lub do kolejnego etapu.

Scenariusze testowe pisane językiem procesu

Scenariusz testowy opisuje krok po kroku konkretną sytuację z pracy firmy i oczekiwany wynik, bez odwołań do kodu czy bazy danych. Dzięki temu może go wykonać pracownik działu handlowego czy magazynu, a wynik jest jednoznaczny: zgodny albo niezgodny.

Weźmy przykład firmy dystrybucyjnej, która odbiera system do obsługi zamówień. Fragment listy scenariuszy mógłby wyglądać tak:

Scenariusz	Kroki	Oczekiwany wynik
Zamówienie klienta z rabatem indywidualnym	Handlowiec zakłada zamówienie dla klienta z przypisanym rabatem	Ceny pozycji uwzględniają rabat zgodny z kartą klienta
Przekroczony limit kupiecki	Handlowiec zakłada zamówienie powyżej limitu klienta	System wstrzymuje zamówienie i wysyła je do akceptacji kierownika
Zamówienie częściowe	Magazyn kompletuje tylko część pozycji	Klient dostaje informację o częściowej wysyłce, reszta czeka w zamówieniu
Uprawnienia handlowca	Handlowiec próbuje otworzyć klienta z innego regionu	System odmawia dostępu

Dobre scenariusze obejmują nie tylko ścieżkę, w której wszystko idzie gładko, ale też wyjątki: brak towaru, błędne dane, odrzuconą płatność, przerwę w integracji z innym systemem. Przy systemach zintegrowanych z ERP lub sklepem scenariusz powinien sprawdzić, czy dane dotarły na drugą stronę, a nie tylko czy ekran pokazał komunikat o sukcesie.

Kryteria odbioru i klasy błędów

Kryterium odbioru mówi, przy jakim stanie błędów system uznaje się za odebrany. Najczęściej spotykane podejście: brak otwartych błędów krytycznych i poważnych, a drobne błędy wpisane do protokołu z terminem poprawki. Bez takiej reguły każdy znaleziony błąd staje się argumentem, żeby nie podpisywać odbioru.

Klasa błędu	Przykład	Wpływ na odbiór
Krytyczny	Nie da się złożyć zamówienia, dane giną lub trafiają do niewłaściwego klienta	Blokuje odbiór
Poważny	Proces działa tylko z obejściem, błędne wyliczenie w raporcie	Blokuje odbiór, chyba że strony uzgodnią obejście na piśmie
Drobny	Niewygodny formularz, mylący komunikat	Nie blokuje, trafia do protokołu z terminem poprawki
Kosmetyczny	Literówka, przesunięty element na ekranie	Nie blokuje, poprawka w ramach gwarancji

Definicje klas warto zapisać w umowie razem z przykładami z Twojego procesu. Ta sama klasyfikacja przyda się później w umowie utrzymaniowej, bo od klasy zgłoszenia zależą czasy reakcji i naprawy. Szerzej opisałem to w tekście o tym, co powinna zawierać umowa SLA na utrzymanie systemu.

Protokół odbioru: co w nim zapisać

Protokół odbioru systemu IT to dokument, który zamyka etap i jest podstawą do płatności. Powinien jednoznacznie mówić, co zostało odebrane, w jakiej wersji i z jakimi zastrzeżeniami.

Minimalna zawartość protokołu:

• nazwa systemu lub etapu i oznaczenie wersji, która była testowana,
• lista wykonanych scenariuszy z wynikiem,
• lista otwartych błędów z klasą i terminem poprawki,
• lista przekazanych elementów: kod, dokumentacja, dostępy, instrukcje,
• decyzja: odbiór bez zastrzeżeń, odbiór z zastrzeżeniami albo odmowa odbioru z uzasadnieniem,
• podpisy osób upoważnionych po obu stronach.

Przy większych projektach dobrze sprawdzają się odbiory częściowe, po każdym etapie lub module. Błędy wychodzą wcześniej, a końcowy odbiór dotyczy głównie integracji między modułami. To podejście dobrze łączy się z modelem rozliczeń za etapy, o którym pisałem przy porównaniu fixed price i time and materials.

Co odebrać poza działającą aplikacją

Działający system to tylko część tego, za co płacisz. Odbiór systemu IT powinien obejmować wszystko, czego firma potrzebuje, żeby system utrzymać, rozwijać i w razie potrzeby przekazać innemu wykonawcy.

• Kod źródłowy w repozytorium, do którego firma ma dostęp jako właściciel, a nie tylko gość, razem z historią zmian.
• Dokumentacja techniczna: architektura, opis integracji, sposób instalacji i wdrażania nowych wersji, lista zewnętrznych bibliotek i usług.
• Dostępy: konta administracyjne, serwer, domena, konta w usługach zewnętrznych założone na firmę zamawiającego, a nie na prywatny adres programisty.
• Instrukcje: dla użytkowników i dla administratora, w tym procedura postępowania przy awarii.
• Konfiguracja i dane: ustawienia środowiska produkcyjnego, wynik migracji danych i potwierdzenie, że dane źródłowe zostały przeniesione w całości.

Najłatwiej odebrać te elementy w dniu odbioru, kiedy wykonawca jest jeszcze zaangażowany w projekt i ma wszystko pod ręką. Kwestie praw do kodu i licencji na komponenty powinny być rozstrzygnięte w umowie, a protokół jedynie potwierdza, co faktycznie zostało przekazane.

Co zapisać w umowie, żeby odbiór nie stał się sporem

Umowa powinna opisywać odbiór systemu IT tak, żeby obie strony wiedziały, co się dzieje po każdym kroku. Większość konfliktów przy odbiorach nie dotyczy jakości kodu, tylko tego, że nikt nie ustalił reguł.

1. Procedura: zgłoszenie gotowości, okno testowe, termin na poprawki, ponowne testy, podpisanie protokołu.
2. Kryteria i klasy błędów z definicjami i przykładami.
3. Skutek braku reakcji: co się dzieje, gdy zamawiający nie przetestuje systemu w uzgodnionym terminie. Wykonawca nie może czekać bez końca, ale zamawiający potrzebuje realnego czasu na testy.
4. Odbiory częściowe i ich związek z płatnościami.
5. Lista elementów do przekazania, ta sama, która trafi później do protokołu.
6. Gwarancja: jak długo i na jakich zasadach wykonawca poprawia błędy znalezione po odbiorze.

Przy umowie o dzieło Kodeks cywilny daje zamawiającemu narzędzia także przed odbiorem: art. 636 pozwala wezwać wykonawcę do zmiany sposobu wykonania, jeśli dzieło powstaje wadliwie albo sprzecznie z umową. Umowa dopasowana do projektu informatycznego i tak jest jednak czytelniejsza niż przepisy ogólne, bo opisuje konkretny system, a nie dowolne dzieło.

Jeśli zbliża się odbiór systemu IT w Twojej firmie, zacznij od spisania scenariuszy dla najważniejszych procesów i listy elementów do przekazania, a potem porównaj je z tym, co mówi umowa. Braki lepiej uzupełnić aneksem przed testami niż w trakcie sporu. Jeśli chcesz, żeby ktoś z zewnątrz przejrzał plan odbioru, sprawdź, jak wygląda współpraca ze mną.