Testowanie aplikacji webowych: co sprawdzić, jakie testy i jakimi narzędziami

Czas czytania: około 13 minut

Aplikacja webowa działa poprawnie na Waszym laptopie, w Chrome, przy dobrym łączu i na koncie testowym z pełnymi uprawnieniami. Problem w tym, że użytkownik wchodzi z telefonu w metrze, ma włączony tryb ciemny, blokadę ciasteczek i konto z ograniczeniami. Testowanie aplikacji webowych polega na sprawdzeniu, czy system działa poprawnie także wtedy, gdy warunki odbiegają od tych z komputera zespołu. To praca na czterech warstwach naraz: interfejsie w przeglądarce, komunikacji przez protokół HTTP, logice po stronie serwera i danych w bazie.

Ten materiał jest częścią kursu automatyzacji prowadzonego przez Tomasza Stelmacha, założyciela Quality Island. Zebraliśmy w nim to, co tester musi rozumieć, zanim napisze pierwszy test automatyczny aplikacji webowej: czym różni się aplikacja od strony, jakie rodzaje testów mają sens, co znaczą kody odpowiedzi serwera i jak wygląda kolejność pracy w realnym projekcie.

Czym jest aplikacja webowa?

Aplikacja webowa to program uruchamiany w przeglądarce, który działa na serwerze, a nie na komputerze użytkownika. Nie instalujecie jej, nie aktualizujecie ręcznie i nie zależy od systemu operacyjnego. Wystarczy adres i przeglądarka. Bankowość internetowa, sklep, panel administracyjny, system rezerwacji, poczta w przeglądarce i narzędzie do zarządzania zadaniami to wszystko aplikacje webowe.

Z perspektywy testera najważniejsza jest konsekwencja tej architektury: to, co widzicie na ekranie, jest tylko końcem długiej drogi. Kliknięcie w przycisk uruchamia żądanie do serwera, serwer sięga do bazy danych albo do innej usługi, przetwarza dane i odsyła odpowiedź, którą przeglądarka zamienia na obraz. Błąd może powstać na każdym z tych etapów, a użytkownik zobaczy tylko jego skutek, najczęściej w postaci pustego ekranu albo komunikatu bez treści.

Aplikacja webowa a strona internetowa: gdzie przebiega granica?

Strona internetowa pokazuje treść, aplikacja webowa pozwala coś zrobić. Granica bywa płynna, bo współczesne witryny mają formularze i wyszukiwarki, ale dla testera różnica jest bardzo praktyczna. Strona ma stan, który zmienia redakcja. Aplikacja ma stan, który zmienia użytkownik, i to właśnie ten stan trzeba sprawdzać w wielu kombinacjach.

W praktyce projektowej ta różnica przekłada się wprost na liczbę przypadków testowych. Stronę sprawdza się w kilkunastu scenariuszach, aplikację w kilkuset, bo każdy proces ma warianty zależne od roli, danych i stanu poprzedniego kroku.

Co tester musi rozumieć przed pierwszym testem?

Bez zrozumienia, co dzieje się między kliknięciem a wynikiem na ekranie, zgłoszenia błędów są bezużyteczne dla programistów. Cztery pojęcia wystarczą, żeby zacząć rozmawiać z zespołem tym samym językiem.

W naszych projektach ta wiedza skraca czas diagnozy błędu z godzin do minut. Tester, który potrafi otworzyć narzędzia deweloperskie i pokazać, że serwer odesłał kod 500 z konkretnym komunikatem, oddaje programiście gotowy trop zamiast zdania „nie działa”.

Jakie testy aplikacji webowych wykonujemy?

Rodzaj testu wybiera się na podstawie ryzyka, nie na podstawie mody. Poniższa tabela pokazuje, co sprawdza każdy rodzaj, kiedy go uruchomić i jakimi narzędziami pracuje się najczęściej.

W projekcie dla Argos, sklepu internetowego, zaczęliśmy właśnie od tej tabeli. Okazało się, że zespół miał dużo testów funkcjonalnych nowych funkcji i prawie żadnych regresyjnych, więc każde wydanie było ryzykiem. Po przebudowie zestawu regresja skróciła się z pięciu dni do dziesięciu godzin, a liczba błędów krytycznych na produkcji spadła o 46 procent.

Testy funkcjonalne aplikacji webowych

Testy funkcjonalne odpowiadają na pytanie, czy aplikacja robi to, co obiecuje. Zaczynamy od procesów, które przynoszą pieniądze albo chronią przed stratą: rejestracja, logowanie, wyszukiwanie, koszyk, płatność, wysyłka dokumentu, zatwierdzenie wniosku.

Każdy z tych procesów sprawdzamy w trzech wariantach. Ścieżka pozytywna to zachowanie użytkownika, który robi wszystko poprawnie. Ścieżka negatywna to złe dane, brak uprawnień, przerwane połączenie i cofnięcie się w przeglądarce. Warunki brzegowe to wartości skrajne: pole na 255 znaków wypełnione 256 znakami, koszyk z jednym produktem, koszyk z setką produktów, kwota zero i kwota maksymalna.

Z naszego doświadczenia to właśnie ścieżki negatywne wyłapują najwięcej poważnych błędów, a są testowane najrzadziej. Zespoły chętnie sprawdzają, czy formularz się wysyła, rzadziej sprawdzają, co się stanie, gdy użytkownik kliknie wyślij dwa razy w ciągu sekundy.

Testy wydajnościowe aplikacji webowych

Aplikacja, która odpowiada po ośmiu sekundach, jest dla użytkownika równie bezużyteczna jak aplikacja, która nie odpowiada wcale. Testy wydajnościowe sprawdzają czas odpowiedzi, liczbę jednoczesnych użytkowników i zachowanie systemu przy ruchu większym niż zakładany.

Podstawowe scenariusze to test obciążeniowy, czyli ruch zgodny z prognozą, test przeciążeniowy, czyli ruch ponad prognozę, oraz test wytrzymałościowy, czyli stałe obciążenie przez wiele godzin. Ten ostatni wykrywa wycieki pamięci, których nie widać w krótkim badaniu. Według dokumentacji Google dotyczącej metryk Core Web Vitals czas do największego elementu treści powinien mieścić się w 2,5 sekundy, a to dobry punkt odniesienia dla widoków publicznych.

Najczęstszym narzędziem w polskich projektach pozostaje Apache JMeter, głównie dlatego, że nie wymaga pisania kodu i pozwala zbudować plan testu z gotowych elementów. W projekcie dla Autono, firmy z branży wynajmu samochodów, testy wydajnościowe pokazały, że system utrzymuje stabilność przy obciążeniu większym o 120 procent od zwykłego ruchu, co pozwoliło spokojnie wejść w sezon wakacyjny.

Testy bezpieczeństwa aplikacji webowych

Najczęstszy błąd bezpieczeństwa w aplikacjach webowych nie jest wyrafinowany: to brak sprawdzenia uprawnień po stronie serwera. Interfejs ukrywa przycisk, którego użytkownik nie powinien widzieć, ale samo żądanie do serwera nadal działa. Tester sprawdza to w kilka minut, podmieniając identyfikator w adresie żądania.

Punktem odniesienia jest zestawienie OWASP Top 10, które opisuje najczęstsze kategorie podatności w aplikacjach webowych. Dla testera oznacza to konkretną listę sprawdzeń: kontrola dostępu do cudzych danych, walidacja danych wejściowych, bezpieczeństwo sesji i ciasteczek, ochrona przed wstrzyknięciem kodu oraz poprawna konfiguracja nagłówków bezpieczeństwa.

W naszej praktyce testy bezpieczeństwa dzielimy na dwa poziomy. Pierwszy to codzienna higiena testera, czyli sprawdzenie uprawnień i walidacji przy okazji testów funkcjonalnych. Drugi to testy bezpieczeństwa prowadzone przez specjalistów, z narzędziami do skanowania i ręczną analizą, zwykle przed dużym wdrożeniem albo cyklicznie w sektorze regulowanym.

Kody odpowiedzi HTTP w pracy testera

Kod odpowiedzi to pierwsza informacja, którą tester powinien sprawdzić przed napisaniem zgłoszenia. Mówi, czy problem leży po stronie przeglądarki, po stronie serwera, czy w danych żądania. Pięć kategorii wystarczy, żeby ustawić rozmowę z programistą na właściwym torze.

Dwa rozróżnienia warto zapamiętać na stałe. Kod 401 oznacza brak uwierzytelnienia, czyli system nie wie, kim jesteście, a kod 403 oznacza brak uprawnień, czyli system wie, kim jesteście, i nie pozwala na tę operację. Kod 200 z pustą albo błędną treścią to nadal błąd, mimo że narzędzia pokazują zielony status. Szerzej opisaliśmy to w materiale o metodach HTTP w testach API.

Przeglądarki, urządzenia i rozdzielczości

Nie testujemy wszystkiego wszędzie, tylko tam, gdzie są Wasi użytkownicy. Macierz przeglądarek buduje się z danych analitycznych, a nie z przekonań zespołu. Zwykle wystarczą dwie najpopularniejsze przeglądarki w wersji aktualnej i poprzedniej, plus jedna przeglądarka mobilna na systemie iOS i jedna na Androidzie.

Do tego dochodzą trzy rozdzielczości: telefon, tablet i typowy laptop. W praktyce projektowej najwięcej błędów wizualnych wychodzi na szerokości około 360 pikseli, bo tam elementy zaczynają się nakładać, oraz na bardzo szerokich monitorach, gdzie treść rozjeżdża się na całą szerokość. Warto też sprawdzić tryb ciemny i powiększenie strony do 200 procent, bo to wymóg wytycznych dostępności.

Testowanie aplikacji w sektorze regulowanym

W bankowości, ubezpieczeniach i ochronie zdrowia testowanie przestaje być kwestią dobrej praktyki, a staje się wymogiem formalnym. Rozporządzenie DORA, obowiązujące podmioty finansowe w Unii Europejskiej od 17 stycznia 2025 roku, wymaga regularnego testowania systemów krytycznych, a część tych testów musi wykonać strona niezależna od producenta oprogramowania.

Dla zespołu testowego oznacza to trzy dodatkowe wymagania. Dokumentacja testowa musi być kompletna i możliwa do przedstawienia audytorowi. Wyniki muszą być powtarzalne, czyli test uruchomiony ponownie ma dać ten sam rezultat. Dostęp do danych produkcyjnych jest ograniczony, więc dane testowe trzeba przygotować osobno, z zachowaniem zasad ochrony danych osobowych.

W projekcie dla ChaosGears z branży medycznej zbudowaliśmy dokumentację testową i odbiorczą oraz przeprowadziliśmy procedury odbiorcze właśnie w takim reżimie. Kluczowe okazało się nie samo testowanie, tylko możliwość udowodnienia, co i kiedy zostało sprawdzone.

Jak zapewnić działanie aplikacji przez całą dobę?

Testy przed wydaniem nie wystarczą, bo aplikacja psuje się także wtedy, gdy nikt jej nie zmienia. Kończy się miejsce na dysku, wygasa certyfikat, zewnętrzna usługa przestaje odpowiadać, a baza danych spowalnia wraz z przyrostem rekordów.

Ciągłość działania buduje się na trzech warstwach. Monitoring sprawdza dostępność i czas odpowiedzi z zewnątrz, w krótkich odstępach. Testy dymne uruchamiane po każdym wdrożeniu potwierdzają, że najważniejsze ścieżki działają na środowisku produkcyjnym. Alerty łączą jedno z drugim, kierując zgłoszenie do osoby dyżurnej zamiast do skrzynki, której nikt nie czyta.

Warto też zaplanować, co się dzieje po awarii. Procedura wycofania wdrożenia, kopie zapasowe z odtwarzalnością sprawdzoną w praktyce i lista kontaktów to elementy, które w naszej praktyce najczęściej okazują się nieaktualne dokładnie w momencie, gdy są potrzebne. Ten obszar porządkujemy w ramach audytu QA.

Od czego zacząć testowanie aplikacji webowej?

Kolejność ma znaczenie, bo pierwsze dni pracy decydują o tym, czy testy trafiają w ryzyko, czy w przypadkowe funkcje. W naszych projektach zaczynamy zawsze tak samo.

Najpierw rozmowa o tym, co dla biznesu znaczy poważna awaria. Potem lista procesów krytycznych, zwykle od trzech do siedmiu. Następnie przejście tych procesów ręcznie, z notowaniem wszystkiego, co dziwne. Dopiero wtedy powstają przypadki testowe, a na końcu decyzja, które z nich automatyzować. Automatyzacja bez tego kroku daje zestaw testów, który sprawdza rzeczy łatwe do sprawdzenia, a nie ważne.

Najczęstsze pytania o testowanie aplikacji webowych

Czym różni się testowanie aplikacji webowej od mobilnej? Aplikacja webowa działa w przeglądarce, więc dochodzi zgodność z przeglądarkami i rozdzielczościami, a odpada instalacja i sklep z aplikacjami. Aplikacja mobilna wymaga testów na urządzeniach, uprawnień systemowych i zachowania przy słabym zasięgu. Wspólna zostaje warstwa API i logika serwera.

Ile testów automatycznych potrzebuje aplikacja webowa? Nie liczbę, tylko pokrycie ryzyka. Dobrym punktem wyjścia jest zestaw regresyjny obejmujący wszystkie procesy krytyczne, uruchamiany przy każdym wydaniu, z przewagą testów na poziomie API nad testami przez interfejs, bo te drugie są wolniejsze i mniej stabilne.

Czy tester aplikacji webowych musi umieć programować? Do testów manualnych nie, ale znajomość podstaw HTML, protokołu HTTP i zapytań SQL bardzo przyspiesza pracę. Do automatyzacji potrzebny jest już jeden język programowania i praca z narzędziem takim jak Playwright albo Selenium.

Co sprawdzić najpierw, gdy aplikacja działa wolno? Najpierw czy problem jest po stronie przeglądarki, czy serwera. Zakładka sieci w narzędziach deweloperskich pokazuje czas odpowiedzi każdego żądania. Jeśli serwer odpowiada szybko, a strona i tak ładuje się długo, przyczyna leży w obrazach, skryptach albo liczbie żądań.

Czy testy dostępności są obowiązkowe? Dla podmiotów publicznych w Polsce tak, na podstawie ustawy o dostępności cyfrowej. Od czerwca 2025 roku Europejski Akt o Dostępności rozszerza wymagania na wiele usług komercyjnych, w tym handel elektroniczny i bankowość, więc dla części firm prywatnych to również obowiązek, a nie dobra wola.

Powiązane na blogu Quality Island

• Baza danych: co to jest, jakie są rodzaje i jak z niej korzystać w testach
• Techniczne pojęcia przydatne w testowaniu aplikacji webowych
• Metody HTTP: GET, POST, PUT, PATCH i DELETE w testach API
• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Testy regresyjne: co to jest, rodzaje i jak skrócić regresję z dni do godzin
• Testy wydajnościowe: co to jest, rodzaje, metryki i narzędzia
• Poziomy testowania oprogramowania: od jednostkowych po akceptacyjne

Pełna lista źródeł

• MDN Web Docs, HTTP response status codes, stan na wrzesień 2026
• Google web.dev, Core Web Vitals, stan na wrzesień 2026
• OWASP, OWASP Top 10, stan na wrzesień 2026
• Unia Europejska, Rozporządzenie DORA 2022/2554, obowiązuje od 17 stycznia 2025
• W3C, Web Content Accessibility Guidelines, stan na wrzesień 2026
• Dane własne Quality Island: ponad 450 000 napisanych testów automatycznych, liczby z projektów dla Argos i Autono potwierdzone przez klientów, stan na wrzesień 2026

Autor materiału kursowego: Tomasz Stelmach, założyciel Quality Island. Tekst zaktualizowany we wrześniu 2026 roku.