Testy niezależne od producenta to weryfikacja oprogramowania przez firmę, która go nie tworzyła i nie ma interesu w tym, żeby wynik wyszedł dobrze.
Dostawca testuje, żeby oddać system.
My testujemy, żebyście wiedzieli, co odbieracie.
Takiego rozdziału ról wymagają dziś regulacje i praktyka nadzoru w sektorze finansowym, odbiory systemów w ochronie zdrowia oraz coraz częściej umowy z dostawcami oprogramowania w dużych organizacjach.
To nasz czwarty segment klientów z wymogiem, o którym piszemy na stronie zgodności regulacyjnej.
Dlaczego testy niezależne od producenta?
Oprogramowanie testowane wyłącznie przez jego wykonawcę ma jeden problem: ten sam zespół pisze wymagania, kod i testy, więc rozumie je tak samo i popełnia te same błędy.
Niezależny zespół czyta wymagania bez wiedzy o tym, co „miało być”, i sprawdza to, co jest.
W sektorze finansowym regulacje i praktyka nadzoru oczekują rozdziału testowania od wytwarzania.
Rozporządzenie DORA wymaga, żeby testy operacyjnej odporności cyfrowej przeprowadzały strony niezależne, wewnętrzne albo zewnętrzne, a w przypadku testów penetracyjnych opartych na analizie zagrożeń testerzy muszą spełniać określone warunki.
Dyrektywa NIS2 i polska ustawa o krajowym systemie cyberbezpieczeństwa wymagają od podmiotów kluczowych i ważnych zarządzania ryzykiem w łańcuchu dostaw, co w praktyce oznacza sprawdzanie oprogramowania dostawców.
W ochronie zdrowia odbiór systemu przetwarzającego dane pacjentów wymaga dokumentacji testowej, którą da się pokazać audytorowi, a nie tylko zapewnienia dostawcy, że „wszystko działa”.
Więcej o wymogach piszemy w artykułach DORA a testy niezależne oraz audyt QA w sektorze regulowanym.
Co obejmuje niezależny audyt aplikacji?
Zakres dobieramy do wymogu, który macie spełnić, i do systemu, który odbieracie.
Najczęściej łączymy kilka rodzajów testów w jeden projekt z jedną dokumentacją:
- Testy akceptacyjne wobec wymagań: czy system robi to, co zamówiliście, z macierzą pokrycia wymagań, która jest podstawą decyzji o odbiorze.
- Testy bezpieczeństwa i pentest: podatności, kontrola dostępu, ochrona danych, raport techniczny i biznesowy, retest po poprawkach.
- Testy wydajności: zachowanie systemu pod obciążeniem, którego spodziewacie się w szczycie.
- Testy dostępności cyfrowej: zgodność z WCAG 2.2 tam, gdzie wymaga tego ustawa o dostępności albo klient.
- Przegląd dokumentacji testowej dostawcy: czy to, co dostawca nazywa testami, faktycznie pokrywa ryzyka.
Wynik to raport z oceną ryzyka, lista błędów z priorytetami i rekomendacja: odbierać, odbierać warunkowo albo nie odbierać.
Dokumentację piszemy tak, żeby przeszła przegląd audytora bez naszych wyjaśnień.
Dlaczego Quality Island?
- Zajmujemy się wyłącznie testami i jakością oprogramowania, nie budujemy systemów i nie sprzedajemy wdrożeń, więc nie mamy interesu w wyniku testu.
- Ponad 150 zrealizowanych projektów, ponad 100 firm, które skorzystały z naszych usług lub szkoleń, w tym PKO BP, Pekao SA, Santander, BNP Paribas, XTB, Luxmed i NFZ.
- Dla PKO BP opracowaliśmy strategię jakości oprogramowania dla całej organizacji i przeprowadziliśmy audyt procesów QA, dla ChaosGears z branży medycznej zbudowaliśmy dokumentację testową i odbiorczą oraz procedury odbiorcze.
- Ponad 70 projektów z testów bezpieczeństwa i ponad 70 z dostępności cyfrowej, dla dużych organizacji państwowych i mniejszych firm prywatnych.
- Zespół certyfikowany ISTQB, a firmę prowadzi Tomasz Stelmach, od ponad 15 lat w QA.
Jeżeli zanim zaczniecie testy, chcecie uporządkować cały proces jakości, lepszym pierwszym krokiem jest audyt QA.
Powiemy Wam to wprost na pierwszej rozmowie.
Chcę bezpłatną konsultację
