Jak przejść z testów manualnych na automaty: plan nauki i projekty do portfolio

Frameworki i narzędzia powiązane z wybranym językiem

Gdy język jest wybrany, pojawia się kolejne pytanie: „to teraz Selenium i do domu?”. Niekoniecznie. Wokół każdego języka istnieje ekosystem narzędzi, które albo ułatwiają życie, albo je skutecznie utrudniają. Dobór kilku sensownych narzędzi na start oszczędzi sporo frustracji.

• Test runner – coś, co uruchamia testy, grupuje je, daje raporty:
  • Java: JUnit, TestNG,
  • Python: pytest,
  • JS/TS: Jest, Mocha (często wbudowane w Playwright/Cypress).
• Narzędzia do testów UI:
  • klasyczne: Selenium WebDriver (Java, Python, C#, JS),
  • nowoczesne: Playwright, Cypress (JS/TS, Playwright też dla Pythona, Javy, .NET).
• Testy API:
  • Java: REST Assured,
  • Python: requests + pytest,
  • JS/TS: wbudowane klienty HTTP w Playwright/Cypress lub biblioteki axios, supertest.
• Build & dependency management – trzyma zależności i scenariusze uruchamiania:
  • Java: Maven lub Gradle,
  • Python: pip, poetry lub pipenv,
  • JS/TS: npm lub yarn, czasem pnpm.

Na początek wystarczy prosty zestaw: język + test runner + narzędzie do UI lub API. Całą resztę (raportowanie, integracje, gridy) można dobudowywać z czasem.

Czego unikać na starcie stosu technologicznego

Przy pierwszych krokach łatwo wpaść w pułapkę „dobiorę wszystko, co mają seniorzy w projekcie”. Efekt: 15 zależności, 8 pluginów i jedna osoba kompletnie zagubiona.

Na początek lepiej odpuścić sobie:

• zaawansowane rozwiązania chmurowe (BrowserStack, Sauce Labs, gridy w Kubernetesie) – lokalny Chrome i Firefox w zupełności wystarczą,
• nadmiar warstw abstrakcji – trzy poziomy dziedziczenia Page Objectów to o dwa za dużo,
• frameworki BDD typu Cucumber/Behave/SpecFlow, jeśli i tak testy piszesz sam dla siebie – opis w Gherkinie nie doda im magii, tylko więcej plików.

Najpierw prosty, czytelny kod testów. Dopiero gdy zaczynasz odczuwać ból powtarzalności lub bałagan, jest sens sięgać po cięższe działa.

Plan nauki – od zera do pierwszego frameworka (mapa 3–6 miesięcy)

Miesiąc 1: Fundamenty programowania i „oswojenie się z kodem”

Pierwszy etap nie musi być heroiczny. Celem jest swoboda w czytaniu prostego kodu i pisaniu krótkich skryptów, a nie kariera w data science.

• Przerób podstawowy kurs wybranego języka:
  • zmienne, typy danych, instrukcje warunkowe, pętle,
  • funkcje/metody, moduły, proste klasy/obiekty.
• Rozwiąż kilkanaście prostych zadań:
  • operacje na stringach, listach/tablicach, słownikach/mapach,
  • proste parsowanie danych (np. z pliku tekstowego lub JSON-a).
• Zainstaluj IDE lub edytor (IntelliJ, VS Code, PyCharm) i przyzwyczaj się:
  • otwieranie projektów,
  • uruchamianie skryptów,
  • korzystanie z autouzupełniania i podpowiedzi.

Zadanie minimalne na ten miesiąc: napisz kilka krótkich skryptów rozwiązujących drobne problemy z życia (np. zmiana nazw plików, proste przetwarzanie danych). Nie muszą być piękne – mają działać i oswajać Cię z kodem.

Miesiąc 2: Testy jednostkowe i małe automaty „bez przeglądarki”

Zanim pojawi się Selenium czy Playwright, dobrze jest zrozumieć, jak działają testy jako takie. UI dodaje sporo szumu, który potrafi zabić motywację.

• Poznaj test runnera:
  • tworzenie klasy/pliku z testami,
  • oznaczanie testów adnotacjami (np. @Test) lub funkcjami,
  • uruchamianie wszystkich testów i wybranych grup (tagi, nazwy).
• Naucz się asercji:
  • sprawdzanie wartości, list, wyjątków,
  • opisowe komunikaty błędów.
• Napisz kilka testów do własnych funkcji:
  • np. walidacja hasła, prosty kalkulator, parser JSON-a.

Na koniec tego etapu ma sens pierwszy kontakt z testami API bez UI:

• wybierz publiczne API (np. do pogody, filmów, walut),
• napisz funkcje do wysyłania zapytań,
• oprzyj na nich kilka testów sprawdzających status, pola w odpowiedzi, kody błędów.

Automaty nie muszą od razu klikać w przeglądarce. Testy API są prostsze technicznie, a uczą tych samych nawyków: asercje, organizacja kodu, setup/teardown.

Miesiąc 3: Wejście w testy UI i podstawy wzorca Page Object

Gdy fundamenty programowania i testów są ogarnięte, można dorzucić przeglądarkę. Tu przyda się cierpliwość – testy UI są najbardziej kapryśne.

• Zainstaluj i skonfiguruj framework UI:
  • Selenium, Playwright lub Cypress – zależnie od języka i stacku.
• Naucz się:
  • otwierania strony,
  • znajdowania elementów (lokatory: id, name, CSS, XPath),
  • klikania, wpisywania tekstu, odczytu tekstu z elementów,
  • prostych czekań (waitów) – unikaj wszędzie sleep().
• Stwórz swoje pierwsze Page Objecty:
  • oddziel definicje elementów i akcji od samych testów,
  • zadbaj o metody typu loginAs(user), searchFor(product).

Dobrym praktycznym celem na ten miesiąc jest zautomatyzowanie 2–3 prostych scenariuszy dla demo-aplikacji (np. rejestracja, logowanie, wyszukiwanie produktu). To będzie już zaczątek portfolio.

Miesiące 4–6: Utrwalanie, rozbudowa frameworka i projekty do portfolio

Kolejne miesiące to nie „uczenie się kolejnego kursu”, tylko systematyczne dokładanie kolejnych elementów do tego, co już masz.

• Rozbuduj testy UI:
  • dodaj kilka krytycznych ścieżek użytkownika (zakup, zmiana danych, filtrowanie),
  • zadbaj o ponowne użycie Page Objectów i helperów.
• Połącz UI + API:
  • w jednym projekcie miej zestaw testów API i UI,
  • w razie możliwości używaj API do przygotowania danych do testów UI.
• Dodaj raportowanie:
  • Java: Allure, ExtentReports,
  • Python/JS: raporty wbudowane w runner, pluginy do generowania HTML.
• Przygotuj skonfigurowane profile uruchamiania:
  • np. zestaw smoke, regresja, testy API osobno,
  • parametryzacja uruchomień (środowisko, przeglądarka).

Na tym etapie możesz zacząć odtwarzać w automatach scenariusze z realnych projektów, w których pracujesz manualnie. To robi różnicę podczas rozmowy rekrutacyjnej – nie pokazujesz tylko „testów na demo-sklepiku”, ale też kawałek prawdziwego świata.

Środowisko pracy i narzędzia – techniczny „setup” krok po kroku

Podstawowy zestaw: system, przeglądarka, IDE

Automatyzacja nie wymaga kosmicznego sprzętu, ale przydaje się porządek. Mniej „misternej konfiguracji”, więcej klikania „Run”.

• System operacyjny:
  • Windows – jak najbardziej ok, tylko zaprzyjaźnij się z PowerShellem,
  • Linux/Mac – wygodne terminale i narzędzia, ale nie są obowiązkowe.
• Przeglądarki:
  • Chrome/Chromium i Firefox to standard,
  • warto zainstalować też przynajmniej jedną dodatkową (Edge, Safari na Macu) do ręcznego sprawdzania zachowań.
• IDE/edytor:
  • Java/C#: IntelliJ IDEA, Visual Studio, Rider,
  • Python: PyCharm lub VS Code z pluginami,
  • JS/TS: VS Code jest często najwygodniejszym wyborem.

Zainstaluj także rozszerzenia deweloperskie przeglądarek (DevTools, selektory lokatorów) – pomagają szybko namierzać elementy, z których potem korzystasz w testach.

Git i GitHub/GitLab – bez tego portfolio nie istnieje

Kod testów, którego nikt nie może zobaczyć, ma ograniczoną wartość rekrutacyjną. Repozytorium z czytelną historią to właściwie Twoje CV techniczne.

• Zainstaluj Gita i skonfiguruj:
  • globalne dane użytkownika,
  • klucz SSH lub token do GitHuba/GitLaba.
• Naucz się podstawowych komend:
  • git clone, git status, git add, git commit, git push, git pull,
  • praca na branchach: git checkout -b, git merge.
• Ćwicz na własnych projektach:
  • każdy projekt testowy jako osobne repo,
  • opis w README.md – co to jest, jak uruchomić, co testuje.

Z punktu widzenia rekrutera repo z kilkoma sensownymi commitami mówi więcej niż dyplom z kursu. Pokazuje nie tylko kod, ale i sposób pracy.

Konfiguracja środowiska dla przykładowego stosu

Przykładowy scenariusz: Java + Maven + Selenium + JUnit. Analogicznie można przygotować setup Pythona czy JS.

1. Instalacja JDK:
   • zainstaluj najnowszą LTS (np. Java 17),
   • dodaj JAVA_HOME do zmiennych środowiskowych.
2. Instalacja IDE:
   • IntelliJ IDEA Community Edition w zupełności wystarczy na start.
3. Nowy projekt Maven:
   • utwórz projekt typu „Maven”,
   • w pom.xml dodaj zależności do JUnit i Selenium,
   • utwórz pierwszy pakiet na testy (np. src/test/java).
4. Pierwszy test:
   • otwarcie strony i sprawdzenie tytułu,
   • uruchomienie testu z poziomu IDE,
   • sprawdzenie, czy logi i raporty są czytelne.

Takie „hello world” w świecie automatyzacji jest ważniejsze, niż się wydaje – przechodzisz przez cały cykl: konfiguracja, kod, uruchomienie, rezultat.

CI/CD na poziomie juniora – minimum, które robi wrażenie

Nie trzeba konfigurować całego Jenkinsa w Kubernetesie, żeby pokazać, że rozumiesz ideę ciągłej integracji. Wystarczy prosty pipeline w GitHub Actions lub GitLab CI.

Prosty pipeline CI – krok po kroku na przykładzie GitHub Actions

Najbardziej „mięsny” element CI dla testów automatycznych to po prostu uruchomienie ich przy każdym pushu i pull requeście. Bez tysiąca pluginów i dashboardów.

1. Dodaj katalog na workflow:
   • utwórz folder .github/workflows w swoim repo,
   • w środku dodaj plik, np. tests.yml.
2. Skonfiguruj podstawowy workflow:

   name: Tests
   
   on:
     push:
       branches: [ main ]
     pull_request:
   
   jobs:
     tests:
       runs-on: ubuntu-latest
   
       steps:
         - name: Checkout repo
           uses: actions/checkout@v4
   
         - name: Setup Java
           uses: actions/setup-java@v4
           with:
             distribution: 'temurin'
             java-version: '17'
   
         - name: Build & test
           run: mvn -B clean test

   Dla Pythona/JS zmienia się tylko część z instalacją i komendą testów.

3. Dodaj badge do README:
   • weź link wygenerowany w zakładce „Actions”,
   • wklej do README.md – rekruter jednym rzutem oka widzi, że testy się odpalają.

Na początek wystarczy jedna prosta praca w CI. Jeśli działa stabilnie, dopiero wtedy ma sens dzielenie jej na smoke/regresję, różne środowiska itp.

Stabilność testów w CI – jak uniknąć „flakiness hell”

Nic tak nie psuje wizerunku testów jak czerwone buildy „od czasu do czasu” z powodu przypadkowych timeoutów.

• Deterministyczne dane:
  • unikać polegania na zewnętrznych, żywych API w każdym buildzie,
  • używać seedowanych danych testowych, mocków lub sandboxów.
• Rozsądne timeouty i czekania:
  • jasno określić maksymalny czas czekania na elementy,
  • nie maskować problemów ślepym wydłużaniem timeoutów „bo w CI wolniej”.
• Logi i screenshoty:
  • przy nieudanym teście UI robić zrzut ekranu i załączać go w raportach/paczkach artefaktów,
  • logować kluczowe kroki: which user, which URL, which API payload.

Im szybciej wyrobisz odruch: „test jest niestabilny => domykam temat od razu”, tym mniej wieczorów spędzisz na analizie „dlaczego w CI czasem jest na czerwono”.

Pierwsze projekty do portfolio – małe, ale sensowne

Jak wybierać pomysły na projekty, które coś pokazują

Dwa kryteria są kluczowe: zobaczalna wartość (scenariusze faktycznie coś sprawdzają) i rozsądny rozmiar (da się to utrzymać bez frustracji).

• Publiczne demo-aplikacje:
  • sklep internetowy, aplikacja do zadań, prosty CRM,
  • plus za takie, które mają publiczne API i UI jednocześnie.
• Własne mini-aplikacje:
  • prosta strona w stylu „lista zadań”,
  • niewielkie API napisane według tutoriala (np. CRUD użytkowników).
• Fragmenty świata rzeczywistego:
  • scenariusze z Twojej aktualnej pracy manualnej, o ile nie łamią NDA,
  • odtworzenie logiki, ale na zanonimizowanych danych lub na demo-klonie.

Lepiej pokazać 2–3 dopieszczone projekty niż 7 porzuconych repo z jednym testem „otwórz Googla”.

Projekt 1: Testy API dla publicznego serwisu

Dobry pierwszy projekt to zestaw testów API bez UI. Mniej problemów technicznych, szybki feedback, czy ogarniasz asercje i strukturę kodu.

• Zakres:
  • wybierz jedno, maksymalnie dwa zasoby (np. filmy i użytkownicy, produkty i koszyk),
  • sprawdź scenariusze: lista elementów, szczegóły, błędne zapytania.
• Struktura projektu:
  • pakiet/ folder z clients – klasy/funkcje wywołujące API,
  • tests – faktyczne testy, bez logiki HTTP,
  • osobny plik/klasa z konfiguracją (URL bazowy, klucze, środowisko).
• Zakres testów:
  • statusy odpowiedzi,
  • walidacja kluczowych pól w JSON-ie,
  • typowe błędy – nieautoryzowany dostęp, brak zasobu, walidacja pól.

Całość pokaże, że umiesz rozdzielić warstwę „mówienia do API” od samych asercji, no i że rozumiesz kody HTTP, a nie tylko „200 dobre, 500 złe”.

Projekt 2: Mini framework UI dla demo-sklepu

Drugi projekt może być klasycznym „sklepikiem” z kilkoma dobrze opisanymi ścieżkami użytkownika.

• Zakres funkcjonalny:
  • rejestracja/logowanie (jeśli jest),
  • wyszukiwanie produktu, dodanie do koszyka,
  • prosta ścieżka zakupu lub przynajmniej przejście do checkoutu.
• Architektura testów:
  • Page Objecty dla kluczowych ekranów: Home, Product, Cart, Checkout,
  • testy scenariuszy w stylu: test_guest_can_add_product_to_cart(),
  • helpery do zakładania konta, logowania, czyszczenia koszyka.
• Techniczny „smaczek”:
  • prosta konfiguracja przez parametry/zmienne środowiskowe: environment, browser,
  • raport HTML lub Allure, który można zlinkować w README.

Taki projekt pokazuje, że potrafisz wykorzystać Page Objecty w praktyce, ogarnąć podstawowe czekania, a testy są czymś więcej niż „sprawdź tytuł strony”.

Projekt 3: Połączenie UI + API w jednym repo

Tu zaczyna się materiał, który zwykle robi wrażenie na rozmowach – spójny projekt łączący różne typy testów.

• Cel:
  • w jednym repo mieści się framework do testów API i UI,
  • API przygotowuje dane, UI je weryfikuje (lub odwrotnie).
• Przykładowy scenariusz:
  • API tworzy użytkownika lub zamówienie,
  • UI loguje się na tego użytkownika i sprawdza, czy widać poprawne dane,
  • API sprawdza później konsekwencje akcji z UI (np. zmiana statusu zamówienia).
• Organizacja projektu:
  • oddzielne moduły/foldery api i ui,
  • wspólna konfiguracja środowisk,
  • jeden runner (Maven/pytest/npm) do odpalania różnych zestawów testów.

Taki projekt pokazuje już myślenie systemowe: rozumiesz, że UI to tylko jedna z warstw, a prawdziwe życie dzieje się w API i bazie danych.

Opis projektów w README – co musi się tam znaleźć

Repozytorium bez opisu wygląda na porzucone. Kilka konkretnych sekcji w README robi ogromną różnicę.

• Krótki opis:
  • 2–3 zdania: co to jest, jakie technologie, jaki typ testów.
• Instrukcja uruchomienia:
  • wymagane narzędzia (JDK, Python, Node, Maven, itp.),
  • konkretne komendy: mvn test, pytest, npm test,
  • jak ustawić zmienne środowiskowe (URL, klucze API).
• Zakres testów:
  • wymienione główne scenariusze,
  • krótka notka, jakie decyzje architektoniczne podjąłeś (np. dlaczego taki framework).
• Przykładowe raporty:
  • link/ screenshot do raportu HTML lub Allure,
  • ewentualnie link do logów z CI (GitHub Actions / GitLab CI).

Rekruter techniczny często otwiera tylko README i parę plików z testami. Jeśli tam jest klar i porządek, połowa sukcesu za Tobą.

Rozwijanie projektów zamiast produkcji „jednorazówek”

Zamiast co tydzień zakładać nowe repo, lepiej wracać do 1–2 projektów i regularnie je szlifować. To mocno przypomina realną pracę.

• Iteracyjne dodawanie funkcji:
  • dokładasz nowe testy, gdy poznasz nowy wzorzec (np. parametryzację, data-driven),
  • refaktorujesz Page Objecty, gdy zaczynają puchnąć.
• Eksperymenty na branchach:
  • tworzysz branch typu refactor/waits lub feature/api-client-v2,
  • po udanym eksperymencie mergujesz do głównej gałęzi.
• Changelog w README lub pliku CHANGELOG:
  • krótkie wpisy: co doszło, co poprawione,
  • ładnie pokazuje, że projekt żyje, a nie jest efektem jednego kursu online.

Taki rozwijany projekt staje się z czasem Twoim poligonem. To na nim możesz testować nowe biblioteki, wzorce, konfiguracje CI – bez ryzyka, że „zepsujesz projekt produkcyjny”.

Jak mówić o projektach na rozmowie rekrutacyjnej

Kod w repo to jedno. Drugie – umiejętność sensownego opowiedzenia, co tam właściwie zrobiłeś i dlaczego.

• Podkreśl problemy i decyzje:
  • „Miałem problem z niestabilnymi testami na tym ekranie, rozwiązałem to przez…”,
  • „Zastanawiałem się między biblioteką X i Y, wybrałem X, bo…”.
• Pokazuj proces, nie tylko efekt:
  • jak wygląda Twój typowy cykl: nowy scenariusz → analiza → implementacja → refaktor,
  • jak reagujesz na czerwone testy: analiza logów, odtwarzanie błędu, korekta.
• Łącz projekty z praktyką manualną:
  • „Ten scenariusz wynika z błędów, które często widzę przy testach manualnych checkoutu…”,
  • „Ten typ regresji zawsze był upierdliwy ręcznie, więc zrobiłem z niego pierwszy smoke w automatach”.

Przy takim podejściu nawet prosty projekt przestaje wyglądać jak „zadanie z kursu”, a zaczyna jak miniaturowy fragment prawdziwej pracy automatyzującej testera.

Kluczowe Wnioski

• Tester manualny ma solidną bazę do automatyzacji: zna procesy, narzędzia typu Jira/TestRail, rozumie ryzyko w systemie i problemy użytkowników – brakuje mu głównie obycia technicznego (IDE, terminal, podstawy kodu).
• Przejście na automatyzację to zmiana sposobu pracy, a nie zawodu na „programistę” – nadal testujesz, tylko coraz więcej robisz przez kod, budując skrypty, warstwy abstrakcji i dbając o utrzymanie testów.
• Największe blokady to mity: nie trzeba poziomu mida z programowania, wieloletnie doświadczenie manualne nie jest przeszkodą, automatyzacja to znacznie więcej niż Selenium, a kompletna „encyklopedyczna” wiedza nie jest warunkiem startu.
• Decyzję o wejściu w automatyzację warto oprzeć na trzech filarach: min. 1–2 lata sensownej praktyki manualnej, realne potrzeby rynku (wymagane technologie, widełki, oferty z możliwością rozwoju) oraz gotowość do systematycznej nauki po godzinach.
• Realistyczny horyzont przejścia to zwykle 3–9 miesięcy przy pracy na etat; przy regularnych 2–3 godzinach dziennie da się w kilka miesięcy zbudować portfolio 2–3 projektów i zacząć sensownie aplikować na role automation (nie da się tego „pyknąć” w dwa weekendy).
• Bez mocnych fundamentów testerskich automatyzacja nie ma sensu – nadal kluczowe są analiza wymagań, projektowanie przypadków testowych i myślenie o ryzyku; kiepskie testy manualne przełożone na kod stają się tylko „szybciej działającym bublem”.