Dlaczego wiedza domenowa to supermoc testerów?

Junior wchodzi do projektu, dostaje swój pierwszy ticket i pracuje uczciwie, krok po kroku. Kliknięcia pasują do kryteriów akceptacji, payload w API wygląda jak w przykładowym requestcie, a UI wyświetla to, co miało wyświetlać. A jednak po wdrożeniu klienci zgłaszają problemy, o których w ogóle nie pomyśleliśmy. Nie dlatego, że tester coś „pominął”, tylko dlatego, że testował ticket, a nie produkt. Brakowało mu kontekstu, który pozwala zobaczyć dalej niż to, co jest zapisane w story.

Ten problem świetnie opisała autorka artykułu Know the Product, Own the Quality: Why Product Knowledge is a QA Superpower (and How to Do It) - a teraz ja przybliżę Ci najważniejsze wnioski płynące z jej tekstu. Choć, oczywiście, zachęcam też do odwiedzenia źródła.

Testujesz ticket czy chronisz produkt?

Wiedza domenowa nie jest żadnym „dodatkiem” do roli QA. To filtr, przez który patrzysz na ryzyko. I gdy go nie masz, nawet najlepsze testy eksploracyjne zamieniają się w zgadywanie. Podejmujesz decyzje o priorytetach w ciemno, bo nie widzisz konsekwencji. A kiedy filtr się pojawia, nagle zaczynasz dostrzegać miejsca, gdzie użytkownik utknie, gdzie biznes straci pieniądze, a gdzie automatyzacja przykryje problem tylko na chwilę.

Najłatwiej to poczuć przy rzeczach, które pozornie są banalne. Weźmy kupon rabatowy w e-commerce. Ticket mówi: „10% zniżki dla koszyka powyżej 200 zł”. Tester bez wiedzy domenowej sprawdzi poprawność obliczeń, działanie kodu, komunikaty o błędach. I wszystko będzie grało. Tester z produktem w głowie zaczyna inaczej. Pyta, jak rabat wpływa na API płatności, czy nalicza się po stronie backendu, czy front ma logikę, czy to będzie widoczne w analityce, czy można to nadużyć w koszykach splitowanych, jak zachowują się promocje skumulowane, a co jeśli user ma walutę inną niż domyślna. Niby ten sam ticket, ale zakres testów zmienia się o rząd wielkości.

To właśnie ta różnica sprawia, że tester przestaje być wykonawcą przypadków testowych, a zaczyna być partnerem decyzji. Pojawia się shift-left: QA wchodzi w refinementy, zadaje pytania o scenariusze brzegowe, proponuje testowalność jeszcze zanim powstanie linijka kodu. Zespół zyskuje nie tylko testy, ale też kompas jakości, o którym wspominałem kiedyś, pisząc o pojedynczym testerze w projekcie.

Wiedza domenowa = lepsza priorytetyzacja ryzyka

W praktyce największa zmiana pojawia się wtedy, gdy trzeba zdecydować, co testować najpierw. Bez wiedzy domenowej łatwo popaść w pułapkę „najpierw proste rzeczy”, albo w klasyczne „idziemy po kryteriach akceptacji”. I tu pojawia się problem: kryteria mówią tylko, co miało działać. Nie mówią, co jest naprawdę ważne dla użytkownika i biznesu. Jeśli rozumiesz produkt, wiesz, że błąd w obliczeniach rabatu kosztuje firmę realne pieniądze, a UI glitch na tooltipie raczej nie. Widzisz, że zmiana w logowaniu może całkiem wywrócić analitykę, sesje albo model płatności. I to zmienia sposób myślenia o ryzyku - zamiast „czy działa?”, myślisz „kogo to dotknie i jak mocno?”.

Wiedza domenowa działa tu jak mapa nawigacyjna. Przestajesz chodzić po systemie na ślepo i zaczynasz celować w miejsca, które mają największy wpływ. To nie jest magia ani doświadczenie seniora. To tylko zrozumienie, co tak naprawdę dostarczacie jako produkt, a nie jako zbiór ticketów.

Tester, który widzi skutki zmian, zanim powstanie kod

Kiedy już czujesz domenę, zaczynasz widzieć powiązania między pozornie odległymi elementami systemu. Zmiana w koszyku? Myślisz o dostawach, stockach i podatkach. Zmiana w logowaniu? O refresh tokenach, analityce i sesjach. Zmiana w promocjach? O płatnościach, fraudach i raportach. To właśnie moment, w którym QA realnie wpływa na decyzje projektowe. Czasem poprzez jedno pytanie typu „czy ta promocja może się nakładać na istniejące”, które oszczędza zespołowi wiele godzin późniejszego gaszenia pożarów.

Ta umiejętność nie wynika z technikaliów. To czysta wiedza produktowa. I właśnie dlatego sprawdza się niezależnie od stacku, frameworka czy technologii.

7-dniowy plan wejścia w domenę

Autorka tekstu stworzyła też praktyczną checklistę, która pomoże Ci wdrożyć plan zdobycia wiedzy domenowej w życie:

• Dzień 1 - Zrozum „Dlaczego”: Spotkaj się z Product Managerem, przejrzyj zgłoszenia i samodzielnie przeklikaj aplikację, aby zrozumieć jej wartość dla użytkownika.

• Dzień 2 - Zmapuj system: Rozrysuj schemat architektury, usług i zależności, identyfikując przy tym krytyczne punkty awarii.

• Dzień 3 - Zidentyfikuj ryzyka: Przeanalizuj główne ścieżki użytkownika i oceń ryzyka pod kątem prawdopodobieństwa wystąpienia oraz ich wpływu na biznes.

• Dzień 4 - Dane i telemetria: Przeanalizuj logi i metryki, aby poznać rzeczywiste zachowania użytkowników oraz najczęstsze błędy produkcyjne.

• Dzień 5 - Zdefiniuj wyrocznie: Ustal konkretne i mierzalne kryteria sukcesu (w UI, bazie danych lub logach) dla sprawdzanych funkcjonalności.

• Dzień 6 - Stwórz karty testowe: Przygotuj scenariusze testów eksploracyjnych, które wykraczają poza standardowe happy pathy.

• Dzień 7 - Testuj i omawiaj: Przeprowadź sesję testową z deweloperem lub PM-em i wspólnie omówcie wnioski oraz luki w jakości.

Dlaczego to wszystko ma znaczenie?

Wiedza domenowa jest najtańszą i najszybszą supermocą QA, bo nie wymaga żadnych narzędzi. Wymaga tylko ciekawości, rozmowy z zespołem i spojrzenia poza ticket. Z nią przestajesz „odhaczać kryteria”, a zaczynasz chronić to, co naprawdę ważne. Produkt, użytkownika i decyzje biznesowe. A w efekcie rośniesz jako QA Engineer, który nie tylko reaguje, ale przede wszystkim przewiduje.

Chcesz być na bieżąco? Zapisz się do newslettera!

Polecane wpisy:

Sprawdź też moje social media: