Harness engineering

Autor wpisu, który zainspirował ten artykuł, jest jedynym testerem w zespole agile, a mimo to nie pisze przypadków testowych ani nie przeklikuje aplikacji. Zamiast tego zajmuje się tworzeniem skilli dla narzędzia Claude Code, z którego korzystają deweloperzy. Równolegle utrzymuje on swój własny "QA harness", czyli zestaw narzędzi, konfiguracji i reguł, dzięki którym jego agent wie, jak i co sprawdzać w konkretnym projekcie czy SDLC. Według jego deklaracji, mimo braku nowych etatów w testach zespół ma dowozić dwa i pół raza więcej historyjek niż jeszcze rok temu. Liczba ta jest oczywiście tylko deklaracją, ale sam opis pracy brzmi wiarygodnie – i właśnie dlatego postanowiliśmy poświęcić mu trochę uwagi. 

Na cały ten wątek należy patrzeć z perspektywy ewolucji roli testera oprogramowania do inżyniera AI, z jednoczesnym uwzględnieniem ryzyk związanych z odsunięciem testera od jego klasycznych obowiązków. 

Oryginalny wpis zamieszczamy poniżej:

Cztery szczeble

Sam autor podzielił swoją pracę na cztery etapy: najpierw dopracowywanie promptów, potem tworzenie MCP, dalej generowanie skilli, a na końcu tzw. harness engineering. Problem jednak w tym, że z każdym kolejnym etapem tester znajduje się o krok dalej od aplikacji, którą przecież formalnie testuje. 

Na samym początku tester uczy się rozmawiać z modelem i dopracowuje polecenia. Krok drugi to podłączenie narzędzia do systemów – Jiry, dokumentacji i środowiska testowego. Na trzecim szczeblu odchodzi od pojedynczych promptów na rzecz skilli, czyli trwałych procedur odtwarzanych przez agenta automatycznie według tego samego wzoru. Czwarty etap domyka ten proces: harness buduje pełne ramy pracy. To on określa uprawnienia agenta, automatyczne testy po deploymencie oraz wymogi dotyczące dokumentacji niezbędnej do zamknięcia zadania. 

Zwróćcie uwagę, co w tym procesie dzieje się z samym obiektem testów. Tester zaczyna od bezpośredniego sprawdzania systemu, a kończy jako ktoś, kto konstruuje i kalibruje maszynę wykonującą testy, a jego własna praca sprowadza się do nadzorowania tego narzędzia. 

Zawód spoza sylabusa

Próżno szukać takiego stanowiska w sylabusach ISTQB®. Cały system certyfikacji działa w tempie komitetowym, więc zanim jakikolwiek sylabus zostanie zrecenzowany i przetłumaczony, rzeczywistość rynkowa znajduje się już o parę generacji narzędzi dalej. Certyfikacja CTFL wciąż uczy tworzenia przypadków testowych, czyli zadania, które w tym zespole przejmuje agent. Tymczasem tester tworzący skille dla sztucznej inteligencji zajmuje się czymś, czego certyfikacyjne programy nie zdążyły jeszcze nawet nazwać. 

Problem z określeniem tej roli ma także HR. Oferty pracy dla testerów wciąż krążą wokół Selenium, Playwrighta, i "mile widzianej znajomości CI/CD". Tymczasem opisane wyżej kompetencje (projektowanie procedur dla agentów, wyznaczanie granic ich działania czy dbanie o infrastrukturę wokół modelu) wymykają się tradycyjnym etykietom i nazewnictwu, i nie pasują w pełni ani do testera automatyzującego, ani do inżyniera DevOps. Autor wpisu formalnie nadal zajmuje etat testera, ale tylko na papierze. Nazwa w umowie pozostała, ale treść tej pracy to już zupełnie inna bajka. 

Odpowiedzialność 

W całej tej zmianie najbardziej ciekawi zmiana zakresu odpowiedzialności. Tradycyjny tester rozliczany był z konkretnego efektu: wykrył defekt albo go przeoczył. Ktoś, kto projektuje i utrzymuje harness, bierze na siebie odpowiedzialność za samą maszynę testującą. Błąd w jednym teście kosztuje najwyżej pojedynczego przepuszczonego buga. Pomyłka w harnessie – w skillu, konfiguracji czy w samych założeniach pracy agenta – powiela się systematycznie przy każdym uruchomieniu. Przejście od roli wykonawcy do roli konstruktora przynosi więc także większą skalę ewentualnej pomyłki. 

I tu dochodzimy do pytania, na które w tym wpisie nie znajdziemy odpowiedzi. Autor twierdzi, że jego zespół testuje teraz "głębiej, szerzej i szybciej". Być może tak jest. Sęk w tym, że głębokość testowania mierzona przez harness jest tylko tak dobra, jak założenia człowieka, który go stworzył. A tych założeń nikt z zewnątrz przecież nie weryfikuje. 

W zespole pracuje jeden tester. Kod deweloperów przechodzi tradycyjne code review, jednak skille i harness, przez które przepływa cała wiedza zespołu o jakości, trafiają do produkcji bez takiej kontroli. Bardzo możliwe, że patrzymy właśnie na rzeczywisty kierunek rozwoju branży. Możliwe też, że oglądamy klasyczny pojedynczy punkt awarii, który po prostu jeszcze nie zdążył dać o sobie znać. 

Nie da się dziś rozstrzygnąć, czy harness engineering to narodziny nowej roli, czy odosobniony przypadek kogoś, kto dostał wolną rękę i cierpliwego klienta. Póki co to po prostu praca, która wyprzedza jakiekolwiek oficjalne nazwy, opisy i programy szkoleniowe. Historia testowania zna zresztą ten moment: automatyzacja też była najpierw fanaberią kilku osób, a dopiero z czasem stała się standardem w ogłoszeniach. 

Pytanie tylko, kto tym razem napisze sylabus – i czy zdąży, zanim treść tego zawodu znowu się zmieni.