Od testera manualnego do inżyniera automatyzacji testów w 12 miesięcy

Cel: świadome przejście na automatyzację w 12 miesięcy

Przejście z testów manualnych do roli inżyniera automatyzacji testów w 12 miesięcy jest realne, jeśli potraktujesz ten czas jak dobrze zaplanowany projekt. Potrzebny jest konkretny plan rozwoju testera automatyzującego, rozpisany na etapy, z jasnymi priorytetami: najpierw fundamenty techniczne, potem narzędzia, a na końcu solidne portfolio i wejście na rynek.

Celem jest nie tylko zmiana nazwy stanowiska, ale realna zmiana sposobu myślenia: z wykonywania testów na projektowanie i utrzymanie systemów testów automatycznych, współpracujących z resztą procesu wytwarzania oprogramowania.

Punkt startowy: kim jest tester manualny, a kim inżynier automatyzacji

Różnice w odpowiedzialnościach i zakresie pracy

Tester manualny skupia się przede wszystkim na wykonywaniu testów według scenariuszy, eksploracji aplikacji oraz raportowaniu błędów. Jego narzędziami są zazwyczaj: przypadki testowe, arkusze, system do zgłaszania defektów (Jira, Azure DevOps) oraz sama aplikacja. Odpowiedzialność koncentruje się na znalezieniu istotnych błędów z punktu widzenia użytkownika i biznesu.

Inżynier automatyzacji testów pracuje bliżej świata programistów. Zajmuje się tworzeniem i utrzymaniem kodu testów automatycznych, frameworków, integracją testów z pipeline’ami CI/CD oraz analizą stabilności tych testów. To nie jest tylko „szybsze klikanie w przeglądarce”. W praktyce oznacza to:

• pisanie kodu w wybranym języku (Java, C#, Python, JavaScript itp.),
• projektowanie struktury testów (wzorce takie jak Page Object, Screenplay, warstwy abstrakcji),
• konfigurację narzędzi do uruchamiania testów na różnych środowiskach,
• współpracę z deweloperami przy debugowaniu problemów wychwytywanych przez testy.

Różnica jest też w odpowiedzialności długoterminowej. Tester manualny może traktować każdy projekt bardziej „tu i teraz”. Inżynier automatyzacji buduje coś, co ma działać miesiącami lub latami, będzie rozwijane przez kolejne osoby i musi być zrozumiałe oraz utrzymywalne.

Z czym realnie mierzy się inżynier automatyzacji na co dzień

Obraz pracy automatyka bywa mocno uproszczony. W praktyce dzień wypełniają nie tylko same testy, ale też:

• analiza, dlaczego testy losowo „padają” (flaky tests),
• utrzymanie stabilnych selektorów i warstw abstrakcji, gdy UI się zmienia,
• konflikty w repozytorium, code review, poprawianie stylu kodu,
• dostosowywanie testów do nowych wymagań biznesowych i architektonicznych,
• konfiguracja nowych środowisk testowych (Docker, kontenery, mocki usług),
• bieżąca współpraca z DevOps (lub deweloperami) w temacie pipeline’ów CI.

W efekcie praca automatyka to w dużej części rozwiązywanie problemów technicznych i architektonicznych, a nie tylko przenoszenie scenariuszy z Excela do kodu. Trzeba brać pod uwagę czas wykonania testów, ich niezawodność, koszty utrzymania i to, czy da się je uruchamiać równolegle.

W projektach o wyższym poziomie dojrzałości jakości inżynier automatyzacji ma również wpływ na to, co w ogóle powinno być testowane automatycznie, a co pozostaje w rękach testów manualnych czy eksploracyjnych. To przejście od roli „wykonawcy testów” do roli współprojektanta procesu jakości.

Jak zmienia się dzień pracy podczas przejścia z manuala do automatyzacji

Przykładowy dzień testera manualnego: przegląd zgłoszonych ticketów, planowanie testów do nadchodzącego release’u, przygotowywanie danych testowych, wykonywanie testów regresyjnych, sesja testów eksploracyjnych, raportowanie błędów. Większość czasu spędzasz w aplikacji i narzędziu do zgłaszania defektów.

Przykładowy dzień inżyniera automatyzacji: code review zmian w testach, dopisywanie nowych scenariuszy do frameworka, walka z niestabilnym testem regresyjnym, analiza logów z pipeline’u CI, poprawa konfiguracji środowiska testowego, rozmowa z deweloperem o zmianie w API, która wymaga aktualizacji testów. Duży procent dnia to praca w IDE (np. IntelliJ, VS Code, Rider) i terminalu.

Zmiana jest również mentalna. W testach manualnych łatwo „dowieźć” wynik, zwiększając swój nakład pracy (zostanę godzinę dłużej i do-testuję). W automatyzacji rośnie znaczenie decyzji architektonicznych. Błędna struktura frameworka może kosztować tygodnie refactoru, a każda kolejna funkcjonalność będzie coraz trudniejsza do pokrycia testami.

Diagnoza kompetencji startowych i wybór specjalizacji automatyzacji

Co już masz jako tester manualny, czego brakuje do automatyzacji

Testerzy manualni często nie doceniają tego, co już wnoszą do automatyzacji. Zazwyczaj masz:

• myślenie testowe – umiejętność znajdowania scenariuszy brzegowych, złych ścieżek, przypadków nietypowych,
• znajomość procesu wytwarzania oprogramowania – wiesz, jak wygląda release, planowanie sprintu, regresja, smoke testy,
• domenę biznesową – rozumiesz logikę systemu, żargon biznesowy, typowe błędy, które najbardziej bolą użytkowników,
• komunikację z zespołem – umiesz rozmawiać z PM, devami, UX, supportem.

Tego nie trzeba budować od zera. To jest podstawa, na której można szybko nauczyć się przekładać wiedzę domenową na testy automatyczne. Brakuje natomiast zazwyczaj:

• solidnych podstaw programowania (minimum jednego języka, zrozumienie obiektowości),
• swobody w pracy z GIT-em i repozytoriami kodu,
• rozumienia narzędzi CI/CD i pipeline’ów,
• podstaw sieci, HTTP, API, baz danych,
• zmysłu „engineeringowego” – projektowania rozwiązań, a nie tylko ich używania.

Diagnoza startu jest prosta: jeśli dziś nie jesteś w stanie samodzielnie stworzyć małego skryptu CLI (np. pobierającego dane z API i zapisującego je do pliku), to pierwszy kwartał planu musi być mocno programistyczny.

Frontend, backend, API, mobile – gdzie chcesz i możesz wejść

Automatyzacja testów to nie tylko testy UI w przeglądarce. Rynek pracy oferuje kilka wyraźnych ścieżek:

• automatyzacja UI (frontend) – Selenium, Cypress, Playwright, WebdriverIO; testy przeglądarkowe, e2e, regresja interfejsu,
• automatyzacja API (backend) – REST, czasem GraphQL; testy kontraktów, walidacja payloadów, scenariusze end-to-end bez UI,
• testy mobilne – Appium, Espresso, XCUITest; aplikacje Android/iOS, emulatory, fizyczne urządzenia,
• testy na poziomie komponentów / mikrousług – testy integracyjne, kontraktowe (np. Pact),
• testy wydajnościowe – JMeter, Gatling, k6; osobny kierunek, ale często łączony z automatyzacją API.

Na start najbardziej dostępna jest ścieżka UI albo API. UI jest „namacalne” – widzisz efekty testów, jesteś blisko manualnej perspektywy. API jest mniej efektowne wizualnie, ale za to stabilniejsze, szybsze i często lepiej wynagradzane na rynku. W praktyce sensowny plan nauki automatyzacji testów w rok zwykle łączy: UI + API + podstawy baz danych.

Decyzja o specjalizacji powinna uwzględniać:

• obecny projekt – jeśli testujesz głównie UI, zacznij od UI, ale równolegle dodaj API,
• oferty pracy w Twojej lokalizacji / na rynku zdalnym,
• Twoje preferencje – nie każdy lubi narzędzia stricte mobilne czy głęboki backend.

Jak przeanalizować ogłoszenia o pracę, żeby świadomie wybrać stos technologiczny

Ścieżka kariery testera automatyzacji powinna być zsynchronizowana z tym, czego faktycznie szukają firmy. Mechaniczna nauka „popularnych narzędzi” prowadzi często do rozczarowania. Lepiej działa podejście odwrotne: wychodzisz od ogłoszeń.

Praktyczne kroki:

1. Wybierz 20–30 aktualnych ogłoszeń na „Test Automation Engineer”, „QA Automation”, „SDET” z Twojego rynku.
2. Wyodrębnij z nich:
   • główne języki programowania (Java, C#, Python, JS/TS),
   • narzędzia UI (Selenium, Cypress, Playwright),
   • narzędzia API (REST Assured, Postman, Karate, SuperTest),
   • stack CI/CD (Jenkins, GitLab CI, GitHub Actions, Azure DevOps),
   • must-have vs nice-to-have.
3. Stwórz prostą tabelę, która pokaże dominujące technologie.

Taka prosta analiza podpowie, w co zainwestować. Przykładowo: jeśli 70% ogłoszeń wymaga Javy + Selenium + Jenkins, a w Twoim mieście jest sporo firm .NET, możesz wybrać Java + Selenium jako bazę, ale mieć świadomość, że w razie potrzeby łatwo się przekwalifikujesz do C#.

Fundamenty techniczne przed automatyzacją: programowanie, GIT, podstawy systemów

Język programowania – jak wybrać i czego się w nim nauczyć

Dla testera automatyzującego język programowania to narzędzie pracy, nie cel sam w sobie. Kryteria wyboru:

• popularność w ogłoszeniach (Java, C#, JS/TS, Python),
• dostępność ekosystemu testowego (biblioteki, frameworki, community),
• Twoje otoczenie – w jakim języku pracuje aktualny zespół, od kogo możesz się uczyć.

Java i C# dominują w klasycznych rolach QA Automation w korporacjach i dużych projektach. JavaScript/TypeScript króluje w świecie frontendu i narzędzi typu Cypress/Playwright. Python jest prosty na start i częsty w testach API, ale w wielu firmach nie jest pierwszym wyborem na testy UI.

Niezależnie od języka, zestaw konstrukcji, które musisz realnie opanować, jest podobny:

• typy zmiennych, operatory, instrukcje warunkowe (if/else, switch),
• pętle (for, while, iteracja po kolekcjach),
• kolekcje (listy, mapy, sety) – praca z kolekcją danych testowych,
• funkcje/metody – parametry, typy zwracane, przeciążanie (overloading),
• podstawy programowania obiektowego (OOP) – klasy, obiekty, dziedziczenie, enkapsulacja, interfejsy,
• obsługa wyjątków – try/catch/finally, własne wyjątki testowe,
• moduły/pakiety – sensowna organizacja kodu, żeby rosnący framework się nie rozpadł.

Na tym etapie łatwo wpaść w pułapkę: „znam if-y i pętle, czas na Selenium”. Uwaga: to, co działa dla prostego tutoriala, rozsypie się przy 200 testach w jednym projekcie. Rozsądnie jest poświęcić 1–2 miesiące na sam język, pisząc małe, niezależne programy: parser pliku CSV, generator danych testowych, prosty klient HTTP, który odpytuje API.

Kontrola wersji i praca z kodem zespołu

Bez GIT-a nie ma realnej pracy inżyniera automatyzacji. Umiejętność commitowania nie wystarczy, gdy pojawią się konflikty, code review, kilka równoległych gałęzi i potrzeba utrzymania historii zmian.

Minimalny pakiet umiejętności GIT dla testera automatyzującego:

• klonowanie repozytorium – git clone,
• aktualizacja lokalnej kopii – git fetch, git pull,
• tworzenie gałęzi – git branch, git checkout -b,
• commitowanie – dobre komunikaty commitów, łączenie małych zmian w logiczne jednostki,

Podstawy systemów: terminal, sieć, bazy danych

Automatyzacja bez zrozumienia środowiska, w którym działają testy, szybko prowadzi do ściany. Nie chodzi o to, żeby zostać adminem, tylko umieć sobie poradzić, gdy testy „nagle” przestają działać na CI albo na innym środowisku.

Trzy filary na początek:

• system operacyjny i terminal – praca z linią komend na Windows (PowerShell) i/lub Linux (bash),
• sieć i HTTP – zrozumienie, co się dzieje między przeglądarką / klientem API a serwerem,
• bazy danych – podstawowy SQL, żeby móc przygotować i weryfikować dane testowe.

Terminal to nie jest „magia dla developerów”. W praktyce będziesz:

• uruchamiać testy z linii komend (np. mvn test, gradle test, npm test),
• sprawdzać logi aplikacji (tail -f, grep),
• manipulować plikami konfiguracyjnymi (np. .env, pliki YAML do CI/CD),
• wykonywać proste skrypty wspierające testy (np. czyszczenie katalogów z raportami).

Sieć i HTTP to przede wszystkim:

• różnica między GET/POST/PUT/DELETE,
• kody odpowiedzi (2xx, 4xx, 5xx) i ich znaczenie testowe,
• nagłówki (headers), parametry zapytań (query params), body (JSON, czasem XML),
• podstawowe narzędzia: curl, przeglądarkowe devtools (zakładka Network), Postman.

SQL na poziomie automatyzacji nie musi być zaawansowany. Wystarczą:

• SELECT z filtrowaniem (WHERE), sortowaniem (ORDER BY),
• proste złączenia (JOIN) między 2–3 tabelami,
• podstawowy INSERT/UPDATE/DELETE do przygotowania danych testowych,
• świadomość transakcji (commit/rollback), żeby nie rozwalić środowiska QA.

Tip: przy każdym nowym projekcie testów automatycznych zaplanuj godzinę na zrobienie „inwentaryzacji technicznej”: jaki system, jaki serwer aplikacyjny, jaka baza danych, gdzie są logi, jak wygląda sieć między komponentami. Ta mapa oszczędza później dziesiątki godzin debugowania.

Praktyczne minimum CI/CD dla inżyniera automatyzacji

Pipeline CI/CD (Continuous Integration / Continuous Delivery) to miejsce, gdzie twoje testy będą żyły na co dzień. Nawet jeśli początkowo pipeline skonfiguruje ktoś inny, z czasem i tak będziesz musiał go rozumieć, modyfikować i diagnozować.

Na start wystarczy opanować kilka rzeczy:

• podstawowy schemat: checkout kodu → instalacja zależności → build → testy → raport,
• konfiguracja jobów w wybranym narzędziu (Jenkinsfile, .gitlab-ci.yml, workflow GitHub Actions),
• zmienne środowiskowe (ENV) – przechowywanie URL, tokenów, danych logowania,
• artefakty – gdzie lądują raporty, logi, zrzuty ekranu z testów UI,
• prosty podział testów na grupy (np. smoke, regression) i ich uruchamianie na różnych etapach.

Dobry krok praktyczny: zbuduj dla siebie mini-pipeline, który:

1. po każdym pushu do repo uruchamia kilkanaście testów API/UI,
2. po wykonaniu testów publikuje raport HTML jako artefakt,
3. oznacza build jako failed, jeśli choć jeden test padnie.

Po kilku takich iteracjach zaczynasz myśleć jak inżynier, a nie tylko „użytkownik frameworka testowego”. Zaczynasz też rozumieć, czemu testy niestabilne (flaky) są większym problemem niż brak testów.

Plan 12 miesięcy: podział na kwartały i priorytety

Architektura planu – od fundamentów do specjalizacji

Rok to sporo czasu, ale tylko wtedy, gdy ma się priorytety i metryki postępu. Tutaj kluczowa jest kolejność: najpierw fundamenty, potem narzędzia, dopiero na końcu „ładne rzeczy” typu raporty, integracje, framework „enterprise”.

Praktyczny podział na kwartały:

• Q1 (miesiące 1–3) – fundamenty techniczne: język programowania, GIT, podstawy systemów, prosty CI; pierwsze skrypty i testy na surowych bibliotekach,
• Q2 (miesiące 4–6) – stabilne wejście w automatyzację UI i/lub API; własny mini-framework, wzorce projektowe, organizacja projektu testowego,
• Q3 (miesiące 7–9) – pogłębienie wiedzy: testy na różnych poziomach (component/integration), zaawansowane scenariusze, rozsądne raportowanie, utrzymanie testów w zespole,
• Q4 (miesiące 10–12) – specjalizacja i „produkcyjność”: dopracowanie portfolio, kontrybucja do istniejących projektów, mocki, kontenery, przygotowanie do rozmów rekrutacyjnych.

Dla każdej ćwiartki sensowne jest zdefiniowanie 2–3 mierzalnych rezultatów. Przykład dla Q2: „Mam projekt automatyzacji UI z minimum 30 stabilnymi testami, odpalanymi z CI po każdym pushu, z raportem dostępnym w artefaktach.”

Strategia nauki: małe projekty zamiast kursów „od A do Z”

Same kursy wideo często dają złudzenie postępu. Kod z tutoriala działa, dopóki jest przepisany 1:1. Problem zaczyna się przy pierwszej nietypowej sytuacji w realnym projekcie.

Dużo lepiej działa podejście oparte na małych, zamkniętych projektach:

• każdy projekt ma konkretny cel (np. „API client do publicznego API + 10 testów walidujących odpowiedzi”),
• kod ląduje w publicznym lub prywatnym repo,
• do każdego projektu konfigurujesz choćby prosty pipeline CI,
• po skończeniu robisz krótką retrospekcję: co działało, co było nieczytelne, co byś przepisał.

Uwaga: nie bój się kasować lub archiwizować projektów. Głównym efektem ma być wiedza w głowie i nawyki, nie „idealne repo na GitHubie”.

Miesiące 1–3: wejście w automatyzację – od testów manualnych do pierwszych testów UI/API

Priorytety pierwszego kwartału

W pierwszych trzech miesiącach kluczowe są trzy rzeczy:

1. swoboda w jednym języku programowania (na poziomie „piszę małe narzędzia bez patrzenia cały czas w Google”),
2. pewność w GIT i podstawach pracy projektowej (branch → zmiana → PR → review),
3. pierwszy, działający projekt testów automatycznych (UI lub API), choćby bardzo prosty.

W praktyce oznacza to przesunięcie uwagi z samego klikania w aplikacji na myślenie: jak tę samą czynność wyrazić w kodzie, żeby dało się ją powtarzać setki razy bez udziału człowieka.

Tydzień po tygodniu – struktura pracy w pierwszym miesiącu

Dobrym rytmem jest praca w iteracjach tygodniowych. Każdy tydzień ma swój mini-cel, który kończy się działającym kodem.

Tydzień 1: odświeżenie i ugruntowanie podstaw programowania

• powtórka konstrukcji języka: typy, warunki, pętle, funkcje/metody, kolekcje,
• napisanie 2–3 małych programów CLI:
  • np. skrypt, który wczytuje dane z pliku CSV i filtruje wiersze wg kryteriów,
  • generator danych testowych (losowe e-maile, numery telefonów, identyfikatory).
• pierwsze użycie prostych bibliotek zewnętrznych (np. biblioteka do obsługi JSON).

Tydzień 2: GIT + struktury projektów

• założenie konta na GitHub/GitLab, stworzenie pierwszego repo,
• ćwiczenie workflow:
  • tworzenie gałęzi dla zmian,
  • commitowanie małych kroków z sensownymi opisami,
  • łączenie gałęzi poprzez Pull Request/Merge Request (nawet do własnego repo).
• nauka ignorowania plików (.gitignore),
• zrozumienie pojęć „origin”, „upstream”, „remote”.

Tydzień 3: programistyczny „mięsień” – praca z API i plikami

• napisanie prostego klienta HTTP:
  • wysyłanie GET/POST do publicznego API,
  • parsowanie odpowiedzi JSON,
  • wyciąganie konkretnych pól (np. nazwy użytkownika, statusu zamówienia).
• utrwalanie pracy z plikami: zapisywanie wyników zapytań do pliku, proste logowanie.

Tydzień 4: mini-projekt kończący miesiąc

Dobry projekt na koniec pierwszego miesiąca:

• aplikacja CLI, która:
  • wysyła zapytania do wybranego API (np. baza filmów, pogoda, waluty),
  • waliduje podstawowe pola w odpowiedzi (np. że kurs waluty jest liczbą > 0),
  • zapisuje wynik w pliku raportowym (np. CSV, JSON, prosty tekst).
• projekt jest w repo,
• zmiany wprowadzane są przez osobne gałęzie i PR,
• kod jest uruchamiany jednym poleceniem z linii komend.

Pierwsze testy API – szybka ścieżka z manuala na kod

Dla wielu testerów manualnych API jest bliższe niż UI w kodzie. Jeśli na co dzień używasz Postmana, start jest prosty: przekładasz istniejące scenariusze na kod.

Logiczna sekwencja kroków:

1. wybór biblioteki do testów API (np. REST Assured dla Javy, Requests + pytest dla Pythona, axios + Jest dla JS/TS),
2. zapisanie jednego istniejącego scenariusza z Postmana w postaci testu automatycznego,
3. dodanie asercji na:
   • kod odpowiedzi HTTP,
   • wybrane pola w body,
   • czas odpowiedzi (np. < 2 s, ale bez przesady na tym etapie).
4. uruchomienie testu lokalnie z linii komend i analiza wyniku,
5. dodanie kolejnych scenariuszy – np. warianty z błędnym tokenem, pustym body, niepoprawnym ID.

Przykładowe przypadki, które łatwo zautomatyzować na start:

• utworzenie nowego zasobu (np. użytkownika) i weryfikacja, że da się go pobrać po ID,
• próba pobrania nieistniejącego zasobu i sprawdzenie, że serwer zwraca poprawny błąd 404 z sensownym komunikatem,
• scenariusz autoryzacji: poprawny token vs niepoprawny / wygasły.

Tip: utrzymuj testy API w tym samym repo, w którym trzymasz małe projekty programistyczne. Na tym etapie priorytetem jest nauka, nie perfekcyjny rozdział mikro-repozytoriów.

Pierwsze testy UI – od klikacza do autora scenariuszy w kodzie

Jeśli na co dzień pracujesz z UI, naturalnie kusi wejście od razu w Selenium, Cypress czy Playwright. Sensowniej jednak poświęcić kilka dni na zrozumienie, jak przeglądarka „widzi” stronę.

Plan minimalny na pierwsze dwa tygodnie pracy z UI:

• praca z devtools:
  • podgląd struktury DOM (drzewo elementów HTML),
  • szukanie elementów po id, name, data-testid,
  • podstawy CSS selektorów (#id, .klasa, selektory atrybutów).
• wybór frameworka UI (np. Selenium + TestNG/JUnit w Javie, Cypress/Playwright w JS/TS),
• napisanie pierwszego testu:
  • otwarcie strony,
  • wpisanie danych w formularz,
  • kliknięcie przycisku,
  • sprawdzenie komunikatu na ekranie.

Na początku unikaj skomplikowanych frameworków typu „Page Object + własny DSL + 4 warstwy abstrakcji”. Lepiej zacząć od testów „bliskich” kodowi strony, a dopiero po kilkunastu scenariuszach wyciągać powtarzalne fragmenty do osobnych klas.

Przykład naturalnej ewolucji:

1. masz 5 testów logowania, w każdym jest ten sam blok: otwarcie strony, wpisanie loginu/hasła, kliknięcie „Zaloguj”,

Naturalne wyciąganie powtarzalnych fragmentów kodu

2. dostrzegasz duplikację i wyciągasz logikę logowania do jednej funkcji/metody,
3. po kilku kolejnych testach wyodrębniasz całą stronę logowania jako oddzielną klasę (Page Object) z metodami typu loginAs(user, password),
4. gdy pojawiają się kolejne strony, budujesz spójny „mini-framework” dopasowany do swojego projektu, zamiast kopiować cudze struktury 1:1.

Takie podejście jest dużo bliższe temu, jak realnie rozwija się framework w projekcie komercyjnym: od prostych skryptów do rozsądnej architektury, która wynika z potrzeb, a nie z diagramów w kursie.

Uczenie się przez porównanie: ten sam scenariusz manualny w Postmanie i w kodzie

Dobry most między światem manualnym a automatyzacją to świadome przepisywanie scenariuszy. Zamiast wymyślać „sztuczne” przypadki, można wziąć gotowy, opatrzony scenariusz, który klikasz od miesięcy, i zapisać go w kodzie.

Działa to szczególnie dobrze przy API:

• masz kolekcję w Postmanie,
• wybierasz 3–5 często powtarzanych requestów (np. rejestracja, logowanie, pobranie profilu),
• przepisujesz je do biblioteki testowej (pytest, JUnit, NUnit itp.),
• to, co robisz „oczami”, przekładasz na asercje (czyli warunki sprawdzające wynik).

Efekt uboczny: zaczynasz myśleć o scenariuszu nie tylko w kategoriach „co klikam / co wysyłam”, ale też „co jest niezmienne, co ma być przetestowane, co jest tylko szumem”. To fundament dobrego inżyniera automatyzacji.

Nawyk codziennego kodowania i mikro-retrospekcje

Pierwszy kwartał to również budowanie mięśnia: codzienny kontakt z kodem, choćby na 30 minut. Lepsze jest krótkie, regularne pisanie niż 6-godzinny „maraton” raz w tygodniu.

Praktyczny rytm dnia:

• 10–15 minut – szybkie ćwiczenie z języka (np. mały problem z plikami lub kolekcjami),
• 15–30 minut – rozwijanie aktualnego mini-projektu (testy API/UI, narzędzie CLI),
• 5 minut – retrospekcja: co dziś było trudne, co cię zblokowało, co spisać jako „rzecz do doczytania”.

Uwaga: zapisuj krótkie notatki z retrospekcji w repo (np. notes.md) albo w osobnym notatniku. Po kilku tygodniach zobaczysz konkretne ścieżki postępu, a przy okazji materiał do późniejszego portfolio.

Stabilizacja środowiska: narzędzia, konfiguracja, pierwsze CI

Wraz z końcówką pierwszego kwartału dobrze jest mieć względnie stabilne środowisko pracy. Chodzi o to, żeby minimalizować „przeszkadzacze” typu brakująca wersja JDK czy nieaktualne zależności.

Podstawowy setup może obejmować:

• IDE dopasowane do języka (IntelliJ/VS Code/PyCharm itp.) + skonfigurowane formatowanie kodu,
• menedżer zależności (Maven/Gradle, pip/Poetry, npm/yarn),
• konfigurację jednego, prostego pipeline CI:
  • wyzwalany na push do głównej gałęzi,
  • instalacja zależności,
  • uruchomienie testów i zapisanie raportu (nawet prostego tekstowego) jako artefakt.

Tip: jeśli w pracy używacie już konkretnego systemu CI (GitLab CI, Jenkins, GitHub Actions), sklonuj minimalną konfigurację, którą znasz z projektu komercyjnego. Nie ma sensu wynajdować wszystkiego od zera.

Miesiące 4–6: budowa pierwszego „prawdziwego” frameworka i stabilnych testów

Przesunięcie akcentu: z nauki języka na projekt testowy

Po trzech miesiącach język programowania i GIT nie powinny już być główną przeszkodą. Drugi kwartał to czas, kiedy środek ciężkości przenosi się z „uczę się programować” na „buduję sensowny projekt testowy”.

Cel na ten etap można sprowadzić do kilku punktów:

• jeden, spójny projekt automatyzacji (UI, API albo hybryda) w wybranym języku,
• 20–50 stabilnych testów, które uruchamiają się w CI,
• rozsądna struktura katalogów i kodu (brak spaghetti rozrzuconego po jednym pliku),
• podstawowe wzorce projektowe (np. Page Object, warstwa clientów API, helpery).

Wybór domeny: UI czy API jako główny focus

Na tym etapie trzeba wybrać przynajmniej na kilka miesięcy obszar dominujący. Robienie wszystkiego naraz (UI, API, mobilka, performance) zwykle kończy się płytką wiedzą o wszystkim.

Prosty algorytm wyboru:

• jeśli w obecnej pracy większość testów robisz na API lub macie mocne wsparcie developerów – zainwestuj w automatyzację API,
• jeśli twoja domena to przede wszystkim interfejs webowy (np. e-commerce, panel administracyjny) – postaw na UI (Selenium/Cypress/Playwright).

Decyzja nie jest na zawsze, ale dobrze ją „zamrozić” na 3–6 miesięcy. Dzięki temu wiedza układa się w spójną całość, a nie w zbiór przypadkowych trików.

Projekt szkieletowy: jak ułożyć katalogi i warstwy

Na przełomie miesiąca 3 i 4 warto stworzyć szkielet frameworka, który będzie „domem” dla testów. Nie musi być idealny, ma być zrozumiały.

Przykładowy układ dla projektu API (w pseudo-strukturze):

tests/
  api/
    users/
      test_create_user.py
      test_get_user.py
    auth/
      test_login.py
  conftest.py (wspólne fixture'y / setup)
src/
  api_clients/
    users_client.py
    auth_client.py
  utils/
    config.py
    data_generators.py
reports/
  ...

Analogicznie dla UI:

tests/
  ui/
    login/
      test_login_valid.py
      test_login_invalid.py
    checkout/
      test_add_to_cart.py
pages/
  login_page.py
  home_page.py
  checkout_page.py
core/
  driver_factory.py
  base_page.py

Kluczowy mechanizm: testy odwołują się do klienta API lub obiektów stron (Page Objects), a nie do „gołych” wywołań HTTP/webdrivera. Dzięki temu zmiana np. sposobu logowania nie wymaga refaktoru kilkudziesięciu plików testowych.

Page Object i klienci API w praktyce

Wzorzec Page Object i podejście z „clientami” API bywają nadużywane, ale w podstawowej formie ułatwiają życie.

Przykładowy client API (uproszczony):

class UsersClient:
    def __init__(self, http_client):
        self.http = http_client

    def create_user(self, payload):
        return self.http.post("/users", json=payload)

    def get_user(self, user_id):
        return self.http.get(f"/users/{user_id}")

Test zamiast klepać adresy URL i nagłówki „z palca”, korzysta ze spójnego interfejsu:

def test_create_and_get_user(users_client):
    create_resp = users_client.create_user(valid_user_payload())
    user_id = create_resp.json()["id"]

    get_resp = users_client.get_user(user_id)
    assert get_resp.status_code == 200
    assert get_resp.json()["id"] == user_id

Dla UI Page Object będzie wyglądał podobnie w koncepcji:

class LoginPage(BasePage):
    def open(self):
        self.driver.get(self.base_url + "/login")

    def login_as(self, username, password):
        self.find("#username").send_keys(username)
        self.find("#password").send_keys(password)
        self.find("#login-btn").click()

Test:

def test_login_valid(login_page, home_page):
    login_page.open()
    login_page.login_as("standard_user", "secret")
    home_page.assert_user_is_logged_in()

Cel jest jeden: przy czytaniu testu widać scenariusz biznesowy, a detale techniczne (lokatory, URL-e, nagłówki) żyją w jednej, kontrolowanej warstwie.

Konfiguracja, środowiska i dane testowe

Drugi kwartał to czas, kiedy testy zaczynają być wrażliwe na środowisko: adresy, klucze, użytkownicy, hasła. Trzymanie wszystkiego „na sztywno” w kodzie szybko się mści.

Praktyczne zasady:

• adresy bazowe, klucze API, ścieżki do driverów – w konfiguracji (np. plik YAML/JSON, zmienne środowiskowe),
• użytkownicy testowi – na poziomie danych, nie w treści testu:
  • np. funkcje admin_user(), standard_user(),
  • w bardziej zaawansowanej wersji – generowanie użytkownika „na świeżo” przed testem.
• rozróżnienie środowisk (dev/test/stage) – np. przez parametr w linii komend lub zmienną env.

Tip: nie zaczynaj od wielkiego systemu zarządzania konfiguracją. Wystarczy prosty plik konfiguracyjny i jedna, dwie funkcje pobierające wartości w kodzie.

Raportowanie: widoczność wyników zamiast fajerwerków

Raport testów jest tak dobry, jak szybko pozwala odpowiedzieć na pytanie: „co się wywaliło i dlaczego”. Na tym etapie wystarczy prosty, ale czytelny mechanizm.

Przykłady rozwiązań:

• pytest + wbudowany raport w konsoli + plugin do generowania HTML,
• JUnit + raporty XML zbierane przez CI i prezentowane jako „Test Results”,
• Allure / ExtentReports – gdy chcesz trochę bogatszy frontend (ale nie jest to must-have po 4–6 miesiącach).

Dobrą praktyką jest dołożenie do raportów:

• zrzutu ekranu przy testach UI w przypadku niepowodzenia,
• logów request/response przy testach API (status, URL, body, podstawowe nagłówki).

Prosty mechanizm: decorator/fixture, który „nasłuchuje” wyniku testu i jeśli jest fail, zapisuje potrzebne artefakty w katalogu raportów.

Stabilność i flaki: jak szybko przestać walczyć z „losowymi” błędami

Przy 20–30 testach UI pojawia się klasyczny problem: coś, co lokalnie działa, w CI pada co któryś build. Zazwyczaj powody są prozaiczne: brak synchronizacji, niestabilne lokatory, nieuporządkowane dane.

Kilka podstawowych mechanizmów stabilizacji:

• wprowadzenie jawnych waitów (explicit waits) zamiast sleep(),
• używanie stabilnych identyfikatorów (data-testid, data-cy) zamiast długich ścieżek XPath,
• czyszczenie i przygotowywanie danych przed testem zamiast polegania na „tym, co zostało w systemie”,
• izolacja testów – pojedynczy scenariusz nie powinien zależeć od wyniku innego.

Z kolei dla API główne pułapki to:

• testy zależne od konkretnych rekordów w bazie (np. „user o ID 1 zawsze istnieje”),
• brak sprzątania po sobie (tworzenie użytkowników, zamówień bez ich usuwania),
• współbieżność testów a ograniczenia systemu (limity requestów, blokady rekordów).

Dobrym nawykiem jest dopisanie krótkiego „checklistu stabilności” i przechodzenie przez niego przy każdym dziwnym, niereprodykowalnym błędzie.

Drugi projekt w kwartale: inne UI lub inne API

Gdy podstawowy projekt nabierze kształtu, sensownym ruchem jest sklonowanie koncepcji na inne środowisko:

• masz głównie testy API w pracy – zrób mały projekt UI na publicznej stronie (np. demo-shop),
• masz głównie UI – wybierz publiczne API i zbuduj mały framework testów API.

Nie chodzi o to, żeby mieć dwa „wypasione” frameworki, tylko o dywersyfikację doświadczenia. Otwarcie się na inne typy aplikacji pomaga później przy wyborze specjalizacji w trzecim i czwartym kwartale.

Miesiące 7–9: testy na różnych poziomach i praca „jak w projekcie”

Przejście z roli „twórcy skryptów” do roli członka zespołu

Po pół roku w automatyzacji można już wyjść poza perspektywę: „mam swoje testy”. Trzeci kwartał to dobry moment, żeby zacząć odwzorowywać warunki pracy w realnym zespole deweloperskim.

Elementy, na których warto się skupić:

• review kodu – przyzwyczajenie do czytania i komentowania cudzych zmian,
• utrzymanie istniejących testów przy zmianach w aplikacji,
• testy na różnych poziomach (component/integration, nie tylko end-to-end),
• rozsądne pokrycie – mniej „testów show-case”, więcej scenariuszy, które realnie łapią regresję.

Refaktoryzacja istniejącego frameworka

Framework zbudowany w Q2 zwykle jest funkcjonalny, ale rzadko elegancki. Zanim zaczniesz dopisywać kolejne dziesiątki przypadków, zrób jeden krok w tył.

Prosty plan refaktoryzacji:

Najważniejsze wnioski

• Przeskok z testów manualnych do automatyzacji w 12 miesięcy jest realny tylko wtedy, gdy potraktujesz go jak projekt: z etapami, priorytetami (najpierw programowanie i fundamenty techniczne, potem narzędzia i dopiero portfolio).
• Rola inżyniera automatyzacji to nie „szybsze klikanie”, ale tworzenie i utrzymanie systemu testów: kod testów, frameworki, integracja z CI/CD, analiza stabilności i kosztu utrzymania zestawu testów.
• Zmienia się odpowiedzialność: z wykonywania testów tu i teraz na projektowanie rozwiązań, które będą czytelne i utrzymywalne przez miesiące lub lata oraz współtworzenie procesu jakości (co automatyzujemy, a co testujemy ręcznie).
• Dzień pracy automatyka to głównie praca w IDE i terminalu: debugowanie niestabilnych testów, analiza logów z pipeline’ów, konflikty w repozytorium, konfiguracja środowisk (np. Docker, mocki), rozmowy z devami o zmianach w API czy UI.
• Kompetencje manualne są realnym kapitałem: myślenie testowe, znajomość domeny biznesowej, procesu wytwarzania i komunikacja z zespołem są bezpośrednio wykorzystywane przy projektowaniu sensownych testów automatycznych.
• Główna luka do zasypania to technikalia: przynajmniej jeden język programowania (z obiektowością), GIT i praca na repozytoriach, podstawy sieci/HTTP/API/baz danych oraz zrozumienie, jak działają pipeline’y CI/CD.
• Jeśli nie jesteś w stanie samodzielnie napisać prostego skryptu CLI (np. pobierającego dane z API i zapisującego je do pliku), pierwszy kwartał zmiany zawodowej musi być skoncentrowany na nauce programowania, a nie narzędzi testowych.