Rola testera w projekcie: 6 sposobów na wartość poza testowaniem funkcjonalnym

Rola testera w projekcie to coś więcej niż sprawdzanie, czy funkcja działa zgodnie z wymaganiem: tester dostarcza zespołowi informacji o ryzyku, użyteczności, wydajności, bezpieczeństwie i samym procesie wytwarzania. Poniżej znajdziecie sześć takich obszarów, a przy każdym jedno zadanie do wykonania w bieżącym sprincie, narzędzie, którym to zrobicie, i miarę, po której poznacie efekt.

Wiele zespołów zatrudnia testerów, a potem prosi ich wyłącznie o odhaczanie przypadków testowych przed wydaniem. To tak, jakby kupić drona i używać go jako przycisku do papieru. Testerzy siedzą na styku wymagań, kodu i doświadczenia użytkownika, więc widzą rzeczy, których nie widzi nikt inny. Ten tekst pokazuje, jak tę perspektywę zamienić na konkretną pracę, a nie na kolejne hasło o „ambasadorach jakości”.

Na czym polega rola testera w projekcie poza testami funkcjonalnymi?

Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w wersji 4.0.1 z 2024 roku opisuje w podrozdziale 1.5.2 podejście całego zespołu (whole team approach): jakość jest wspólną odpowiedzialnością, a tester pracuje z programistami i przedstawicielami biznesu od pierwszych rozmów o wymaganiach. Ten sam sylabus w podrozdziale 1.4.5 rozdziela rolę testową i rolę zarządzania testami i zaznacza, że zadania obu ról zależą od kontekstu projektu. Rola testera w projekcie nie jest więc zamknięta w fazie „testy”, tylko rozciąga się na cały cykl. Jeśli chcecie mieć te pojęcia w małym palcu, przerobicie je na szkoleniu Foundation Level 4.0.

Poniższa tabela to skrót całego artykułu. Każdy wiersz to jeden sposób, w jaki tester dodaje wartość poza testowaniem funkcjonalnym, razem z zadaniem na najbliższy sprint.

Jak tester poprawia użyteczność, zanim zrobią to użytkownicy?

Tester poprawia użyteczność, gdy obserwuje prawdziwych ludzi przy jednym zadaniu, zamiast oceniać ekran na wyczucie. Jakob Nielsen w artykule Nielsen Norman Group z 2000 roku pokazał, że pierwsze 5 osób w badaniu znajduje około 85 procent problemów z użytecznością, a każda kolejna wnosi coraz mniej nowego. Do takiego badania nie potrzebujecie laboratorium: wystarczy wideorozmowa z udostępnianiem ekranu, scenariusz zadania i prośba, żeby uczestnik myślał na głos.

Zadanie na sprint wygląda tak. Wybieracie jedną ścieżkę, która przynosi pieniądze albo generuje zgłoszenia do wsparcia, na przykład zmianę danych do faktury. Umawiacie 5 osób spoza zespołu po 30 minut. Po sesji każda osoba wypełnia ankietę SUS, czyli 10 standardowych pytań. Jeff Sauro z MeasuringU, analizując 500 badań, podaje średni wynik SUS równy 68, więc od razu wiecie, czy Wasz produkt jest powyżej, czy poniżej przeciętnej. Wynik zapisujecie w raporcie razem z listą problemów i nagraniami najbardziej bolesnych momentów.

Do tej samej perspektywy należy dostępność. Wytyczne WCAG 2.2 opublikowane przez W3C w 2023 roku wymagają między innymi kontrastu tekstu co najmniej 4,5 do 1 dla zwykłego tekstu, a tester może to sprawdzić w kilka minut wbudowanymi narzędziami przeglądarki. Pełny audyt to osobna praca, którą robimy w ramach testów dostępności cyfrowej, a badanie z użytkownikami prowadzimy w testach użyteczności. Jeżeli wolicie nauczyć się tego w zespole, warsztat Testowanie UX i użyteczności prowadzimy także jako szkolenie zamknięte.

Ilu użytkowników naprawdę symulować w testach wydajnościowych?

Tylu, ilu macie w szczycie według własnej analityki, a nie tylu, ile brzmi groźnie na slajdzie. Teza, że typowy system musi wytrzymać miliony równoczesnych użytkowników, jest przesadzona: dotyczy garstki globalnych platform. Większość sklepów, bankowości dla firm i systemów rezerwacji ma w godzinie szczytu setki albo kilka tysięcy aktywnych sesji, a test wydajnościowy przygotowany na „miliony” mierzy tylko wyobraźnię autora.

Realną liczbę policzycie z prawa Little’a, znanego z teorii kolejek: średnia liczba osób w systemie równa się tempu napływu pomnożonemu przez średni czas przebywania. Przykład: sklep ma w szczytowej godzinie 9 000 sesji, a średnia sesja trwa 8 minut. Napływ to 150 sesji na minutę, razy 8 minut daje około 1 200 równoczesnych sesji. Do tego dokładacie zapas na kampanię, na przykład 50 procent, i macie cel testu oparty na danych. Więcej o rodzajach testów, metrykach i narzędziach znajdziecie w przewodniku testy wydajnościowe: rodzaje, metryki i narzędzia, a o tym, kiedy taki test się opłaca, w tekście dlaczego testy wydajnościowe są ważne.

Zadanie na sprint: tester bierze liczby z analityki, wylicza cel i pisze prosty skrypt w k6 z progami, które same mówią, czy test przeszedł. Poniższy przykład podnosi obciążenie do 1 200 wirtualnych użytkowników i kończy się błędem, jeśli więcej niż 1 procent żądań zawiedzie albo 95. percentyl czasu odpowiedzi przekroczy 800 ms. Testy obciążeniowe uruchamiajcie wyłącznie na własnym środowisku testowym, nigdy na cudzej produkcji.

import http from 'k6/http';
import { check, sleep } from 'k6';

// Cel z prawa Little'a: 150 sesji na minutę x 8 minut = 1 200 równoczesnych sesji
export const options = {
  stages: [
    { duration: '5m', target: 1200 },  // rozbieg do szczytu
    { duration: '15m', target: 1200 }, // utrzymanie szczytu
    { duration: '2m', target: 0 },     // wygaszenie
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],    // mniej niż 1% błędów
    http_req_duration: ['p(95)<800'],  // 95% odpowiedzi poniżej 800 ms
  },
};

export default function () {
  const res = http.get('https://staging.example.com/produkty?kategoria=buty');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(Math.random() * 20 + 10); // 10 do 30 s namysłu, jak prawdziwy klient
}

Po stronie przeglądarki tester ma drugi, łatwy wskaźnik: według web.dev, serwisu zespołu Chrome, interakcja jest dobra, gdy INP (Interaction to Next Paint) wynosi 200 ms lub mniej, a powyżej 500 ms jest słaba. Sprawdzicie to w Lighthouse i w raporcie Core Web Vitals. Kiedy test pokaże wąskie gardło, pełną diagnozę z rekomendacjami robimy w testach wydajności, a narzędzia przećwiczycie na szkoleniu testowanie wydajnościowe w JMeter.

Które testy oddać automatyzacji jako pierwsze?

Te, które powtarzacie najczęściej, które chronią pieniądze i które są stabilne. Tu rola testera w projekcie polega bardziej na wyborze niż na pisaniu kodu. Automatyzacja nie zaczyna się od wyboru frameworka, tylko od listy kandydatów. Tester zna regresję lepiej niż ktokolwiek, więc nawet jeśli nie pisze kodu, może zrobić najważniejszą część pracy: uporządkować, co warto zautomatyzować. Prosta punktacja od 1 do 3 w czterech kryteriach wystarcza, żeby rozmowa z programistami przestała być sporem o gust.

Zadanie na sprint: tester punktuje 20 przypadków regresji i wskazuje 5 pierwszych do automatyzacji. Jeśli zna podstawy, nagrywa szkic testu poleceniem npx playwright codegen i oddaje go programiście do dopracowania, co skraca rozmowę o tym, „co właściwie ma kliknąć test”. Efekt mierzycie czasem regresji. W naszych projektach to właśnie ta metryka przekonuje zarząd: u Argos automatyzacja i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin, a błędów krytycznych na produkcji było o 46 procent mniej, co opisujemy w case study jak skrócić testy regresyjne z 5 dni do 10 godzin.

Granice automatyzacji znajdziecie w tekście zalety i wady automatyzacji testów. Jeśli chcecie, żeby ktoś zbudował ją z Wami od zera, zajmujemy się tym w automatyzacji testów, a zespół, który chce pisać testy sam, zaczyna od szkolenia automatyzacja testów z Playwright.

Co tester sprawdzi w bezpieczeństwie bez certyfikatu pentestera?

Najwięcej, sprawdzając kontrolę dostępu, bo to najczęstsza kategoria podatności. W zestawieniu OWASP Top 10 z 2025 roku Broken Access Control utrzymuje pierwsze miejsce, a OWASP podaje, że jakaś forma tej słabości wystąpiła w 100 procentach przetestowanych aplikacji. Takie błędy nie wymagają egzotycznych narzędzi: często wystarczy zalogować się na drugie konto i podmienić identyfikator w adresie albo w żądaniu do API. Testerzy robią to zresztą od lat, tylko zwykle nazywają to „ciekawe, co się stanie, jak zmienię tę liczbę”.

Zadanie na sprint wygląda tak: przygotowujecie dwa konta o różnych uprawnieniach, otwieracie zasoby pierwszego (faktura, zamówienie, profil) i próbujecie je odczytać, zmienić albo usunąć z konta drugiego, w przeglądarce i w Postmanie. Każdy sukces to błąd o najwyższym priorytecie. Drugim krokiem jest skan bazowy OWASP ZAP w trybie pasywnym, który dokumentacja ZAP pozwala uruchomić jednym poleceniem i podpiąć do pipeline CI.

# Skan bazowy OWASP ZAP na środowisku testowym, np. jako krok w pipeline CI
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com \
  -r raport-zap.html

Według raportu IBM Cost of a Data Breach z 2025 roku średni globalny koszt naruszenia danych wyniósł 4,44 mln dolarów, więc godzina testera na dwóch kontach jest bardzo tanią polisą. Granica jest jasna: taki test nie zastępuje testu penetracyjnego, a skanów nie uruchamia się na systemach bez zgody właściciela. Różnicę między tymi pracami opisujemy w artykule testy bezpieczeństwa i testy penetracyjne, pełne testy realizujemy w ramach testów bezpieczeństwa aplikacji, a zespoły uczymy na szkoleniu automatyczne testy bezpieczeństwa z OWASP ZAP. W czerwcu 2026 roku z takich podstaw przeszkoliliśmy 14 osób z zespołu AgroApp.

Jak optymalizować proces testowy na danych, a nie na przeczuciu?

Rola testera w projekcie obejmuje też sam proces. Zaczynacie od jednego eksportu z trackera i jednego pytania: gdzie powstaje większość błędów, które dochodzą do użytkowników. Ogólne „wyobraźmy sobie zespół, który ma problemy z logowaniem” zamieniacie na konkret: zapytanie JQL zwraca błędy z produkcji z ostatnich 90 dni, a tester grupuje je według komponentu. Zwykle kilka modułów odpowiada za większość zgłoszeń i tam warto dołożyć testów, przeglądów kodu albo walidacji danych.

project = SKLEP AND issuetype = Bug AND created >= -90d
  AND labels = produkcja ORDER BY component ASC

Taki eksport mówi, gdzie są błędy. Żeby wiedzieć, czy proces się poprawia, potrzebujecie kilku miar zbieranych co sprint. DORA, program badawczy Google Cloud, mierzy stabilność dostarczania między innymi wskaźnikiem change fail rate, czyli odsetkiem wdrożeń, które wymagają natychmiastowej interwencji, wycofania albo poprawki. Poniżej zestaw, który u naszych klientów da się uruchomić bez nowego narzędzia.

Jak przełożyć te liczby na język zarządu, piszemy w tekście jak mierzyć jakość oprogramowania. Jeśli chcecie, żeby ktoś z zewnątrz spojrzał na cały proces i wskazał zmiany według ryzyka, to zakres audytu QA.

Jak tester uczy zespół i interesariuszy, żeby błędów było mniej?

Uczy na przykładach z własnego produktu, krótko i regularnie, zamiast raz w roku robić prezentację o jakości. To ta część, w której rola testera w projekcie najmocniej wpływa na innych. Najskuteczniejsza znana nam forma to rozmowa o historii użytkownika, zanim powstanie kod. Matt Wynne z Cucumber opisał w 2015 roku Example Mapping: tester, programista i właściciel produktu przez około 25 minut rozpisują jedną historię na reguły, przykłady i pytania. Jeśli po 25 minutach nadal jest dużo pytań, historia jest za duża albo za mało znana, żeby brać ją do sprintu.

Tu przydaje się warsztat analityczny, bo tester, który umie rozłożyć wymaganie na warunki i wartości graniczne, prowadzi takie spotkania znacznie pewniej. Ćwiczymy to na szkoleniu analiza testowa dla testerów i analityków. O tym, dlaczego najlepsi testerzy wyróżniają się właśnie komunikacją, a nie wyłącznie techniką, ciekawie pisze Strefa QA w tekście o najlepszych testerach. Z naszego doświadczenia wynika, że tester, który regularnie prowadzi takie rozmowy, po kilku sprintach dostaje mniej niejasnych wymagań, bo zespół sam zaczyna zadawać jego pytania.

Od czego zacząć w najbliższym sprincie?

Od jednego obszaru, nie od wszystkich sześciu naraz. Rola testera w projekcie rośnie krok po kroku, a nie dekretem. Wybierzcie ten, w którym boli najbardziej: jeśli użytkownicy dzwonią do wsparcia, zacznijcie od użyteczności; jeśli wydanie trwa tydzień, od punktacji regresji; jeśli nikt nie wie, gdzie powstają błędy, od eksportu z trackera. Po dwóch tygodniach pokażcie zespołowi jedną liczbę przed i po. Zasady, które stoją za tym podejściem, czyli testowanie według ryzyka i kontekstu, opisujemy w tekście o 7 zasadach testowania według ISTQB.

Jeśli prowadzicie zespół i chcecie, żeby testerzy przejęli część tych zadań, warto zacząć od szkoleń zespołowych. Przeszkoliliśmy już ponad 2 500 specjalistów, a terminy otwartych zajęć znajdziecie w kalendarzu szkoleń. Ludzi, którzy robią to na co dzień w innych firmach, spotkacie też na Testing Ground Conference.

Powiązane na blogu Quality Island

• Testy wydajnościowe: co to jest, rodzaje, metryki i narzędzia
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają i czym się różnią
• Zalety i wady automatyzacji testów: kiedy się opłaca
• Jak mierzyć jakość oprogramowania
• 7 zasad testowania oprogramowania według ISTQB

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level, sylabus v4.0.1, 2024, podrozdziały 1.4.5 Roles in Testing i 1.5.2 Whole Team Approach.
• J. Nielsen, Nielsen Norman Group, Why You Only Need to Test with 5 Users, 2000. Stąd 85 procent problemów przy 5 uczestnikach i zalecenie 3 badań po 5 osób.
• J. Sauro, MeasuringU, Measuring Usability with the System Usability Scale (SUS), 2011. Stąd średnia 68 z 500 badań.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2023, kryterium 1.4.3 Kontrast (minimum).
• Deloitte Digital dla Google, Milliseconds Make Millions, 2020. Stąd 8,4, 9,2 i 10,1 procent przy 0,1 s szybszym ładowaniu.
• web.dev (Google Chrome), Interaction to Next Paint (INP), aktualizacja 2025. Stąd progi 200 i 500 ms.
• Grafana Labs, k6, Thresholds, dokumentacja 2026. Składnia progów http_req_failed i http_req_duration.
• OWASP, Top 10:2025, A01 Broken Access Control, 2025. Stąd pierwsze miejsce i 100 procent przetestowanych aplikacji.
• ZAP, ZAP Baseline Scan, dokumentacja 2026. Polecenie skanu bazowego w Dockerze.
• IBM, Cost of a Data Breach Report 2025, komunikat prasowy, 2025. Stąd 4,44 mln dolarów średniego kosztu naruszenia.
• DORA, DORA’s software delivery performance metrics, aktualizacja 2026. Stąd definicja change fail rate.
• M. Wynne, Cucumber, Introducing Example Mapping, 2015. Stąd 25 minut na historię.
• Quality Island, case study Argos i dane własne o szkoleniach, 2026, liczby potwierdzone przez klientów.