Jest taki moment w życiu zespołu, kiedy wszyscy mówią, że potrzebujemy lepszych testów. Albo że brakuje nam automatyzacji i musimy zatrudnić kogoś bardziej technicznego, bo inaczej nie dowieziemy jakości. I zwykle wtedy wchodzi na scenę bardzo logiczna, kusząca myśl: najlepszy tester to ten, który najwięcej potrafi w narzędzia, w kod, we frameworki, w API, w pipeline.
- Dlaczego najlepsi testerzy nie muszą być najlepsi technicznie
- Trzy supermoce świetnego testera
- Kiedy techniczność naprawdę ma znaczenie
- Jak rozpoznać świetnego testera na rozmowie
- Najczęstszy błąd zespołów: mylenie techniczności z wpływem
- Pięć ruchów, które to zmieniają bez rewolucji
- Co z tego wynika dla liderów
- Co mierzyć, żeby docenić wpływ, a nie aktywność
Tylko że z naszego doświadczenia to nie tak działa. Najlepsi testerzy, jakich spotkaliśmy w projektach, często nie byli najbardziej techniczni. Nie mieli najszybszych palców do pisania skryptów. Nie znali na pamięć wszystkich flag w Cypressie. A mimo to właśnie oni ratowali projekty przed katastrofami i błędami, które nie wyglądają jak bug w Jirze, tylko jak spadek konwersji, utrata zaufania, lawina zwrotów i komentarze „aplikacja jest zepsuta, nie polecam”.
Dlaczego najlepsi testerzy nie muszą być najlepsi technicznie
Techniczność jest łatwa do zmierzenia. Umiesz SQL, umiesz pisać testy API, umiesz automatyzować, znasz Dockera, potrafisz czytać logi. Można zrobić rozmowę, dać zadanie, ocenić wynik, opisać to w widełkach i siatce kompetencji. Tylko że jakość produktu bardzo rzadko psuje się dlatego, że ktoś nie znał konkretnego narzędzia. Psuje się częściej przez rzeczy miękkie, ale brutalnie realne: użytkownik nie rozumie komunikatu, proces rejestracji działa, ale budzi nieufność, kluczowa akcja kończy się ciszą zamiast potwierdzenia, a prawdziwe życie nie jest szczęśliwą ścieżką.
I tu pojawia się paradoks. Najlepsi testerzy to często ci, którzy nie wchodzą w produkt jak inżynier. Oni wchodzą jak człowiek, jak klient, jak ktoś, kto nie czyta specyfikacji, nie zna skrótów i nie ma cierpliwości. Właśnie dlatego widzą rzeczy, których nie widzi nikt inny.
Trzy supermoce świetnego testera
Pierwsza: myślenie scenariuszami, nie przypadkami testowymi. Słabszy tester sprawdza, czy pole przyjmuje 50 znaków. Dobry tester pyta, co się stanie, gdy użytkownik wpisze coś bez sensu, cofnie się, straci sieć, zmieni zdanie, przerwie w połowie i wróci za godzinę. Świetny tester widzi cały przepływ i to, gdzie rodzi się frustracja, błędne decyzje i porzucenie.
Druga: pytania, które wyłapują ryzyka, zanim staną się bugami. Nie chodzi o pytania typu „a co, jeśli pole będzie puste”, tylko o pytania dotykające sensu produktu: po czym użytkownik pozna, że operacja się udała, co jest obietnicą tej funkcji, kiedy system powinien odmówić, a kiedy pomóc, jakie konsekwencje ma jedna pomyłka w życiu użytkownika.
Trzecia: tłumaczenie. Świetny tester potrafi przełożyć problem jakości na język programistów, productu i biznesu. Nie mówi „jest błąd”. Mówi: tutaj użytkownik traci zaufanie, tutaj nie wie, co dalej, tutaj wsparcie dostanie falę zgłoszeń, tutaj ryzykujemy zwroty. To jest moment, w którym QA przestaje być rolą od testowania, a staje się partnerem w dostarczaniu produktu.
Źródło: metodyka i praktyka własna Quality Island z pracy z zespołami QA i rekrutacji testerów.
Kiedy techniczność naprawdę ma znaczenie
Żeby było jasne: technika ma znaczenie i są sytuacje, w których techniczna siła robi różnicę. Kiedy budujecie automatyzację end to end i chcecie, żeby nie była generatorem niestabilnych testów. Kiedy trzeba czytać logi, korelować żądania i rozumieć system rozproszony. Kiedy debugujecie integracje, asynchroniczność i zależności środowiskowe. Ale nawet wtedy techniczność jest środkiem, a nie celem. Ma wspierać decyzje o tym, co testować, gdzie ryzyko jest największe i jak chronić krytyczne ścieżki użytkownika. Jeśli zaczynacie od narzędzia, a nie od ryzyka, łatwo skończyć z piękną automatyzacją, która testuje nie to, co trzeba.
Jak rozpoznać świetnego testera na rozmowie
Da się to zrobić bez zadania z kodu. Poproście kandydata, żeby opisał, jak przetestuje prostą funkcję: rejestrację, koszyk, rezerwację albo zapisanie ustawień. Potem słuchajcie, czy zaczyna od pól i walidacji, czy od celu użytkownika. Czy myśli o przerwaniach, ryzykach, komunikatach, potwierdzeniach. Czy widzi miejsca, w których użytkownik się zgubi. Czy rozumie, co jest krytyczne dla biznesu. Najbardziej wiarygodne sygnały: kandydat potrafi opisać produkt oczami użytkownika, umie wskazać największe ryzyka bez znajomości całej dokumentacji, mówi o konsekwencjach zamiast o symptomach, proponuje minimum testów, które daje maksimum ochrony, i zadaje pytania ujawniające luki w wymaganiach.
Najczęstszy błąd zespołów: mylenie techniczności z wpływem
W wielu firmach QA rośnie przez automatyzację i to jest naturalne. Ale po drodze łatwo zacząć nagradzać tylko to, co widać w repozytorium: skrypty, frameworki, pokrycie, raporty. A pomijać to, co widać dopiero po czasie: dobre pytania na refinemencie, zatrzymanie złej decyzji przed wdrożeniem, ochronę kluczowych ścieżek, wykrycie ryzyka, którego nie było w ticketach. Efekt jest przewidywalny: zespół produkuje automatyzację, a jednocześnie przepuszcza defekty doświadczenia, bo nikt już nie ma przestrzeni, żeby patrzeć na produkt jak człowiek.
„Nie budujcie jakości tylko narzędziami. Budujcie ją sposobem myślenia o ryzyku i o użytkowniku. Narzędzia dopiero potem.”
Pięć ruchów, które to zmieniają bez rewolucji
Kultura jakości nie powstaje od razu. Buduje się w małych, powtarzalnych momentach, w których ktoś patrzy na funkcję jak użytkownik, a nie jak osoba znająca backlog. Nie musicie zmieniać narzędzi ani robić reorganizacji. Wystarczy zmienić kilka rytuałów i pytań.
Najlepsze w tym wszystkim jest to, że zmieniacie tylko to, na co patrzycie i jak o tym rozmawiacie. A jeśli zmieni się to, zmieni się też jakość. Bo jakość nie jest produktem ubocznym narzędzi. Jakość jest produktem ubocznym uwagi.
Co z tego wynika dla liderów
Jeśli macie poczucie, że QA u Was za bardzo kręci się wokół techniki, a za mało wokół realnej wartości, nie naprawiajcie tego wielkim programem transformacji. Zacznijcie od pięciu ruchów wyżej i od zmiany tego, co nagradzacie: obok skryptów w repozytorium doceniajcie zatrzymane złe decyzje i pytania, które ujawniły ryzyko przed kodem. W Quality Island pracujemy z zespołami dokładnie nad tym: przeglądy procesów QA, warsztaty strategii testów i ustawienie automatyzacji tak, żeby wspierała krytyczne ścieżki, a nie była celem samym w sobie.
- Jakość produktu rzadko psuje się przez brak znajomości narzędzia. Psuje się przez bariery, których nie widzi nikt patrzący jak inżynier.
- Trzy supermoce świetnego testera: myślenie scenariuszami, pytania o ryzyko przed kodem i tłumaczenie jakości na język decyzji.
- Techniczność ma znaczenie, ale jest środkiem: jeśli zaczynacie od narzędzia zamiast od ryzyka, automatyzacja testuje nie to, co trzeba.
- Na rozmowie rekrutacyjnej słuchajcie, czy kandydat zaczyna od pól i walidacji, czy od celu użytkownika.
- Pięć ruchów bez rewolucji: sesja ryzyk, trzy żelazne ścieżki, jedno pytanie na refinemencie, demo bez ułatwień, ticket opisany wpływem.
Jeśli chcecie, żeby QA w Waszej organizacji miało większy wpływ na produkt, a nie tylko wykonywało więcej testów, poukładajmy to razem: od przeglądu procesu po warsztaty strategii testów.
Sprawdźcie warsztaty QACo mierzyć, żeby docenić wpływ, a nie aktywność
Jeśli chcecie, żeby w zespole opłacało się być testerem z trzema supermocami, a nie tylko autorem skryptów, musicie zmienić to, co mierzycie. Miary aktywności (liczba testów, liczba zgłoszonych bugów, pokrycie) nagradzają produkcję artefaktów. Miary wpływu nagradzają ochronę ryzyka.
Cztery miary, które to robią. Pierwsza: defekty, które dotarły do klienta, liczone w krytycznych ścieżkach, nie ogółem. To jedyna liczba, która wprost mówi, czy ochrona działa. Druga: problemy zatrzymane przed kodem. Prowadzenie prostej listy sytuacji, w których pytanie na refinemencie zmieniło wymaganie albo ujawniło ryzyko, brzmi miękko, ale po kwartale ta lista jest najlepszym dowodem wpływu, jaki QA może położyć na stole. Trzecia: czas od zgłoszenia do naprawy dla defektów krytycznych, bo dobry opis wpływu i dowody skracają go bardziej niż jakiekolwiek narzędzie. Czwarta: stabilność trzech żelaznych ścieżek, mierzona po każdym wydaniu, jako proste przeszło albo nie.
I jedna rzecz, której nie mierzcie indywidualnie: liczby znalezionych bugów per osoba. Ta miara psuje wszystko, bo nagradza zgłaszanie drobnicy i karze osobę, która spędziła dzień na zatrzymaniu złej decyzji, zanim powstał kod. Jakość jest wynikiem zespołu, a rola świetnego testera polega właśnie na tym, że część jego najlepszej pracy nie zostawia śladu w liczniku defektów. Zostawia ślad w tym, czego użytkownik nigdy nie zobaczył.
Na koniec wątek, o który pytają liderzy najczęściej: co z juniorami, skoro supermoce brzmią jak doświadczenie. Dobra wiadomość jest taka, że te trzy kompetencje da się ćwiczyć od pierwszego tygodnia pracy, w przeciwieństwie do intuicji, która faktycznie wymaga lat. Junior może od pierwszego sprintu opisywać defekty przez wpływ, a nie symptom. Może przechodzić produkt na koncie bez ułatwień i notować, gdzie się pogubił, bo świeże oko jest tu przewagą, nie brakiem. Może zadawać na refinemencie jedno pytanie o to, skąd użytkownik pozna sukces. Zespół, który tego wymaga i to docenia od początku, wychowuje testerów z wpływem w dwa lata. Zespół, który przez dwa lata rozlicza juniora wyłącznie z liczby wykonanych przypadków testowych, wychowuje operatora checklisty i potem dziwi się, że automatyzacja go zastępuje.
Powiązane na Strefie QA
- „Nie jestem techniczny”, czyli 3 mity, które blokują Cię przed karierą QA
- Zarządzanie jakością. Czyli dlaczego system jest ważniejszy niż ludzie
- QA + UX: co może się wydarzyć, gdy rozmawiają
Źródła:
- Metodyka i praktyka własna Quality Island z pracy z zespołami QA, rekrutacji testerów i warsztatów strategii testów
- Warsztaty QA dla zespołów i liderów, Quality Island
- Audyt QA i przegląd procesu testowego, Quality Island
