Najlepsi testerzy, których znałem, nie byli najlepsi technicznie

Najlepsi testerzy, których znałem, nie byli najlepsi technicznie

Jest taki moment w życiu zespołu, kiedy wszyscy mówią, że potrzebujemy lepszych testów. Albo że brakuje nam automatyzacji. Albo że musimy zatrudnić kogoś bardziej technicznego, bo inaczej nie dowieziemy jakości. I zwykle wtedy wchodzi na scenę bardzo logiczna, bardzo kusząca myśl: najlepszy tester to ten, który najwięcej umie w narzędzia, w kod, w frameworki, w API, w chmurę, w pipeline. Tylko że z mojego doświadczenia to nie tak działa. Najlepsi testerzy, jakich spotkałem, często nie byli najbardziej techniczni. Nie mieli najszybszych palców do pisania skryptów. Nie wygrywali konkursu na najładniejszy kod w Playwright. Nie znali na pamięć wszystkich flag w Cypress. Czasem nawet nie byli osobami, do których zwracasz się, gdy pada CI i trzeba gasić pożar. A mimo to to właśnie oni ratowali projekty przed katastrofami, które naprawdę bolą. Przed błędami, które nie wyglądają jak bug w Jirze, tylko jak spadek konwersji, utrata zaufania, lawina zwrotów i komentarze w stylu 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 Docker, potrafisz czytać logi. Można zrobić rozmowę, dać zadanie, ocenić wynik. Można to nawet opisać w widełkach, w siatce kompetencji i w ścieżce kariery. 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, aplikacja nie wybacza błędu i nie prowadzi dalej, a prawdziwe życie nie jest happy path. 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 supermoc to 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 supermoc to zadawanie pytań, 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, co oznacza sukces i porażka, kiedy system powinien odmówić, a kiedy pomóc, jakie konsekwencje ma jedna pomyłka w życiu użytkownika. Trzecia supermoc to tłumaczenie. Świetny tester potrafi przełożyć problem jakości na język devów, productu i biznesu. Nie mówi jest błąd. Mówi tutaj użytkownik traci zaufanie, tutaj nie wie, co dalej, tutaj support dostanie fale zgłoszeń, tutaj ryzykujemy zwroty albo churn. To jest moment, w którym QA przestaje być rolą od testowania, a staje się partnerem w dostarczaniu produktu.

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 budujesz automatyzację end to end i chcesz, żeby nie była generatorem flaków. Kiedy musisz czytać logi, korelować requesty i rozumieć, co się dzieje w systemie rozproszonym. Kiedy debugujesz integracje, asynchroniczność, webhooks i zależności środowiskowe. Kiedy Twoja organizacja chce mieć testy jako element platformy jakości, a nie tylko zestaw skryptów. Ale nawet wtedy techniczność jest środkiem, a nie celem. Technika ma wspierać decyzje o tym, co testować, gdzie ryzyko jest największe i jak najlepiej chronić krytyczne ścieżki użytkownika. Jeśli zaczynasz 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ś kandydata, żeby opisał, jak przetestuje prostą funkcję, na przykład rejestrację, koszyk, rezerwację albo zapisanie ustawień. Potem słuchaj, czy zaczyna od pól i walidacji, czy od celu użytkownika. Czy myśli o przerwaniach, o ryzykach, o komunikatach, o potwierdzeniach. Czy widzi miejsca, w których użytkownik się zgubi. Czy rozumie, co jest krytyczne dla biznesu. Jeśli chcesz mieć krótką ściągę, to tu jest lista sygnałów, które dla mnie są najbardziej wiarygodne.

• Potrafi opisać produkt oczami użytkownika, a nie oczami specyfikacji
• Umie wskazać największe ryzyka bez poznania całej dokumentacji
• Mówi o konsekwencjach, a nie tylko o symptomach
• Potrafi zaproponować minimum testów, które daje maksimum ochrony
• Zadaje pytania, które ujawniają niejasności i 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 popełnić błąd: nagradzać tylko to, co widać w repozytorium, czyli skrypty, frameworki, coverage, raporty. A pomijać to, co widać dopiero po czasie: dobre pytania na refinement, zatrzymanie złej decyzji przed wdrożeniem, ochrona kluczowych ścieżek, poprawa komunikatów, uproszczenie flow, wykrycie ryzyka, którego nie było w ticketach. Efekt jest przewidywalny. Zespół zaczyna produkować automatyzację, a jednocześnie przepuszcza defekty doświadczenia, bo nikt już nie ma przestrzeni, żeby patrzeć na produkt jak człowiek. Jeśli miałbym dać jedną radę liderom QA i productu, to brzmiałaby tak: nie budujcie jakości tylko narzędziami. Budujcie ją sposobem myślenia o ryzyku i o użytkowniku. Narzędzia dopiero potem.

Jak to wdrożyć w zespole bez rewolucji

Jeśli masz wrażenie, że u Was QA za bardzo kręci się wokół techniki, a za mało wokół realnej wartości, nie próbuj tego naprawiać wielkim programem transformacji. Najczęściej wystarczy zmienić kilka rytuałów i kilka pytań, które zespół zadaje regularnie. Bo kultura jakości nie powstaje od razu. Ona się buduje w małych powtarzalnych momentach, w których ktoś patrzy na funkcję jak użytkownik, a nie jak osoba, która zna backlog.

Zacznij od krótkiej, tygodniowej sesji ryzyk. Nie planowania testów, nie przeglądu regresji, tylko ryzyk. Piętnaście minut, raz w tygodniu, najlepiej na początku sprintu albo zaraz po planowaniu. Pytanie jest jedno: co w tym sprincie może uderzyć w użytkownika i biznes. I tu ważna zasada: ryzyko nie musi być techniczne. Ryzykiem jest też niejasny komunikat. Ryzykiem jest flow, w którym użytkownik nie wie, co dalej. Ryzykiem jest krok, który wygląda jak błąd, choć formalnie jest poprawny. Po dwóch trzech tygodniach zobaczysz, że zespół zaczyna myśleć o jakości wcześniej, a nie dopiero wtedy, gdy testy już płoną na końcu.

Drugi ruch to przejście z myślenia liczbą testów na myślenie krytycznymi ścieżkami. Zamiast mieć ambicję zrobić dwadzieścia testów, wybierz trzy przepływy, które jeśli padną, zrobią realną krzywdę. W większości produktów to będzie coś w stylu wejście do wartości, konwersja i powrót. I teraz sedno: te trzy przepływy mają być żelazne. Nie piękne. Nie idealnie zautomatyzowane. Żelazne. Takie, które są sprawdzone w realistycznych warunkach, z danymi, które mają sens, i z komunikatami, które człowiek rozumie. Reszta może poczekać, bo w MVP i w szybko zmieniającym się produkcie jakość nie rośnie przez ilość, tylko przez ochronę tego, co krytyczne.

Trzeci ruch to jedno pytanie, które dodajesz do refinementu i które w magiczny sposób wyłapuje połowę problemów zanim staną się bugami. Skąd użytkownik będzie wiedział, że to zadziałało. To pytanie brzmi banalnie, ale ono dotyka potwierdzeń, stanów, komunikatów i spójności flow. Jeśli nikt nie potrafi odpowiedzieć, to masz ryzyko jakości, nawet jeśli kod będzie perfekcyjny. Jeśli odpowiedź brzmi użytkownik zobaczy sukces, ale nikt nie wie, jak ten sukces wygląda, to masz ryzyko jakości. A jeśli odpowiedź brzmi nie wiem, to właśnie uratowałeś sprint przed oddaniem funkcji, która będzie działać, ale będzie wyglądać jak zepsuta.

Czwarty ruch to zmiana sposobu, w jaki robicie demo. Zamiast pokazywać funkcję jak prezentację, raz na jakiś czas zrób demo jak test użytkownika. Ktoś z zespołu, najlepiej nie autor, przechodzi flow na żywo, bez skrótów, bez dopowiedzeń, bez przeskakiwania niewygodnych momentów. I tu jest dodatkowy trik: przechodzicie flow na koncie, które nie ma ułatwień. Bez roli admina, bez włączonych flag, bez danych, które tylko dev ma na swoim środowisku. Ten prosty zabieg sprawia, że nagle zaczynacie widzieć rzeczy, które normalnie są niewidzialne. Brak potwierdzenia. Niezrozumiałe copy. Stan po odświeżeniu. Ekran, z którego nie wiadomo jak wyjść. To są te problemy, które zabijają produkt, choć nie zawsze wyglądają jak bug.

Piąty ruch to wprowadzenie prostego standardu opisu defektu, który wymusza myślenie o wpływie, a nie tylko o symptomie. Jeśli dziś w ticketach widzisz hasła typu nie działa albo błąd na ekranie, to zespół będzie je traktować jak drobiazg. Zmień to na format, który ma trzy elementy: co robi użytkownik, co widzi, co to robi biznesowo. I nie chodzi o wielkie elaboraty. Chodzi o jedno zdanie kontekstu, które sprawia, że dev i product widzą, po co to poprawiać. Kiedy taki nawyk wejdzie, QA zaczyna mieć większy wpływ, bo problemy są komunikowane w języku decyzji.

Jeśli chcesz mieć małą ściągę do wdrożenia, to oto zestaw działań, które w wielu zespołach robią różnicę już po dwóch sprintach.

• Raz w tygodniu 15 minut sesji ryzyk, skupionej na użytkowniku i biznesie
• Trzy krytyczne ścieżki w sprincie, które mają być żelazne, a nie liczne
• Jedno pytanie na refinement: skąd użytkownik wie, że to zadziałało
• Demo jako przejście flow przez osobę, która tego nie budowała, bez skrótów
• Ticket defektu opisany przez wpływ, a nie przez sam symptom

Najlepsze w tym wszystkim jest to, że nie musisz zmieniać narzędzi, nie musisz przepisywać automatyzacji i nie musisz robić reorganizacji zespołu. Zmieniasz 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.

Jeśli chcesz, żeby QA w Twojej organizacji miało większy wpływ na produkt, a nie tylko większą liczbę testów, możemy w Quality Island pomóc Ci to poukładać. Robimy przeglądy procesów QA, warsztaty strategii testów i pracujemy z zespołami nad tym, żeby automatyzacja wspierała krytyczne ścieżki, a nie była celem samym w sobie. Jeśli masz poczucie, że jakość u Was kosztuje za dużo albo daje za mało, odezwij się, a przejdziemy przez to na Twoim przykładzie.