Piątek po południu. Jako Tech Lead dostajesz od działu zakupów trzy oferty na outsourcing testów do produktu, który rośnie szybciej niż Twój zespół. Pierwsza: 45 PLN za wykonany przypadek testowy, przy szacowanych 2 000 przypadkach miesięcznie. Druga: tester manualny i dwóch inżynierów automatyzacji w modelu time and material, stawki dzienne podane w tabeli. Trzecia: „zarządzany zespół QA”, stały abonament miesięczny, bez rozbicia na osoby. Zakupy pytają o jedno: która jest najtańsza?
Na to pytanie nie da się odpowiedzieć, porównując liczby z ofert. Pierwsza oferta daje 90 000 PLN miesięcznie, ale tylko wtedy, gdy przypadków rzeczywiście będzie 2 000, a nikt nie wie, ile ich będzie po podzieleniu scenariuszy na drobniejsze. Druga zależy od tego, ile dni realnie przepracują ludzie i czy ktoś po Twojej stronie będzie nimi zarządzał. Trzecia jest przewidywalna, ale nie wiadomo, co dokładnie kupujesz.
W tym artykule rozkładamy koszt outsourcingu testów na części. Nie powtarzamy tabeli stawek, bo osobny tekst Stawki outsourcingu QA w Polsce i CEE w 2026 roku robi to szczegółowo. Zajmujemy się tym, co dzieje się ze stawką po podpisaniu umowy: jak działają trzy główne modele rozliczeń, ile realnie kosztuje każdy z nich, gdzie leżą pułapki, za które płacisz bez wiedzy o tym, i co zapisać w umowie.
Z czego naprawdę składa się koszt outsourcingu testów?
Koszt outsourcingu testów ma pięć składników, a stawka jest tylko jednym z nich. Kto porównuje oferty po stawce, porównuje jedną piątą rachunku.
Pierwszy składnik to praca wykonawcza: stawka dzienna lub godzinowa pomnożona przez liczbę osób i dni. To jedyna pozycja, którą widać w ofercie wprost. W cenniku ARDURA testerzy manualni zaczynają od 560 PLN netto za dzień, a inżynier QA (automatyzacja testów, SDET) kosztuje 720–1 040 PLN na poziomie junior, 1 440–2 000 PLN na poziomie senior i 2 000–2 560 PLN na poziomie architekt/lead, za 8-godzinny dzień (cennik). Do kwot netto dolicz 23% VAT, jeśli Twoja firma nie odlicza go w całości.
Drugi składnik to wdrożenie i wiedza o produkcie. Nowa osoba potrzebuje czasu, żeby poznać domenę, środowiska, dane testowe i sposób pracy zespołu. W tym czasie płacisz pełną stawkę za niepełną wydajność, a Twoi ludzie poświęcają czas na wyjaśnienia. Ten koszt jest nieunikniony; da się go tylko ograniczyć dobrą dokumentacją i stabilnym składem.
Trzeci składnik to zarządzanie. Ktoś musi ustalać priorytety testów, przeglądać raporty błędów, decydować, co jest wystarczająco dobre do wydania. W modelu time and material robi to zwykle ktoś z Twojej strony; w modelu zespołu zarządzanego część tej pracy przejmuje dostawca i wlicza ją w cenę. Tak czy inaczej, ten koszt istnieje.
Czwarty składnik to narzędzia i środowiska: licencje na narzędzia do zarządzania testami, farmy urządzeń, infrastruktura do testów automatycznych w CI, środowiska testowe. Część dostawców wlicza je w stawkę, część fakturuje osobno, a część zakłada, że zapewnisz je Ty.
Piąty składnik to utrzymanie tego, co powstało. Testy automatyczne trzeba aktualizować przy każdej zmianie interfejsu i logiki. Przypadki testowe się starzeją. Jeśli w budżecie jest tylko budowa automatyzacji, a nie jej utrzymanie, za pół roku zapłacisz drugi raz. O kosztach samej automatyzacji piszemy szerzej w artykule Ile kosztuje automatyzacja testów w 2026 roku?.
Dopiero suma tych pięciu pozycji w okresie, na który planujesz współpracę, pozwala porównać oferty. Większość różnic między ofertami nie leży w stawce, tylko w tym, który z pozostałych czterech składników dostawca wziął na siebie, a który zostawił Tobie.
Jak działa model time and material w testach i kiedy się opłaca?
W modelu time and material (T&M) płacisz za czas pracy konkretnych specjalistów według ustalonej stawki, zwykle dziennej, fakturowanej miesięcznie za przepracowane dni. Specjaliści pracują w Twoim zespole, według Twoich priorytetów i w Twoich narzędziach. W Polsce to najczęściej forma wynajmu testera oprogramowania, czyli body leasingu ról QA.
Zaletą T&M jest elastyczność. Zakres testów zmienia się z każdym sprintem, a Ty nie musisz renegocjować umowy przy każdej zmianie. Możesz dodać osobę przed dużym wydaniem i zmniejszyć zespół po nim. W ARDURA staff augmentation ma minimalny okres jednego miesiąca, nowych specjalistów można dodać z dwutygodniowym wyprzedzeniem, a zmniejszyć zespół z 30-dniowym wypowiedzeniem, bez opłat rekrutacyjnych i bez kar za skalowanie, zgodnie z warunkami w cenniku.
Wadą T&M jest to, że całe ryzyko efektywności zostaje po Twojej stronie. Dostawca odpowiada za dostarczenie kompetentnej osoby, a nie za to, ile błędów wykryje ani czy wydanie będzie stabilne. Jeśli nikt po Twojej stronie nie ustala priorytetów, tester w T&M będzie pracowicie wykonywał to, co mu się wskaże, a niekoniecznie to, co najważniejsze.
T&M opłaca się, gdy masz w zespole osobę, która potrafi zarządzać jakością: Tech Leada albo QA Leada, który ustala strategię testów, a zewnętrzni specjaliści ją realizują. Opłaca się też przy zmiennym zakresie, przy produktach we wczesnej fazie i wtedy, gdy chcesz budować kompetencje QA wewnątrz organizacji, a zewnętrzne osoby mają je uzupełniać. Przy T&M sprawdź trzy rzeczy: czy płacisz za przepracowane dni, a nie za dni kalendarzowe, czy urlopy i choroby specjalisty są poza fakturą oraz jakie są warunki wymiany osoby, która się nie sprawdza.
W tym ostatnim punkcie warunki bywają bardzo różne, więc warto je porównać czarno na białym. W ARDURA każda współpraca zaczyna się od dwutygodniowej gwarancji: jeśli specjalista nie spełni oczekiwań w ciągu pierwszych dwóch tygodni, jest wymieniany bezpłatnie, a jeśli odejdzie w trakcie współpracy, zastępstwo jest zapewniane w ciągu 5 dni roboczych.
Jak działa model dedykowanego lub zarządzanego zespołu testowego?
W modelu zespołu dostawca dostarcza nie pojedyncze osoby, tylko zespół z określonym składem i odpowiedzialnością, rozliczany zwykle stałą stawką miesięczną. Dostawca zarządza rekrutacją, zastępstwami i organizacją pracy, a często także procesem testowym. W cenniku ARDURA dedykowany zespół rozliczany jest miesięczną stawką zespołową z rabatem, z zalecanym minimum trzech miesięcy i trzech specjalistów.
Zaletą tego modelu jest przewidywalność i ciągłość. Znasz koszt miesięczny, nie zarządzasz każdą osobą osobno, a dostawca odpowiada za to, żeby zespół działał mimo urlopów i rotacji. Przy długim, stabilnym produkcie to często najtańszy model w ujęciu rocznym, bo wiedza o produkcie zostaje w zespole, a koszt wdrożenia ponosisz raz.
Wadą jest ryzyko, że kupisz wykonanie, a myśleć będziesz, że kupiłeś zapewnienie jakości. Zespół zarządzany przez dostawcę może bardzo sprawnie realizować przypadki testowe i jednocześnie nie mieć ani prawa, ani informacji, żeby powiedzieć, czy wydanie jest gotowe. O tym zjawisku piszemy szczegółowo w artykule Outsourcing QA bez oddania definicji jakości: jeśli definicja jakości zostaje po Twojej stronie, a wykonanie po stronie dostawcy, płacisz za klikanie zamiast za odpowiedzialność.
Model zespołu opłaca się, gdy produkt jest rozwijany długoterminowo, potrzebujesz kilku ról naraz (testy manualne, automatyzacja, wydajność) i nie masz w zespole osoby, która chce lub może zarządzać testerami na co dzień. Przed podpisaniem zapytaj o skład z nazwami ról i poziomami, o to, jak zmienia się cena przy zmianie składu, o mierniki efektu (o nich niżej) i o to, kto po stronie dostawcy odpowiada za jakość, a nie tylko za obsadę.
Kiedy stały zakres i stała cena mają sens w testowaniu?
Stała cena za określony zakres to model, w którym dostawca bierze odpowiedzialność za rezultat w ustalonym budżecie. W testowaniu działa dobrze dla prac jednorazowych, które mają wyraźny początek, koniec i produkt: budowa frameworka automatyzacji, audyt procesu QA, wdrożenie strategii testów i narzędzia do zarządzania testami, testy wydajnościowe przed premierą, test regresji przed migracją.
Przykładem jest pakiet strategii testów i wdrożenia zarządzania testami w ofercie ARDURA: strategia testów oparta na ryzyku i działające wdrożenie TestRail, Xray lub Zephyr, z migracją istniejących przypadków testowych i integracją z Jirą oraz CI, w dwa tygodnie, od 16 000 PLN. Zakres jest zamknięty, więc cenę da się ustalić z góry.
Stała cena nie sprawdza się jako model ciągłego testowania rozwijanego produktu. Zakres testów zmienia się z każdym sprintem, więc dostawca musi albo wycenić ryzyko z dużym zapasem, albo bronić się przed każdą zmianą aneksem. W obu przypadkach płacisz więcej niż w T&M. Typowy objaw: oferta „stała cena za testowanie wydania” z długą listą wyłączeń, a potem seria zleceń zmian za każdy nowy ekran.
W polskim prawie warto pamiętać o różnicy między umową o dzieło (art. 627 Kodeksu cywilnego), w której wykonawca odpowiada za rezultat, a umową o świadczenie usług, do której stosuje się przepisy o zleceniu (art. 750 KC), gdzie odpowiada za należytą staranność. Ciągłe testowanie w T&M to z natury usługa; zamknięty pakiet z określonym produktem bliżej jest dzieła. Nazwa umowy ma mniejsze znaczenie niż jej treść, ale to, za co dostawca odpowiada, powinno wynikać z zapisów wprost, a nie z domysłów.
Ile realnie kosztuje każdy model w przykładowym scenariuszu?
Policzmy to na jednym przykładzie, żeby pokazać, jak bardzo model zmienia rachunek. Przyjmijmy produkt webowy z aplikacją mobilną, wydania co dwa tygodnie, potrzebę jednego testera manualnego i dwóch inżynierów automatyzacji przez 12 miesięcy. Liczby poniżej to nasz ilustracyjny szacunek oparty na stawkach z cennika ARDURA, a nie wycena; przyjmujemy około 20 dni fakturowanych miesięcznie.
T&M. Dwóch seniorów automatyzacji po około 1 700 PLN dziennie i tester manualny na poziomie mid po około 900 PLN dziennie to około 86 000 PLN netto miesięcznie, czyli około 1 030 000 PLN rocznie. Do tego czas Twojego QA Leada na zarządzanie (jeśli go masz) i narzędzia po Twojej stronie. Jeśli wydania się zatrzymają na miesiąc, możesz zmniejszyć zespół z 30-dniowym wypowiedzeniem.
Dedykowany zespół. Ten sam skład w modelu zespołu ma miesięczną stawkę zespołową z rabatem i część zarządzania po stronie dostawcy. Rabat i zakres zarządzania ustala się indywidualnie, więc nie podajemy kwoty; porównując, odejmij od T&M rabat i dodaj koszt zarządzania, który przechodzi na dostawcę. Jeśli Twój QA Lead i tak będzie zarządzał zespołem, płacisz za zarządzanie dwa razy.
Rozliczenie za przypadek testowy. Przy 45 PLN za przypadek i 2 000 przypadkach miesięcznie wychodzi 90 000 PLN miesięcznie, porównywalnie z T&M. Tyle że liczba przypadków nie jest stała. Jeśli dostawca podzieli każdy scenariusz na trzy drobniejsze przypadki, rachunek rośnie trzykrotnie bez żadnej zmiany w pokryciu ryzyka. Jeśli w miesiącu z dużym wydaniem potrzebujesz testów eksploracyjnych, których nie da się policzyć jako przypadki, nie ma ich w modelu wcale.
Stały zakres. Dla ciągłego testowania tego produktu oferta stałej ceny musiałaby wycenić niepewność zakresu na 12 miesięcy. W praktyce oznacza to bufor ryzyka i procedurę zmian. Stały zakres ma za to sens dla jednorazowych elementów: budowa frameworka automatyzacji na starcie, wdrożenie strategii testów, testy wydajnościowe przed premierą.
Wniosek z przykładu: przy podobnej kwocie miesięcznej modele różnią się tym, kto ponosi ryzyko zmiany zakresu i czy płacisz za efekt, czy za aktywność. Najtańszy na papierze bywa model, który przerzuca ryzyko na Ciebie w sposób niewidoczny w ofercie.
Czym jest płacenie za klikanie i jak je rozpoznać?
Płacenie za klikanie to sytuacja, w której rozliczasz dostawcę za aktywność testową (wykonane przypadki, godziny ręcznego przeklikiwania, liczbę zgłoszonych błędów), a nie za informację o jakości, której potrzebujesz do decyzji. Aktywność łatwo zmierzyć i zafakturować; informację trudniej, i właśnie dlatego tak wiele umów rozlicza to pierwsze.
Najczęstsze formy płacenia za klikanie wyglądają tak.
Rozliczenie za wykonany przypadek testowy. Nagradza liczbę przypadków, a nie ich wartość. Dostawca ma interes w dzieleniu scenariuszy, w powtarzaniu tych samych testów regresji ręcznie zamiast automatyzowania ich i w unikaniu testów eksploracyjnych. Wzrost liczby przypadków w raporcie nie znaczy, że testy pokrywają więcej ryzyka.
Rozliczenie za zgłoszony błąd. Wygląda na rozliczenie za efekt, ale nagradza liczbę zgłoszeń. Dostawca ma interes w zgłaszaniu drobiazgów, duplikatów i błędów kosmetycznych, a mniej w długim śledzeniu jednego poważnego problemu, który trudno odtworzyć. Twój zespół spędza czas na triage zamiast na naprawach.
Ręczna regresja bez planu automatyzacji. Tester w T&M, który co dwa tygodnie przeklikuje te same 300 przypadków, to koszt rosnący liniowo z każdym wydaniem. Automatyzacja nie zawsze się opłaca, ale brak decyzji, co automatyzować, to zawsze płacenie za klikanie.
SLA na liczbę przypadków. Umowa, w której dostawca zobowiązuje się do wykonania X przypadków w cyklu, mierzy dokładnie to, czego nie chcesz kupić. Spełnione SLA nie mówi nic o tym, czy wydanie jest bezpieczne.
Jak to rozpoznać we własnej współpracy? Zadaj trzy pytania. Czy raport z testów mówi, czy wydanie jest gotowe, czy tylko ile przypadków wykonano? Czy liczba ręcznie wykonywanych testów regresji maleje z czasem, czy rośnie? Czy poważne błędy znajdują klienci na produkcji, mimo że raporty z testów są zielone? Jeśli odpowiedzi brzmią „tylko liczby”, „rośnie” i „tak”, płacisz za klikanie.
Jakie mierniki efektu wpisać zamiast liczby przypadków testowych?
Skoro liczba przypadków mierzy aktywność, potrzebujesz mierników, które opisują efekt. Żaden miernik nie jest idealny i każdy da się przy złej woli zmanipulować, dlatego używa się kilku naraz i patrzy na trendy, a nie pojedyncze wartości.
Błędy wykryte po wydaniu (escaped defects), ważone krytycznością. To najbardziej bezpośredni sygnał, czy testy łapią to, co trzeba. Wymaga uzgodnienia, co jest błędem, a co zmianą wymagań.
Pokrycie ryzyka, a nie pokrycie przypadkami: jaki odsetek obszarów o wysokim ryzyku biznesowym ma testy automatyczne lub zaplanowane testy manualne. Wymaga listy ryzyk, którą tworzysz Ty, a dostawca ją utrzymuje. To element strategii testowej, bez której żaden miernik nie ma punktu odniesienia.
Czas od zmiany do informacji zwrotnej: ile trwa od scalenia zmiany do wyniku testów regresji. Dobrze zbudowana automatyzacja skraca go z dni do godzin i bezpośrednio przyspiesza wydania.
Stabilność testów automatycznych: odsetek niestabilnych testów, które przechodzą i nie przechodzą bez zmiany w kodzie. Wysoki odsetek oznacza, że zespół przestaje ufać testom, a każda czerwona lampka jest ignorowana.
Udział testów regresji wykonywanych automatycznie i jego trend. Nie chodzi o 100%, tylko o to, żeby ręczna praca szła tam, gdzie ma wartość: w testy eksploracyjne, użyteczności i nowe funkcje.
Przykład, jak to wygląda w praktyce: zamiast zapisu „dostawca wykona 1 500 przypadków testowych w cyklu wydania” umowa mówi, że strony co kwartał przeglądają liczbę krytycznych błędów wykrytych na produkcji, odsetek obszarów wysokiego ryzyka objętych automatyzacją i czas trwania regresji, a dostawca przedstawia plan poprawy tych wartości na kolejny kwartał. Taki zapis niczego nie gwarantuje, ale przesuwa rozmowę z „ile zrobiliście” na „co się poprawiło”.
Mierniki wpisz do umowy jako przedmiot regularnego przeglądu (na przykład kwartalnego), a nie jako warunek wypłaty wynagrodzenia, przynajmniej na początku. Mierniki powiązane z płatnościami przyciągają manipulację; mierniki przeglądane wspólnie budują rozmowę o jakości. Po kilku kwartałach, gdy znasz już wartości bazowe, możesz rozważyć powiązanie części wynagrodzenia z trendem.
Jakie ukryte koszty najczęściej podnoszą rachunek?
Poza płaceniem za klikanie jest kilka pozycji, które rzadko pojawiają się w ofercie, a regularnie pojawiają się w budżecie.
Rotacja i ponowne wdrożenie. Każda zmiana osoby to kilka tygodni niepełnej wydajności i czas Twojego zespołu na wyjaśnienia. Zapytaj dostawcę o retencję specjalistów i o to, kto płaci za okres wdrożenia zastępcy. ARDURA podaje na stronie cennika 99% retencji specjalistów; niezależnie od dostawcy poproś o tę liczbę i o sposób jej liczenia.
Wiedza zamknięta u dostawcy. Przypadki testowe w narzędziu dostawcy, skrypty automatyzacji w jego repozytorium, dane testowe na jego serwerach. Przy zmianie dostawcy lub przejęciu testów do zespołu wewnętrznego zaczynasz od zera. Ten koszt nie pojawia się, dopóki nie chcesz odejść, i wtedy jest bardzo wysoki.
Utrzymanie automatyzacji. Framework zbudowany w trzy miesiące wymaga utrzymania przez kolejne lata. Jeśli oferta nie mówi nic o utrzymaniu, zapytaj, ile osobodni miesięcznie przewiduje na aktualizację testów przy zmianach w aplikacji.
Przestoje środowisk. Testerzy, którzy czekają na działające środowisko, kosztują tyle samo co testerzy, którzy testują. W T&M ten koszt jest wprost Twój; w modelu stałej ceny wróci jako bufor ryzyka.
Narzędzia i infrastruktura. Licencje na narzędzia do zarządzania testami, farmy urządzeń mobilnych, minuty w CI. Sprawdź, kto je zapewnia i kto za nie płaci.
Minimalne zobowiązania i długie wypowiedzenia. Oferta z niższą stawką bywa okupiona minimalnym okresem 12 miesięcy albo trzymiesięcznym wypowiedzeniem. Jeśli po kwartale okaże się, że skład jest za duży albo projekt zwalnia, płacisz za osoby, których nie potrzebujesz. Policz, ile kosztowałoby wyjście w najgorszym momencie, i dodaj tę kwotę do porównania. Krótszy okres wypowiedzenia przy nieco wyższej stawce jest często tańszy w całym okresie współpracy, bo pozwala dopasować zespół do rzeczywistego tempa prac zamiast do prognozy z dnia podpisania umowy.
Koszt koordynacji po Twojej stronie. Nawet najlepszy zewnętrzny zespół potrzebuje kogoś, kto zna produkt i podejmuje decyzje. Jeśli tej osoby nie masz, uwzględnij jej koszt albo wybierz model, w którym część tej roli bierze dostawca.
Przy porównywaniu ofert ułóż te pozycje w jednej tabeli dla każdej oferty w perspektywie 12 miesięcy. Różnica w stawce rzędu 10% rzadko przeważa nad różnicą w rotacji, własności artefaktów i utrzymaniu automatyzacji.
Jak porównać oferty, które wyceniają różne rzeczy?
Oferty na outsourcing testów rzadko są porównywalne wprost, bo każdy dostawca wycenia inny zestaw z pięciu składników kosztu. Żeby je porównać, sprowadź je do wspólnego mianownika. Poniższa tabela to narzędzie do tego: dla każdego modelu pokazuje, za co płacisz, kto ponosi ryzyko i na co uważać.
| Kryterium | Time and material | Dedykowany / zarządzany zespół | Stały zakres i cena | Za przypadek lub za błąd |
|---|---|---|---|---|
| Za co płacisz | Przepracowane dni konkretnych osób | Miesięczna stawka za zespół o ustalonym składzie | Określony produkt (framework, strategia, raport) | Liczba wykonanych przypadków lub zgłoszonych błędów |
| Kto ponosi ryzyko zmiany zakresu | Ty | Głównie Ty, w granicach składu | Dostawca, w granicach zapisanego zakresu | Pozornie dostawca, w praktyce Ty |
| Kto zarządza pracą | Ty | Dostawca, w ustalonym zakresie | Dostawca | Dostawca |
| Najlepszy dla | Zmiennego zakresu i zespołu z liderem QA | Długiego, stabilnego produktu bez lidera QA | Prac jednorazowych z jasnym rezultatem | Rzadko uzasadniony; ewentualnie krótkie testy akceptacyjne |
| Główna pułapka | Brak priorytetów po Twojej stronie | Kupno wykonania zamiast odpowiedzialności | Aneksy przy każdej zmianie | Płacenie za klikanie |
| Co sprawdzić w ofercie | Warunki wymiany, fakturowanie tylko przepracowanych dni | Skład z poziomami, mierniki efektu, kto odpowiada za jakość | Zakres, założenia, liczba rund poprawek | Definicję przypadku i błędu, limit miesięczny |
| Własność artefaktów | Zwykle Twoje narzędzia, Twoje repozytorium | Do zapisania w umowie | Do zapisania w umowie | Często u dostawcy |
Na koniec porównania policz całkowity koszt w 12 miesiącach dla każdej oferty: praca, wdrożenie, zarządzanie po Twojej stronie, narzędzia, utrzymanie automatyzacji i szacowany koszt wyjścia. Szerszą perspektywę decyzji, czy w ogóle oddawać testy na zewnątrz, znajdziesz w artykule QA wewnętrzne czy outsourcing testów? Jak podjąć decyzję.
Co zapisać w umowie, żeby nie przepłacić?
Umowa na outsourcing testów powinna chronić Cię przed trzema ryzykami: płaceniem za aktywność zamiast efektu, utratą wiedzy przy zmianie dostawcy i niekontrolowanym wzrostem kosztów. Oto zapisy, które warto mieć niezależnie od modelu.
Cel i podział odpowiedzialności za jakość. Kto ustala, co jest wystarczająco dobre do wydania, kto utrzymuje listę ryzyk, kto podejmuje decyzję o wydaniu. Jeśli dostawca ma tylko wykonywać, napisz to wprost; jeśli ma współodpowiadać za jakość, daj mu do tego informacje i prawo głosu.
Model rozliczeń i zasady fakturowania. Stawki, jednostka (dzień, godzina, zespół, produkt), fakturowanie tylko przepracowanego czasu, zasady rozliczania urlopów, choroby i przestojów środowisk, waluta i waloryzacja stawek.
Mierniki efektu i rytm przeglądów. Kilka mierników z poprzedniej sekcji, wartości bazowe do ustalenia w pierwszych tygodniach i kwartalny przegląd.
Wymiana i ciągłość. Okres gwarancyjny na wymianę osoby, czas zapewnienia zastępstwa, zasady przekazania wiedzy przy zmianie osoby, kto płaci za okres wdrożenia zastępcy.
Własność i przekazanie artefaktów. Przypadki testowe, skrypty automatyzacji, dane testowe i dokumentacja w Twoich narzędziach i repozytoriach. Przeniesienie autorskich praw majątkowych z wymienionymi polami eksploatacji, bo samo przekazanie plików praw nie przenosi. Obowiązek przekazania wiedzy przy zakończeniu współpracy, z określoną liczbą dni.
Wypowiedzenie i skalowanie. Okres wypowiedzenia, zasady zmniejszania i zwiększania zespołu, brak kar za skalowanie lub ich wysokość.
Bezpieczeństwo i dane osobowe. Umowa powierzenia przetwarzania danych osobowych, jeśli testerzy mają dostęp do danych osobowych, zasady dostępu do środowisk, NDA.
Jak zacząć współpracę, żeby pierwsze trzy miesiące nie przepadły?
Pierwsze trzy miesiące outsourcingu testów decydują o tym, czy kolejne dziewięć będzie opłacalne. W tym okresie płacisz pełną stawkę za rosnącą wydajność, więc każdy tydzień zaoszczędzony na wdrożeniu przekłada się bezpośrednio na koszt.
Zacznij od strategii, nie od obsady. Zanim dołączą testerzy, spisz, co jest ryzykiem w Twoim produkcie, które obszary są krytyczne, co już jest zautomatyzowane i gdzie są największe luki. Bez tego testerzy zaczną od tego, co najłatwiej przetestować, a nie od tego, co najważniejsze. Jeśli nie masz na to czasu ani kompetencji w zespole, rozważ krótki pakiet o stałym zakresie na start, a dopiero potem T&M lub zespół.
Przygotuj wdrożenie. Dostęp do środowisk, narzędzi i dokumentacji od pierwszego dnia. Osoba po Twojej stronie, która odpowiada na pytania. Lista pierwszych zadań na dwa tygodnie. Testerzy, którzy pierwszy tydzień czekają na dostępy, to najdroższy tydzień całej współpracy.
Ustal wartości bazowe mierników. Ile błędów trafia na produkcję, jak długo trwa regresja, ile testów jest zautomatyzowanych. Bez wartości bazowych za trzy miesiące nie będziesz w stanie powiedzieć, czy współpraca przynosi efekt.
Zrób przegląd po sześciu tygodniach. Czy skład jest właściwy, czy osoby się sprawdzają, czy priorytety są dobrze ustawione. To moment na wymianę osoby w ramach gwarancji, zmianę składu albo modelu, zanim koszt pomyłki się nawarstwi.
Szybkość obsadzenia ról nie jest zwykle wąskim gardłem. ARDURA deklaruje dostarczenie zweryfikowanych specjalistów QA w ciągu 2 tygodni, a w pilnych przypadkach wstępnie wyselekcjonowanych testerów w 48–72 godziny. Wąskim gardłem jest gotowość Twojej organizacji do ich przyjęcia.
Kiedy outsourcing testów się nie opłaca?
Są sytuacje, w których żaden model rozliczeń nie uratuje opłacalności, i warto je znać, zanim zaczniesz porównywać oferty.
Gdy nikt po Twojej stronie nie odpowiada za jakość. Outsourcing testów bez właściciela jakości po stronie zamawiającego kończy się zwykle aktywnością bez kierunku. Najpierw ustal, kto u Ciebie decyduje o tym, co jest gotowe do wydania.
Gdy problemem nie są testy, tylko proces. Jeśli błędy wynikają z niejasnych wymagań, braku przeglądów kodu albo wydań bez środowiska testowego, dodatkowi testerzy znajdą więcej błędów, ale ich nie zapobiegną. Wtedy lepiej zacząć od audytu procesu QA niż od zespołu.
Gdy produkt jest bardzo mały lub krótkotrwały. Koszt wdrożenia zewnętrznej osoby może przewyższyć koszt jej pracy w projekcie trwającym kilka tygodni. Wtedy lepiej sprawdza się krótki, zamknięty zakres albo wsparcie programistów w pisaniu testów.
Gdy kluczowa wiedza domenowa jest unikalna i rzadko dostępna. W niektórych domenach testowanie wymaga wiedzy, której zewnętrzny tester nie zdobędzie w rozsądnym czasie. Wtedy outsourcing sprawdza się dla automatyzacji, wydajności i bezpieczeństwa, a testy domenowe zostają wewnątrz.
Te sytuacje nie wykluczają outsourcingu całkowicie, ale zmieniają jego zakres. Często najlepszym rozwiązaniem jest model mieszany: strategia i decyzje o jakości wewnątrz, specjalistyczne kompetencje (automatyzacja, wydajność, testy mobilne, bezpieczeństwo) z zewnątrz.
Jakie są kluczowe wnioski?
Koszt outsourcingu testów oprogramowania to nie stawka, tylko suma pięciu składników: pracy, wdrożenia, zarządzania, narzędzi i utrzymania. Oferty różnią się głównie tym, które z nich dostawca bierze na siebie, a które zostawia Tobie, więc porównuj całkowity koszt w perspektywie 12 miesięcy, a nie stawki.
Zapamiętaj pięć rzeczy. Po pierwsze, time and material opłaca się przy zmiennym zakresie i wtedy, gdy masz po swojej stronie osobę, która zarządza jakością; dedykowany zespół przy długim, stabilnym produkcie; stały zakres przy pracach jednorazowych z jasnym rezultatem. Po drugie, rozliczanie za przypadek testowy lub zgłoszony błąd to najczęstsza forma płacenia za klikanie; unikaj go jako głównego modelu. Po trzecie, zamiast liczby przypadków mierz efekt: błędy po wydaniu, pokrycie ryzyka, czas informacji zwrotnej, stabilność i udział automatyzacji. Po czwarte, zapisz w umowie własność artefaktów, przeniesienie praw autorskich, warunki wymiany i przekazania wiedzy. Po piąte, zacznij od strategii i przygotowanego wdrożenia, bo pierwsze trzy miesiące decydują o opłacalności całej współpracy.
Więcej o testowaniu i jakości znajdziesz w hubie Quality Assurance. Jeśli porównujesz oferty na outsourcing testów albo chcesz policzyć, który model pasuje do Twojego produktu, zobacz zakres naszych usług testowania oprogramowania albo porozmawiajmy o Twoim przypadku. W krótkiej rozmowie ustalimy, który model rozliczeń ma sens, jaki skład jest potrzebny i ile to będzie kosztować w Twoim scenariuszu.