Wyłapuję bugi,
zanim zrobią to użytkownicy.
QA Automation Engineer i twórca TESTron. Buduję systemy automatyzacji, frameworki jakości i produkty SaaS — nie tylko testuję.
Większość problemów wychodzi po wdrożeniu.
Moje systemy działają przed.
Nie tylko testuję — buduję.
Inżynier QA automation — ktoś, który traktuje testowanie jak inżynierię produktu. Przeszedłem drogę od programisty CNC przez testowanie manualne, pełną automatyzację, aż po budowanie własnych produktów SaaS.
Moje portfolio to prawdziwe projekty na żywych aplikacjach — nie tutoriale, nie sandbox. Każdy test ma swoją historię: plan, asercje, wynik. Jeden wykryty realny bug w filtrach sklepu, który mógł kosztować sprzedaż.
Buduję narzędzia, których sam potrzebuję. Monitor Tokenów Claude — desktopowa aplikacja z 64 testami. TESTron — platforma SaaS dla testerów, bo widzę każdego dnia, czego brakuje w tej branży.
Wierzę, że dobry inżynier QA to architekt jakości i partner programisty — nie tylko klikacz. Jeden nieznaleziony bug może kosztować więcej niż cały kwartał testów.
Droga, która tutaj doprowadziła
Nie studia, nie przypadek — każdy krok był świadomym przejściem od precyzji do automatyzacji, od automatyzacji do budowania.
Programista CNC
Precyzja do mikronów. Zero tolerancji dla błędów — bo błąd w programie CNC kosztuje materiał, czas i reputację. Tu nauczyłem się, że automatyzacja eliminuje ludzki błąd. Ta lekcja zostaje na zawsze.
QA Engineer — testowanie manualne
Kurs w Software Development Academy. Projekt końcowy z oceną celującą. Testowanie aplikacji bankowej Guru99 — TestRail, przypadki testowe, zgłoszenia błędów. Pierwsze zetknięcie z myśleniem o jakości jako procesie.
QA Automation Engineer
Python, Playwright, Pytest, Page Object Model. 83 testy na żywych aplikacjach. Jeden wykryty realny bug w produkcji. Własna aplikacja desktopowa z 64 testami pisanymi metodą TDD. To już nie klikanie — to inżynieria.
Product Builder — twórca TESTron
Widzę problem w branży QA z perspektywy praktyka. Buduję TESTron — platformę SaaS dla testerów, stworzoną przez testera. Bo najlepsze narzędzia powstają, gdy twórca sam jest użytkownikiem.
Zobacz TESTron →TESTron
Platforma SaaS dla testerów oprogramowania — stworzona przez testera.
Nie buduję TESTron dlatego, że mogę.
Buduję go dlatego, że sam potrzebuję takiego narzędzia.
Jako inżynier QA widzę każdego dnia, czego brakuje w ekosystemie testowania. TESTron ma to zmienić — od środka, przez kogoś kto rozumie problem na własnej skórze.
Projekty — prawdziwe, nie demo
Każdy projekt to żywa aplikacja, prawdziwe scenariusze i mierzalne wyniki.
Ta strona jest stale testowana i ulepszana
Buduję i modyfikuję ją na bieżąco — każda zmiana jest weryfikowana przez 51 automatycznych testów SEO, dostępności WCAG 2.1 AA i wydajności. Raport audytu pokazuje nie tylko aktualny stan, ale też historię wszystkich uruchomień — widać dokładnie jak jakość rośnie wraz z każdą iteracją. To właśnie tak wygląda profesjonalne podejście do QA w praktyce.
Co robię i jak to robię
Nie lista technologii — opis tego, co faktycznie potrafię zbudować.
Język, w którym piszę logikę testów i automatyzacji — nie dodatek do frameworka, tylko rdzeń.
Cały pakiet tests/ na tej stronie i każdy projekt QA w portfolio.
Fixture axe i page_loaded w conftest.py są celowo function-scoped, mimo że przeglądarka jest session-scoped — każdy test dostaje świeżą stronę.
Steruje prawdziwą przeglądarką, więc testuję to, co faktycznie widzi użytkownik.
saucedemo, biopoprom, koparka-kobierzyce, dbcraftmode i audyt tej strony.
page.goto(..., wait_until="networkidle") + osobne czekanie na #splash-screen.hiding — sama nawigacja nie znaczy, że strona skończyła animować.
Organizuje testy w fixtures i generuje dowód — nie tylko zielony/czerwony pasek.
Każdy projekt QA; raport pytest-html z audytu tej strony.
Realny wall-clock z nagłówka raportu — „50 tests took 00:05:08" — zmierzony, nie zgadywany.
Oddziela logikę testu od struktury strony — zmiana HTML nie wywraca całego zestawu testów.
saucedemo.com — pierwszy projekt, gdzie zbudowałem POM od zera; stał się wzorcem dla kolejnych.
Gdy dbcraftmode.pl zmieniło filtr produktów, poprawka poszła w jednej klasie strony, nie w dziesięciu testach.
Automatyczny skaner dostępności — łapie naruszenia (kontrast, aria, etykiety) zanim zrobi to czytnik ekranu.
test_wcag.py na tej stronie.
Zamiana --text3 na --text2 w 12 miejscach arkusza stylów podniosła kontrast z 2.2:1 do 5.1:1.
Mierzy realne odczucie szybkości (LCP, CLS, TTFB), nie subiektywne wrażenie.
test_performance.py, monitoring tej strony.
LCP 4088ms — 88ms powyżej progu „poor" (4000ms). Notuję i obserwuję trend; nie naprawiam na siłę po jednym pomiarze.
Sprawdza, czy strona jest poprawnie opisana dla wyszukiwarek — meta, nagłówki, Open Graph.
test_seo.py, realna naprawa w historii projektu.
Duplikat H1 naprawiony (splash screen z <h1> na <p>) i meta description skrócone z 172 do 154 znaków.
Piszę test, zanim napiszę kod, który ma przejść — kod od pierwszej linii ma dowód, że działa.
Monitor Tokenów Claude, własna aplikacja desktopowa.
46 testów jednostkowych + 18 integracyjnych, pisanych równolegle z kodem.
Kontrola wersji — śledzi zmiany w kodzie, pozwala cofać i rozgałęziać.
Codziennie w TESTron i na tej stronie — cały workflow z Claude Code stoi na commitach.
Zasada „żaden commit bez potwierdzenia, show diff before saving".
Porozmawiajmy
Masz aplikację i chcesz spać spokojniej po deployu?
Pokaż mi projekt — znajdę miejsca, które warto przetestować.
Odpowiadam zwykle w ciągu 24h.