Testowanie wydajnościowe sprawdza zachowanie systemu pod obciążeniem. Ma kilka odmian: load testing (spodziewany ruch), stress testing (szukanie punktu, w którym system się łamie), spike testing (nagłe skoki ruchu) i soak testing (długotrwała praca, wycieki pamięci).
Rola analityka zaczyna się dużo wcześniej niż same testy: ktoś musi zdefiniować, co znaczy „wydajnie". To są wymagania niefunkcjonalne z liczbami - ilu równoczesnych użytkowników, jaki czas odpowiedzi, na którym percentylu. Bez nich test wydajnościowy nie ma kryterium zaliczenia, a deklaracja „system ma działać szybko" jest nietestowalna.
Przykład z MediFlow: szczyt rezerwacji wypada w poniedziałki między 7:00 a 8:30, gdy pacjenci dzwonią i klikają po weekendzie. Analityk zapisał wymaganie: wyszukiwanie terminów poniżej 2 sekund dla 95% zapytań przy 500 jednoczesnych użytkownikach. Test obciążeniowy (symulacja 800 użytkowników, z zapasem) pokazał, że baza danych dławi się już przy 300 - zapytanie o wolne sloty robiło pełny skan tabeli wizyt. Poprawka: jeden indeks i cache odświeżany co 60 sekund. Bez testu wyszłoby to pierwszego poniedziałku po starcie.
Częsta pomyłka: testowanie na średnim ruchu zamiast na szczytowym. Systemy nie padają „średnio" - padają w pikach: poniedziałek 7:00, pierwszy dzień zapisów, moment po wysyłce SMS-ów do 3 000 pacjentów naraz. Druga: odkładanie testów wydajnościowych na tydzień przed startem, gdy na zmiany architektury jest już za późno.