Testy oprogramowania w umowie wdrożeniowej IT. Poradnik dla software house’ów #12

W artykule na temat odbiorów wspominałem, że w ramach tego etapu, rekomendowanym przeze mnie rozwiązaniem jest wprowadzenie procedur testowych celem weryfikacji poprawności wykonanego oprogramowania. Z lektury tego artykułu dowiesz się, na jakie podstawowe kwestie w tym zakresie należy zwrócić uwagę w umowie wdrożeniowej.

Artykuł jest częścią serii dotyczącej umowy wdrożeniowej, poniżej znajdziesz odnośniki do pozostałych wpisów. Jeśli, któryś z artykułów nie jest jeszcze podlinkowany, oznacza to, że wpis dotyczący tego zagadnienia pojawi się na blogu w najbliższej przyszłości.

Dlaczego testowanie wytworzonego oprogramowania jest tak ważne?

Przeprowadzenie testów przed dokonaniem odbioru stanowi dobrą praktykę w umowach wdrożeniowych. Podjęcie takich czynności pozwala na weryfikację działania przedmiotu odbioru oraz jego zgodności z umową.

Testowanie stanowi integralną część cyklu życia oprogramowania (SDLC, software development life cycle) i pozwala na wczesne wykrywanie oraz usuwanie błędów, co znacząco obniża koszty naprawy w porównaniu do defektów wykrytych po wdrożeniu w środowisku produkcyjnym.

Dodatkowo, testowanie buduje zaufanie do wprowadzanych zmian i nowych funkcji, zapewniając że działają one poprawnie i nie wpływają negatywnie na istniejącą funkcjonalność systemu.

Testy – jako warunek odbioru oprogramowania – mogą być przeprowadzane zarówno dla każdej z faz, tylko dla określonych faz lub jednorazowo przed dokonaniem odbioru końcowego. Decyzja zależy przede wszystkim od charakteru i zakresu przedmiotu umowy oraz stopnia zawiłości projektu.

Zamów wzór umowy wdrożeniowej IT!

Ustalanie procesu testowania oprogramowania

Strony powinny ustalać tryb przeprowadzania testów oraz podmiotu upoważnione do ich przeprowadzenia. W praktyce należy rozróżnić różne rodzaje testów i przypisać odpowiedzialność za ich wykonanie.

Testy jednostkowe (unit testing) weryfikujące poprawność najmniejszych fragmentów kodu są zazwyczaj wykonywane przez deweloperów software house’u. Testy integracyjne sprawdzające interakcje między modułami realizują deweloperzy wspólnie z testerami. Testy systemowe oceniające całość systemu przeprowadzają dedykowane zespoły QA. Natomiast testy akceptacyjne stanowią ostateczną weryfikację przez klienta, czy oprogramowanie spełnia jego oczekiwania biznesowe.

Najczęściej są to testy przeprowadzane przez wykonawcę z prawem uczestniczenia w nich przez zamawiającego (przy czym należy opisać, na czym taki udział klienta ma polegać). Umowa powinna precyzować procedury akceptacyjne, szczegółowe kryteria akceptacji, ramy czasowe na przeprowadzenie testów i zgłaszanie uwag, a także konsekwencje niepowodzenia testów, takie jak konieczność poprawek czy renegocjacja terminów. W branżach o rygorystycznych standardach prawnych, takich jak opieka zdrowotna czy finanse, konieczne może być także przeprowadzenie testów akceptacyjnych regulacyjnych zapewniających zgodność z normami prawnymi.

Nierzadko zamawiający negocjują także możliwość przeprowadzenia własnych testów (ponad te przeprowadzane przez wykonawcę) przez siebie lub wyznaczone osoby trzecie. W tym przypadku należy jednak pamiętać o uprzednim ustaleniu i wyrażeniu zgody na dane scenariusze testowe oraz ewentualne osoby trzecie przeprowadzające testy.

Testowanie wyprodukowanego oprogramowania to dzisiaj standard na rynku IT

Z perspektywy wykonawcy warto zwrócić uwagę na odpowiednie określenie kryteriów pozytywnego przeprowadzenia testów. Kryteria akceptacji powinny być mierzalne, obiektywne i weryfikowalne, co umożliwia jednoznaczną ocenę.

Należy rozróżnić kryteria funkcjonalne określające co system ma robić (np. „System powinien pozwalać użytkownikom logować się za pomocą poprawnej nazwy użytkownika i hasła”) od kryteriów niefunkcjonalnych określających jak system ma działać (np. „Aplikacja powinna ładować się w ciągu 3 sekund od otwarcia”). Standard ISO 25010 definiuje dziewięć głównych charakterystyk jakościowych oprogramowania, które mogą stanowić podstawę dla szczegółowych kryteriów w umowie.

Niewielkie nieprawidłowości, niewpływające na funkcjonowanie systemu, nie powinny bowiem uniemożliwiać dokonania odbioru (usterki mogą zostać naprawione np. w ramach kolejnego odbioru, usług gwarancji, usług serwisowych – w zależności od ustaleń stron).

W tym kontekście kluczowa jest klasyfikacja defektów według ich wpływu na system. Defekty krytyczne powodujące całkowite zatrzymanie działania systemu wymagają natychmiastowej reakcji (np. w ciągu 24 godzin), defekty poważne ograniczające kluczową funkcjonalność powinny być naprawione w ciągu 72 godzin, podczas gdy drobne usterki wizualne mogą być usunięte w kolejnej aktualizacji. Umowa powinna jasno określać progi akceptowalnej liczby błędów każdej kategorii, które nie blokują odbioru.

Wskazanie w umowie wdrożeniowej środowiska testowego

W umowie należy określić także środowisko testowe, w którym przeprowadzane będą testy lub ewentualne wskazać inne środowiska, w których wykonywane będą testy funkcjonalne oprogramowania IT.

Środowisko testowe to kontrolowana infrastruktura stworzona specjalnie do celów testowania, mająca na celu jak najwierniejsze odzwierciedlenie środowiska produkcyjnego. Klauzule kontraktowe powinny precyzować konfigurację wymaganego sprzętu i oprogramowania, procesy zarządzania danymi testowymi z zapewnieniem prywatności i bezpieczeństwa, kontrolę dostępu oraz procedury monitorowania i utrzymania środowiska.

Należy jasno określić, kto jest odpowiedzialny za dostarczenie i utrzymanie środowiska testowego – często klient dostarcza infrastrukturę, a software house konfiguruje i testuje. Jeśli środowisko testowe znacząco różni się od produkcyjnego, umowa powinna określać implikacje takiej rozbieżności dla odpowiedzialności za wady wykryte dopiero w produkcji.

Testowanie akceptacyjne zgodności z umową wdrożeniową

Procedura przeprowadzania testów oraz scenariusze testowe mogą stanowić część umowy, niemniej w wielu przypadkach strony w kontrakcie jedynie ustalają, w jaki sposób takie scenariusze testowe będą ustalane przez strony na danym etapie wykonywania umowy. W części projektów nie sposób z góry ustalić plany testowe. Tryb powinien jednak być na tyle szczegółowy, aby proces w odpowiednim zakresie uwzględniał uprawnienia wykonawcy w przedmiocie ustalania scenariuszy.

Dokumentacja testowa stanowi kluczowy dowód zgodności z umową. Powinna obejmować strategię testów, plan testów, przypadki testowe, dane testowe oraz raporty podsumowujące.

Odwołanie się do uznanych standardów branżowych, takich jak terminologia ISTQB czy procesy opisane w normie ISO/IEC/IEEE 29119, pozwala przekształcić ogólne zobowiązania do „należytej staranności” w konkretne, mierzalne wymagania.

W przypadku sporów, szczegółowa dokumentacja testowa służy jako dowód dołożenia należytej staranności przez software house.