Tester manualny w erze AI: co robi w 2026 roku, czego się od niego wymaga i jaką ma przyszłość?

Tech Lead zespołu budującego aplikację bankowości internetowej dostaje od zarządu pytanie: „Skoro kupiliśmy narzędzie AI do generowania testów, czy nadal potrzebujemy dwóch testerów manualnych?”. Narzędzie rzeczywiście działa. W ciągu tygodnia wygenerowało kilkaset przypadków testowych na podstawie historyjek użytkownika i przepisało część z nich na skrypty. Trzy tygodnie później, podczas ręcznej sesji eksploracyjnej, jeden z testerów zauważa, że przelew na kwotę z przecinkiem wpisaną z klawiatury numerycznej telefonu przechodzi walidację z inną kwotą niż ta wyświetlona klientowi. Żaden z wygenerowanych testów tego nie sprawdzał, bo żadna historyjka nie opisywała klawiatury numerycznej.

To nie jest argument przeciwko AI w testowaniu. To opis tego, jak w 2026 roku zmieniła się rola testera manualnego: mniej ręcznego wykonywania scenariuszy, które da się zapisać, więcej pracy tam, gdzie scenariusza nie ma — w eksploracji, ocenie użyteczności, dostępności, wiedzy domenowej i weryfikacji tego, co wygenerowała maszyna.

Ogólne przewodniki po zawodzie już opublikowaliśmy — kim jest tester oprogramowania i jak zostać testerem. Tutaj skupiamy się na jednym stanowisku i jednym pytaniu, które zadaje dziś wielu Tech Leadów: co konkretnie robi tester manualny w zespole, który używa AI, ile to jest warte i jak zbudować wokół tej roli zespół QA, który nie marnuje ani ludzi, ani narzędzi.

Czym zajmuje się tester manualny w 2026 roku na co dzień?

Tester manualny to specjalista, który weryfikuje oprogramowanie, używając go tak jak użytkownik — bez pisania kodu testów. Ta definicja się nie zmieniła. Zmieniła się proporcja zadań w jego tygodniu pracy.

Jeszcze kilka lat temu duża część pracy testera manualnego w typowym projekcie polegała na wykonywaniu tych samych scenariuszy regresji przed każdym wydaniem: logowanie, rejestracja, koszyk, płatność, raport. W zespołach, które mają dziś rozsądnie rozwiniętą automatyzację i korzystają z narzędzi AI, codzienny zakres pracy testera manualnego wygląda inaczej:

• Analiza wymagań przed implementacją. Tester czyta historyjki i kryteria akceptacji, zanim programista zacznie pracę, i zadaje pytania o przypadki brzegowe. Błąd znaleziony w wymaganiach nie wymaga poprawki w kodzie.
• Testy eksploracyjne nowych funkcji. Sesje ograniczone czasowo, prowadzone według karty testu (celu sesji), bez gotowego scenariusza. To główne źródło błędów, których nikt nie przewidział.
• Ocena użyteczności i spójności. Czy komunikat błędu jest zrozumiały, czy ścieżka ma sens dla klienta, czy nowa funkcja zachowuje się spójnie z resztą aplikacji.
• Testy dostępności. Sprawdzanie aplikacji z czytnikiem ekranu, samą klawiaturą, powiększeniem i ustawieniami systemowymi — o czym szerzej niżej.
• Weryfikacja wyników AI. Przegląd przypadków testowych i danych wygenerowanych przez narzędzia, ocena, czy pokrywają ryzyka, a nie tylko tekst wymagań.
• Testy akceptacyjne z biznesem. Wspólne sesje z właścicielem produktu lub użytkownikami kluczowymi przed wydaniem.
• Raportowanie i triaż. Opisanie błędu tak, żeby programista mógł go odtworzyć, i ocena jego wpływu na biznes.

Jak to wygląda w praktyce? Weźmy przykładowy dwutygodniowy sprint zespołu aplikacji mobilnej sklepu internetowego, w którym pracuje jeden tester manualny. W pierwszych dniach sprintu tester uczestniczy w doprecyzowaniu trzech historyjek: nowej metody płatności, zmiany w koszyku i programu lojalnościowego. Przy płatności pyta, co się dzieje, gdy klient zamknie aplikację w trakcie autoryzacji w banku — tej sytuacji nie było w wymaganiach, a jej obsługa staje się osobnym kryterium akceptacji. Narzędzie AI generuje szkic kilkudziesięciu przypadków testowych, z których tester usuwa duplikaty i dopisuje przypadki wynikające z wiedzy o tym, jak klienci naprawdę korzystają z koszyka.

W połowie sprintu, gdy pierwsza wersja płatności działa na środowisku testowym, tester prowadzi dwie godzinne sesje eksploracyjne: jedną skupioną na przerwanych transakcjach, drugą na słabym zasięgu i przełączaniu między Wi-Fi a siecią komórkową. Znajduje dwa błędy, których nie przewidział żaden scenariusz. Pod koniec sprintu sprawdza nowy ekran z czytnikiem ekranu i powiększeniem tekstu, a ze zgłoszeń z produkcji z poprzedniego wydania wybiera trzy powtarzające się problemy i przekazuje je do automatyzacji. Regresji całej aplikacji nie wykonuje ręcznie — robią to testy automatyczne uruchamiane przy każdej zmianie.

Różne rodzaje testów manualnych — czarnoskrzynkowe, szaroskrzynkowe, akceptacyjne — opisaliśmy w artykule o rodzajach testów manualnych. Tu ważniejsze jest przesunięcie akcentu: tester manualny w 2026 roku coraz rzadziej jest „ręcznym wykonawcą scenariuszy”, a coraz częściej osobą, która odpowiada za to, czego scenariusze nie obejmują.

Które zadania testera manualnego AI realnie przejmuje?

Skala zmian jest duża, ale mniejsza, niż sugerują materiały marketingowe dostawców narzędzi. W World Quality Report 2025-26, przygotowanym przez Capgemini, Sogeti i OpenText, 89% organizacji pilotuje lub wdraża przepływy pracy wspierane przez AI generatywną w obszarze jakości. W produkcji ma je jednak 37%, a w skali całego przedsiębiorstwa — tylko 15%. Najczęściej wskazywane bariery to ryzyka związane z prywatnością danych (67%), złożoność integracji (64%) i luki kompetencyjne (50%).

W zespołach, w których narzędzia AI działają już produkcyjnie, najwięcej zmieniło się w pięciu obszarach:

1. Szkice przypadków testowych. Model językowy na podstawie historyjki użytkownika tworzy w kilka sekund listę scenariuszy, którą tester wcześniej pisał godzinę. Szkic wymaga przeglądu, ale praca przesuwa się z pisania na redagowanie.
2. Dane testowe. Generowanie realistycznych danych — adresów, numerów kont w poprawnym formacie, zestawów przypadków brzegowych — przestało być ręczną pracą.
3. Regresja powtarzalnych ścieżek. Narzędzia, które na podstawie opisu w języku naturalnym wykonują test w przeglądarce, przejmują część scenariuszy, które wcześniej klikał człowiek, bo automatyzacja w kodzie była za droga.
4. Porównania wizualne. Wykrywanie nieoczekiwanych zmian w interfejsie między wersjami.
5. Streszczanie i grupowanie zgłoszeń. Łączenie duplikatów błędów, streszczanie logów, propozycje kroków do odtworzenia.

Wspólną cechą tych zadań jest to, że wynik da się opisać z góry. Jeśli wiesz, co ma się stać, maszyna potrafi to sprawdzić — szybciej i taniej niż człowiek. Szerzej o tym, gdzie przebiega granica między automatyzacją a pracą ręczną, piszemy w artykule o testach automatycznych i manualnych w 2026 roku.

Czego AI w testowaniu nie przejmie i dlaczego?

Odwrotna zasada wyznacza obszar, który zostaje po stronie człowieka: tam, gdzie oczekiwanego wyniku nie da się opisać z góry, potrzebny jest osąd. W praktyce to cztery obszary.

Testy eksploracyjne. Tester, który podczas sesji zauważa, że pole kwoty zachowuje się inaczej na klawiaturze numerycznej telefonu, nie realizuje scenariusza — tworzy go na bieżąco, na podstawie tego, co właśnie zobaczył. Model generujący testy z wymagań odtwarza wiedzę zapisaną w wymaganiach. Tester eksploracyjny szuka wiedzy, której w nich nie ma. Technikę opisaliśmy w artykule o testowaniu eksploracyjnym, a pojęcie w słowniku.

Wiedza domenowa. Tester w projekcie bankowym wie, że przelew natychmiastowy ma inne limity niż zwykły, a księgowanie w dniu wolnym od pracy działa według innych zasad. Tester w projekcie medycznym wie, że dawka leku podana w złych jednostkach to nie „błąd walidacji”, tylko zagrożenie życia. Ta wiedza rzadko jest w pełni zapisana w dokumentacji, więc narzędzie nie ma jej skąd wziąć.

Ocena doświadczenia użytkownika. Formularz może przejść wszystkie testy funkcjonalne i nadal być mylący. Ocena, czy komunikat „Operacja nie powiodła się (kod 4012)” jest akceptowalny dla klienta banku, wymaga empatii i znajomości kontekstu, a nie porównania z oczekiwanym wynikiem.

Odpowiedzialność. Decyzja „ten błąd blokuje wydanie” ma skutki biznesowe. Ktoś musi ją podjąć i za nią odpowiadać. W regulowanych branżach — finansach, medycynie — ta odpowiedzialność jest wymagana formalnie.

Do tych czterech obszarów dochodzą dwa nowe, które w ostatnich dwóch latach urosły najszybciej: testy dostępności i testowanie samych systemów AI.

Dlaczego testy dostępności stały się od czerwca 2025 roku pracą dla testera manualnego?

28 czerwca 2025 roku zaczął obowiązywać Europejski Akt o Dostępności (EAA), wdrożony w Polsce ustawą z 26 kwietnia 2024 roku o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Przepisy obejmują m.in. handel elektroniczny, usługi bankowe dla konsumentów, telekomunikację, e-booki i elementy usług transportowych. Mikroprzedsiębiorstwa świadczące usługi są z nich zwolnione. Za naruszenia grożą kary administracyjne — w Polsce do dziesięciokrotności przeciętnego wynagrodzenia, nie więcej niż 10% obrotu — poprzedzone wezwaniem do usunięcia niezgodności.

Technicznym punktem odniesienia jest norma EN 301 549, której obecna wersja odwołuje się do wytycznych WCAG 2.1 na poziomie AA. Kolejna wersja normy ma uwzględnić WCAG 2.2, opublikowane przez W3C w 2023 roku.

Dlaczego to praca dla testera manualnego, a nie dla narzędzia? Bo narzędzia automatyczne wykrywają tylko część problemów. Brytyjski Government Digital Service przeprowadził audyt, w którym celowo wprowadził 142 bariery dostępności na jedną stronę i sprawdził ją 13 narzędziami automatycznymi. Najlepsze narzędzie znalazło 40% barier, najsłabsze — 13%. Wszystkie pominęły m.in. problemy z kolejnością czytania, brak widocznego wskaźnika fokusu i znaczenie przekazywane wyłącznie kolorem.

Przełożenie na praktykę jest proste: automatyczny skan w pipeline to warunek konieczny, ale nie wystarczający. Resztę sprawdza człowiek — przechodząc ścieżki klienta samą klawiaturą, z czytnikiem ekranu (NVDA, VoiceOver, TalkBack), z powiększeniem do 200% i z systemowymi ustawieniami kontrastu. To umiejętność, której większość testerów manualnych musiała się nauczyć w ostatnich dwóch latach, i jedna z najbardziej poszukiwanych specjalizacji w zespołach budujących aplikacje konsumenckie. Wprowadzenie do tematu znajdziesz w naszym artykule o WCAG i pierwszych krokach w dostępności.

Od czego tester manualny powinien zacząć, jeśli zespół dopiero wprowadza testy dostępności? Z naszego doświadczenia najwięcej problemów wykrywa sześć prostych sprawdzeń na kluczowych ścieżkach klienta — rejestracji, logowaniu, wyszukiwaniu, koszyku i płatności:

1. Obsługa samą klawiaturą. Czy da się przejść całą ścieżkę klawiszem Tab, czy kolejność ma sens i czy nigdzie nie utyka się w pułapce fokusu?
2. Widoczny fokus. Czy w każdym momencie widać, który element jest aktywny?
3. Czytnik ekranu. Czy przyciski i pola mają zrozumiałe nazwy, a komunikaty o błędach są odczytywane w momencie ich pojawienia się?
4. Powiększenie do 200% i zmiana rozmiaru tekstu. Czy treść nie nachodzi na siebie i nie znika poza ekranem?
5. Znaczenie przekazywane kolorem. Czy błędne pole jest oznaczone nie tylko czerwoną ramką?
6. Limity czasowe. Czy sesja płatności nie wygasa bez ostrzeżenia i możliwości przedłużenia?

Te sprawdzenia nie zastępują pełnego audytu według WCAG, ale w kilka godzin pokazują, gdzie są największe bariery i czy zespół potrzebuje specjalisty.

Jak testować funkcje oparte na AI, skoro nie dają deterministycznych wyników?

Coraz więcej aplikacji ma w sobie funkcje oparte na modelach językowych: asystenta w aplikacji bankowej, streszczenie dokumentu, podpowiedź odpowiedzi dla konsultanta, wyszukiwanie w języku naturalnym. Testowanie ich zmienia pracę testera bardziej niż używanie AI do testowania.

Klasyczny test zakłada, że dla tych samych danych wejściowych system daje ten sam wynik, a tester porównuje go z oczekiwanym. Model językowy na to samo pytanie może odpowiedzieć na kilka sposobów, a każdy z nich może być poprawny — albo tylko brzmieć poprawnie. Tester nie porównuje więc wyniku z wzorcem, tylko ocenia go według kryteriów:

• Poprawność merytoryczna. Czy odpowiedź asystenta o limicie przelewu zgadza się z regulaminem? Czy streszczenie nie dodaje faktów, których nie ma w dokumencie?
• Granice zachowania. Czy asystent odmawia udzielenia porady inwestycyjnej, jeśli nie powinien jej udzielać? Czy da się go nakłonić do ujawnienia danych innego klienta lub instrukcji systemowych?
• Spójność. Czy na to samo pytanie zadane na trzy sposoby odpowiada zgodnie?
• Ton i dostępność. Czy odpowiedź jest zrozumiała, uprzejma i czytelna dla czytnika ekranu?

W praktyce oznacza to pracę na zestawach pytań testowych, ocenę wielu odpowiedzi na to samo pytanie i ścisłą współpracę z zespołem, który buduje automatyczne mechanizmy oceny. Automat potrafi sprawdzić tysiące odpowiedzi według prostych reguł, ale reguły i przypadki graniczne definiuje człowiek, który rozumie domenę. Przykład: zespół aplikacji ubezpieczeniowej wprowadza asystenta, który odpowiada na pytania o zakres polisy. Tester manualny przygotowuje zestaw kilkudziesięciu pytań w trzech grupach: pytania, na które odpowiedź jest w warunkach ubezpieczenia (asystent ma odpowiedzieć poprawnie i wskazać źródło), pytania, na które odpowiedzi w dokumentach nie ma (asystent ma przyznać, że nie wie, zamiast zgadywać), oraz pytania, na które asystent nie powinien odpowiadać (porada prawna, dane innego klienta). Każde pytanie zadaje kilka razy i w kilku sformułowaniach, a odpowiedzi ocenia według ustalonych z właścicielem produktu kryteriów. Zestaw staje się później podstawą automatycznej oceny przy każdej zmianie modelu lub instrukcji systemowych.

Kreatywne próby „złamania” asystenta — nietypowe sformułowania, pytania łączące dwa tematy, próby manipulacji — to w dużej mierze testy eksploracyjne, tylko w nowym medium.

Jak tester manualny weryfikuje pracę AI w zespole QA?

Druga strona tej samej zmiany: jeśli AI generuje przypadki testowe, dane i skrypty, ktoś musi sprawdzić, czy robi to dobrze. W wielu zespołach to zadanie trafia do testera manualnego, bo najlepiej zna produkt i ryzyka.

Z naszych projektów wynikają cztery typowe problemy z wynikami narzędzi AI w testowaniu, które wychwytuje człowiek:

• Pokrycie tekstu zamiast pokrycia ryzyka. Wygenerowane przypadki odzwierciedlają to, co jest napisane w historyjce. Jeśli historyjka pomija przypadek brzegowy, pomijają go też testy — a wynik wygląda na kompletny, bo testów jest dużo.
• Oczekiwany wynik zgadnięty, nie wynikający z wymagań. Model uzupełnia brakujące informacje tym, co brzmi prawdopodobnie. Test, który sprawdza „komunikat o powodzeniu operacji”, może utrwalić błędne zachowanie.
• Duplikaty i pozorna liczba. Pięćdziesiąt wariantów tego samego scenariusza z różnymi danymi daje imponującą liczbę testów i niewielką wartość.
• Dane testowe niezgodne z rzeczywistością. Numery kont, które przechodzą walidację formatu, ale nie odpowiadają żadnym realnym przypadkom produkcyjnym, i brak danych z problematycznymi znakami, na których system faktycznie się myli.

Dlatego sensowny podział pracy wygląda tak: AI przygotowuje szkic, tester manualny go redaguje — usuwa duplikaty, dopisuje przypadki wynikające z wiedzy domenowej i ryzyk, poprawia oczekiwane wyniki — a dopiero potem zespół decyduje, co automatyzuje. W World Quality Report 2025-26 AI generatywna była najwyżej ocenianą umiejętnością inżynierów jakości (63% wskazań), tuż przed klasycznymi kompetencjami inżynierii jakości (60%). Te dwie umiejętności nie konkurują ze sobą — druga jest warunkiem sensownego użycia pierwszej.

Jakich kompetencji wymaga stanowisko testera manualnego w 2026 roku?

Ogłoszenia na stanowisko testera manualnego w 2026 roku różnią się od tych sprzed kilku lat mniej w nazwach wymagań, a bardziej w ich wadze. Z perspektywy Tech Leada, który rekrutuje lub rozwija zespół, kompetencje układają się w trzy warstwy.

Fundament — bez zmian. Techniki projektowania testów (podział na klasy równoważności, wartości brzegowe, tablice decyzyjne, przejścia stanów), rzetelne raportowanie błędów, rozumienie cyklu wytwarzania oprogramowania i pracy w Scrumie, podstawy zarządzania testami. To zakres certyfikatu ISTQB Foundation Level, który nadal jest najczęstszym wymaganiem formalnym.

Warstwa techniczna — coraz ważniejsza. Tester manualny, który nie pisze kodu testów, i tak potrzebuje:

• narzędzi deweloperskich przeglądarki (konsola, sieć, pamięć lokalna),
• testowania API w narzędziu typu Postman lub podobnym,
• podstaw SQL do sprawdzenia, co naprawdę zapisało się w bazie,
• czytania logów i podstaw monitoringu,
• pracy z narzędziami AI — pisania poleceń, oceny wyników, rozumienia ich ograniczeń.

Warstwa specjalistyczna — źródło wartości. Wiedza domenowa (finanse, ubezpieczenia, medycyna, logistyka), dostępność według WCAG, testowanie eksploracyjne jako świadoma technika, a nie „klikanie bez scenariusza”, testowanie systemów AI. To tutaj tester manualny różni się od narzędzia i od juniora z kursu.

Kompetencje miękkie mają w tej roli większe znaczenie niż w wielu innych stanowiskach technicznych: umiejętność zadawania pytań na etapie wymagań, jasne opisywanie problemu programiście i rozmowa z biznesem o ryzyku bez żargonu.

Dla Tech Leada praktyczną konsekwencją jest zmiana tego, w co inwestuje budżet szkoleniowy zespołu. Kurs automatyzacji dla każdego testera manualnego nie zawsze jest najlepszym wyborem. Często większy zwrot daje kilka dni szkolenia z testów dostępności, warsztat z testowania eksploracyjnego prowadzonego według kart testu albo wspólne sesje z analitykiem biznesowym, podczas których tester poznaje procesy klienta. Warto też ustalić w zespole proste zasady korzystania z narzędzi AI: jakie dane wolno do nich wprowadzać, kto przegląda wygenerowane testy i kiedy wynik narzędzia wymaga akceptacji człowieka. W World Quality Report ryzyka związane z prywatnością danych były najczęściej wskazywaną barierą skalowania AI w QA — zasady ustalone na początku oszczędzają problemów później.

Ile zarabia tester manualny w 2026 roku i skąd bierze się luka wobec testera automatyzującego?

Najpełniejszych danych dostarcza Badanie Społeczności IT 2025 przeprowadzone przez Bulldogjob — kwoty na umowie o pracę podawane są w nim na rękę, a na B2B jako netto na fakturze. Testerzy manualni stanowili 34% respondentów z obszaru testowania.

Stanowisko	UoP — średnia (na rękę)	UoP — mediana	UoP senior — średnia	B2B — średnia (netto na fakturze)
Tester manualny	6 635 zł	6 020 zł	9 044 zł	12 942 zł
QA	8 513 zł	8 000 zł	10 850 zł	17 801 zł
Tester automatyzujący	9 538 zł	9 000 zł	12 592 zł	19 396 zł

Tester automatyzujący zarabia na umowie o pracę średnio o ok. 44% więcej niż tester manualny, a na B2B — o ok. 50% więcej. W liczbach bezwzględnych to ok. 34,8 tys. zł rocznie na rękę na etacie i ok. 77,4 tys. zł rocznie na B2B. Wśród seniorów różnica na umowie o pracę wynosi ok. 39%. Raport zwraca też uwagę, że wynagrodzenia testerów manualnych przestają rosnąć po ok. 10 latach pracy, podczas gdy specjaliści od automatyzacji i liderzy utrzymują wzrost.

Te liczby warto czytać ostrożnie. Po pierwsze, „tester manualny” w badaniu to szeroka kategoria — od osoby wykonującej scenariusze według instrukcji po specjalistę od dostępności w banku. Po drugie, luka odzwierciedla różnicę w zakresie pracy, a nie tylko w nazwie: tester manualny, który opanował testy dostępności, API i wiedzę domenową, konkuruje o inne stawki niż osoba wykonująca wyłącznie regresję. Aktualne stawki dla ról QA w modelu body leasingu znajdziesz w naszym przeglądzie stawek QA w Polsce na 2026 rok.

Wniosek dla Tech Leada: jeśli zespół płaci testerowi manualnemu za ręczne wykonywanie regresji, którą da się zautomatyzować, marnuje zarówno pieniądze, jak i potencjał tej osoby. Jeśli płaci mu za eksplorację, dostępność i wiedzę domenową, to stawka jest zwykle niższa od wartości, którą ta osoba dostarcza.

Jak wygląda ścieżka rozwoju testera manualnego w erze AI?

Ścieżka „tester manualny → tester automatyzujący” nadal istnieje i jest najprostszą drogą do wyższego wynagrodzenia. Nie jest jednak jedyna. Z naszych obserwacji rynku wynikają cztery kierunki, które w 2026 roku dają testerowi manualnemu realną przewagę:

1. Specjalista domenowy. Tester, który zna procesy bankowe, ubezpieczeniowe lub medyczne na poziomie analityka biznesowego, jest trudny do zastąpienia i często przechodzi później do roli analityka lub właściciela produktu.
2. Specjalista dostępności. Po wejściu w życie EAA popyt na osoby, które potrafią przeprowadzić audyt według WCAG i EN 301 549 oraz przetestować aplikację z technologiami asystującymi, wyraźnie rośnie.
3. Tester systemów AI. Ocena jakości odpowiedzi modeli, testy odporności na manipulację, budowa zestawów pytań testowych i kryteriów oceny. To kierunek, w którym doświadczenie w testach eksploracyjnych jest wprost przydatne.
4. Automatyzacja. Klasyczna ścieżka do roli inżyniera QA i testera automatyzującego, dziś łatwiejsza, bo narzędzia AI obniżają próg wejścia w pisanie kodu testów.

Piąty kierunek, lider testów lub QA lead, jest naturalny dla osób, które lubią koordynować pracę i rozmawiać z biznesem o ryzyku.

Formalnym wsparciem są certyfikaty ISTQB. Foundation Level pozostaje podstawą. W lipcu 2025 roku zgromadzenie ogólne ISTQB zatwierdziło certyfikat specjalistyczny Testing with Generative AI (CT-GenAI), obejmujący praktyczne użycie modeli językowych w testowaniu, pisanie poleceń i zarządzanie ryzykiem. W kwietniu 2026 roku ukazała się wersja 1.1 sylabusa. Warunkiem przystąpienia do egzaminu jest certyfikat Foundation Level. Dla osób testujących systemy AI przeznaczony jest osobny certyfikat Certified Tester AI Testing (CT-AI).

Jak Tech Lead powinien ułożyć zespół z testerami manualnymi?

Najczęstszy błąd, który widzimy w zespołach, to traktowanie testerów manualnych jako „bufora” przed wydaniem: programiści oddają funkcję pod koniec sprintu, tester ma dwa dni na sprawdzenie wszystkiego, regresja jest wykonywana ręcznie, bo automatyzacji brakuje. W takim układzie AI rzeczywiście może zastąpić część tej pracy — ale tylko dlatego, że była to praca, której człowiek nie powinien był wykonywać.

Sprawdza się model, w którym tester manualny jest częścią zespołu od początku pracy nad funkcją:

• Przed implementacją uczestniczy w doprecyzowaniu historyjek i pisze kryteria akceptacji razem z właścicielem produktu i programistą.
• W trakcie implementacji prowadzi krótkie sesje eksploracyjne na wczesnych wersjach funkcji, zamiast czekać na „gotowe”.
• Przed wydaniem odpowiada za eksplorację, dostępność i akceptację z biznesem, a nie za ręczną regresję.
• Po wydaniu analizuje zgłoszenia z produkcji i zamienia powtarzające się problemy w przypadki do automatyzacji.

Regresja powinna być w możliwie dużej części zautomatyzowana — przez programistów, testera automatyzującego albo z pomocą narzędzi AI. Tester manualny decyduje, co warto automatyzować, bo najlepiej wie, które ścieżki psują się najczęściej.

Proporcje zależą od produktu, ale z naszego doświadczenia wynikają trzy zasady:

• Produkt konsumencki z wieloma ścieżkami użytkownika, regulacjami i wymaganiami dostępności potrzebuje więcej pracy manualnej niż system integracyjny bez interfejsu użytkownika.
• Zespół, który wprowadza funkcje oparte na AI, potrzebuje co najmniej jednej osoby, która systematycznie ocenia ich wyniki — to rzadko jest zadanie dla programisty tej funkcji.
• Jeden tester manualny na kilka zespołów oznacza, że wróci on do roli „bufora przed wydaniem”, bo na nic więcej nie wystarczy mu czasu.

Jeśli brakuje Ci w zespole konkretnej kompetencji na określony czas — audytu dostępności przed terminem EAA, testów domenowych przy wdrożeniu nowego produktu — nie zawsze trzeba rekrutować na etat. W modelu testowania jako usługi można dołączyć specjalistę do zespołu na czas projektu.

Po czym poznać, że zespół marnuje potencjał testera manualnego?

Rola testera manualnego jest źle wykorzystana znacznie częściej, niż jest zbędna. Sześć sygnałów ostrzegawczych, które warto sprawdzić w swoim zespole:

1. Tester wykonuje ręcznie ten sam zestaw scenariuszy przed każdym wydaniem. To regresja, którą należy zautomatyzować. Czas testera jest potrzebny gdzie indziej.
2. Tester dostaje funkcję dopiero po zakończeniu implementacji. Błędy w wymaganiach wychodzą wtedy jako błędy w kodzie, a ich poprawa kosztuje wielokrotnie więcej.
3. Nikt nie prowadzi sesji eksploracyjnych. Wszystkie testy wynikają ze scenariuszy, więc zespół znajduje tylko te błędy, które przewidział.
4. Dostępność sprawdza wyłącznie automatyczny skan. Przy wynikach audytu GDS oznacza to, że większość barier pozostaje niewykryta.
5. Wyniki narzędzia AI trafiają do repozytorium testów bez przeglądu. Liczba testów rośnie, zaufanie do nich — nie.
6. Tester nie ma kontaktu z użytkownikami ani biznesem. Bez tego nie zbuduje wiedzy domenowej, która jest jego główną przewagą nad narzędziem.

Każdy z tych sygnałów da się naprawić bez zmiany składu zespołu — zmianą procesu. Dlatego pytanie „czy nadal potrzebujemy testerów manualnych” warto zastąpić pytaniem „za co im płacimy”.

Jak rekrutować testera manualnego w 2026 roku i o co pytać na rozmowie?

Opis stanowiska „tester manualny” skopiowany z ogłoszenia sprzed kilku lat przyciąga kandydatów do pracy, której w dobrze zorganizowanym zespole już nie ma: ręcznego wykonywania scenariuszy regresji. Jeśli szukasz osoby do eksploracji, dostępności i współpracy z biznesem, trzeba to napisać i sprawdzić na rozmowie.

Z naszego doświadczenia w rekrutacji specjalistów QA sprawdzają się cztery elementy procesu:

• Zadanie eksploracyjne zamiast testu wiedzy. Daj kandydatowi 30 minut na realną aplikację — choćby publiczną stronę sklepu — i poproś o notatki z sesji. Liczba znalezionych błędów jest mniej ważna niż to, jak kandydat wybiera obszary, jakie hipotezy stawia i jak opisuje to, co zobaczył.
• Opis błędu do oceny. Pokaż słabo napisane zgłoszenie i poproś o poprawienie. To w pięć minut pokazuje, czy kandydat rozumie, czego potrzebuje programista.
• Rozmowa o wygenerowanych testach. Pokaż kilkanaście przypadków testowych wygenerowanych przez AI z jednej historyjki i zapytaj, czego brakuje, co jest zbędne i co jest błędne. Kandydat, który tylko przyjmuje listę, nie będzie jej weryfikował w pracy.
• Pytanie o dostępność. Nie oczekuj znajomości całego WCAG. Wystarczy sprawdzić, czy kandydat wie, jak przejść formularz samą klawiaturą i co powinien usłyszeć użytkownik czytnika ekranu.

Szerzej o procesie zatrudniania specjalistów z tego obszaru piszemy w artykule o tym, jak zatrudnić QA developera w 2026 roku. Warto też pamiętać, że od 24 grudnia 2025 roku ogłoszenie o pracę musi zawierać informację o wynagrodzeniu lub jego przedziale — dane z tabeli wyżej pomagają ustalić widełki adekwatne do zakresu roli, a nie do samej nazwy stanowiska.

Jak ocenić dojrzałość roli testera manualnego w zespole?

Poniższy model pomaga Tech Leadowi ocenić, na jakim etapie jest rola testera manualnego w jego zespole i co zmienić, żeby przynosiła więcej wartości:

Obszar	Poziom 1: wykonawca scenariuszy	Poziom 2: tester w zespole	Poziom 3: właściciel ryzyk jakościowych
Moment włączenia	Po zakończeniu implementacji	Na początku sprintu	Przy doprecyzowaniu wymagań
Regresja	Wykonywana ręcznie	Częściowo zautomatyzowana	Zautomatyzowana; tester wskazuje, co automatyzować
Testy eksploracyjne	Brak lub ad hoc	Sesje przy większych funkcjach	Sesje z kartami testu przy każdej funkcji ryzykownej
Dostępność	Nie jest sprawdzana	Automatyczny skan	Skan plus testy z technologiami asystującymi wg WCAG
Narzędzia AI	Nieużywane lub bez przeglądu	Szkice testów i danych	Szkice redagowane przez testera, reguły przeglądu
Funkcje oparte na AI	Testowane jak zwykłe funkcje	Ręczne sprawdzanie przykładów	Zestawy pytań, kryteria oceny, testy odporności
Wiedza domenowa	Z dokumentacji	Z kontaktu z właścicielem produktu	Z kontaktu z użytkownikami i danych z produkcji
Rozwój	Brak planu	Certyfikat Foundation Level	Ścieżka specjalizacji: domena, dostępność, AI lub automatyzacja

Najważniejsze wnioski:

1. AI przejmuje zadania, których wynik da się opisać z góry. Szkice testów, dane, powtarzalna regresja i porównania wizualne to dziś praca narzędzi.
2. Człowiek zostaje tam, gdzie potrzebny jest osąd: w eksploracji, ocenie użyteczności, wiedzy domenowej i odpowiedzialności za decyzję o wydaniu.
3. Dostępność i funkcje AI to dwa nowe obszary pracy manualnej. Automatyczne narzędzia znajdują w najlepszym razie 40% barier dostępności, a odpowiedzi modeli trzeba oceniać według kryteriów, nie wzorca.
4. Luka płacowa wobec testerów automatyzujących wynosi 44–50%, ale dotyczy zakresu pracy, nie nazwy stanowiska. Specjalizacja ją zmniejsza.
5. Rola testera manualnego jest częściej źle wykorzystana niż zbędna. Zanim zdecydujesz o redukcji, sprawdź, czy zespół nie płaci mu za pracę, którą powinien wykonywać automat.

W ARDURA Consulting od ponad 10 lat budujemy i wspieramy zespoły QA dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA — od testów manualnych i eksploracyjnych, przez audyty dostępności, po automatyzację. Pomagamy Tech Leadom ułożyć podział pracy między ludzi i narzędzia tak, żeby testerzy zajmowali się tym, czego maszyna nie zrobi.

Jeśli chcesz ocenić, jak wykorzystujesz testerów w swoim zespole, albo potrzebujesz specjalisty od testów manualnych, dostępności lub systemów AI na czas projektu, porozmawiaj z naszym zespołem. Więcej o naszym podejściu do jakości znajdziesz na stronie usług testowania.