Testy dostawcy a testy niezależne: kiedy jedno nie zastępuje drugiego

Dostawca testuje, i robi to lepiej, niż się o tym mówi

Zacznijmy od uczciwego postawienia sprawy. Jeśli Wasz dostawca ma własny zespół testowy, pisze przypadki testowe i pokazuje raport przed odbiorem, robi dokładnie to, co do niego należy. W projektach, które przeglądamy po 15 latach na rynku, zespoły dostawców testują w większości porządnie, a programista zna wnętrze swojego modułu najlepiej. Mówi to wprost sam standard: według sylabusa ISTQB Foundation Level w wersji 4.0.1 z 2024 roku niezależność nie zastępuje znajomości przedmiotu, bo programiści potrafią skutecznie znaleźć wiele defektów we własnym kodzie. Problem nie leży więc w umiejętnościach dostawcy. Leży w strukturze.

Skąd wtedy biorą się błędy, które wychodzą dopiero u Was, w pierwszym tygodniu po wdrożeniu? Prawie nigdy z braku staranności. Ten sam zespół spisuje założenie, implementuje je i sprawdza, czy zostało spełnione, więc to samo założenie siedzi we wszystkich trzech krokach. Jeśli było błędne, wszystkie trzy potwierdzą się wzajemnie, a raport wyjdzie zielony. Prosić autora założenia, żeby znalazł w nim błąd, to jak szukać literówki we własnym nazwisku: wzrok prześlizguje się po niej od lat.

Ten argument waży dziś więcej niż pięć lat temu. Według World Quality Report 2025 od Capgemini i OpenText, opartego na rozmowach z ponad 2 000 menedżerów w 22 krajach, 89% organizacji pilotuje albo wdraża przepływy pracy wspomagane generatywną AI w inżynierii jakości. Jeśli dostawca generuje część kodu i część testów tym samym narzędziem, oba artefakty dziedziczą ten sam zestaw założeń.

Cztery poziomy niezależności, czyli co właściwie dokupujecie

„Testy niezależne” brzmią jak jedna pozycja na fakturze, a w praktyce są suwakiem. Według sylabusa ISTQB Foundation Level w wersji 4.0.1 z 2024 roku niezależność ma cztery poziomy: produkt testuje jego autor, koledzy autora z tego samego zespołu, testerzy spoza zespołu autora, ale z tej samej organizacji, albo testerzy spoza organizacji. Różnica między nimi nie polega na kompetencji, polega na odległości od założeń.

Drugi wymiar tej rozmowy opisała agencja kosmiczna. NASA w opisie swojego programu IV&V, w wersji strony z 2024 roku, przypomina definicję IEEE, według której niezależność w weryfikacji i walidacji ma trzy parametry: techniczny, zarządczy i finansowy. Zarządczy oznacza, że odpowiedzialność leży w organizacji odrębnej od wdrażającej system, a zespół sam wybiera fragmenty do analizy, techniki i harmonogram. Finansowy oznacza, że budżet leży po stronie niezależnej od wytwórcy. Jeśli zakres i stawkę drugiej pary oczu ustala ten, kogo ta para oczu kontroluje, niezależność została wyłącznie nazwana.

Sylabus ISTQB w wersji 4.0.1 z 2024 roku zaleca przy tym pracę na kilku poziomach naraz: programiści biorą testy komponentów, zespół testowy testy systemowe i integrację systemową, a przedstawiciele biznesu testy akceptacyjne. NASA dodaje zdanie przydatne przy rozmowie o budżecie: „Most projects view V&V as sufficient and do not recognize the added value the independence brings.” Weryfikacja pyta, czy produkt budujemy poprawnie, walidacja, czy budujemy właściwy produkt, a to drugie pytanie prawie zawsze zostaje bez niezależnego gospodarza. Dla części z Was zdecydował już ustawodawca, co opisujemy w tekście o testach niezależnych od producenta jako wymogu prawnym.

Protokół odbioru jest najsłabszym filtrem w całym łańcuchu

Przejdźmy do liczb, bo obiekcja, którą słyszymy od CTO najczęściej, brzmi: nie wiemy, jaki będzie efekt końcowy testów. W modelu Capersa Jonesa z Namcook Analytics z 2012 roku, w tabeli 7, dwa scenariusze startują z tego samego potencjału 1 000 defektów. W pierwszym, bez inspekcji i analizy statycznej, testy jednostkowe usuwają 25%, systemowe 35%, a akceptacyjne 15%, co daje 134 defekty u klienta i skuteczność usuwania defektów całego łańcucha na poziomie 86,60%.

W drugim scenariuszu tego samego zestawienia Capersa Jonesa dochodzi analiza statyczna o skuteczności 60% i inspekcja przed testami o skuteczności 85%. Do klienta trafia wtedy 5 defektów, a skuteczność całego łańcucha wynosi 99,50%. Jeden etap nie drgnął: testy akceptacyjne, 15% w obu wariantach. Tego etapu, na którym Wy podpisujecie protokół odbioru, nie podnoszą ani inspekcje, ani analiza statyczna.

Do tego dochodzi próg. W zestawieniu Capersa Jonesa z 2012 roku projekty ze skutecznością poniżej 85% zawsze są spóźnione, zawsze przekraczają budżet i nigdy nie mają zadowolonych klientów, a projekty powyżej 95% zwykle zdążą i zmieszczą się w budżecie. Podpis na protokole nie jest dowodem jakości systemu, jest dowodem, że przeszedł ostatni i najcieńszy filtr. Jak rozmawiać o takich liczbach z finansami, pokazujemy w tekście o metrykach jakości, które CFO rozumie bez tłumacza.

Trzy rzeczy, których testy dostawcy nie wyłapią strukturalnie

Pierwsza to błąd w samym założeniu. Według sylabusa ISTQB Foundation Level w wersji 4.0.1 z 2024 roku niezależny tester może zweryfikować, podważyć albo obalić założenia przyjęte przy specyfikacji i implementacji systemu, bo wnosi inne tło i inne skrzywienia poznawcze. Autor tego nie zrobi, bo dla niego założenie jest tłem, nie przedmiotem badania.

Druga to integracje i dane po Waszej stronie. Dostawca nie ma u siebie Waszej hurtowni, Waszej historii rekordów ani Waszych wyjątków taryfowych, więc testuje na danych, które sam sobie wymyślił. Z naszych ponad 450 000 napisanych testów automatycznych widzimy to w kółko: dane dostawcy są czyste i grzeczne, a prawdziwy rekord sprzed dekady ma puste pole, które według specyfikacji puste być nie może. Tę warstwę da się sprawdzić tylko na Waszym środowisku.

Trzecia to warunki pozafunkcjonalne w Waszym szczycie, a nie w laboratorium dostawcy. Tutaj liczby z naszych projektów mówią najwięcej. W projekcie dla Autono z branży car rental system pozostał stabilny przy obciążeniu większym o 120%, a błędy krytyczne w procesach rezerwacji spadły o 55%. W projekcie dla Argos z e-commerce awarie w szczycie spadły o 72%, a regresja przed releasem skróciła się z 5 dni do 10 godzin. Żadnej z tych liczb nie dałoby się uzyskać na profilu obciążenia wymyślonym poza Waszym biznesem, dlatego warto rozważyć własne testy oprogramowania po stronie zamawiającego.

Co zapisać w umowie, żeby druga para oczu nie była walką o budżet

Najtrudniejsze rozmowy o testach niezależnych widzimy tam, gdzie umowa milczała, a temat wypłynął przy poślizgu wdrożenia. Wtedy każda złotówka na niezależną weryfikację wygląda jak zarzut wobec dostawcy. Gdy to samo stoi w umowie od pierwszego dnia, jest elementem odbioru, obok dokumentacji i szkoleń. W sektorze finansowym macie to zresztą narzucone: rozporządzenie DORA wymaga testów niezależnych wprost, a przy dostawcach oprogramowania podobnie działa reżim NIS2 wobec łańcucha dostaw.

Źródło: opracowanie własne Quality Island.

Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „Niezależność testów to nie wotum nieufności wobec dostawcy. To przyznanie, że jeden zespół nie może być naraz autorem założenia i jego egzaminatorem. Dlatego w umowie pytam nie o to, czy dostawca testuje, tylko kto sprawdzi to, czego dostawca ze swojego miejsca nie ma jak zobaczyć.”

W projekcie dla ChaosGears z branży medycznej zbudowaliśmy dokumentację testową i odbiorczą oraz procedury odbiorcze, i to one, spisane przed odbiorem, zdejmowały później spory z agendy spotkań. Trzeci najczęstszy powód, z którym przychodzą do nas firmy, to wymóg prawny, że testy musi wykonać podmiot niezależny od producenta. Jeśli działacie w sektorze regulowanym, dobrą kolejnością jest najpierw audyt procesów QA od 15 500 zł, a dopiero potem decyzja o stałym zarządzaniu testami. Co w takim przeglądzie sprawdza kontroler, rozkładamy w tekście o audycie niezależnym od producenta.

Nasza perspektywa: niezależność to nie wotum nieufności

Uczciwie: niezależność ma koszty, a sylabus ISTQB Foundation Level w wersji 4.0.1 z 2024 roku wymienia pięć z nich bez owijania. Niezależni testerzy mogą zostać odizolowani od zespołu wytwórczego, co prowadzi do braku współpracy albo relacji przeciwniczej. Programiści mogą stracić poczucie odpowiedzialności za jakość. A sam niezależny tester łatwo staje się wąskim gardłem i adresatem zarzutów o opóźnienie wydania. To nie są argumenty przeciw niezależności, to lista rzeczy do zaprojektowania w procesie.

Co w naszych projektach rozbraja te punkty? Wspólna definicja ukończenia, uzgodniona przez Was, dostawcę i zespół niezależny, zanim zaczną się testy. Wspólne kryteria wejścia i wyjścia. Jeden rejestr defektów. I zasada, przy której upieramy się najmocniej: żadnych dwóch konkurencyjnych raportów o tym samym systemie, bo dwa raporty kończą się dyskusją o raportach, a nie o defektach. Jeśli chcecie, żeby Wasz zespół czytał cudze raporty na równych prawach, dobrym startem jest nasze szkolenie ISTQB Foundation Level z naszego kalendarza szkoleń, a raz w roku warto posłuchać praktyków na naszej konferencji Testing Ground. Wtedy druga para oczu nie jest kontrolą nad Wami, jest Waszym narzędziem.

Powiązane na Strefie QA

• Testy niezależne od producenta jako wymóg prawny: kto, kiedy i jaka dokumentacja
• Jak wybrać firmę do testów oprogramowania: checklista dla dyrektora IT
• Umowa ramowa na testy: jak sektor publiczny kupuje QA i co z tego wynika dla wyceny

Źródła:

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Stąd cztery poziomy niezależności, korzyści i wady oraz zalecenie testów na kilku poziomach naraz.
• Capers Jones, Namcook Analytics, Software Quality Metrics: Three Harmful Metrics and Two Helpful Metrics, 2012. Stąd skuteczności poziomów testów, 15% dla akceptacyjnych, wyniki 86,60 i 99,50% oraz koszty jakości 125 000 i 120 000 dolarów.
• NASA, IV&V Overview, 2024. Stąd trzy parametry niezależności według IEEE oraz różnica między weryfikacją i walidacją.
• Capgemini i OpenText, World Quality Report 2025, 2025. Stąd skala badania, ponad 2 000 menedżerów w 22 krajach, oraz 89% organizacji wdrażających generatywną AI w inżynierii jakości.