Testy wydajnościowe jako usługa: zakres, harmonogram, czynniki ceny i raport

Jest wtorek, połowa września. Za sześć tygodni rusza kampania, na którą marketing wydał więcej niż na cały poprzedni kwartał, a sklep albo portal klienta ma przyjąć kilka razy więcej ruchu niż zwykle. Na spotkaniu zarządu ktoś zadaje pytanie, które ląduje na Twoim biurku jako Tech Leada: „czy system to wytrzyma?”. Nie masz na nie uczciwej odpowiedzi, bo nikt nigdy nie sprawdził, gdzie leży granica. Zespół jest zajęty funkcjami na kampanię, więc decydujesz się zlecić testy wydajnościowe na zewnątrz.

Po tygodniu masz trzy oferty. Pierwsza: 9 000 PLN, „test obciążeniowy do 5 000 użytkowników, raport”. Druga: 38 000 PLN, cztery tygodnie, scenariusze, test obciążeniowy, stresowy i wytrzymałościowy, analiza wąskich gardeł, test potwierdzający. Trzecia: 120 000 PLN, trzy miesiące, „kompleksowy program inżynierii wydajności”. Każda brzmi rozsądnie i żadnej nie da się porównać z pozostałymi, bo każda wycenia coś innego.

Ten artykuł jest dla Ciebie, jeśli jesteś właśnie w tym miejscu. Nie tłumaczymy od zera, czym są testy wydajnościowe, bo zrobiliśmy to w osobnych tekstach. Tu zajmujemy się zakupem: co naprawdę wchodzi w zakres usługi, jak wygląda harmonogram, od czego zależy cena, co musi znaleźć się w raporcie i co zapisać w zamówieniu, żeby za kilka tygodni mieć odpowiedź na pytanie zarządu, a nie plik z wykresami.

Co właściwie kupujesz, zamawiając testy wydajnościowe jako usługę?

Kupujesz odpowiedź na pytanie biznesowe, a nie liczbę wirtualnych użytkowników. To rozróżnienie wydaje się banalne, ale właśnie ono tłumaczy, dlaczego oferty różnią się dziesięciokrotnie. Oferta za 9 000 PLN sprzedaje wygenerowanie ruchu. Oferta za 38 000 PLN sprzedaje ustalenie, czy system spełni określone kryteria i co trzeba zmienić, jeśli nie spełni. Oferta za 120 000 PLN sprzedaje zmianę sposobu pracy zespołu. To trzy różne produkty o tej samej nazwie.

Dobrze zdefiniowana usługa testów wydajnościowych składa się z pięciu elementów. Pierwszy to model obciążenia: jakie operacje wykonują użytkownicy, w jakich proporcjach, z jakim czasem namysłu i w jakim szczycie. Drugi to skrypty i dane testowe, czyli zautomatyzowane scenariusze, które odtwarzają ten model, z danymi na tyle zróżnicowanymi, żeby nie testować wyłącznie pamięci podręcznej. Trzeci to przebiegi testów z monitoringiem aplikacji i infrastruktury. Czwarty to analiza: dlaczego czas odpowiedzi rośnie, gdzie jest wąskie gardło, co jest przyczyną, a co objawem. Piąty to raport i rekomendacje, a w lepszych zleceniach także test potwierdzający po poprawkach.

Tani wariant zwykle zawiera tylko trzeci element w uproszczonej postaci. Dostawca nagrywa kilka ścieżek, puszcza ruch, przekazuje wykres czasów odpowiedzi i stwierdza, że „przy 3 000 użytkowników średni czas odpowiedzi przekroczył 2 sekundy”. To zdanie nie mówi Ci, czy kampania się uda, bo nie wiadomo, czy 3 000 wirtualnych użytkowników to dużo, czy mało w porównaniu z realnym ruchem, ani dlaczego czas wzrósł.

Dlatego pierwszym krokiem przed porównywaniem ofert jest zapisanie, jaką decyzję mają wesprzeć testy. „Czy wchodzimy w kampanię bez skalowania infrastruktury?”, „czy nowa wersja nie jest wolniejsza od poprzedniej?”, „ile ruchu przyjmie system, zanim zaczniemy tracić zamówienia?” To trzy różne zlecenia, z innym zakresem i inną ceną. Szerzej o tym, jak myśleć o samej metodyce, piszemy w przewodniku Testy obciążeniowe 2026: liczba wirtualnych użytkowników jest najmniej ważną liczbą.

Jakiego rodzaju testów potrzebujesz: obciążeniowych, przeciążeniowych czy wytrzymałościowych?

Każdy rodzaj testu odpowiada na inne pytanie i ma inny koszt, więc w zamówieniu warto je nazwać wprost. Dokumentacja Grafana k6 (Load test types) porządkuje je w sposób, który dobrze sprawdza się także w rozmowie z dostawcą niezależnie od narzędzia.

Test dymny (smoke) sprawdza przy minimalnym obciążeniu, czy skrypty działają i czy system w ogóle odpowiada poprawnie. Trwa sekundy lub minuty. Nie odpowiada na żadne pytanie biznesowe, ale jest warunkiem wiarygodności pozostałych testów. Jeśli oferta go nie wspomina, zapytaj, jak dostawca sprawdza poprawność skryptów.

Test obciążeniowy (load, average-load) mierzy zachowanie systemu przy spodziewanym ruchu, zwykle przez kilkadziesiąt minut. To podstawowy test przed kampanią: czy przy prognozowanym szczycie czasy odpowiedzi i odsetek błędów mieszczą się w kryteriach.

Test przeciążeniowy (stress) idzie wyraźnie powyżej oczekiwań. Odpowiada na pytanie, co się stanie, gdy prognoza okaże się za niska: czy system zwalnia łagodnie, czy przestaje działać, i czy wraca do normy, gdy ruch spada. Pokrewny jest test punktu załamania (breakpoint), w którym obciążenie rośnie stopniowo aż do granicy pojemności. On mówi, ile masz zapasu.

Test skokowy (spike) sprawdza nagły, krótki wzrost ruchu, na przykład po wysłaniu newslettera do całej bazy albo po emisji reklamy telewizyjnej. Tu często wychodzą problemy z autoskalowaniem, które reaguje za wolno.

Test wytrzymałościowy (soak) utrzymuje typowe obciążenie przez wiele godzin. Wykrywa to, czego nie zobaczysz w godzinnym teście: wycieki pamięci, rosnące kolejki, przepełniające się dzienniki, połączenia do bazy, które nie wracają do puli. Jest drogi w czasie kalendarzowym i w infrastrukturze, ale dla systemów działających bez restartów przez tygodnie bywa najważniejszy.

Praktyczna rada: nie zamawiaj „pełnego pakietu” tylko dlatego, że brzmi bezpiecznie. Przed kampanią z jednodniowym szczytem potrzebujesz testu obciążeniowego, przeciążeniowego i skokowego. Przed migracją systemu, który chodzi miesiącami, kluczowy będzie soak. Przed wydaniem nowej wersji często wystarczy porównanie wyników z poprzednią wersją przy tym samym obciążeniu. Wybór testów to pierwsza pozycja, na której możesz świadomie oszczędzić albo przepłacić.

Jak przełożyć cel biznesowy na kryteria zaliczenia testu?

Bez kryteriów zaliczenia test wydajnościowy nie może się nie udać, a więc nie może też niczego udowodnić. Kryterium musi mieć trzy części: metrykę, próg i warunki. „Strona produktu ma być szybka” nie jest kryterium. „Dla 95% żądań do karty produktu czas odpowiedzi serwera nie przekracza 800 ms przy 1 200 żądaniach na minutę i odsetku błędów poniżej 0,5%” jest kryterium.

Zwróć uwagę na trzy elementy tego zdania. Po pierwsze, percentyl zamiast średniej. Średnia ukrywa problemy: jeśli 90% użytkowników dostaje odpowiedź w 200 ms, a 10% czeka 8 sekund, średnia wygląda przyzwoicie, a co dziesiąty klient odchodzi. Kryteria opisuje się zwykle 95. albo 99. percentylem. Po drugie, przepustowość wyrażona w operacjach biznesowych, nie w „użytkownikach”. Liczba wirtualnych użytkowników zależy od czasu namysłu w skrypcie, więc ta sama liczba VU może oznaczać zupełnie różny ruch. Po trzecie, odsetek błędów, bo system, który szybko odpowiada błędem 503, formalnie ma świetne czasy.

Skąd wziąć progi? Najlepiej z danych: logi i analityka z poprzednich szczytów, prognoza marketingu przeliczona na operacje, wymagania umowne wobec Twoich klientów. Dla warstwy przeglądarki punktem odniesienia mogą być publiczne progi Google: według web.dev dobry wynik to LCP do 2,5 s, INP do 200 ms i CLS do 0,1, mierzone na 75. percentylu wizyt. Testy obciążeniowe mierzą jednak głównie serwer, a progi dla API i backendu musisz ustalić sam, wychodząc od tego, ile z tych 2,5 sekundy może zużyć serwer.

Dobry dostawca zacznie od warsztatu, na którym razem przeliczycie cel biznesowy na model obciążenia i kryteria. Jeśli oferta zawiera gotową liczbę użytkowników, zanim ktokolwiek zapytał o Twój ruch, to sygnał, że dostawca sprzedaje szablon. Z kolei jeśli to Ty nie potrafisz podać prognozy, nie udawaj: powiedz to wprost i zamów test punktu załamania. Wtedy odpowiedzią będzie „system wytrzymuje X operacji na minutę”, a decyzja, czy to wystarczy, zostaje po Twojej stronie.

Jak wygląda harmonogram typowego zlecenia tydzień po tygodniu?

Jednorazowe zlecenie dla jednej aplikacji z kilkoma kluczowymi ścieżkami zwykle zamyka się w dwóch do pięciu tygodni kalendarzowych. Poniższy harmonogram to typowy przebieg, a nie norma; podajemy go po to, żebyś mógł zapytać dostawcę, gdzie jego plan się różni i dlaczego.

Tydzień 1: cele, model obciążenia, środowisko. Warsztat z Tobą i kimś, kto zna ruch produkcyjny. Ustalenie kryteriów zaliczenia, wybór 3–8 scenariuszy, które odpowiadają za większość ruchu albo przychodu, przegląd środowiska testowego i monitoringu, lista danych testowych. Na koniec tygodnia powinieneś dostać krótki plan testów do akceptacji. To najtańszy tydzień całego zlecenia i ten, który najczęściej decyduje o jego wartości.

Tydzień 2: skrypty i dane. Napisanie skryptów, parametryzacja (różni użytkownicy, różne produkty, różne koszyki), korelacja dynamicznych wartości, takich jak tokeny sesji, przygotowanie danych testowych, test dymny. Jeśli aplikacja ma złożone uwierzytelnianie, nietypowe protokoły albo dużo logiki po stronie przeglądarki, ten etap rośnie.

Tydzień 3: przebiegi i analiza. Przebieg referencyjny (baseline), test obciążeniowy, przeciążeniowy, ewentualnie skokowy. Soak zwykle w nocy albo w weekend. Równolegle analiza: korelacja czasów odpowiedzi z metrykami CPU, pamięci, puli połączeń, zapytań do bazy, kolejek. Tu dostawca powinien być w stałym kontakcie z Twoim zespołem, bo część hipotez da się zweryfikować tylko z dostępem do konfiguracji.

Tydzień 4: raport, poprawki, test potwierdzający. Raport wstępny, omówienie, wprowadzenie poprawek przez Twój zespół, powtórzenie testów i raport końcowy. Bez testu potwierdzającego nie wiesz, czy poprawka zadziałała, czy tylko przesunęła wąskie gardło w inne miejsce.

Co wydłuża harmonogram? Prawie nigdy samo testowanie. Najczęściej: środowisko, które nie jest gotowe, dane testowe, których nie można użyć ze względu na RODO, brak dostępu do monitoringu, zapora blokująca ruch z generatorów obciążenia i brak osoby, która może zmienić konfigurację w trakcie testów. Jeśli kampania jest za sześć tygodni, zacznij od zaplanowania okna środowiskowego, nie od wyboru dostawcy.

Które narzędzie wybrać: k6, JMeter czy Gatling, i czy to w ogóle Twoja decyzja?

Narzędzie ma mniejsze znaczenie, niż sugerują oferty, ale wpływa na trzy rzeczy, które Cię dotyczą: koszt utrzymania skryptów po zakończeniu zlecenia, łatwość włączenia testów do CI/CD i to, kto w Twoim zespole będzie w stanie te skrypty czytać.

Apache JMeter to dojrzałe narzędzie open source napisane w Javie. Jak zaznacza strona projektu, działa na poziomie protokołu, a nie przeglądarki, i obsługuje między innymi HTTP/HTTPS, SOAP i REST, JDBC, JMS, LDAP i FTP. Ma graficzny edytor planów testów, więc nadaje się do zespołów, w których testy przygotowują osoby niebędące programistami, oraz do systemów z protokołami innymi niż HTTP. Plany testów zapisuje w XML, co utrudnia przegląd zmian w repozytorium.

Grafana k6 to narzędzie open source, w którym scenariusze pisze się w JavaScripcie (dokumentacja k6). Skrypty są zwykłym kodem, łatwo je wersjonować, przeglądać w pull requestach i uruchamiać w potoku CI. Dobrze pasuje do zespołów, w których programiści mają współtworzyć i utrzymywać testy.

Gatling pozwala pisać testy w Javie albo w JavaScripcie i TypeScripcie (dokumentacja Gatling), ma wersję społecznościową i komercyjną. Generuje czytelne raporty HTML i jest naturalnym wyborem w zespołach JVM.

Do tego dochodzą narzędzia komercyjne, takie jak LoadRunner, często używane w dużych organizacjach z licencjami i wieloma protokołami. ARDURA wymienia na stronie testowania oprogramowania JMeter, Gatling i LoadRunner jako narzędzia w testach wydajnościowych.

Czy to Twoja decyzja? Częściowo. Nie pozwól, żeby dostawca wybrał narzędzie wyłącznie dlatego, że tak mu wygodnie, jeśli skrypty mają potem zostać u Ciebie. Zapytaj: kto będzie utrzymywał skrypty po zleceniu, w jakim języku pisze Twój zespół i czy testy mają działać w CI. Jeśli odpowiedzi brzmią „my”, „TypeScript” i „tak”, k6 albo Gatling w JS/TS będą tańsze w utrzymaniu. Jeśli testujesz system kolejkowy z JMS i bazę przez JDBC, JMeter może być rozsądniejszy. Najważniejsze, żeby skrypty były w repozytorium, które należy do Ciebie, a nie w narzędziu dostawcy.

Od czego zależy cena testów wydajnościowych?

Cena usługi to w praktyce liczba osobodni specjalisty pomnożona przez stawkę, plus ewentualnie koszt infrastruktury do generowania ruchu i licencji. Stawka jest mniej zmienna, niż się wydaje; wycenę rozjeżdża liczba dni. Poniższa tabela zbiera czynniki, które ją przesuwają, i pytania, którymi możesz je sprawdzić u siebie przed wysłaniem zapytania ofertowego.

Czynnik	Co obniża liczbę dni	Co podnosi liczbę dni	Pytanie kontrolne
Liczba i złożoność scenariuszy	3–5 ścieżek HTTP/REST, proste logowanie	10+ ścieżek, SSO, wieloetapowe procesy, WebSocket, protokoły inne niż HTTP	Które ścieżki odpowiadają za 80% ruchu lub przychodu?
Rodzaje testów	Obciążeniowy i porównanie z poprzednią wersją	Do tego stres, spike, breakpoint i soak trwający godzinami	Na jakie pytanie biznesowe odpowiada każdy test?
Gotowość środowiska	Osobne środowisko zbliżone architekturą do produkcji, gotowe od dnia 1	Środowisko współdzielone, budowane w trakcie, okna testowe nocą	Kto i kiedy udostępni środowisko na wyłączność?
Dane testowe	Gotowe, zanonimizowane dane w realnej skali	Dane trzeba wygenerować lub zanonimizować, baza pusta	Czy baza testowa ma wolumen zbliżony do produkcji?
Monitoring	APM i metryki infrastruktury już działają	Brak monitoringu, trzeba go doinstalować	Czy widzisz dziś czasy zapytań do bazy i zużycie puli połączeń?
Zakres analizy	Pomiar wobec kryteriów, bez diagnozy	Diagnoza przyczyn, profilowanie, rekomendacje na poziomie kodu i konfiguracji	Czy chcesz wiedzieć „czy”, czy także „dlaczego”?
Test potwierdzający	Brak, raport kończy zlecenie	Jedna lub dwie rundy po poprawkach	Kto i kiedy wprowadzi poprawki?
Skala ruchu i infrastruktura	Ruch możliwy z kilku maszyn	Generatory w wielu regionach chmury, licencje komercyjne	Czy ruch musi pochodzić z wielu lokalizacji?
Przekazanie	Skrypty w repozytorium klienta, krótkie omówienie	Integracja z CI/CD, dokumentacja, szkolenie zespołu	Czy testy mają być uruchamiane po zleceniu?

Z tabeli wynika ważny wniosek: kilka największych czynników leży po Twojej stronie. Środowisko, dane, monitoring i dostępność osób, które mogą wprowadzać poprawki, potrafią podwoić liczbę dni bez żadnej zmiany w zakresie testów. Dostawca nie ma na nie wpływu, więc rozsądny dostawca albo wyceni je z zapasem, albo zapisze w ofercie założenia. Ten drugi jest dla Ciebie lepszy, bo widzisz, za co płacisz.

Osobną pozycją bywają koszty infrastruktury do generowania ruchu w chmurze i licencje. W narzędziach open source licencji nie ma, a maszyny generujące ruch rozlicza się według cennika dostawcy chmury. Poproś, żeby ta pozycja była w ofercie wydzielona, z informacją, czy płacisz za nią bezpośrednio, czy przez dostawcę i z jaką marżą. O tym, jak rozłożyć budżet na wiele cykli testów w roku, piszemy szerzej w artykule Budżet testów wydajnościowych: jak go zaplanować i zoptymalizować.

Ile to kosztuje w praktyce: jak policzyć widełki samodzielnie?

Nie podamy jednego cennika, bo uczciwego cennika testów wydajnościowych nie ma; jest stawka i liczba dni. Możesz jednak policzyć widełki sam, zanim zobaczysz pierwszą ofertę, i dzięki temu rozpoznać ofertę nierealnie tanią albo napompowaną.

Zacznij od stawki. W cenniku ARDURA inżynier QA na poziomie senior (automatyzacja testów, SDET) kosztuje 1 440–2 000 PLN netto za dzień, a na poziomie architekt/lead 2 000–2 560 PLN (cennik). To stawki za 8-godzinny dzień, all-inclusive. Testy wydajnościowe rzadko robi junior, bo wymagają rozumienia architektury, baz danych i infrastruktury, więc przyjmij poziom seniora jako punkt wyjścia.

Potem szacuj dni. Poniższe widełki to nasz szacunek dla typowego zlecenia, a nie fakt rynkowy ani cennik; przesuwają je czynniki z tabeli wyżej.

• Zakres podstawowy (3–5 scenariuszy HTTP/REST, gotowe środowisko i monitoring, test obciążeniowy i przeciążeniowy, raport bez głębokiej diagnozy): około 8–12 osobodni. Przy stawce seniora to rząd 11 500–24 000 PLN netto.
• Zakres typowy przed ważnym wydarzeniem (5–8 scenariuszy, przygotowanie danych, load, stress, spike i jeden soak, diagnoza wąskich gardeł, jedna runda testu potwierdzającego): około 15–25 osobodni, czyli rząd 21 600–50 000 PLN netto.
• Zakres rozszerzony (wiele systemów i integracji, protokoły inne niż HTTP, środowisko do zbudowania, kilka rund poprawek, integracja testów z CI/CD i szkolenie zespołu): 30 osobodni i więcej. Tu sensowniej rozmawiać o stałym specjaliście w zespole niż o jednorazowym zleceniu.

Wróćmy do trzech ofert ze wstępu. Oferta za 9 000 PLN to przy stawce seniora około 5–6 osobodni. Taki zakres wystarcza na nagranie kilku ścieżek i przebieg testu, ale nie na model obciążenia, dane i diagnozę. Nie jest oszustwem, tylko innym produktem. Oferta za 38 000 PLN mieści się w zakresie typowym i warto sprawdzić, czy założenia są zapisane. Oferta za 120 000 PLN to 60–80 osobodni; ma sens tylko wtedy, gdy rzeczywiście chcesz zbudować w organizacji praktykę inżynierii wydajności, a nie odpowiedzieć na jedno pytanie przed kampanią.

Ostatnia uwaga o porównywaniu: proś o wycenę w osobodniach z rozbiciem na etapy. Kwota ryczałtowa bez rozbicia uniemożliwia porównanie i negocjację, a rozbicie natychmiast pokazuje, czy ktoś zaplanował jeden dzień na analizę, czy pięć.

Co musisz przygotować po swojej stronie, żeby nie przepłacić?

Najtańsze osobodni to te, których dostawca nie musi zużyć na czekanie. Większość opóźnień i dopłat w zleceniach wydajnościowych wynika z braków po stronie zamawiającego, a nie z błędów wykonawcy. Zanim podpiszesz zamówienie, przygotuj siedem rzeczy.

Prognozę ruchu w operacjach. Nie „100 tysięcy użytkowników”, tylko: ile wyświetleń karty produktu, wyszukiwań, dodań do koszyka i płatności na minutę w szczycie. Jeśli masz dane z poprzedniego szczytu, przeanalizuj je z marketingiem i przemnóż przez prognozę kampanii.

Środowisko na wyłączność w ustalonym oknie. Test na środowisku, na którym w tym samym czasie ktoś uruchamia testy regresji albo wdraża nową wersję, daje wyniki do wyrzucenia. Zarezerwuj okno, a jeśli środowisko testowe odbiega od produkcji, spisz różnice.

Dane testowe w realnej skali. Baza z tysiącem produktów zachowuje się inaczej niż baza z milionem. Jeśli dane produkcyjne zawierają dane osobowe, przygotuj anonimizację wcześniej; to częsta przyczyna tygodniowych opóźnień.

Monitoring. Bez metryk aplikacji i infrastruktury dostawca powie Ci tylko, że jest wolno. Z metrykami powie, dlaczego. Jeśli nie masz narzędzia APM, ustal przed testami, czym dostawca zbierze metryki aplikacji (śledzenie transakcji, pamięć, wątki, czasy zapytań do bazy) i kto zainstaluje je w środowisku testowym.

Dostęp sieciowy. Ustal z administratorami, z jakich adresów przyjdzie ruch, i wyłącz albo skonfiguruj limity, WAF i ochronę przed botami, które inaczej zablokują generatory w pierwszej minucie.

Osobę po Twojej stronie z uprawnieniami. Kogoś, kto w trakcie testów może zmienić rozmiar puli połączeń, zrestartować usługę albo dodać indeks. Bez niej każda hipoteza czeka dzień.

Decyzję, kto wprowadza poprawki. Test potwierdzający ma sens tylko wtedy, gdy Twój zespół ma czas na poprawki między rundami. Zaplanuj to w sprincie, zanim zlecenie się zacznie.

Co powinien zawierać raport z testów wydajnościowych?

Raport jest jedynym trwałym produktem zlecenia, więc warto ustalić jego zawartość w zamówieniu, a nie zobaczyć ją po raz pierwszy na końcu. Dobry raport da się przeczytać na dwóch poziomach: zarząd dostaje odpowiedź na pytanie biznesowe na pierwszej stronie, zespół dostaje szczegóły potrzebne do działania.

Podsumowanie dla decydentów. Jedno zdanie odpowiedzi („przy prognozowanym szczycie system spełnia kryteria dla czterech z pięciu scenariuszy; płatność przekracza próg przy 70% prognozy”), trzy najważniejsze ryzyka i rekomendacja: wchodzimy, wchodzimy po poprawkach, nie wchodzimy bez skalowania.

Warunki testu. Opis środowiska i jego różnic względem produkcji, wersja aplikacji, model obciążenia, scenariusze, dane, czas trwania przebiegów. Bez tej części wyników nie da się powtórzyć ani porównać za pół roku.

Wyniki wobec kryteriów. Tabela: scenariusz, metryka, próg, wynik, zaliczony lub nie. Percentyle (p50, p95, p99), przepustowość, odsetek błędów z podziałem na typy.

Wykresy skorelowane w czasie. Czasy odpowiedzi, liczba żądań i błędów na jednej osi czasu z CPU, pamięcią, połączeniami do bazy, długością kolejek. To właśnie ta korelacja pozwala odróżnić przyczynę od objawu.

Wąskie gardła z hipotezą przyczyny i priorytetem. Nie „baza danych jest wolna”, tylko „zapytanie X w usłudze koszyka wykonuje pełny skan tabeli, czas rośnie liniowo z liczbą produktów; dodanie indeksu Y powinno usunąć problem; priorytet wysoki, bo blokuje płatność”.

Rekomendacje z szacunkiem wysiłku. Co zmienić w kodzie, konfiguracji i infrastrukturze, w jakiej kolejności i ile to mniej więcej kosztuje.

Artefakty. Skrypty testowe, konfiguracja, dane wejściowe i surowe wyniki w Twoim repozytorium. Jeśli dostawca zachowuje skrypty dla siebie, płacisz za ich napisanie przy każdym kolejnym teście.

Jeśli test wypadnie źle tuż przed premierą, przyda Ci się też plan reakcji opisany w artykule Kryzys wydajności aplikacji? Twoje pierwsze 5 kroków do odzyskania kontroli.

Jakie pytania zadać dostawcy przed podpisaniem umowy?

Siedem pytań wystarcza, żeby oddzielić dostawcę, który sprzedaje odpowiedź, od dostawcy, który sprzedaje ruch.

Jak ustalicie model obciążenia? Dobra odpowiedź zaczyna się od Twoich danych: logów, analityki, prognozy. Zła odpowiedź zaczyna się od liczby użytkowników.

Jakie kryteria zaliczenia proponujecie i skąd je bierzecie? Szukaj percentyli, przepustowości w operacjach i odsetka błędów. Jeśli dostawca nie proponuje kryteriów, test nie będzie mógł się nie udać.

Kto wykonuje analizę i jakie ma doświadczenie z naszym stosem? Testy wydajnościowe aplikacji Java na serwerze aplikacyjnym, serverless w chmurze i aplikacji PHP na współdzielonym hostingu to trzy różne kompetencje. Poproś o rozmowę z osobą, która będzie analizować wyniki, nie tylko z handlowcem.

Jak sprawdzacie, że generator obciążenia nie jest wąskim gardłem? Generator, któremu brakuje CPU albo przepustowości sieci, mierzy własne ograniczenia, a nie Twój system. Dostawca powinien monitorować także swoje maszyny.

Co jest w raporcie? Poproś o zanonimizowany przykład albo spis treści. Porównaj go z listą z poprzedniej sekcji.

Czyje są skrypty i w jakim narzędziu powstaną? Odpowiedź powinna brzmieć: Twoje, w Twoim repozytorium, w narzędziu, które Twój zespół będzie w stanie utrzymać.

Jakie założenia przyjmujecie w wycenie i co się dzieje, gdy nie zostaną spełnione? Dobre oferty wymieniają założenia (gotowe środowisko w dniu X, dane, dostęp do monitoringu) i opisują, jak rozliczane są dni oczekiwania. Brak założeń oznacza, że ryzyko jest ukryte w cenie albo wróci jako aneks.

Co zapisać w umowie lub zamówieniu?

Testy wydajnościowe zlecane jednorazowo najczęściej rozlicza się na dwa sposoby: ceną stałą za określony zakres albo czasem pracy (time and material) z limitem budżetu. Oba są w porządku, pod warunkiem że zamówienie zawiera kilka konkretnych zapisów.

Cel i kryteria zaliczenia. Wpisz pytanie biznesowe i kryteria, nawet jeśli mają zostać doprecyzowane w pierwszym tygodniu. Dzięki temu „wykonanie testów” ma mierzalny sens.

Zakres testów i liczba rund. Rodzaje testów, liczba scenariuszy, maksymalny czas trwania soak, liczba rund testu potwierdzającego. Bez tego każda dodatkowa runda staje się przedmiotem negocjacji.

Założenia i obowiązki zamawiającego. Termin udostępnienia środowiska, danych i dostępów, osoba kontaktowa, okno testowe. Uczciwy zapis o tym, jak rozliczane są przestoje z przyczyn leżących po Twojej stronie, chroni obie strony.

Produkty i własność. Raport o określonej zawartości, skrypty, konfiguracje i surowe wyniki przekazane do Twojego repozytorium. W polskich realiach dopilnuj przeniesienia autorskich praw majątkowych do skryptów i dokumentacji z wymienionymi polami eksploatacji; samo „przekazanie plików” nie przenosi praw.

Bezpieczeństwo i dane. Zasady dostępu do środowisk, zakaz używania danych osobowych bez umowy powierzenia, sposób przechowywania i usunięcia danych po zleceniu, NDA. Jeśli test ma dotykać produkcji, dodaj okno serwisowe, plan wycofania i osobę, która może test przerwać.

Kryterium odbioru. Odbiór następuje po przekazaniu raportu i artefaktów zgodnych z zakresem, a nie po tym, jak system „spełni kryteria”. Dostawca odpowiada za rzetelny pomiar i analizę, nie za wydajność Twojego kodu. To uczciwy podział, który warto zapisać, żeby uniknąć sporu przy złym wyniku.

Kiedy jednorazowy test nie wystarczy i co wtedy zamiast niego?

Jednorazowy test to zdjęcie stanu systemu w jednym dniu. Jeśli zespół wdraża zmiany co tydzień, za miesiąc to zdjęcie jest nieaktualne. Są trzy sytuacje, w których warto pomyśleć o czymś więcej niż o kolejnym zleceniu przed kolejną kampanią.

Wydajność regularnie psuje się między wydaniami. Jeśli każde większe wydanie przynosi niespodzianki, potrzebujesz testów wydajnościowych w potoku CI/CD: krótkiego testu porównawczego przy każdym scaleniu do głównej gałęzi, dłuższego testu przed wydaniem i okresowego soak. Skrypty z jednorazowego zlecenia są dobrym punktem wyjścia, o ile zostały napisane w narzędziu, które da się uruchamiać automatycznie.

System ma umowne SLA wobec klientów. Gdy czas odpowiedzi jest zapisany w umowach, testy przed premierą nie wystarczą; potrzebujesz także stałego monitoringu wydajności produkcji, żeby wykrywać degradację, zanim zauważą ją klienci. O tej różnicy piszemy w artykule „Proaktywne vs. reaktywne QA: dlaczego ciągłe monitorowanie wydajności się opłaca”.

Nikt w zespole nie czuje się właścicielem wydajności. Wtedy kolejne zlecenia będą odkrywać te same problemy. Rozsądniejszym rozwiązaniem bywa inżynier QA ze specjalizacją wydajnościową w zespole przez kilka miesięcy, który zbuduje testy, nauczy zespół je utrzymywać i odejdzie, gdy praktyka się utrwali. W ARDURA taki model to inżynierowie QA w modelu body leasingu, rozliczani stawką dzienną, z minimalnym okresem jednego miesiąca i 30-dniowym wypowiedzeniem, zgodnie z warunkami w cenniku.

Jest też sytuacja odwrotna: jeśli system jest mały, ruch przewidywalny, a infrastruktura skaluje się sama, jeden test obciążeniowy raz na rok i porządny monitoring mogą w zupełności wystarczyć. Nie kupuj programu inżynierii wydajności, jeśli Twoje pytanie zmieści się w jednym zleceniu.

Jakie są kluczowe wnioski?

Testy wydajnościowe jako usługa to zakup odpowiedzi na pytanie biznesowe. Oferty różnią się dziesięciokrotnie, bo wyceniają różne produkty pod tą samą nazwą: generowanie ruchu, pomiar wobec kryteriów z diagnozą albo budowę praktyki. Zanim porównasz ceny, zapisz, jaką decyzję mają wesprzeć testy.

Zapamiętaj sześć rzeczy. Po pierwsze, wybierz rodzaje testów pod pytanie: obciążeniowy na spodziewany ruch, przeciążeniowy i skokowy na niespodzianki, soak na systemy działające bez przerwy. Po drugie, kryteria zaliczenia opisuj percentylami, przepustowością w operacjach biznesowych i odsetkiem błędów. Po trzecie, typowe zlecenie trwa od dwóch do pięciu tygodni, a harmonogram wydłużają głównie środowisko, dane i dostęp do monitoringu po Twojej stronie. Po czwarte, cena to osobodni razy stawka; przy stawce seniora QA 1 440–2 000 PLN netto za dzień typowe zlecenie na 15–25 osobodni to szacunkowo 21 600–50 000 PLN netto. Po piąte, raport ma odpowiadać na pytanie na pierwszej stronie i wskazywać przyczyny, a skrypty mają zostać w Twoim repozytorium. Po szóste, jeśli wydajność psuje się między wydaniami, zamiast kolejnych jednorazowych zleceń wbuduj testy w potok CI/CD.

Więcej tekstów o testowaniu i jakości znajdziesz w hubie Quality Assurance. Jeśli przed Tobą kampania, migracja albo premiera i potrzebujesz odpowiedzi na pytanie „czy system wytrzyma?”, zobacz, jak prowadzimy testy wydajnościowe w ramach usług testowania oprogramowania albo umów krótką rozmowę o zakresie. Po rozmowie będziesz wiedzieć, jakie testy są Ci potrzebne, ile osobodni zajmą i co przygotować po swojej stronie.