Praca jako tester oprogramowania: 15 pytań, na które musisz znać odpowiedź

Praca jako tester oprogramowania polega na sprawdzaniu, czy system działa tak, jak powinien, i na dostarczaniu zespołowi informacji o ryzyku, zanim produkt trafi do użytkowników. Na rozmowie rekrutacyjnej na stanowisko junior QA prawie zawsze padają te same pytania. Poniżej zebraliśmy 15 z nich, każde z wyjaśnieniem, czego naprawdę szuka rekruter, i z przykładem dobrej odpowiedzi.

Lista powstała z myślą o osobach, które szukają pierwszej pracy w testowaniu albo przebranżawiają się do IT. Nie uczcie się odpowiedzi na pamięć: rekruter po trzecim zdaniu słyszy, czy mówicie własnymi słowami, czy cytujecie definicję. Traktujcie przykłady jako szkielet, który wypełniacie własnym doświadczeniem z kursu, projektu stażowego albo poprzedniej pracy.

Jak korzystać z tej listy pytań?

Pytania ułożyliśmy od ogólnych do praktycznych. Pierwsze sześć sprawdza, czy rozumiecie podstawowe pojęcia, w dużej mierze zgodne z sylabusem ISTQB Foundation Level 4.0. Kolejne pięć sprawdza, czy umiecie te pojęcia zastosować. Ostatnie cztery dotyczą narzędzi, programowania i pieniędzy, czyli tematów, które pojawiają się zwykle pod koniec rozmowy.

1. Co robi tester oprogramowania, w tym tester manualny?

Tester analizuje wymagania, projektuje przypadki testowe, wykonuje testy, zgłasza i weryfikuje defekty oraz raportuje, jakie ryzyko zostaje przed wydaniem. Tester manualny robi to bez skryptów automatycznych: klika, wpisuje dane, porównuje wynik z oczekiwanym i szuka miejsc, o których nikt nie pomyślał. Duża część dnia to rozmowa: z analitykiem o niejasnym wymaganiu, z programistą o zgłoszonym błędzie, z właścicielem produktu o tym, co jest ważniejsze.

Dobra odpowiedź na rozmowie: „Tester dostarcza informacji o jakości, żeby zespół mógł podjąć decyzję o wydaniu. Na co dzień czytam wymagania i dopytuję o niejasności, projektuję i wykonuję testy, zgłaszam defekty z krokami do odtworzenia i sprawdzam poprawki.”

Pełny opis obowiązków i wymagań z ogłoszeń znajdziecie w tekście o obowiązkach i wymaganiach wobec testera oprogramowania, a o testach manualnych więcej w artykule testy manualne: czyli co?.

2. Czym różni się testowanie od zapewniania jakości (QA)?

Testowanie sprawdza produkt i szuka w nim defektów. Zapewnianie jakości (quality assurance) dotyczy procesu: jak zespół pracuje, żeby defektów powstawało mniej. Sylabus ISTQB rozróżnia to wprost: testowanie jest działaniem nastawionym na produkt i formą kontroli jakości, a QA jest nastawione na proces. Na rozmowie wystarczy pokazać, że rozumiecie, dlaczego tester, który zgłasza ten sam typ błędu piąty raz, powinien zaproponować zmianę w procesie, a nie tylko piąte zgłoszenie.

Szczegółowo różnicę opisujemy w artykule co to jest QA i czym różni się od testera oprogramowania.

3. Czym różni się błąd, defekt i awaria?

To jedno z ulubionych pytań, bo sprawdza precyzję języka. Według sylabusa ISTQB Foundation Level 4.0 człowiek popełnia błąd (pomyłkę), który wprowadza defekt do kodu albo dokumentu, a defekt po wykonaniu może wywołać awarię, czyli widoczne niepoprawne zachowanie systemu. Nie każdy defekt kończy się awarią, a awarię mogą wywołać także warunki środowiskowe.

Dobra odpowiedź na rozmowie: „Programista pomylił znak w warunku, to błąd. W kodzie jest teraz zły warunek, to defekt. Klient z koszykiem za dokładnie 200 zł nie dostaje rabatu, to awaria.”

4. Jakie są poziomy testów?

Sylabus ISTQB 4.0 wymienia pięć poziomów: testy komponentów (jednostkowe), integracji komponentów, systemowe, integracji systemów i akceptacyjne. Jeśli powiecie „cztery: jednostkowe, integracyjne, systemowe i akceptacyjne”, nikt Was nie skreśli, ale dopowiedzenie, że w wersji 4.0 integrację rozdzielono na dwa poziomy, pokazuje, że uczyliście się z aktualnych materiałów. Każdy poziom pokazujemy na jednym przykładzie kodu rabatowego w artykule o poziomach testowania oprogramowania.

5. Czym różnią się testy funkcjonalne od niefunkcjonalnych?

Testy funkcjonalne sprawdzają, co system robi: czy liczy, zapisuje i wyświetla to, co powinien. Testy niefunkcjonalne sprawdzają, jak to robi: czy jest wystarczająco szybki, bezpieczny, dostępny i wygodny. Dobry przykład na rozmowie: „Logowanie działa, to wynik testu funkcjonalnego. Logowanie trwa 9 sekund przy 500 użytkownikach, to wynik testu wydajności.” Rozwinięcie znajdziecie w tekście o testach niefunkcjonalnych.

6. Czym różni się retest od testu regresyjnego?

Retest, w ISTQB nazywany testem potwierdzającym, sprawdza, czy konkretny defekt został naprawiony. Test regresyjny sprawdza, czy zmiana, także ta poprawka, nie zepsuła czegoś innego: w tym samym module, w innych modułach albo w systemach połączonych. Regresja nie jest metodą testowania manualnego. Sylabus ISTQB wprost nazywa ją mocnym kandydatem do automatyzacji, bo zestaw testów regresyjnych uruchamia się wiele razy i rośnie z każdym wydaniem.

Dobra odpowiedź na rozmowie: „Po poprawce najpierw robię retest zgłoszonego przypadku. Potem uruchamiam regresję obszarów, których mogła dotknąć zmiana, najlepiej automatyczną w potoku CI, a zakres ustalam na podstawie analizy wpływu.”

Jak w praktyce skrócić regresję, pokazujemy w case study Argos: w projekcie dla tego klienta z branży e-commerce czas regresji przed wydaniem spadł z 5 dni do 10 godzin, co opisujemy w artykule jak skrócić testy regresyjne z 5 dni do 10 godzin.

7. Jakie znacie techniki projektowania testów?

Sylabus ISTQB 4.0 opisuje cztery techniki czarnej skrzynki, które junior powinien umieć zastosować: podział na klasy równoważności, analizę wartości brzegowych, tablice decyzyjne i testowanie przejść między stanami. Do tego techniki oparte na doświadczeniu: zgadywanie błędów, testowanie eksploracyjne i testowanie na podstawie list kontrolnych. Nie wystarczy wymienić nazw. Rekruter prawie zawsze poprosi o przykład, więc przejdźcie od razu do pytania 8.

8. Jak zaprojektujecie przypadki testowe dla pola „wiek”?

To klasyczne zadanie praktyczne. Załóżmy wymaganie: formularz przyjmuje wiek od 18 do 65 lat włącznie, liczby całkowite. Połączenie klas równoważności i wartości brzegowych daje krótki, mocny zestaw:

Wymaganie: wiek od 18 do 65 lat włącznie, liczba całkowita

Klasy równoważności:
  poniżej zakresu   (np. 10)   -> błąd walidacji
  w zakresie        (np. 40)   -> zapis
  powyżej zakresu   (np. 80)   -> błąd walidacji

Wartości brzegowe (dwie wartości na granicę):
  17 -> błąd    18 -> zapis
  65 -> zapis   66 -> błąd

Dane spoza typu:
  puste pole, "abc", 18.5, -1, spacja przed liczbą

Dobra odpowiedź kończy się pytaniem do rekrutera, a nie listą: „Czy pole jest obowiązkowe? Co ma się stać z wartością 18,0?”. Tester, który dopytuje o niejasność wymagania, jest cenniejszy niż tester, który zna wszystkie definicje. Rozpisywanie takich zestawów ćwiczymy na szkoleniu tester manualny: kurs kompleksowy.

9. Jak zgłosicie błąd, żeby nikt go nie odrzucił?

Dobre zgłoszenie da się odtworzyć bez rozmowy z autorem. Minimum to: krótki tytuł mówiący, co się dzieje i gdzie, środowisko i wersja, kroki do odtworzenia, wynik oczekiwany i faktyczny, waga i priorytet, a do tego zrzut ekranu, nagranie albo fragment logu. Tytuł „Nie działa koszyk” zostanie odbity. Tytuł „Koszyk: kod WIOSNA10 nie obniża ceny przy kwocie dokładnie 200 zł” zostanie naprawiony. Wzory zgłoszeń i najczęstsze błędy w raportach opisujemy w przewodniku jak poprawnie zgłosić błąd.

10. Co zrobicie, gdy programista mówi, że to nie błąd?

To pytanie sprawdza dojrzałość, nie wiedzę. Zła odpowiedź to „będę obstawać przy swoim”. Dobra zaczyna się od źródła prawdy: wymagania, kryteria akceptacji, ustalenia z właścicielem produktu. Jeśli wymaganie jest jasne, pokazujecie je spokojnie, bez wytykania. Jeśli jest niejasne, prosicie właściciela produktu o decyzję i zapisujecie ją w zgłoszeniu. W każdym zespole znajdzie się defekt, który ktoś nazwie „nieudokumentowaną funkcją”; Waszym zadaniem jest sprawić, żeby został udokumentowany albo naprawiony, a nie wygrać dyskusję.

11. Czym jest testowanie eksploracyjne?

Testowanie eksploracyjne to jednoczesne poznawanie systemu, projektowanie testów i ich wykonywanie, zwykle w sesjach ograniczonych czasem i z jasno określonym celem (kartą sesji). To nie jest testowanie „bez planu”: plan istnieje, tylko nie ma postaci gotowych skryptów. Sprawdza się, gdy specyfikacja jest uboga, gdy czasu jest mało albo gdy chcecie znaleźć błędy, których nie przewidziały scenariusze. Na rozmowie dobrze opisać jedną sesję: cel, czas, co znaleźliście. Metodę ćwiczymy na szkoleniu testy eksploracyjne i heurystyczne w praktyce.

12. Czy testuje się na produkcji?

Tak, ale świadomie i nie zamiast testów wcześniej. Testowanie na produkcji to na przykład testy dymne zaraz po wdrożeniu, monitorowanie błędów i wydajności, testy A/B oraz udostępnianie funkcji części użytkowników przez przełączniki funkcji. Podejście to nazywa się shift right i opisujemy je w artykule o shift right testing. Zła odpowiedź: „testujemy na produkcji, bo nie ma środowiska testowego”. Dobra: „na produkcji sprawdzamy to, czego nie da się wiarygodnie odtworzyć wcześniej, i robimy to bez ryzyka dla danych klientów”. Jak takie testy wyglądają w usłudze dla firm, pokazuje strona testów oprogramowania Quality Island.

13. Jakie narzędzia powinien znać junior tester?

Nie musicie znać wszystkiego. Na start wystarczy zestaw, z którym pracuje większość zespołów:

• Jira albo podobny system zgłoszeń, razem z narzędziem do zarządzania przypadkami testowymi.
• Narzędzia deweloperskie przeglądarki (DevTools): zakładka sieci, konsola, podgląd elementów.
• Postman do testów API. Według Just Join IT testowanie API było w 2025 roku jedną z umiejętności, których pracodawcy szukali u testerów najczęściej.
• SQL na poziomie zapytań SELECT z warunkami i złączeniami, żeby sprawdzić dane po wykonaniu testu.
• Podstawy jednego narzędzia do automatyzacji: dziś najczęściej Playwright, Cypress albo Selenium WebDriver.
• Git w podstawowym zakresie, jeśli celujecie w automatyzację.

Testy API ćwiczycie na szkoleniu wprowadzenie do testowania API w Postmanie, a zapytania do bazy na szkoleniu język SQL dla testerów.

14. Czy tester musi umieć programować?

Na stanowisko testera manualnego zwykle nie, ale rynek wyraźnie przesuwa się w stronę testerów, którzy potrafią zautomatyzować własne testy. Raport wynagrodzeń Just Join IT z 2026 roku (dane za 2025 rok) wskazuje automatyzację testów, integrację testów z CI/CD, testy API, testy wydajności i praktyki shift left jako najbardziej poszukiwane kompetencje w testowaniu, a jako drogę do wyższych stawek podaje role SDET i test architect. Na rozmowie warto więc powiedzieć, czego już się uczycie i w jakim języku.

Pytanie o zalety i wady automatyzacji często pada w tym samym miejscu. Krótka, uczciwa odpowiedź: automatyzacja daje szybkie i powtarzalne sprawdzenie regresji przy każdej zmianie, ale kosztuje czas na napisanie i utrzymanie testów, więc nie automatyzujemy rzeczy jednorazowych ani tych, których wymagania zmieniają się co tydzień. Szerzej o bilansie piszemy w artykule zalety i wady automatyzacji testów. Jeśli blokuje Was przekonanie, że „nie jesteście techniczni”, przeczytajcie tekst Strefy QA o trzech mitach, które blokują start w QA.

15. Ile zarabia tester oprogramowania?

Według Raportu Wynagrodzeń IT 2026 serwisu Just Join IT, opartego na danych za 2025 rok, kategoria Testing stanowiła 7,06 procent ofert pracy w IT i zajęła piąte miejsce pod względem popularności. Średnie wynagrodzenie w ofertach wyniosło 12 250 zł brutto na umowie o pracę i 14 863 zł netto na fakturze w modelu B2B, a w ciągu roku wzrosło o 3,2 procent.

Co z tego wynika dla Was? Na rozmowie podawajcie oczekiwania oparte na danych z aktualnego raportu, a nie na wpisach sprzed lat, i pamiętajcie, że najszybciej rosną stawki osób łączących testy manualne z automatyzacją i testami API. Ile kosztuje zespół QA z perspektywy pracodawcy, liczymy w artykule koszt zespołu QA: własny zespół czy outsourcing.

Co zrobić po przeczytaniu tej listy?

Wybierzcie trzy pytania, przy których odpowiedź przyszła Wam najtrudniej, i przygotujcie do nich własne przykłady z kursu, projektu albo poprzedniej pracy. Potem przećwiczcie zadanie praktyczne z pytania 8 na innym polu: kodzie pocztowym, dacie urodzenia albo kwocie przelewu. Rekruterzy pamiętają kandydatów, którzy pokazali sposób myślenia, nie tych, którzy wyrecytowali definicję.

Z naszego doświadczenia rekrutacyjnego wynika, że najwięcej punktów daje dowód praktyki: repozytorium z kilkoma testami, przykładowy raport z testów, opis jednej sesji eksploracyjnej. Quality Island rekrutuje i dostarcza specjalistów IT do dużych firm, a w szkoleniach przeszkoliliśmy już ponad 2500 specjalistów, więc wiemy, jak bardzo taki dowód skraca rozmowę. Jeśli chcecie zdobyć go w realnym projekcie, sprawdźcie projekt szkoleniowo stażowy dla testera manualnego. Oferty pracy i profile kompetencyjne testerów znajdziecie na QA Board, platformie łączącej specjalistów QA z firmami. O szerszej ścieżce wejścia do zawodu piszemy w przewodniku jak zostać testerem oprogramowania, a o tym, co odróżnia dobrego testera po kilku latach, w artykule tester oprogramowania: jak osiągnąć sukces w testowaniu.

Powiązane na blogu Quality Island

• Jak zostać testerem oprogramowania: ścieżka krok po kroku
• 15 rzeczy, których powinien nauczyć się każdy junior tester
• Certyfikat ISTQB: poziomy, egzamin i czy warto
• Poziomy testowania oprogramowania: pięć poziomów ISTQB na jednym przykładzie
• Testy regresyjne: rodzaje, kiedy je uruchamiać i jak skrócić regresję

Pełna lista źródeł

• Just Join IT, Raport Wynagrodzeń IT w Polsce 2026, statystyki kategorii Testing, dane za 2025 rok. Stąd udział w ofertach, średnie i stawki według poziomu, wzrost rok do roku, oczekiwania juniorów i najbardziej poszukiwane kompetencje.
• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024 (wersja 4.0 wydana 21.04.2023). Stąd definicje błędu, defektu i awarii, pięć poziomów testów, test potwierdzający i regresja, techniki projektowania testów.
• Martin Fowler, Ham Vocke, The Practical Test Pyramid, 2018. Tło dla pytań o automatyzację i proporcje testów.
• Microsoft Playwright, dokumentacja Playwright, stan na 2026. Punkt startu do nauki automatyzacji.
• Dane własne Quality Island, 2026: ponad 2500 przeszkolonych specjalistów, case study Argos z liczbami potwierdzonymi przez klienta.