Nawyk, który odróżnia testera w rozwoju od testera, który stoi w miejscu
Trzy pytania, które warto zadać przed otwarciem aplikacji
Znam sporo testerów z podobnym stażem, podobnymi narzędziami w CV i podobnymi projektami za sobą, a mimo to ich ścieżki rozjeżdżają się dramatycznie. Jedna osoba po dwóch latach prowadzi rozmowy o strategii testów i ma realny wpływ na produkt, druga wciąż robi dokładnie to samo, co pierwszego miesiąca. Długo myślałem, że różnica siedzi w narzędziach, frameworkach albo certyfikatach - i długo się myliłem.
Różnica siedzi w jednym nawyku, który kosztuje jakieś pięć minut dziennie: zadawaniu pytań, zanim zaczniesz testować. Brzmi banalnie, wiem. Ale kiedy przyjrzysz się, jak dwie osoby podchodzą do tego samego ticketa, ten banał zamienia się w przepaść, która z każdym sprintem tylko rośnie.
Dwa podejścia do tego samego ticketa
Tester, który stoi w miejscu, dostaje ticket i zaczyna klikać. Otwiera aplikację, przechodzi ścieżkę opisaną w wymaganiu, sprawdza, czy przycisk robi to, co miał robić. Jeśli działa - zamyka taska i bierze kolejny. Jeśli nie działa - zgłasza buga i czuje, że wykonał swoją robotę.
Tester, który rośnie, zatrzymuje się na pięć minut, zanim w ogóle dotknie aplikacji. W tym czasie zadaje sobie kilka pytań: co tu może pójść nie tak dla użytkownika? Jakie dane wejściowe są krytyczne? Gdzie jest ryzyko biznesowe - co się stanie, jeśli to się wysypie na produkcji? Dopiero z odpowiedziami w głowie siada do testowania, bo teraz wie, czego szuka.
Na pierwszy rzut oka to drobiazg, który nie powinien robić różnicy. W praktyce to zmiana kierunku uwagi - z "czy działa" na "co może nie działać i ile to kosztuje" - i ta zmiana przestawia całe testowanie na inne tory. Pierwsze podejście weryfikuje wymaganie, drugie bada ryzyko, a to są dwie różne dyscypliny, choć z zewnątrz wyglądają identycznie.
Dlaczego "czy działa" to za mało
Sprawdzenie, czy funkcja działa zgodnie z opisem w tickecie, to najniższy poziom wartości, jaką tester może wnieść do projektu. Nie dlatego, że jest nieważne - regresja i weryfikacja wymagań muszą się dziać. Problem w tym, że ten poziom coraz częściej pokrywają automaty, a w erze AI generowanie testów pod happy path trwa sekundy.
To, czego automat nie zrobi, to ocena konsekwencji. Formularz płatności może "działać" w rozumieniu ticketa i jednocześnie wywalić się przy przerwanej autoryzacji, timeout'cie bramki albo podwójnym kliknięciu w przycisk "zapłać". Żadne z tych zachowań nie jest opisane w wymaganiu, bo wymagania prawie nigdy nie opisują scenariuszy awaryjnych. Ktoś musi o nie zapytać, zanim znajdzie je klient na produkcji.
I tu wracamy do tych pięciu minut. Pytanie "co jeśli to się wysypie na produkcji?" zmusza do myślenia o koszcie błędu - czy chodzi o brzydko wyświetlony tooltip, czy o zablokowane zamówienia i telefon od klienta o 22:00. Ta ocena decyduje, gdzie włożyć wysiłek testowy, a umiejętność jej przeprowadzenia jest dokładnie tym, za co projekty płacą doświadczonym testerom.
Playwright Starter Pack - zacznij od gotowych fundamentów 🎯
Największy czas w automatyzacji nie ginie na pisanie testów, tylko na research - jaką strukturę projektu wybrać, jak ułożyć Page Object Model, żeby nie rozjechał się po trzech sprintach, i jak w ogóle zabrać się za Playwrighta z głową.
Playwright Starter Pack to konkretny punkt wyjścia: sprawdzona struktura projektu, przykładowe testy i checklista dobrych praktyk, które normalnie zbiera się metodą prób i błędów przez pierwsze miesiące pracy z narzędziem.
Trzy pytania, od których warto zacząć
Nie potrzebujesz rozbudowanego frameworka do analizy ryzyka, żeby zacząć. Wystarczą trzy pytania zadane przed każdym ticketem, konsekwentnie, przez kilka tygodni. Z czasem wejdą Ci w krew tak, że przestaniesz je zauważać.
Pierwsze: co tu może pójść nie tak dla użytkownika? Nie dla wymagania, nie dla systemu - dla człowieka, który będzie z tego korzystał w biegu, na słabym internecie, z niecierpliwością w palcach. To pytanie otwiera scenariusze, których nie ma w dokumentacji: przerwane sesje, cofanie przeglądarką, wklejanie danych zamiast wpisywania.
Drugie: jakie dane wejściowe są krytyczne? Każda funkcja ma dane, na których stoi - kwoty, daty, identyfikatory, pliki. Warto wiedzieć, które z nich mogą przyjść puste, za długie, w złym formacie albo z innej strefy czasowej, bo to tam zwykle mieszkają bugi, które bolą.
Trzecie: gdzie jest ryzyko biznesowe? Czyli co się realnie stanie, jeśli ta funkcja padnie na produkcji - kto straci pieniądze, kto straci dane, kto zadzwoni z pretensjami. Odpowiedź na to pytanie ustawia priorytety całej sesji testowej i pozwala bronić swoich decyzji na retro, kiedy ktoś zapyta, czemu nie zdążyłeś przetestować wszystkiego.
Myślenie o ryzyku przed bugiem, nie po nim
Najciekawsza w tym wszystkim jest kolejność. Tester, który kręci się w kółko, też myśli o ryzyku - tyle że dopiero po znalezieniu buga, kiedy pisze zgłoszenie i zastanawia się nad priorytetem. Tester, który się rozwija, robi tę samą analizę przed testowaniem, dzięki czemu bug nie jest przypadkowym znaleziskiem, tylko potwierdzeniem hipotezy.
Ta kolejność zmienia sposób, w jaki postrzega Cię zespół. Osoba, która zgłasza losowo znalezione bugi, jest wykonawcą - potrzebnym, ale wymienialnym. Osoba, która na refinemencie pyta "co powinno się stać, jeśli użytkownik przerwie płatność w trakcie autoryzacji?", zanim ktokolwiek napisał linijkę kodu, jest partnerem w projektowaniu produktu. To jest shift-left w praktyce: jakość zaczyna się od pytań na etapie wymagań, a nie od klikania po wdrożeniu na środowisko testowe.
Widzę to też po drugiej stronie - w tym, jak takie osoby korzystają z AI. Tester bez nawyku pytania bierze od modelu sto wygenerowanych przypadków testowych i odpala je jak leci. Tester z nawykiem pytania patrzy na tę listę i w minutę zauważa, że żaden scenariusz nie dotyka krytycznej integracji, bo model nie zna kontekstu biznesowego projektu. Narzędzia są te same, różnica siedzi w głowie.
Od czego zacząć jutro rano
Jeśli chcesz sprawdzić ten nawyk na sobie, nie zmieniaj wszystkiego naraz. Weź jutro pierwszy ticket z brzegu i zanim otworzysz aplikację, zapisz odpowiedzi na trzy pytania z tego tekstu - dosłownie w notatniku, po jednym zdaniu na pytanie. Zapisanie jest ważne, bo zmusza do konkretu i zostawia ślad, do którego możesz wrócić.
Po dwóch tygodniach porównaj swoje sesje testowe z tymi sprzed eksperymentu. Zwróć uwagę, ile znalezionych bugów pochodziło ze scenariuszy, które przewidziałeś w notatkach, a ile z przypadku. U większości osób, które namówiłem na ten eksperyment, proporcje zaskakują - i to one najlepiej pokazują, że pięć minut myślenia przed testowaniem zwraca się szybciej niż kolejny kurs narzędziowy.
Dwie osoby, podobny staż, podobne narzędzia, a zupełnie inna trajektoria - bo jedna myśli o ryzyku, zanim zacznie, a druga dopiero wtedy, gdy bug sam wpadnie jej w ręce. Po której stronie tej różnicy jesteś dzisiaj, zależy wyłącznie od tego, co zrobisz z najbliższym ticketem.
Przestań składać wiedzę o Playwright + AI z przypadkowych źródeł 🤖
Można uczyć się metodą "obejrzę dziesięć różnych tutoriali i sam poskładam całość", tylko że w praktyce zajmuje to tygodnie, a i tak zostają dziury - zwłaszcza tam, gdzie AI zaczyna generować kod, którego nie rozumiesz.
Mini-kurs Playwright + AI prowadzi Cię krok po kroku: od fundamentów frameworka, przez świadome korzystanie z AI przy pisaniu testów, po budowę stabilnego, skalowalnego projektu automatyzacji.
Polecane wpisy:
Sprawdź też moje social media:
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
Kontakt
kontakt@rwasik.pl