Outsourcing QA bez oddania definicji jakości: dlaczego kupujesz klikanie zamiast odpowiedzialności

Firma outsource’uje testy regresji do wyspecjalizowanego dostawcy. Kontrakt jest solidny: SLA na czas wykonania cyklu, stawki wynegocjowane o osiemnaście procent poniżej pierwszej oferty, raport po każdym wydaniu. Po osiemnastu miesiącach współpraca wygląda wzorowo — dostawca wykonuje 640 przypadków testowych na każde wydanie, raportuje 97 procent zaliczeń, nie przekroczył terminu ani razu. W tym samym okresie na produkcji wydarzyły się trzy poważne incydenty. Wszystkie trzy w obszarach formalnie pokrytych przypadkami, które przeszły.

Na spotkaniu podsumowującym pada pytanie, kto zawinił. Dostawca pokazuje, że wykonał dokładnie to, co dostał, i wykonał to bez zarzutu. Klient pokazuje, że płaci za testy, a produkt się psuje. Obie strony mają rację i to jest właśnie problem: kontrakt kupował wykonanie scenariusza, a strony myślały, że kupuje jakość. Nikt nie kłamał. Nikt też nigdy nie zapisał, kto ma prawo powiedzieć, że produkt nie nadaje się do wydania.

Ten artykuł broni tezy, która brzmi niewygodnie dla obu stron takiego kontraktu: outsourcing QA działa wyłącznie wtedy, gdy razem z wykonaniem oddaje się dostawcy prawo do definiowania kryteriów jakości. Zatrzymanie tej definicji u siebie — konfiguracja domyślna, spotykana w większości umów, jakie widzieliśmy — zamienia wyspecjalizowanego dostawcę w wykonawcę klikania i każe za to klikanie płacić stawkę uzasadnioną tylko wtedy, gdy kupuje się osąd.

Co właściwie kupujesz, zlecając testy na zewnątrz?

W każdej funkcji QA mieszczą się dwie zupełnie różne rzeczy, które umowa outsourcingowa niemal nigdy nie rozdziela na piśmie.

Pierwsza to wykonanie: przejście przypadku testowego, uruchomienie suite’u, przygotowanie danych, zaraportowanie wyniku. To praca mierzalna w godzinach i przypadkach, łatwa do wyceny, łatwa do umieszczenia w SLA i łatwa do porównania między dostawcami — właśnie dlatego rynek porównuje dostawców QA głównie po stawkach outsourcingu QA, bo to jedyny wymiar, który wszyscy opisują tak samo.

Druga to definicja: rozstrzygnięcie, co w ogóle należy przetestować, co liczy się jako defekt, jak poważny jest ten defekt i czy przy takim zestawie otwartych defektów produkt nadaje się do wydania. To praca nie do zmierzenia w godzinach, bo jej wartość leży w trafności, a nie w nakładzie. Godzina spędzona na trafnym rozpoznaniu, że ryzyko siedzi w migracji danych, a nie w interfejsie, jest warta trzydziestu godzin klikania po interfejsie.

Jakość produktu jest wytwarzana przez tę drugą warstwę. Pierwsza tylko ją realizuje. Można wykonać bezbłędnie zestaw przypadków, który omija obszar realnego ryzyka — i dokładnie to opisuje otwierająca ten tekst historia. Suite testowy, który nie pokrywa scenariusza, w którym system się wywalił, jest z inżynierskiego punktu widzenia poprawny w każdym pojedynczym kroku i bezużyteczny jako całość.

Stąd wniosek, który wygląda na truizm, dopóki nie skonfrontuje się go z realnymi umowami: jeśli dostawca dostaje wyłącznie warstwę wykonawczą, kupujesz od niego pracowitość, a nie jakość. Pracowitość można kupić taniej.

Dlaczego w polskich umowach definicja jakości najczęściej nie istnieje na piśmie?

Zanim przejdziemy do konfiguracji, warto zatrzymać się przy tym, jak ta warstwa wygląda w polskim obrocie prawnym — bo prawo zadało to pytanie wcześniej niż zarządzanie i zwykle nie dostaje odpowiedzi.

Umowy QA na polskim rynku plasują się między dwiema konstrukcjami kodeksowymi i to rozróżnienie ma bezpośrednie przełożenie na definicję jakości. Umowa o dzieło (art. 627 KC) zobowiązuje do osiągnięcia oznaczonego rezultatu — czyli wymaga, żeby ktoś rezultat opisał. Umowa o świadczenie usług, do której stosuje się odpowiednio przepisy o zleceniu (art. 750 KC), zobowiązuje do starannego działania i rezultatu nie wymaga. Znaczna część kontraktów testowych jest podpisywana jako ta druga, a rozliczana i oceniana tak, jakby była pierwszą: klient oczekuje jakości produktu, umowa gwarantuje wyłącznie staranność wykonania czynności. Ten rozjazd nie jest formalnością — to on rozstrzyga, kto odpowiada za incydent w obszarze, którego scenariusz nie objął.

Przy umowie o dzieło dochodzą dwa dalsze mechanizmy, które również wymagają definicji, a rzadko ją dostają. Odpowiedzialność za wady dzieła (art. 638 KC) odsyła do przepisów o rękojmi, a wada jest tam odnoszona między innymi do właściwości, jakie rzecz danego rodzaju powinna mieć ze względu na cel oznaczony w umowie. Jeśli cel nie został w umowie oznaczony precyzyjnie, miarę wyznacza to, czego „można się spodziewać” — czyli w praktyce biegły w sporze, a nie strony przy stole. Odbiór dzieła (art. 643 KC) jest z kolei czynnością o realnych skutkach: rodzi obowiązek zapłaty i uruchamia bieg terminów. Podpisując protokół odbioru na podstawie raportu, którego zakres sam ustaliłeś, podejmujesz decyzję prawną w oparciu o własne, niezweryfikowane założenia o ryzyku.

Do tego w obrocie profesjonalnym obowiązują akty staranności (art. 563 KC): kupujący traci uprawnienia z rękojmi, jeśli nie zbadał rzeczy w sposób przyjęty przy rzeczach tego rodzaju i nie zawiadomił niezwłocznie o wadzie. Zbadać może jednak tylko ten, kto wie, na co patrzeć — czyli ten, kto ma model ryzyka. Klient, który zatrzymał definicję, nie mając wiedzy o ryzyku, bierze na siebie ciężar, którego nie rekompensuje mu żaden arbitraż stawkowy.

W zamówieniach publicznych obraz jest jeszcze ostrzejszy, bo opis przedmiotu zamówienia musi być jednoznaczny i wyczerpujący (art. 99 PZP), a kryteria odbioru trafiają do dokumentacji przetargowej przed wyborem wykonawcy. Zamawiający jest więc zmuszony zapisać definicję jakości, zanim pozna kogokolwiek, kto zna wzorce awarii jego systemu. To strukturalna przyczyna, dla której w sektorze publicznym warstwa definicji niemal zawsze zostaje po stronie zamawiającego — i dobry powód, żeby traktować przekazanie jej jako proces po podpisaniu umowy, a nie jako coś do rozstrzygnięcia w SWZ.

Ostatnie ograniczenie jest praktyczne i realne: RODO (art. 28). Dostawca przetwarzający dane testowe z danymi osobowymi staje się podmiotem przetwarzającym, a bez umowy powierzenia i sensownej pseudonimizacji nie zobaczy tej bliskości produkcji, z której bierze się dobry model ryzyka. To najmocniejszy merytoryczny zarzut wobec tezy tego artykułu i jest on rozwiązywalny — przez dane syntetyczne o realistycznym rozkładzie albo udokumentowaną pseudonimizację — ale kosztuje i ten koszt należy do rachunku, a nie do dyskusji o dobrych intencjach. Praktyczny punkt zaczepienia daje tu przewodnik po testach akceptacyjnych, bo to na UAT zderzają się zwykle wymogi dowodowe i ochrona danych.

Dlaczego „hybryda” jest najczęstszą konfiguracją i jednocześnie najgorszą?

W dyskusji o modelu QA — także w naszym własnym opracowaniu o wyborze między QA wewnętrznym a outsourcingiem — model hybrydowy pojawia się jako rozsądny kompromis: dostawca dostarcza moce wykonawcze, klient zachowuje kontrolę nad tym, co i jak jest testowane. Brzmi jak najlepsze z obu światów i sprzedaje się znakomicie, bo nie wymaga od nikogo zaufania.

Warto powiedzieć wprost: ta konkretna hybryda jest najgorszym z możliwych podziałów pracy, a jej popularność wynika z tego, że jest najwygodniejsza politycznie, a nie z tego, że działa. Rozdziela ona wiedzę od odpowiedzialności w dokładnie odwrotną stronę, niż powinna iść.

Dostawca po kilkunastu miesiącach na projekcie wie o wzorcach awarii produktu więcej niż ktokolwiek po stronie klienta — widział wszystkie defekty, wszystkie regresje, wszystkie miejsca, w których „to zawsze się psuje przy wydaniu”. Ta wiedza jest jego jedynym prawdziwym aktywem i jedynym uzasadnieniem jego stawki. A jednocześnie nie ma on prawa jej użyć, bo zakres testów definiuje ktoś, kto tej historii nie widział z bliska.

Klient natomiast zachowuje prawo decyzji, ale nie ma podstawy informacyjnej, żeby ją dobrze podjąć. Jego menedżer QA pisze przypadki na podstawie specyfikacji i własnej intuicji sprzed dwóch lat, kiedy jeszcze sam testował.

Efekt jest strukturalny, nie personalny. Nie da się go naprawić lepszą komunikacją ani cotygodniowym statusem, bo to nie jest problem przepływu informacji — to problem umiejscowienia prawa do decyzji. Osoba z wiedzą nie ma uprawnienia, osoba z uprawnieniem nie ma wiedzy, a umowa opisuje wyłącznie to, ile przypadków zostanie wykonanych. Tak powstaje wykonawca klikania: nie dlatego, że dostawca jest słaby, tylko dlatego, że kontrakt nie przewiduje momentu, w którym mógłby użyć tego, co wie.

Z czego składa się definicja jakości i której części nikt nie oddaje?

Żeby rozmawiać o oddaniu definicji, trzeba ją najpierw rozbić na części, bo „definicja jakości” jako całość jest zbyt mglista, żeby cokolwiek podpisać. W praktyce składa się z czterech elementów, z których każdy może osobno leżeć po stronie klienta albo dostawcy.

Model ryzyka. Odpowiedź na pytanie, co może pójść nie tak i ile to będzie kosztowało. To on wyznacza, gdzie w ogóle warto szukać defektów. Model ryzyka rozstrzyga, czy sześćdziesiąt procent wysiłku idzie w ścieżkę płatności, czy rozkłada się równo po wszystkich ekranach.

Kryteria akceptacji. Rozstrzygnięcie, co znaczy „działa” dla konkretnej funkcji. Poziom, na którym najczęściej dochodzi do cichego rozjazdu: klient uważa, że eksport do PDF działa, gdy plik się generuje; dostawca uważa, że działa, gdy generuje się poprawnie dla dokumentu z 400 pozycjami i polskimi znakami w nazwie.

Taksonomia wagi defektu. Reguła zamieniająca znalezisko na priorytet. To najbardziej niedoceniany element definicji i jednocześnie ten, który najsilniej wpływa na realny poziom jakości, bo waga defektu decyduje o tym, czy ktokolwiek go naprawi przed wydaniem.

Prawo do rekomendacji wydania. Uprawnienie do napisania zdania „w naszej ocenie ten build nie nadaje się do wydania” i do tego, żeby zdanie to miało w organizacji ciężar. Bez niego trzy poprzednie elementy są opisem stanu, a nie mechanizmem.

Z naszych obserwacji rynkowych wynika prawidłowość, która powtarza się na tyle regularnie, że warto ją nazwać: klienci oddają pierwszy element najczęściej, a czwarty prawie nigdy. Zlecenie dostawcy analizy ryzyka jest bezpieczne — to dokument. Oddanie prawa do zatrzymania wydania jest niebezpieczne — to władza. A dokładnie ten czwarty element jest tym, co odróżnia usługę QA od podwykonawstwa.

Wersja pośrednia, którą spotyka się najczęściej, brzmi: „dostawca może zgłosić zastrzeżenie, decyzję podejmuje komitet wydaniowy klienta”. Ta formuła wygląda na rozsądną i w praktyce nic nie zmienia, o ile nie zapisano, że zastrzeżenie musi zostać odnotowane z uzasadnieniem odrzucenia. Bez tego zapisu zastrzeżenie jest opinią, a opinia nie tworzy odpowiedzialności po żadnej ze stron.

Skąd wiadomo, że dostawca dostał wykonanie zamiast odpowiedzialności?

Diagnoza nie wymaga audytu i da się ją zrobić w jedno popołudnie, na danych, które już istnieją w narzędziach.

Sprawdź autorstwo przypadków testowych. Wejdź do systemu zarządzania testami i wyfiltruj pole „autor” dla przypadków dodanych w ostatnich sześciu miesiącach. Jeśli dominują konta po stronie klienta, dostawca realizuje cudzy scenariusz. To najtwardszy pojedynczy sygnał, bo autorstwo przypadku jest operacyjnym śladem tego, kto rozstrzyga, co jest testowane.

Policz spory o wagę defektu i sprawdź, kto je wygrywa. Przejrzyj zgłoszenia, w których waga została zmieniona po zgłoszeniu. Jeśli zmiany idą systematycznie w dół i systematycznie robi je klient, taksonomia wagi jest po stronie klienta niezależnie od tego, co mówi umowa. Widzieliśmy projekty, w których obniżanie wagi dotyczyło ponad jednej trzeciej zgłoszeń o wysokim priorytecie — przy takiej skali to nie jest korygowanie pojedynczych pomyłek, to przejęcie kryterium.

Poszukaj rekomendacji negatywnej. Przejrzyj raporty z ostatnich dwunastu wydań i znajdź choć jedno zdanie, w którym dostawca nie rekomenduje wydania. Jeśli takiego zdania nie ma ani razu, są tylko dwie możliwości: albo produkt był bezbłędny dwanaście razy z rzędu, albo dostawca nie ma mechanizmu, żeby takie zdanie napisać. Pierwsza możliwość nie zdarza się w praktyce.

Zobacz, co mierzy raport miesięczny. Jeśli pierwsza tabela w raporcie pokazuje liczbę wykonanych przypadków, czas cyklu i procent zaliczeń, dostawca raportuje aktywność. Jeśli pokazuje defekty, które uciekły na produkcję, ich wagę i pokrycie ryzyk z modelu — raportuje wynik. Różnica między metrykami aktywności a metrykami wyniku w QA jest tu równoznaczna z różnicą między wykonaniem a odpowiedzialnością.

Trzy z czterech sygnałów na „tak” oznaczają, że płacisz stawkę za osąd, a dostajesz przepustowość.

Dlaczego SLA na liczbę przypadków mierzy dokładnie to, czego nie chcesz kupić?

Zapisanie w umowie liczby przypadków testowych do wykonania wygląda na jedyny obiektywny sposób opisania zakresu usługi. Jest też najprostszą drogą do tego, żeby dostawca zaczął optymalizować coś innego, niż zamawiałeś.

Mechanizm jest znany z każdej dziedziny, w której miara staje się celem. Skoro rozliczenie idzie po liczbie wykonanych przypadków, racjonalny dostawca zwiększa ich liczbę i skraca czas jednostkowy. Wynikają z tego decyzje, z których każda z osobna jest obroniona: rozbicie jednego złożonego scenariusza na cztery proste, utrzymywanie przy życiu przypadków, które od dwóch lat nigdy nie wykryły defektu, unikanie testowania eksploracyjnego, bo nie generuje przypadków do rozliczenia. Suma tych decyzji to suite, który rośnie, kosztuje coraz więcej i wykrywa coraz mniej.

Testowanie eksploracyjne jest tu przypadkiem szczególnie kosztownym. Jest to jedyna technika, w której wartość powstaje z osądu testera w trakcie pracy, a nie z wcześniej zapisanego kroku — i jednocześnie jedyna, której nie da się rozliczyć w modelu „przypadek testowy jako jednostka”. W kontraktach rozliczanych po przypadkach znika ona pierwsza, a wraz z nią znika większość szans na wykrycie defektu, którego nikt nie przewidział na etapie pisania scenariuszy.

Alternatywa nie polega na rezygnacji z mierzalności, tylko na przesunięciu miary o jeden poziom wyżej — do wyniku. Umowa może rozliczać liczbę defektów, które uciekły na produkcję, z podziałem na wagi i z progiem tolerancji dla najcięższych. Może rozliczać pokrycie ryzyk z uzgodnionego modelu ryzyka, a nie pokrycie linii kodu. Może zawierać zobowiązanie dostawcy do wydania rekomendacji wydaniowej i konsekwencję za jej wystawienie niezgodnie z własną wiedzą. Wszystkie trzy miary są trudniejsze do policzenia niż liczba przypadków i wszystkie trzy mierzą to, co faktycznie kupujesz.

To jest miejsce, w którym większość organizacji zatrzymuje się z prostego powodu: miara wyniku wymaga wcześniejszego oddania definicji. Nie da się rozliczać dostawcy z defektów, które uciekły, jeśli zakres testów napisał ktoś inny — dostawca zasadnie odpowie, że testował to, co dostał. Kontrakt oparty na wyniku i zatrzymanie definicji u siebie wykluczają się nawzajem, i właśnie dlatego rynek trzyma się miar aktywności.

Ile realnie kosztuje utrzymanie definicji jakości po swojej stronie?

Argument za outsourcingiem QA jest zwykle kosztowy, a rachunek robi się na stawce godzinowej. Ten rachunek pomija pozycję, która w modelu z zatrzymaną definicją bywa większa niż uzyskany arbitraż stawkowy.

Etat po stronie klienta, którego nikt nie wliczył do modelu. Ktoś musi pisać i utrzymywać przypadki testowe, rozstrzygać wagi, odpowiadać na pytania dostawcy i przygotowywać zakres na każde wydanie. Z naszych obserwacji przy średniej wielkości produkcie to zwykle między 0,6 a 1,0 etatu doświadczonego menedżera QA — czyli osoby drogiej. Jeśli powodem outsourcingu było to, że QA wewnętrzne kosztuje za dużo, ta pozycja pochłania znaczną część oszczędności, zanim policzy się cokolwiek innego.

Czas oczekiwania po stronie dostawcy. W modelu, w którym każda niejednoznaczność wymaga rozstrzygnięcia u klienta, zespół dostawcy czeka. Ten czas jest fakturowany, bo dostawca sprzedaje dostępność zespołu. Rzadko kiedy przekracza kilkanaście procent, ale liczy się po najwyższej stawce w kontrakcie.

Koszt drugiego przebiegu. Rozjazd między kryteriami akceptacji klienta a rozumieniem dostawcy ujawnia się dopiero na wyniku i kończy się powtórzeniem części cyklu. Każde takie powtórzenie kosztuje dwa razy: raz w godzinach, drugi raz w opóźnieniu wydania.

Koszt incydentu, który mieści się między definicjami. Najdroższa pozycja i jedyna, która nie pojawia się w żadnym zestawieniu, bo formalnie nie jest kosztem QA. Incydent produkcyjny w obszarze nieobjętym scenariuszem jest zdarzeniem, za które nie odpowiada ani dostawca (wykonał zakres), ani menedżer QA klienta (nie mógł przewidzieć wszystkiego). Odpowiedzialność rozproszona to odpowiedzialność żadna, a rachunek i tak przychodzi — w postaci przestoju, utraconych transakcji albo kar umownych wobec własnych klientów.

Kiedy zsumuje się te cztery pozycje i porówna z arbitrażem stawkowym, który był powodem całej operacji, model z zatrzymaną definicją bardzo często wychodzi drożej niż utrzymywanie QA wewnętrznego — i prawie zawsze drożej niż outsourcing z przekazaną definicją. Ten rachunek warto zrobić na własnych liczbach przed przedłużeniem umowy, korzystając z tej samej dyscypliny, co przy porównaniu całkowitego kosztu posiadania QA.

Jak wygląda przekazanie definicji w praktyce — co dokładnie się podpisuje?

Przekazanie definicji jakości nie jest deklaracją zaufania, tylko zestawem konkretnych zapisów. Poniższe pięć elementów wystarcza, żeby zmienić charakter relacji, i żaden z nich nie wymaga renegocjacji stawek.

Warsztat modelu ryzyka z podpisem obu stron. Jednorazowe, kilkudniowe ćwiczenie, w którym powstaje lista obszarów ryzyka z przypisanym skutkiem biznesowym. Klient wnosi wiedzę o skutku, dostawca o prawdopodobieństwie. Dokument jest odtąd podstawą zakresu testów i jedyną rzeczą, którą klient akceptuje przed każdym wydaniem — zamiast akceptować listę przypadków.

Strategia testów autorstwa dostawcy, zatwierdzana raz. Dostawca pisze, jak zamierza pokryć ryzyka z modelu. Klient zatwierdza strategię, a nie poszczególne przypadki. To jest operacyjne sedno przekazania: od tego momentu autorem scenariuszy jest ten, kto zna wzorce awarii.

Taksonomia wagi defektu należąca do dostawcy, ze ścieżką odwołania. Dostawca klasyfikuje, klient ma prawo odwołania w wąskim, zapisanym trybie — z uzasadnieniem i z zapisem w rejestrze. Rejestr odwołań staje się przy okazji najlepszą metryką dojrzałości relacji: jeśli po roku odwołań jest kilka, taksonomia się zestroiła; jeśli są ich dziesiątki, strony nadal nie mówią o tym samym.

Rekomendacja wydaniowa z imieniem i nazwiskiem. Przed każdym wydaniem dostawca wystawia jednoznaczną rekomendację: wydawać albo nie wydawać, z podpisem konkretnej osoby. Klient zachowuje pełne prawo do wydania wbrew rekomendacji — ale musi to zrobić świadomie i zostawić ślad. Ten jeden zapis robi więcej dla jakości niż dowolna zmiana w zakresie testów, bo zamienia rozmytą współodpowiedzialność w dwie jasne, rozdzielone decyzje.

Metryka wynikowa w rozliczeniu. Choćby jedna pozycja rozliczenia powiązana z defektami, które uciekły na produkcję. Nie musi to być kara — wystarczy próg, powyżej którego uruchamia się wspólny przegląd modelu ryzyka. Chodzi o to, żeby wynik w ogóle wchodził do rozmowy handlowej. Warto przy tym korzystać z gotowych zestawów pytań kontraktowych, takich jak nasza lista kontrolna wyboru dostawcy usług IT.

Czego nie wolno oddać — gdzie granica przebiega naprawdę?

Teza tego artykułu jest mocna, ale nie jest absolutna, a udawanie, że jest, byłoby złą radą. Istnieje granica, poza którą delegacja przestaje być przekazaniem kompetencji, a staje się ucieczką od decyzji.

Apetyt na ryzyko biznesowe zostaje po stronie klienta i nie podlega negocjacji. Odpowiedź na pytanie, czy wydajemy z otwartym defektem średniej wagi, bo kampania marketingowa startuje w poniedziałek, nie jest pytaniem o jakość. To pytanie o to, ile ryzyka firma chce zjeść w zamian za konkretną korzyść, i żaden dostawca nie ma podstaw ani mandatu, żeby na nie odpowiedzieć. Dostawca dostarcza jednoznaczną informację, czym ryzykujesz. Rozstrzygnięcie należy do klienta.

Odpowiedzialność regulacyjna jest imienna i nieprzenoszalna. W obszarach objętych nadzorem — wyroby medyczne, część rynku finansowego, bezpieczeństwo produktu — odpowiedzialność za dopuszczenie do użytku spoczywa na konkretnej funkcji po stronie wytwórcy i nie da się jej scedować umową. Dostawca może przygotować całą dokumentację dowodową; podpis pozostaje po stronie klienta.

Kompromisy produktowe należą do produktu. Rozstrzygnięcie, czy funkcja ma być wydana w wersji ograniczonej, czy przesunięta o miesiąc, jest decyzją strategiczną. QA dostarcza do niej dane, a nie ją podejmuje.

Granica jest więc dokładnie tam: dostawca dostaje definicję jakości technicznej, klient zachowuje definicję ryzyka biznesowego. Bez tego rozdziału teza tego artykułu zamienia się w postulat oddania firmy w zarząd zewnętrzny, co byłoby złą radą niezależnie od jakości dostawcy. Z tym rozdziałem staje się czymś znacznie skromniejszym i wykonalnym: przekazaniem osądu inżynierskiego tam, gdzie jest wiedza, przy zachowaniu decyzji biznesowej tam, gdzie jest odpowiedzialność właścicielska.

Kiedy zatrzymanie definicji jest właściwą decyzją?

Są trzy sytuacje, w których zatrzymanie definicji jakości po stronie klienta jest uzasadnione. We wszystkich trzech wniosek praktyczny jest ten sam i brzmi niewygodnie dla dostawcy usług QA.

Produkt o krótkim horyzoncie życia. Jeśli system ma przed sobą kilkanaście miesięcy — bo jest wygaszany, migrowany albo jest sezonową kampanią — koszt przekazania wiedzy o ryzyku nigdy się nie zwróci. Dostawca dojdzie do użytecznego modelu ryzyka mniej więcej wtedy, gdy produkt przestanie istnieć.

Skrajna koncentracja wiedzy o ryzyku. Bywają organizacje, w których wiedza o tym, co może pójść nie tak, mieści się w głowie jednej osoby i nie została nigdy zapisana. Przekazanie definicji wymaga wtedy najpierw jej wydobycia, co jest osobnym, kilkumiesięcznym projektem. Do jego zakończenia definicja siłą rzeczy zostaje po stronie klienta.

Odpowiedzialność regulacyjna obejmująca całość, nie fragment. W nielicznych obszarach nadzór wymaga, by także kryteria akceptacji były ustanowione przez podmiot odpowiedzialny. Tam delegacja jest prawnie wykluczona, a nie tylko ryzykowna.

Wniosek jest w każdym z tych przypadków identyczny: jeśli nie możesz oddać definicji, nie kupuj usługi QA — kup pojemność. Kontraktuj inżynierów pracujących w zespole klienta, pod jego procesem i jego definicją, rozliczanych za dostępność, a nie za wynik jakościowy. To uczciwy model o przewidywalnej ekonomice. Nieuczciwy jest model trzeci: kupowanie usługi QA po stawce za osąd, przy jednoczesnym niedopuszczeniu dostawcy do osądu. Ten model kosztuje jak usługa, działa jak pojemność i nie ma właściciela, gdy coś pójdzie nie tak.

Jak przeprowadzić przekazanie definicji w istniejącym kontrakcie?

Przekazanie nie wymaga zrywania umowy ani nowego przetargu. Sekwencja poniżej mieści się w około dziewięćdziesięciu dniach i większość jej kroków to aneks plus zmiana procesu.

Dni 1–15: pomiar stanu wyjściowego. Cztery liczby: udział przypadków testowych autorstwa klienta, liczba zmian wagi defektu dokonanych przez klienta, liczba negatywnych rekomendacji wydaniowych w ostatnim roku, liczba defektów, które uciekły na produkcję, z podziałem na wagi. Bez tego pomiaru nie da się później wykazać, że zmiana cokolwiek dała.

Dni 16–30: warsztat ryzyka. Dwa lub trzy dni pracy z udziałem właściciela produktu, architekta i zespołu dostawcy. Wynikiem jest lista obszarów ryzyka ze skutkiem biznesowym wyrażonym w pieniądzu albo w czasie niedostępności. Dokument podpisują obie strony.

Dni 31–50: strategia testów po stronie dostawcy. Dostawca pisze, jak pokrywa ryzyka. Klient zatwierdza dokument jako całość i od tego momentu przestaje akceptować pojedyncze przypadki. To najtrudniejszy krok organizacyjnie, bo odbiera menedżerowi QA klienta zajęcie, które definiowało jego rolę — i wymaga jawnego przedefiniowania tej roli na właściciela modelu ryzyka.

Dni 51–70: taksonomia wag i ścieżka odwołania. Wspólne przepisanie definicji wag na maksymalnie cztery poziomy z jednoznacznymi kryteriami. Prawo klasyfikacji przechodzi na dostawcę, klient dostaje zapisaną ścieżkę odwołania z terminem i wymogiem uzasadnienia.

Dni 71–90: rekomendacja wydaniowa i metryka wynikowa. Aneks wprowadza obowiązek imiennej rekomendacji przed każdym wydaniem oraz jedną metrykę wynikową w raportowaniu. Po pierwszych trzech wydaniach powtarza się pomiar z etapu pierwszego.

Sygnał, że przekazanie się udało, jest jeden i pojawia się zwykle między drugim a czwartym miesiącem: dostawca po raz pierwszy odmawia rekomendacji wydania, a organizacja to wydanie wstrzymuje. Do tego momentu wszystko jest deklaracją. W projektach wielodostawczych warto od razu zestroić ten mechanizm z zarządzaniem ryzykiem i jakością między dostawcami, żeby rekomendacje nie znosiły się nawzajem.

Jak wygląda mapa dojrzałości przekazania definicji jakości?

Poniższa mapa pozwala umiejscowić własny kontrakt w kilka minut. Poziomy nie są etapami, przez które trzeba przejść po kolei — z poziomu 1 da się przejść od razu na 3, jeśli istnieje model ryzyka.

Poziom	Kto pisze przypadki	Kto klasyfikuje wagę	Kto rekomenduje wydanie	Co mierzy kontrakt	Typowy efekt
0 — podwykonawstwo	klient	klient	nikt formalnie	roboczogodziny	dostawca wymienny co rok, wiedza o ryzyku nie kumuluje się nigdzie
1 — wykonawstwo mierzone	klient	klient	nikt formalnie	liczba przypadków, czas cyklu	suite rośnie, wykrywalność spada, testy eksploracyjne zanikają
2 — hybryda konsultacyjna	wspólnie	klient, po zgłoszeniu dostawcy	dostawca doradczo, bez śladu	przypadki plus SLA czasu	spory o wagę, odpowiedzialność rozproszona, incydenty bez właściciela
3 — przekazana definicja techniczna	dostawca wg modelu ryzyka	dostawca, odwołanie klienta	dostawca imiennie, klient decyduje	pokrycie ryzyk plus defekty uciekłe	dostawca zaczyna odmawiać rekomendacji, jakość staje się widoczna
4 — partnerstwo wynikowe	dostawca	dostawca	dostawca, z konsekwencją umowną	wyłącznie miary wyniku	wspólny przegląd modelu ryzyka po incydencie zamiast szukania winnego

Większość kontraktów outsourcingu QA, jakie widzieliśmy na polskim rynku, mieści się na poziomach 1 i 2. Poziom 4 jest realny wyłącznie przy dojrzałej relacji i wymaga zgody obu stron na dzielenie konsekwencji — nie każda organizacja tego chce i nie w każdej jest to potrzebne. Poziom 3 wystarcza, żeby usługa zaczęła robić to, za co się płaci.

Jakie są kluczowe wnioski?

Outsourcing QA jest kupowaniem osądu, nie przepustowości. Osąd wytwarza się przez definiowanie: co testować, co jest defektem, jakiej jest wagi i czy produkt nadaje się do wydania. Kontrakt, który zostawia całą tę warstwę u klienta, kupuje wykonanie po cenie osądu i systematycznie rozczarowuje obie strony, przy czym żadna nie łamie umowy.

Trzy rzeczy warto zrobić w tym tygodniu, jeśli ten opis pasuje do twojego kontraktu. Po pierwsze, sprawdź autorstwo przypadków testowych z ostatniego półrocza — to jedno zapytanie w narzędziu i najtwardszy sygnał, jaki istnieje. Po drugie, poszukaj w raportach z ostatniego roku choć jednej negatywnej rekomendacji wydaniowej; jej brak nie oznacza, że nie było powodów. Po trzecie, dolicz do rachunku outsourcingu etat, który po twojej stronie utrzymuje definicję, i sprawdź, czy arbitraż stawkowy nadal istnieje po tej korekcie. Pomocna przy tym będzie checklista planowania testów akceptacyjnych, bo to właśnie na UAT rozjazd definicji ujawnia się najszybciej.

Jeśli po tych trzech krokach okaże się, że płacisz za osąd, którego nie dopuszczasz do głosu, masz do wyboru dwie uczciwe drogi: oddać definicję jakości technicznej dostawcy, zachowując decyzję o ryzyku biznesowym, albo przestać kupować usługę i zacząć kupować pojemność. Trzecia droga — obecna konfiguracja — jest najdroższa z nich.

W ARDURA Consulting prowadzimy usługi zapewnienia jakości w obu modelach i rozmowę o współpracy zaczynamy od pytania, które w tej branży zadaje się zbyt rzadko: kto po podpisaniu umowy będzie miał prawo powiedzieć „to nie nadaje się do wydania”. Porozmawiajmy o twoim kontrakcie, zanim odnowisz go na kolejny rok w niezmienionym kształcie.