„Wasze oprogramowanie jest zbyt specyficzne”: dlaczego to obiekcja, nie fakt

Oprogramowanie zbyt specyficzne, onboarding zewnętrznego zespołu potrwa wieczność, to najczęstsza obiekcja, jaką słyszymy od CTO rozważających testy niezależne. Brzmi jak fakt, ale w praktyce jest to strach przed nieznanym, nie realna bariera techniczna, bo każdy system, niezależnie od stopnia skomplikowania, da się rozłożyć na testowalne komponenty w kilka tygodni, nie miesięcy. Ten artykuł pokazuje, dlaczego ta obiekcja nie wytrzymuje konfrontacji z danymi, jak wygląda realny onboarding zespołu testowego do specyficznego systemu, ile kosztuje firmę wiara w tę obiekcję, kiedy jest nieprawdziwa, i kiedy naprawdę warto potraktować ją poważnie.

Skąd bierze się obiekcja „oprogramowanie zbyt specyficzne”

Obiekcja o specyfice oprogramowania rzadko jest w pełni świadomym argumentem, częściej jest wyrazem lęku przed utratą kontroli. Zespół, który przez lata budował system, zna każdy jego zakamarek intuicyjnie, bez potrzeby dokumentowania tej wiedzy, bo była ona przekazywana ustnie, w code review, w rozmowach przy tablicy. Perspektywa wpuszczenia zewnętrznego zespołu, który tej niepisanej wiedzy nie ma, budzi naturalny opór, bo intuicyjnie wydaje się, że bez niej testowanie będzie powierzchowne albo błędne.

Ten lęk ma realne źródło, ale złą diagnozę. Prawdziwym problemem nie jest specyfika systemu, tylko brak udokumentowanej wiedzy o nim, co jest problemem samym w sobie, niezależnie od tego, czy firma zatrudni zewnętrzny zespół testowy, czy nie. System, którego nie da się przetestować bez wiedzy niepisanej jednej osoby, jest systemem z ukrytym ryzykiem operacyjnym, tym, co w inżynierii oprogramowania nazywa się bus factor: gdy ta osoba odejdzie z firmy, ryzyko się zmaterializuje niezależnie od obecności testerów zewnętrznych. Zewnętrzny audyt QA często jako produkt uboczny ujawnia właśnie ten problem, co samo w sobie jest wartością, nie wadą procesu.

W rozmowach sprzedażowych ta obiekcja pojawia się niemal zawsze w tym samym miejscu: zaraz po pytaniu o cenę, nie przed nim. To ważny sygnał. Gdyby specyfika systemu była realną barierą techniczną, pojawiałaby się na starcie rozmowy, zanim ktokolwiek zapytał o budżet. To, że pojawia się później, sugeruje, że pełni funkcję obronną, sposobu na odłożenie decyzji bez konieczności przyznania wprost, że powodem jest budżet, czas albo brak gotowości organizacyjnej do wpuszczenia kogoś z zewnątrz.

Ta sama obiekcja, inne motywacje w zależności od roli

Warto rozdzielić, kto właściwie mówi te słowa, bo pod tym samym zdaniem kryją się różne obawy. CTO zwykle martwi się budżetem i harmonogramem, nie techniką: dla niego „zbyt specyficzne” bywa skrótem myślowym na „nie wiem, ile to będzie kosztować i jak długo potrwa”, nie realną wątpliwością inżynierską. Head of QA martwi się czym innym: utratą własności procesu, tym że zewnętrzny zespół zacznie narzucać standardy, których wewnętrzny zespół nie akceptuje albo nie rozumie. Inżynierowie, którzy budowali system, martwią się najbardziej personalnie: że audyt ujawni decyzje podjęte kiedyś pod presją terminu, które dziś z boku wyglądają na błędy, choć w swoim czasie były rozsądnym kompromisem. Trzy różne obawy, jedno i to samo zdanie wypowiedziane w rozmowie sprzedażowej, i trzy różne sposoby na jego rozbrojenie, nie jeden uniwersalny argument.

Co ludzie właściwie mają na myśli, mówiąc „zbyt specyficzne”

Warto rozbić obiekcję „oprogramowanie zbyt specyficzne” na trzy realne kategorie, bo każda ma inne rozwiązanie, a mieszanie ich razem jest tym, co sprawia, że problem wygląda na większy, niż jest. Pierwsza to logika biznesowa specyficzna dla branży: reguły podatkowe, procedury zgodności regulacyjnej, algorytmy wyceny ryzyka. Ta kategoria jest realna, ale rozwiązywalna, bo doświadczony zespół QA zadaje właściwe pytania właściwym osobom w pierwszym tygodniu, zamiast zgadywać.

Druga kategoria to kod historyczny bez dokumentacji, czyli system, który działa, ale nikt już nie pamięta dlaczego akurat tak. To nie jest problem specyfiki, tylko problem długu wiedzy, i objawia się identycznie niezależnie od tego, czy firma zatrudnia testerów zewnętrznych, czy nie. Trzecia kategoria to integracje z systemami zewnętrznymi: inne API, starsze bazy danych, dostawcy płatności. Tu doświadczenie z dziesiątek podobnych integracji w innych projektach realnie skraca czas rozpoznania, bo wzorce integracyjne powtarzają się między branżami znacznie częściej, niż wydaje się zespołom wewnętrznym przekonanym o unikalności własnego systemu.

W praktyce te trzy kategorie rzadko występują osobno. Typowy system, na którym słyszymy tę obiekcję, łączy wszystkie trzy naraz: kawałek logiki biznesowej, którego nikt nie udokumentował, bo powstał piętnaście lat temu, zanim ktokolwiek pomyślał o testach, kawałek integracji z systemem zewnętrznym, który zmieniał dostawcę dwa razy i za każdym razem zostawiał ślad starego kodu, i kawałek reguł regulacyjnych, które zmieniły się w międzyczasie, ale kod nie zawsze nadążył. Rozplątanie tego nie jest kwestią tygodni bez planu, tylko kwestii metody: najpierw mapa, potem priorytety, potem testy na tym, co najważniejsze, nie na wszystkim naraz.

O co pyta doświadczony zespół w pierwszym tygodniu

Przewidywalność onboardingu nie bierze się z magii, tylko z tego, że pierwszy tydzień ma zawsze ten sam szkielet pytań, niezależnie od branży klienta. Cztery z nich powtarzają się w każdym projekcie:

Źródło: opracowanie własne Quality Island, checklista stosowana w pierwszym tygodniu audytu.

Żadne z tych pytań nie wymaga znajomości konkretnego systemu z góry. Wymaga metody i doświadczenia w zadawaniu ich w dobrej kolejności, bo odpowiedź na pytanie trzecie zwykle zmienia sposób, w jaki warto zadać pytanie czwarte. To właśnie ta kolejność, wypracowana na setkach wcześniejszych projektów, jest tym, czego nie da się przyspieszyć, czytając dokumentację systemu w oderwaniu od rozmów z ludźmi, którzy go używają na co dzień.

Co pokazuje skala doświadczenia w praktyce

Ponad 350 000 napisanych testów automatycznych w portfolio Quality Island to argument nie o cenie, tylko o wzorcach. Każdy kolejny projekt, niezależnie od branży, ujawnia powtarzalne kategorie złożoności: integracje z systemami zewnętrznymi, logikę biznesową specyficzną dla regulacji branżowej, starsze warstwy kodu bez dokumentacji. Zespół, który przepracował setki takich projektów, rozpoznaje te kategorie w pierwszych dniach audytu, nawet jeśli konkretna implementacja jest nowa, bo wzorzec problemu, nie jego szczegóły, powtarza się między branżami znacznie częściej, niż wydaje się zespołom wewnętrznym przekonanym o unikalności własnego systemu.

To nie oznacza, że onboarding jest natychmiastowy. Oznacza, że ma przewidywalny kształt, który da się zaplanować i zakomunikować z góry, zamiast traktować jako czarną skrzynkę niewiadomego czasu trwania. Doświadczony zespół QA wie z góry, jakich pytań zadać w pierwszym tygodniu, jakie dokumenty poprosić, gdzie szukać ukrytej logiki biznesowej, bo widział analogiczne wzorce dziesiątki razy wcześniej, nawet jeśli nigdy nie widział akurat tego konkretnego systemu.

Ten wzorzec widzieliśmy w praktyce w sektorze bankowym i finansowym, w zdrowiu i administracji publicznej, i w software house’ach budujących produkty dla innych firm. Za każdym razem inna domena, inny język branżowy, inne przepisy w tle, ale ta sama struktura problemu: gdzieś w systemie jest logika, którą rozumie garstka osób, i to ta garstka, nie sam kod, jest prawdziwym wąskim gardłem onboardingu.

Dwa dowody z branż, które same siebie nazywają zbyt specyficznymi

Łatwo mówić o skali doświadczenia w ogólnikach, więc konkretnie: PKO BP i ChaosGears to dwa projekty z branż, w których argument o specyfice pada najczęściej i brzmi najbardziej przekonująco, bo w obu przypadkach jest w nim ziarno prawdy. Bankowość ma regulacje, których złamanie kosztuje realne pieniądze i licencje. Medycyna ma procedury, których pominięcie ma konsekwencje dla pacjenta, nie tylko dla budżetu.

Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji, razem z audytem istniejących procesów QA i szkoleniami dla zespołów. Punktem wyjścia nie było udawanie, że znamy bankowość lepiej niż bank, tylko systematyczne rozpoznanie: gdzie w organizacji leży wiedza o ryzyku, kto podejmuje decyzje o jakości, jakie procesy już istnieją, a jakich brakuje. Dla ChaosGears, firmy z branży medycznej, budowaliśmy dokumentację testową i odbiorczą razem z procesami automatyzacji i realizacją procedur odbiorczych, dokładnie tam, gdzie specyfika regulacyjna jest największa, nie mimo niej. Żaden z tych projektów nie zaczął się od udawania, że specyfika nie istnieje. Zaczął się od audytu, który tę specyfikę nazwał i rozłożył na zadania, zamiast traktować ją jako powód, żeby nie zaczynać.

Wzorzec, który powtórzył się w obu projektach, jest prosty: specyfika regulacyjna nie znika po audycie, ale przestaje być niewiadomą. Zespół wewnętrzny w obu przypadkach zachował pełną kontrolę nad decyzjami merytorycznymi, bo to on najlepiej rozumie ryzyko biznesowe i regulacyjne. Rola zewnętrznego audytu nie polegała na zastąpieniu tej wiedzy, tylko na dostarczeniu metody i mocy przerobowej, których wewnętrzny zespół QA fizycznie nie miał czasu zapewnić przy bieżącym obciążeniu innymi projektami.

Co z tego wynika naszym zdaniem

Jak wygląda realny onboarding krok po kroku

Pierwszy tydzień to zawsze audyt: przegląd architektury, rozmowy z kluczowymi osobami, mapowanie krytycznych ścieżek biznesowych, bez pisania jeszcze jednego testu. Ten etap celowo nie jest pomijany nawet pod presją czasu, bo testy napisane bez zrozumienia priorytetów biznesowych systemu testują rzeczy nieistotne, zostawiając realne ryzyko nietknięte. Drugi i trzeci tydzień to budowa pierwszego zestawu testów na najbardziej krytycznych ścieżkach, zwykle płatności, logowania, kluczowych transakcji biznesowych, żeby jak najszybciej dać zespołowi wewnętrznemu namacalny dowód wartości, zanim padnie pytanie o sens całego przedsięwzięcia.

Od czwartego tygodnia zespół zewnętrzny zwykle działa już z pełną samodzielnością na uzgodnionym zakresie, a rozmowy z zespołem wewnętrznym przechodzą z trybu tłumaczenia systemu do trybu konsultacji przypadków brzegowych, co jest naturalnym znakiem, że onboarding się zakończył. Ten harmonogram bywa dłuższy przy systemach z bardzo starym kodem bez żadnej dokumentacji, ale nawet wtedy mówimy o wydłużeniu o kilka tygodni, nie o miesiącach, których obawia się większość CTO podnoszących tę obiekcję na starcie rozmowy.

Kiedy ta obiekcja bywa uzasadniona

Uczciwie: zdarzają się systemy, przy których obiekcja „oprogramowanie zbyt specyficzne” ma rację, a onboarding realnie trwa dłużej niż cztery tygodnie. Dzieje się tak, gdy nakładają się na siebie dwa czynniki naraz, nie jeden: zerowa dokumentacja i jednoczesny brak dostępu do jedynej osoby, która rozumie kluczową logikę biznesową, bo odeszła z firmy albo jest niedostępna. W takiej sytuacji harmonogram z poprzedniej sekcji się wydłuża, bo pierwszy tydzień audytu musi częściowo odtworzyć wiedzę, której normalnie zespół wewnętrzny po prostu udziela w rozmowie. To wciąż nie jest argument za rezygnacją z zewnętrznego audytu, tylko za tym, żeby zacząć od niego jak najwcześniej, zanim ten scenariusz się zmaterializuje. Im dłużej firma czeka, tym więcej takiej wiedzy niepisanej znika razem z ludźmi, którzy odchodzą.

Dobra wiadomość jest taka, że ten scenariusz da się wykryć zawczasu, bez czekania na sam audyt. Jeśli w firmie istnieje choćby jedna funkcja biznesowa, którą potrafi wytłumaczyć dokładnie jedna osoba, i nikt inny nie zastąpiłby jej w ciągu tygodnia, to sygnał wystarczająco silny, żeby zacząć rozmowę o audycie już teraz, niezależnie od tego, czy akurat planowany jest projekt z zewnętrznym zespołem testowym.

Ile to kosztuje, kiedy obiekcja wygrywa

Obiekcja „oprogramowanie zbyt specyficzne”, która wygrywa, nie jest neutralna, ma koszt, tylko odroczony i niewidoczny w bieżącym budżecie. Firma, która odkłada audyt o rok, bo system jest „zbyt specyficzny”, przez ten rok dalej polega na niepisanej wiedzy tych samych kilku osób, a ryzyko odejścia którejś z nich nie znika, tylko czeka. Co więcej, każdy miesiąc rozwoju bez zewnętrznego spojrzenia dokłada nowe fragmenty systemu do tej samej, niezmapowanej całości, więc problem, który dziś wymagałby czterech tygodni audytu, za rok może wymagać sześciu, nie dlatego, że system stał się bardziej specyficzny, tylko dlatego, że urósł, zanim ktokolwiek go usystematyzował. To ten sam mechanizm, o którym piszemy przy okazji długu technologicznego: koszt odłożenia decyzji o jakości rzadko znika, zwykle tylko czeka na wyższy rachunek.

Dlaczego ta obiekcja przetrwa nawet dobrą odpowiedź

Warto na koniec nazwać coś, czego dane same nie pokazują: nawet po usłyszeniu wszystkich powyższych argumentów część zespołów i tak będzie się wahać, bo to nie jest do końca decyzja racjonalna. Ekspertyza o własnym systemie, zdobywana latami, jest częścią tożsamości zawodowej ludzi, którzy ją mają. Wpuszczenie kogoś z zewnątrz, kto w cztery tygodnie dogoni część tej wiedzy metodą, nie latami pracy, bywa odczuwane jako dewaluacja tego wysiłku, nawet jeśli nikt tego głośno nie powie. To nie jest argument przeciwko audytowi, tylko wskazówka, jak go dobrze przeprowadzić: włączając zespół wewnętrzny jako źródło wiedzy i współautora wyniku, nie jako stronę poddawaną ocenie. Firmy, które to rozumieją, słyszą tę obiekcję rzadziej już przy drugiej rozmowie, nie tylko przy pierwszej.

Najczęściej zadawane pytania o testy w „zbyt specyficznym” systemie

Czy trzeba dać zewnętrznemu zespołowi pełny dostęp do kodu źródłowego?

Nie od pierwszego dnia. Audyt startuje od dostępu do środowiska testowego i dokumentacji, jaka akurat istnieje, nie do repozytorium produkcyjnego. Pełny dostęp do kodu bywa potrzebny dopiero przy automatyzacji na poziomie API i wtedy ustala się go świadomie, z NDA i ograniczeniami, jakie firma uzna za konieczne, nie jako domyślny warunek startu.

Co jeśli naprawdę nie mamy żadnej dokumentacji?

To normalny punkt startu, nie wyjątek dyskwalifikujący. Pierwszy tydzień audytu w takiej sytuacji częściowo zamienia się w odtwarzanie wiedzy z rozmów, nie z plików, co go wydłuża, ale nie zatrzymuje. Zdarzyło się to zarówno w projekcie dla sektora bankowego, jak i medycznego opisanych wyżej, i w obu przypadkach udało się zbudować mapę systemu bez gotowej dokumentacji na starcie.

Czy to się w ogóle opłaca przy naprawdę małym systemie?

Pytanie o skalę jest zasadne, ale odpowiedź zależy od ryzyka, nie od liczby linii kodu. Mały system obsługujący płatności ma inny profil ryzyka niż duży system wewnętrzny bez kontaktu z pieniędzmi klienta, więc decyzja o audycie powinna wynikać z tego, co się stanie w razie błędu, nie z rozmiaru repozytorium.

Ile kosztuje audyt QA na start, zanim zapadnie decyzja o pełnym projekcie?

Zakres wyceniamy indywidualnie, bo zależy od liczby systemów i ich złożoności, ale sam audyt jest zawsze mniejszą, odrębną decyzją niż cały projekt testowy, właśnie po to, żeby firma mogła sprawdzić skalę specyfiki, zanim zaangażuje się w coś większego. Zakres audytu QA jest dobrym punktem startu do rozmowy o wycenie.

Powiązane na blogu Quality Island

• Build vs. buy: prawdziwy koszt zespołu QA in-house kontra dostawcy zewnętrznego
• Agentic testing: czy Wasza praca właśnie się zmienia, czy znika
• Audyt jakości oprogramowania

Pełna lista źródeł

• qualityisland.pl, dane firmowe: 350 000+ napisanych testów automatycznych, 152+ zrealizowanych projektów, 1600+ przeszkolonych specjalistów
• Case study klientów Quality Island: PKO BP, ChaosGears (zakres prac opisany w materiałach firmowych)