Czym się różni Junior QA od Mida QA?
"Junior nie wie czemu nie działa. Mid nie wie czemu działa 😉"
Ostatnio zapytałem na Instagramie: co według Was odróżnia Juniora od Mida QA? Odpowiedzi było sporo, a uwagi dotykały różnych aspektów pracy - od samodzielności, przez komunikację, aż po podejście do własnej niewiedzy. I to jest chyba najciekawszy wniosek z tej ankiety: awans z Juniora na Mida prawie nikomu nie kojarzy się z liczbą przeklikanych scenariuszy ani znajomością kolejnego narzędzia.
Bo różnica między Juniorem a Midem rzadko leży w technikaliach. Junior potrafi napisać test w Playwright, zna Postmana, ogarnia DevTools - i Mid robi dokładnie to samo. Różnica siedzi gdzie indziej: w sposobie myślenia o zadaniu, o ryzyku i o własnej roli w zespole. Wybrałem cztery odpowiedzi ze społeczności, które moim zdaniem najlepiej to pokazują, i do każdej dorzucam swoją perspektywę.
Samodzielność - ale rozumiana właściwie
Ta odpowiedź pojawiła się najczęściej i chyba nikogo to nie dziwi. Junior potrzebuje prowadzenia: dostaje zadanie z opisanym kontekstem, ktoś podpowiada mu, na co zwrócić uwagę, a efekty jego pracy ktoś jeszcze weryfikuje. Mid powinien samodzielnie ogarnąć zadanie od analizy wymagań, przez zaplanowanie testów, aż po raportowanie wyników - i to bez pilnowania z zewnątrz.
Warto jednak doprecyzować, czym ta samodzielność jest, bo łatwo ją źle zrozumieć. Samodzielność to nie postawa "wszystko robię sam(-a) i nikogo o nic nie pytam", tylko umiejętność oceny, kiedy działać, a kiedy zapytać. Mid, który utknął na dwie godziny i milczy, wcale nie jest samodzielny - jest po prostu nieefektywny. Prawdziwa samodzielność objawia się tym, że wiesz, które decyzje możesz podjąć w pojedynkę, a które wymagają konsultacji z devem, Product Ownerem czy innym testerem.
W praktyce wygląda to tak: Junior pyta "jak mam to przetestować?", a Mid przychodzi z gotowym planem i pyta "czy czegoś w tym podejściu nie pomijam?". Pytanie zadają oboje, ale jego jakość jest zupełnie inna. I właśnie po jakości pytań często najszybciej poznasz, na jakim etapie ktoś jest.
Proaktywność i przepływ informacji
Druga odpowiedź dotyczyła proaktywności. Mid nie czeka, aż ktoś powie mu, co sprawdzić - sam wychodzi z inicjatywą, zgłasza się do refinementów i sygnalizuje wątpliwości, zanim staną się problemem. Junior zwykle porusza się w ramach tego, co dostał w tickecie, i to jest na tym etapie zupełnie normalne.
Jest jednak drugi wymiar proaktywności, o którym mówi się rzadziej: przepływ informacji. Mid dba o to, żeby informacja o ryzyku dotarła do właściwej osoby i we właściwym czasie. Znalezienie buga to dopiero połowa roboty. Jeśli wiesz, że dana zmiana może rozjechać płatności, a informacja o tym utknie w komentarzu pod taskiem, którego nikt nie czyta, to z perspektywy produktu jest tak, jakbyś tego ryzyka w ogóle nie wykrył(-a). Bug, o którym wie tylko tester, nadal poleci na produkcję.
Dlatego Mid myśli nie tylko "co znalazłem", ale też "kto musi o tym wiedzieć i kiedy". Czasem to oznacza wiadomość do PM-a przed daily, czasem eskalację tuż przed release'em, a czasem świadomą decyzję, że temat może poczekać. Zarządzanie informacją o jakości to umiejętność, której nie znajdziesz w żadnym sylabusie certyfikatu, a która realnie chroni produkcję.
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.
Ocena ryzyka i łączenie zależności
Będąc już przy ryzyku - trzecia odpowiedź wskazywała na umiejętność łączenia zależności. Mid QA powinien widzieć, jak dany feature wchodzi w interakcję z resztą systemu. Junior testuje funkcjonalność taką, jaka jest opisana w tickecie: sprawdza kryteria akceptacji, przechodzi ścieżki pozytywne i negatywne, zgłasza odstępstwa. I robi to dobrze, tylko że w izolacji.
Mid patrzy szerzej. Widzi, że zmiana w module rabatów może wpłynąć na naliczanie VAT-u w koszyku, że nowy walidator formularza dotknie też starego flow rejestracji, a modyfikacja endpointu API rozjedzie się z aplikacją mobilną, która aktualizuje się wolniej niż web. Łączenie zależności to niezwykle ważna umiejętność, która ratuje przed wieloma bugami - zwłaszcza tymi najdroższymi, bo wychodzącymi na produkcji w miejscu, którego nikt nie testował, bo "przecież ta zmiana tego nie dotyczyła".
Skąd się to bierze? Głównie z wiedzy domenowej i z ciekawości. Mid zna produkt, rozumie architekturę na poziomie "co z czym gada" i pamięta historyczne wtopy. Dobra wiadomość dla Juniorów jest taka, że tę umiejętność da się świadomie budować: czytaj opisy tasków spoza swojego obszaru, dopytuj devów o zależności i notuj, co się zepsuło przy poprzednich zmianach. Regresja w głowie bywa cenniejsza niż regresja w Jirze.
"Mid już wie, że nie wie wszystkiego"
Czwarta odpowiedź była krótka, ale moim zdaniem najbardziej trafna. Junior często nie zdaje sobie sprawy z luk we własnej wiedzy - i to jest zupełnie normalne, bo na tym właśnie polega juniorskość. Nie da się wiedzieć, czego się nie wie, dopóki nie zderzysz się z odpowiednią liczbą projektów, technologii i sytuacji, które Cię zaskoczą.
Mid te luki już widzi i zamiast udawać, że ich nie ma, zaczyna nimi zarządzać. Wie, że słabiej czuje testy wydajnościowe, więc przy tasku z k6 od razu dobiera się do dokumentacji albo prosi o parowanie. Wie, że nie ogarnia jeszcze dostępności, więc nie deklaruje, że "sprawdził wszystko". Ta świadomość zmienia też sposób raportowania: Mid potrafi powiedzieć "przetestowałem X i Y, ale nie mam kompetencji, żeby ocenić Z" - i to jest informacja o wiele cenniejsza niż optymistyczne "wszystko działa".
Paradoksalnie więc awans na Mida wiąże się z większą, a nie mniejszą pokorą. Im więcej wiesz, tym wyraźniej widzisz, ile jeszcze przed Tobą. Jeśli po dwóch latach w QA masz poczucie, że wiesz mniej niż na początku - to prawdopodobnie dobry znak, a nie powód do paniki 😅
Co z tego wynika?
Kiedy zestawi się te cztery odpowiedzi obok siebie, widać wspólny mianownik: żadna z nich nie dotyczy narzędzi. Samodzielność, proaktywność, myślenie o ryzyku i świadomość własnych luk to kompetencje, które rosną wolniej niż znajomość kolejnego frameworka - i których nie da się nadrobić weekendowym kursem. Właśnie dlatego przejście z Juniora na Mida trwa i właśnie dlatego nie da się go sprowadzić do checklisty "naucz się Playwrighta, zdaj certyfikat, gotowe".
Jeśli jesteś Juniorem i zastanawiasz się, nad czym pracować, to zamiast dokładać kolejne narzędzie do CV, przyjrzyj się tym czterem obszarom. Zacznij przychodzić z planem zamiast z pytaniem "co mam zrobić", pilnuj, żeby informacja o ryzyku docierała tam, gdzie trzeba, ucz się produktu szerzej niż wymaga tego bieżący task i nazywaj głośno to, czego jeszcze nie umiesz. To jest ta droga - mniej spektakularna niż nowy framework, ale to ona faktycznie robi z Juniora Mida.
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