CTO firmy e-commerce z Poznania ma dobrze znany problem. Wydania wychodzą co dwa tygodnie, ręczna regresja trwa trzy dni, a co drugie wydanie kończy się poprawką na produkcji w ciągu 48 godzin. Firma od roku wynajmuje czterech testerów od dostawcy body leasingu. Na papierze to wystarczy. W praktyce CTO spędza poniedziałkowe poranki na ustalaniu, czym testerzy mają się zająć, czwartkowe wieczory na decyzji, czy wydawać, a każdą retrospektywę na tłumaczeniu zarządowi, dlaczego błędy znaleźli klienci, a nie zespół.
Problemem nie jest liczba testerów ani ich kompetencje. Problemem jest to, że CTO kupił moce przerobowe, a całą odpowiedzialność zostawił u siebie. Zarządzane usługi QA (managed QA, managed testing services) istnieją po to, żeby to zmienić: przenieść na dostawcę odpowiedzialność za wynik testowania — nie tylko godziny — i rozliczać go z mierzalnych KPI.
Poniżej wyjaśniamy, co ta odpowiedzialność naprawdę obejmuje i czego objąć nie może, czym managed QA różni się od body leasingu, outsourcingu projektowego i crowdtestingu, jak dostawcy wyceniają usługę — z przeliczonym przykładem — jakie KPI i SLA powinny trafić do umowy oraz jak zaplanować przejęcie i wyjście z usługi, zanim ją podpiszesz. Kwoty podajemy w złotych, na podstawie naszego benchmarku stawek na polskim rynku.
Czym są zarządzane usługi QA i co właściwie kupujesz?
Zarządzane usługi QA to model współpracy, w którym zewnętrzny dostawca jest właścicielem procesu testowego i odpowiada za uzgodniony wynik jakościowy. Planuje testy, buduje i prowadzi zespół, dobiera i utrzymuje narzędzia oraz frameworki automatyzacji, raportuje gotowość do wydania i stale usprawnia proces. Płacisz za usługę, a nie za godziny poszczególnych osób.
W praktyce kupujesz cztery rzeczy:
- Zarządzany zespół. Dostawca decyduje, kto jest w zespole, ile osób potrzeba w danym wydaniu, jak podzielić pracę między testy manualne i automatyczne, oraz wymienia ludzi, gdy trzeba — bez Twojego udziału.
- Proces. Strategia testów, planowanie oparte na ryzyku, kryteria wejścia i wyjścia dla każdej fazy testów, zasady triażu defektów, podejście do regresji i raportowanie. W dobrze prowadzonej usłudze to wszystko jest spisane i uzgodnione, a nie improwizowane.
- Aktywa. Zautomatyzowane zestawy testów, dane testowe, konfiguracja środowisk, przypadki testowe i dokumentacja. Powstają w trakcie usługi — a pytanie, kto jest ich właścicielem, przesądza o tym, jak bolesne będzie wyjście.
- Rozliczalność. KPI i SLA z konsekwencjami: raportowanie, ścieżki eskalacji, przeglądy usługi, a w części umów — część opłaty uzależniona od wyników.
Czego nie kupujesz, to odpowiedzialności za jakość produktu jako wynik biznesowy. Dostawca może odpowiadać za to, jak dobrze testuje to, co uzgodniono. Nie może odpowiadać za to, co Twoja firma uważa za „wystarczająco dobre” dla klientów — to zostaje po Twojej stronie. Wracamy do tego niżej.
Czym managed QA różni się od body leasingu testerów, outsourcingu projektowego i crowdtestingu?
Cztery modele często wrzuca się do jednego worka z napisem „outsourcing QA” i właśnie tu zaczyna się wiele nieudanych umów. Różnią się tym, kto zarządza pracą, kto odpowiada za wynik i jak się płaci.
| Kryterium | Body leasing testerów | Outsourcing projektowy QA | Managed QA | Crowdtesting |
|---|---|---|---|---|
| Kto zarządza testerami | Ty | Dostawca | Dostawca | Platforma / dostawca |
| Kto jest właścicielem procesu | Ty | Dostawca, w ramach projektu | Dostawca, w sposób ciągły | Ty definiujesz zakres cyklu |
| Za co odpowiada dostawca | Za dostępność i kompetencje | Za produkty projektu | Za KPI i SLA w czasie | Za liczbę i jakość zgłoszeń |
| Typowe rozliczenie | Stawka godzinowa lub dzienna | Cena stała za projekt | Opłata miesięczna, za wydanie lub częściowo za wynik | Za cykl testów, urządzenie lub zweryfikowany błąd |
| Czas trwania | Miesiące do lat | Tygodnie do miesięcy | Zwykle 12–36 miesięcy | Dni do tygodni na cykl |
| Najlepszy do | Uzupełniania zespołu, którym zarządzasz | Zamkniętego wydania lub migracji | Ciągłego testowania produktu z regularnymi wydaniami | Pokrycia realnych urządzeń i użytkowników, lokalizacji, użyteczności |
| Twój wysiłek zarządczy | Wysoki | Średni, skupiony na kamieniach milowych | Niski do średniego, skupiony na nadzorze | Średni na cykl |
Body leasing to właściwy model, gdy masz działający proces QA i kompetentnego menedżera jakości, a potrzebujesz więcej rąk lub konkretnych umiejętności. Ogólne różnice między modelami opisaliśmy w artykule o modelach sourcingu IT: augmentacji i usługach zarządzanych.
Outsourcing projektowy pasuje do przedsięwzięcia z wyraźnym końcem: testów migracji, certyfikacji wydania, budowy pierwszego zestawu testów automatycznych.
Managed QA pasuje do produktu z regularnym rytmem wydań, w którym chcesz mieć stabilną, rozwijającą się zdolność testową bez codziennego zarządzania nią.
Crowdtesting uzupełnia pozostałe modele, a nie je zastępuje. Daje szerokość — setki urządzeń, lokalizacji i prawdziwych użytkowników — ale nie głębię w Twojej domenie, nie zestaw regresji i nie ciągłość. Dobrze sprawdza się jako uzupełnienie managed QA przed dużym wydaniem mobilnym albo wejściem na nowy rynek, gdy liczy się pokrycie wielu urządzeń i języków w krótkim czasie.
Kiedy managed QA ma sens, a kiedy nie?
Managed QA nie jest uniwersalnie lepszą wersją body leasingu. To inna umowa z innymi warunkami wstępnymi. Z naszego doświadczenia działa dobrze, gdy spełniona jest większość poniższych warunków:
- Produkt ma przewidywalny rytm wydań — co jeden do czterech tygodni — więc dostawca może planować zasoby i mierzyć trendy.
- Zakres da się opisać. Aplikacje, platformy, krytyczne procesy biznesowe, integracje i środowiska są znane i względnie stabilne.
- Chcesz zmniejszyć obciążenie zarządcze, a nie tylko liczbę etatów. Celem jest to, żeby liderzy techniczni przestali układać grafik testerom.
- Rośnie ciężar regresji z każdym wydaniem i potrzebna jest uporządkowana strategia automatyzacji.
- Potrafisz zdefiniować, co oznacza dobra jakość — przynajmniej które procesy nie mogą się zepsuć i jaki poziom defektów na produkcji jest akceptowalny.
Zwykle nie działa albo nie powinien być pierwszym krokiem, gdy:
- Wymagania zmieniają się codziennie, a produkt wciąż szuka dopasowania do rynku. Umowa zarządzana zużyje energię na renegocjowanie zakresu.
- Testowanie jest nierozerwalne z wytwarzaniem w małym zespole pracującym w parach i z ciągłym wdrażaniem, gdzie „tester” to rola wewnątrz zespołu.
- Nikt nie potrafi powiedzieć, co oznacza dobra jakość. Przekazanie odpowiedzialności za niezdefiniowany wynik tworzy umowę, której nikt nie jest w stanie wykonać. W takiej sytuacji zacznij od oceny obecnego procesu — pomoże w tym nasza lista kontrolna dojrzałości procesu QA i analiza QA wewnętrzne czy outsourcing testów.
- Krytyczna wiedza domenowa jest wyłącznie w głowach kilku osób i nie da się jej przekazać w rozsądnym czasie przejęcia.
Co obejmuje zakres zarządzanej usługi QA?
Dojrzała usługa managed QA to więcej niż „wykonywanie testów”. Porównując oferty, sprawdź, które z poniższych obszarów są w zakresie, które są opcjonalne, a których brakuje:
- Strategia i planowanie testów. Spisana strategia oparta na ryzyku: które procesy są krytyczne, jakie poziomy testów je pokrywają, co jest automatyzowane, a co testowane eksploracyjnie. Przeglądana co najmniej raz na kwartał.
- Testy funkcjonalne i eksploracyjne. Uporządkowane testowanie nowych funkcji i sesje eksploracyjne, które szukają tego, czego nie znajdą testy skryptowe. To obszar, w którym doświadczeni testerzy wnoszą najwięcej wartości, jakiej nie zastąpi automatyzacja — piszemy o tym w artykule o testerze manualnym w erze AI.
- Automatyzacja testów. Budowa i utrzymanie zestawów automatycznych na poziomie API i UI, zintegrowanych z CI/CD, z określonym celem stabilności. Krzywą inwestycji opisujemy w artykule ile kosztuje automatyzacja testów w 2026 roku.
- Zarządzanie regresją. Zestaw regresji, który jest nie tylko rozbudowywany, ale też przycinany, z docelowym czasem cyklu. Więcej o samym podejściu w tekście o testach regresyjnych.
- Testy wydajnościowe. Testy obciążeniowe, przeciążeniowe i długotrwałe przed dużymi wydaniami lub sezonowymi szczytami — często jako pula zasobów, a nie stała rola.
- Testy bezpieczeństwa. Co najmniej integracja automatycznego skanowania i koordynacja z wyspecjalizowanymi pentesterami. Pełne testy bezpieczeństwa to zwykle osobne zlecenie.
- Testy dostępności. Coraz częściej obowiązkowe: Europejski Akt o Dostępności obowiązuje od 28 czerwca 2025 roku i obejmuje wiele produktów cyfrowych sprzedawanych w UE, w Polsce wdrożony ustawą z 26 kwietnia 2024 roku. Narzędzia automatyczne znajdują tylko część barier.
- Zarządzanie danymi testowymi. Tworzenie, maskowanie i odświeżanie danych testowych, zwłaszcza gdy dane produkcyjne zawierają dane osobowe podlegające RODO.
- Środowiska i urządzenia. Kto przygotowuje środowiska testowe i kto płaci za chmurę urządzeń oraz narzędzia do zarządzania testami.
- Raportowanie i gotowość do wydania. Jasna rekomendacja przed każdym wydaniem — wydajemy, wydajemy ze znanym ryzykiem albo nie wydajemy — poparta danymi.
Coraz częściej w zakresie pojawia się też AI. Według World Quality Report 2025-26 (Capgemini, Sogeti i OpenText) 89% organizacji pilotuje lub wdraża procesy inżynierii jakości wspierane generatywną AI, ale tylko 37% ma je na produkcji, a 15% wdrożyło je w skali całej firmy. Respondenci wskazywali średni wzrost produktywności o 19%, przy czym co trzecia organizacja nie zauważyła istotnych korzyści. Zapytaj dostawców, gdzie dokładnie używają AI — przy generowaniu przypadków testowych, danych testowych, analizie defektów — i jak weryfikują jej wyniki.
Co musi zostać po Twojej stronie nawet w modelu zarządzanym?
To najważniejsza sekcja dla każdego, kto podpisuje umowę managed QA. Dostawca może przejąć odpowiedzialność za to, jak dobrze testuje. Nie może przejąć odpowiedzialności za to, jaką jakość Twoja firma uznaje za akceptowalną. Pięć rzeczy musi zostać u Ciebie:
- Definicja jakości. Które procesy biznesowe są krytyczne, jaki poziom ważności defektu blokuje wydanie, jaka liczba incydentów produkcyjnych jest akceptowalna. Dostawca może pomóc ją sformułować, ale decyzja należy do Ciebie. Szerzej piszemy o tym w artykule outsourcing QA bez oddania definicji jakości.
- Decyzje o wydaniu. Dostawca rekomenduje, a Twój product owner lub lider techniczny decyduje, czy wydać ze znanym ryzykiem.
- Wiedza o produkcie. Wymagania, kryteria akceptacji i reguły domenowe pochodzą od Ciebie. Dostawca testujący według niejasnych wymagań da niejasne wyniki.
- Nadzór. Ktoś po Twojej stronie — zwykle menedżer QA lub inżynierii na część etatu — co miesiąc przegląda KPI, raz na kwartał prowadzi przegląd usługi i jest właścicielem relacji.
- Dostęp i współpraca. Środowiska, konta testowe, dostępność deweloperów do wyjaśniania defektów. Wiele naruszeń SLA wynika z przyczyn po stronie klienta i dobra umowa mówi o tym wprost.
Firmy, które razem z testowaniem oddają definicję jakości, zwykle kończą z umową mierzącą aktywność — wykonane przypadki testowe, przepracowane godziny — zamiast wyników. Dostawca spełnia wszystkie SLA, a klienci i tak znajdują błędy.
Jak rozlicza się zarządzane usługi QA?
Dostawcy stosują cztery modele rozliczeń, często w połączeniu. Każdy inaczej dzieli ryzyko między Ciebie a dostawcę.
Stała opłata miesięczna. Najczęstszy model. Dostawca zobowiązuje się do zakresu — aplikacje, platformy, częstotliwość wydań, rodzaje testów — i zestawu KPI w zamian za miesięczną opłatę. Obsada zespołu to jego zmartwienie. Daje przewidywalność budżetu; ryzykiem jest zbyt luźno zdefiniowany zakres, przez który każda nowa platforma czy integracja staje się zleceniem zmiany.
Cena za wydanie lub cykl testów. Przydatna, gdy częstotliwość wydań się zmienia. Uzgadnia się cenę standardowego wydania, z dopłatą za duże wydania i rabatem za cykle z samymi poprawkami. Wiąże koszt z aktywnością, ale może zachęcać do dzielenia pracy na więcej mniejszych wydań.
Rozliczenie za wynik (część opłaty uzależniona od KPI). Część opłaty — w umowach, które widzieliśmy, zwykle 10–20% — zależy od spełnienia KPI, takich jak wyciek defektów czy czas regresji. To najsilniejsza forma rozliczalności, ale działa tylko wtedy, gdy KPI są mierzone obiektywnie, znany jest punkt wyjścia, a wkład klienta — dostępność środowisk, jakość wymagań — jest uwzględniony.
Model hybrydowy: zasoby plus usługa. Zespół podstawowy jest wyceniany jako usługa zarządzana, a szczyty — testy wydajności przed Black Friday, duża migracja — dokupowane z puli zasobów po stawkach godzinowych. Z naszego doświadczenia to często najbardziej praktyczny model dla produktów średniej wielkości.
Niezależnie od modelu sprawdź trzy szczegóły: co dokładnie jest w zakresie (i co jest zmianą), kto płaci za narzędzia i chmurę urządzeń oraz jak zmienia się opłata, gdy produkt rośnie — nowe platformy, nowe rynki, częstsze wydania.
Ile kosztuje zarządzana usługa QA na przykładzie?
Policzmy scenariusz ze wstępu: sklep internetowy z aplikacją webową i dwiema aplikacjami mobilnymi, wydania co dwa tygodnie. Zespół potrzebny, żeby testować go dobrze:
| Rola | Etat | Stawka (zł/h) | Koszt miesięczny |
|---|---|---|---|
| QA lead | 0,5 | 240 | 19 200 zł |
| Senior SDET (automatyzacja) | 1 | 215 | 34 400 zł |
| Inżynier automatyzacji (mid) | 1 | 165 | 26 400 zł |
| Tester eksploracyjny / manualny (mid) | 2 | 120 | 38 400 zł |
| Razem | 4,5 | 118 400 zł |
Stawki to środki przedziałów z naszego benchmarku stawek body leasingu na 2026 rok (tester manualny mid 100–140 zł/h, inżynier automatyzacji 130–200 zł/h, senior SDET 180–250 zł/h); stawka QA leada to nasze założenie powyżej przedziału seniora SDET. Przyjmujemy 160 fakturowanych godzin na etat miesięcznie. Szerszy obraz stawek w regionie znajdziesz w zestawieniu stawek outsourcingu QA w Polsce i CEE.
Body leasing: 118 400 zł miesięcznie za zasoby. Klient zarządza zespołem.
Usługa zarządzana, stała opłata miesięczna: dostawca dolicza narzędzia i chmurę urządzeń (zakładamy 6000 zł miesięcznie) oraz premię za przejęcie odpowiedzialności, SLA i ryzyka zastępstw (zakładamy 12%). Opłata miesięczna wynosi 139 328 zł — o 17,7% więcej niż body leasing.
To porównanie jest jednak mylące, bo body leasing ma koszty, których nie widać na fakturze. Klient płaci za te same narzędzia (6000 zł) i poświęca czas zarządczy: menedżer QA lub inżynierii przez ok. 30% czasu układa grafik, przegląda wyniki i raportuje — przy wewnętrznym koszcie 180 zł/h to 8640 zł miesięcznie. Realne porównanie to 133 040 zł wobec 139 328 zł: premia za przeniesienie odpowiedzialności wynosi 6288 zł miesięcznie, czyli mniej niż 5%.
Cena za wydanie: przy dwóch wydaniach w miesiącu — 69 664 zł za standardowe wydanie.
Wariant rozliczenia za wynik: 85% opłaty stałe (118 429 zł) i 15% zależne od wyników (do 20 899 zł), wypłacane według trzech KPI. Jeśli dostawca spełni w danym miesiącu dwa z trzech, opłata wynosi 132 362 zł.
W skali roku usługa zarządzana w tym przykładzie kosztuje ok. 1,67 mln zł. To, czy to dobra wartość, zależy mniej od premii, a bardziej od tego, co za nią dostajesz: czy liderzy techniczni odzyskają poniedziałki i czwartki i czy klienci przestaną znajdować błędy jako pierwsi.
Jakie KPI i SLA powinna zawierać umowa managed QA?
KPI to serce umowy zarządzanej. Dobre KPI mierzą wyniki i trudno je obejść. Złe mierzą aktywność i łatwo je spełnić bez poprawy czegokolwiek.
KPI wynikowe:
- Wyciek defektów (defect leakage) — udział defektów znalezionych na produkcji we wszystkich defektach znalezionych w danym okresie. Jeśli testy znajdą przed wydaniem 188 defektów, a klienci zgłoszą po nim 12, wyciek wynosi 6%.
- Skuteczność usuwania defektów (DRE) — odwrotność: udział defektów usuniętych przed wydaniem (w tym samym przykładzie 94%). Capers Jones, który spopularyzował tę metrykę, szacował średnią dla oprogramowania w USA na ok. 85% i wskazywał, że najlepsze projekty przekraczają 99% — ale tylko łącząc testy z inspekcjami i analizą statyczną. Realistyczny cel w umowie zależy od Twojego punktu wyjścia; ustal go po pomiarze, nie przed nim.
- Wycieki ważone ważnością — liczba defektów krytycznych i poważnych, które trafiły na produkcję. Jeden krytyczny wyciek znaczy więcej niż dziesięć kosmetycznych.
KPI procesowe:
- Czas cyklu regresji — ile trwa pełna regresja, od builda do raportu. W naszym scenariuszu celem jest skrócenie jej z trzech dni do mniej niż jednego.
- Stabilność testów automatycznych — udział niepowodzeń testów automatycznych spowodowanych przez same testy (testy niestabilne, flaky). Deweloperzy ignorują niestabilne zestawy, przez co stają się bezwartościowe.
- Pokrycie oparte na ryzyku — udział krytycznych procesów biznesowych pokrytych testami automatycznymi, a nie surowa liczba przypadków testowych czy pokrycie kodu.
- Terminowość raportu gotowości — rekomendacja „wydajemy / nie wydajemy” dostarczona przed uzgodnionym terminem.
SLA określają czasy reakcji: jak szybko krytyczny defekt przechodzi triaż, jak szybko zespół się skaluje na nieplanowane wydanie, jak szybko odchodzący członek zespołu zostaje zastąpiony.
Jak ustalać cele? Rekomendujemy trzy zasady. Po pierwsze, mierz przez dwa, trzy cykle wydań, zanim jakikolwiek KPI stanie się wiążący — naturalnym momentem jest okres równoległy opisany niżej. Po drugie, uzgadniaj trendy, a nie tylko progi: „zmniejszenie wycieku defektów o jedną trzecią w dwa kwartały” jest uczciwsze i bardziej użyteczne niż bezwzględna liczba wzięta z benchmarku. Po trzecie, powiąż każdy KPI wynikowy z zależnością po stronie klienta: jeśli środowiska testowe są niedostępne dłużej niż uzgodniona liczba godzin w cyklu, SLA na czas regresji w tym cyklu jest zawieszone. Bez takiej klauzuli dostawca ponosi ryzyka, na które nie ma wpływu, i wliczy je w cenę.
W umowach z częścią opłaty uzależnioną od wyników trzymaj mechanikę prostą. Trzy KPI o równej wadze, mierzone co miesiąc, z wynikiem widocznym we wspólnym panelu, działają lepiej niż tuzin ważonych wskaźników, których nikt nie potrafi przeliczyć. W przykładzie wyżej każdy spełniony KPI uwalnia jedną trzecią zmiennej części opłaty. Część klientów dodaje premię powyżej 100% za przekroczenie celów — z naszego doświadczenia ma to sens dopiero po pierwszym roku, gdy punkt wyjścia i realne możliwości dostawcy są dobrze znane.
Dwóch KPI unikaj jako głównych miar: liczby wykonanych przypadków testowych i liczby znalezionych defektów. Oba nagradzają ilość. Dostawca płacony za znalezione defekty nie ma interesu, żeby pomagać Ci im zapobiegać. Szerszy przegląd miar znajdziesz w haśle słownika o metrykach testowych.
Jak przebiega przejęcie usługi przez dostawcę managed QA?
Pierwsze tygodnie usługi zarządzanej decydują o tym, czy reszta zadziała. Uporządkowane przejęcie ma zwykle cztery fazy:
- Rozpoznanie (2–3 tygodnie). Dostawca poznaje produkt, istniejące aktywa testowe, historię defektów i proces wydań, rozmawia z deweloperami i product ownerami oraz mierzy punkt wyjścia: obecny wyciek defektów, czas regresji, stabilność automatyzacji.
- Przekazanie wiedzy i praca w cieniu (2–4 tygodnie). Nowy zespół pracuje obok dotychczasowych testerów lub deweloperów, przejmuje wykonanie testów pod nadzorem i dokumentuje to, co było niespisane.
- Okres równoległy (1–2 cykle wydań). Dostawca prowadzi testy, a zespół klienta nadal weryfikuje wyniki. KPI są mierzone, ale jeszcze nie wiążą.
- Stan docelowy. KPI stają się umowne, zaczynają się przeglądy usługi i realizacja planu usprawnień — zwykle automatyzacji regresji.
Przejęcie kosztuje. Jeśli produktywność w sześciotygodniowym okresie przejęcia wynosi średnio 50% przy pełnej opłacie, „utracona” wartość w naszym przykładzie to ok. 104 500 zł. Część dostawców daje rabat na okres przejęcia, inni wliczają go w cenę. W obu przypadkach powinien być widoczny w ofercie, a nie odkryty później.
Najczęstszy błąd przejęcia to uruchomienie KPI pierwszego dnia. Bez punktu wyjścia cele są zgadywaniem — a dostawca zmuszony do przyjęcia zgadywanych celów doliczy ryzyko do ceny.
Jak zaplanować wyjście z usługi, zanim ją podpiszesz?
Każda usługa zarządzana się kończy — bo zmienia się produkt, firma buduje własne kompetencje albo współpraca się nie układa. Czas na zaplanowanie wyjścia jest przed podpisaniem umowy, kiedy masz jeszcze siłę negocjacyjną.
Dobry plan wyjścia w umowie obejmuje:
- Własność aktywów testowych. Kod testów automatycznych, przypadki testowe, skrypty danych testowych, dokumentacja i konfiguracja środowisk powstałe w trakcie usługi powinny należeć do Ciebie i być przechowywane w Twoich repozytoriach, a nie u dostawcy.
- Niezależność od narzędzi. Jeśli automatyzacja zależy od autorskiego frameworka dostawcy lub jego licencji, wyjście oznacza przepisanie wszystkiego. Wybieraj otwarte frameworki i narzędzia licencjonowane na Ciebie.
- Wsparcie przy wyjściu. Określony okres — zwykle od jednego do trzech miesięcy — w którym dostawca wspiera przekazanie wiedzy Twojemu zespołowi lub nowemu dostawcy, po uzgodnionej cenie.
- Standardy dokumentacji. Strategia testów, rejestr ryzyk i instrukcje utrzymywane na bieżąco przez cały czas trwania usługi, a nie tworzone w pośpiechu na końcu.
- Okresy wypowiedzenia i prawo do rozwiązania umowy dopasowane do ryzyka: wystarczająco długie na uporządkowane przekazanie, ale nie tak długie, żeby Cię uwięzić.
Dwie kwestie formalne warto dopilnować w polskich realiach. Po pierwsze, prawa autorskie do kodu testów. Zestawy testów automatycznych to program komputerowy, więc sama deklaracja „aktywa należą do klienta” nie wystarczy — umowa powinna przenosić autorskie prawa majątkowe z wyliczeniem pól eksploatacji albo co najmniej udzielać szerokiej, niewypowiadalnej licencji. Bez tego po zakończeniu współpracy możesz mieć kod w repozytorium, ale nie mieć prawa go swobodnie modyfikować i przekazać nowemu dostawcy.
Po drugie, dane osobowe w testach. Jeśli dostawca ma dostęp do danych produkcyjnych lub ich kopii, potrzebna jest umowa powierzenia przetwarzania danych zgodna z art. 28 RODO, a plan wyjścia powinien określać, jak i kiedy dostawca usuwa lub zwraca dane po zakończeniu usługi. Najbezpieczniejszym rozwiązaniem pozostaje maskowanie lub generowanie danych testowych, tak aby dostawca w ogóle nie pracował na danych prawdziwych klientów. Ten artykuł nie jest poradą prawną — przed podpisaniem umowy warto przejrzeć te zapisy z prawnikiem.
Dostawca, który nie chce uzgodnić własności aktywów i wsparcia przy wyjściu, mówi Ci coś o tym, jak planuje zatrzymać Twój biznes.
Jak wybrać dostawcę managed QA?
Porównywanie cen ofert managed QA nie ma sensu, dopóki zakres, KPI i własność aktywów nie są porównywalne. Poniższa karta oceny pomaga oceniać oferty w spójny sposób. Każde kryterium oceń od 0 (brak lub niejasne) do 2 (mocne, poparte dowodami):
| Kryterium | Jak wygląda ocena „2” | Waga |
|---|---|---|
| Zrozumienie produktu i ryzyk | Oferta nazywa Twoje krytyczne procesy i ryzyka, a nie ogólne rodzaje testów | 3 |
| Strategia testów | Strategia oparta na ryzyku z jasnym podziałem na testy eksploracyjne i automatyczne | 3 |
| KPI i SLA | KPI wynikowe, punkt wyjścia przed celami, obowiązki klienta opisane | 3 |
| Plan przejęcia | Plan fazowy z okresem równoległym i widocznym kosztem przejęcia | 2 |
| Własność aktywów i wyjście | Aktywa w Twoich repozytoriach, otwarte narzędzia, określone wsparcie przy wyjściu | 3 |
| Podejście do automatyzacji | Utrzymywalny framework, cele stabilności, integracja z CI/CD | 2 |
| Stabilność i seniorność zespołu | Wskazane kluczowe osoby, SLA na zastępstwo, dowody niskiej rotacji | 2 |
| Raportowanie i nadzór | Przykładowy raport gotowości do wydania, przeglądy miesięczne i kwartalne | 2 |
| AI i narzędzia | Konkretne, weryfikowane zastosowania AI; przejrzyste licencjonowanie narzędzi | 1 |
| Referencje z podobnych produktów | Referencje z porównywalnym rytmem wydań i domeną, z możliwością kontaktu | 2 |
Pomnóż oceny przez wagi; maksimum to 46 punktów. Z naszego doświadczenia oferta poniżej ok. 30 punktów zwykle ukrywa luki, które później wracają jako zlecenia zmian. Poproś każdego dostawcę z krótkiej listy, żeby przeprowadził Cię przez prawdziwy raport gotowości do wydania i prawdziwą sesję triażu defektów od innego klienta (zanonimizowane). To, jak dostawca mówi o nieudanym wydaniu, powie Ci więcej niż prezentacja sprzedażowa.
Jakie są czerwone flagi w ofertach managed QA?
W ofertach, które analizowaliśmy dla klientów i razem z nimi, powtarzają się te same sygnały ostrzegawcze:
- KPI oparte na aktywności. „Wykonamy 1500 przypadków testowych na wydanie” to obietnica wysiłku, a nie jakości.
- Cele bez punktu wyjścia. Dostawca, który obiecuje „wyciek defektów poniżej 2%”, zanim zobaczy Twoją historię defektów, albo zgaduje, albo planuje zmienić definicję defektu.
- Brak obowiązków klienta. Jeśli umowa nie mówi, co musisz zapewnić — środowiska, wymagania, dostępność deweloperów — każde naruszenie SLA będzie sporne.
- Autorskie frameworki automatyzacji z licencjami na dostawcę i bez jasnych warunków wyjścia.
- Obietnice automatyzacji bez kosztów utrzymania. Zestawy automatyczne wymagają stałej pielęgnacji; oferta pokazująca tylko koszt budowy z definicji zaniża całość.
- Zespół przedstawiony wyłącznie jako role. Zarządzany nie znaczy anonimowy. Kluczowe osoby — co najmniej QA lead i senior inżynier automatyzacji — powinny być wskazane z imienia, a ich zastępstwo uregulowane.
- „Testujemy wszystko”. Testowanie oparte na ryzyku oznacza świadome niepogłębianie testów niektórych obszarów. Dostawca, który nie pyta, co jest najważniejsze, nie zrozumiał zadania.
- Brak kosztu przejęcia. Albo jest ukryty w opłacie, albo dostawca planuje uczyć się Twojego produktu kosztem Twoich klientów.
Każdą z tych kwestii da się naprawić w negocjacjach — ale tylko wtedy, gdy zauważysz ją przed podpisaniem.
Jak przygotować się do zakupu zarządzanych usług QA?
Najlepsze umowy managed QA zaczynają się od pracy domowej po stronie klienta. Zanim wyślesz zapytanie ofertowe:
- Zmierz punkt wyjścia. Wyciek defektów z ostatnich trzech do sześciu miesięcy, czas regresji, liczba poprawek na wydanie, pokrycie automatyzacją krytycznych procesów. Nawet przybliżone liczby są lepsze niż żadne. Pomoże w tym hasło o pokryciu testowym.
- Spisz definicję jakości. Krytyczne procesy, definicje ważności defektów, kryteria wydania. Na początek wystarczą dwie strony.
- Zinwentaryzuj aktywa. Istniejące przypadki testowe, kod automatyzacji, dane testowe, środowiska — i kto jest dziś ich właścicielem.
- Zdecyduj o nadzorze. Kto po Twojej stronie będzie właścicielem relacji i ile czasu będzie jej poświęcał.
- Świadomie wybierz model rozliczeń. Stała opłata dla przewidywalności, cena za wydanie dla zmiennego rytmu, część opłaty zależna od wyników dla silnej rozliczalności — albo model hybrydowy.
Jeśli nie masz pewności, czy do Twojej sytuacji pasuje managed QA, czy body leasing, porównanie w jednym widoku znajdziesz na stronie staff augmentation vs managed services.
Najważniejsze wnioski:
- Managed QA przenosi odpowiedzialność za wynik testowania, a nie za Twoją definicję jakości. Tę drugą zatrzymaj u siebie.
- Widoczna premia jest myląca. W naszym przykładzie wynosi 17,7% na fakturze, ale mniej niż 5% po doliczeniu narzędzi i czasu zarządczego.
- KPI muszą mierzyć wyniki. Wyciek defektów, DRE, czas cyklu regresji i stabilność testów — nie liczbę wykonanych przypadków testowych.
- Najpierw punkt wyjścia, potem cele. Wiążące KPI od pierwszego dnia bez pomiaru tworzą spory i narzuty na ryzyko.
- Zaplanuj wyjście przed podpisaniem. Własność aktywów, otwarte narzędzia i wsparcie przy wyjściu chronią Cię niezależnie od tego, co się wydarzy.
W ARDURA Consulting od ponad 10 lat realizujemy testowanie oprogramowania dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA — zarówno jako specjaliści QA w zespołach klientów, jak i w modelu usług zarządzanych z uzgodnionymi KPI. Każdą współpracę zaczynamy od pomiaru punktu wyjścia i ustalenia, co oznacza jakość dla danego produktu, bo bez tego żadne SLA nie jest warte podpisania.
Jeśli rozważasz managed QA dla swojego produktu albo chcesz sprawdzić, czy obecna umowa outsourcingu testów mierzy właściwe rzeczy, zobacz nasze usługi testowania oprogramowania lub porozmawiaj z naszym zespołem.