W projektach typu spa single page application QA nie kończy się na sprawdzeniu, czy przycisk działa i widok się renderuje. Trzeba jeszcze kontrolować routing, stan aplikacji, komunikację z API, zachowanie po odświeżeniu oraz to, czy użytkownik nie gubi się przy cofnięciu lub ponownym wejściu w ten sam ekran. W tym tekście porządkuję, jak takie aplikacje testować sensownie, które warstwy automatyzować, a które nadal wymagają ręcznej oceny.
Najważniejsze zasady QA w aplikacjach SPA
- Największe ryzyko w SPA dotyczy stanu, routingu i danych asynchronicznych, a nie samych kliknięć w UI.
- Najlepszy efekt daje połączenie szybkich testów komponentowych z wąską warstwą E2E, a nie odwrotnie.
- Warto obowiązkowo sprawdzać back, forward, deep linki, odświeżenie i zachowanie po błędzie API.
- QA dla SPA powinno obejmować też dostępność, wydajność i monitoring po wdrożeniu.
- Nie wszystko da się dobrze zautomatyzować, więc krótka sesja eksploracyjna nadal ma dużą wartość.
Co w aplikacji SPA zmienia zasady QA
MDN opisuje SPA jako aplikację, która ładuje jeden dokument, a potem podmienia jego treść przez JavaScript. To brzmi prosto, ale z perspektywy QA oznacza zupełnie inny zestaw ryzyk niż w klasycznej stronie wielopodstronicowej. W praktyce nie testuję już tylko tego, czy nowy ekran się otworzył, lecz także to, czy aplikacja zachowuje spójność stanu, gdy użytkownik przechodzi między widokami, odświeża stronę albo wraca przyciskiem wstecz.
Najważniejsza różnica polega na tym, że w SPA ekran często zmienia się bez pełnego przeładowania. Dla użytkownika to wygodne, ale dla testów oznacza więcej miejsc, w których można się potknąć: URL może nie zgadzać się z widokiem, część danych może zostać w pamięci po poprzedniej ścieżce, a błąd API może ujawnić się dopiero po kilku akcjach. Ja zwykle zaczynam od pytania: czy po wejściu na głęboki adres, odświeżeniu i powrocie z historii przeglądarki nadal widzę właściwy stan aplikacji?
Jeśli odpowiedź nie jest oczywista, to znaczy, że proces QA powinien objąć nie tylko warstwę UI, ale też logikę routingu i odtwarzanie stanu. To właśnie na tym etapie widać, czy projekt jest tylko „ładnie klikalny”, czy rzeczywiście przewidywalny dla użytkownika. Kiedy to rozumiem, łatwiej zdecydować, które warstwy testów naprawdę mają sens.
Które warstwy testów naprawdę mają sens
W praktyce nie buduję strategii QA wokół jednego typu testów. Najlepiej działa układ warstwowy: dużo szybkich testów logiki i komponentów, mniejsza liczba testów integracyjnych oraz kilka dobrze dobranych scenariuszy end-to-end. E2E, czyli testy end-to-end, sprawdzają pełną ścieżkę użytkownika od wejścia do wyniku końcowego, ale są wolniejsze i bardziej podatne na flakiness, więc nie powinny dźwigać całego ciężaru jakości.
| Warstwa testów | Po co ją mam | Co najczęściej wykrywa | Gdzie nie wystarczy |
|---|---|---|---|
| Unit | Sprawdza pojedynczą logikę, walidacje, formatowanie danych i reguły biznesowe. | Błędy w obliczeniach, mapowaniu danych, filtrach i warunkach. | Nie widzi prawdziwego DOM, sieci ani problemów z nawigacją. |
| Integracyjne i komponentowe | Weryfikują renderowanie komponentów z mockowanym API i współpracę kilku części UI. | Rozjazdy między stanem, propsami i renderem. | Nie pokażą w pełni, jak aplikacja zachowuje się w realnej przeglądarce. |
| E2E smoke | Potwierdzają, że najważniejsze ścieżki w ogóle działają po wdrożeniu. | Awarię logowania, błędy routingu, niedziałający formularz, problem z checkoutem. | Nie powinny być jedyną linią obrony, bo są wolniejsze i bardziej kruche. |
| Wizualne | Łapią regresje w layoutach, odstępach, ikonach i układzie responsywnym. | Rozjechane komponenty, znikające elementy, błędy po zmianie CSS. | Nie mówią nic o semantyce, dostępności i logice biznesowej. |
| Dostępności | Sprawdzają klawiaturę, fokus, role, etykiety i czytelność interfejsu. | Brak labeli, pułapki fokusu, nieprawidłowe kontrasty, złe kolejności tabulatora. | Nie wychwycą wszystkich problemów manualnych, więc nie zamykają tematu samodzielnie. |
| Wydajności | Mierzą ładowanie, responsywność i stabilność wizualną na poziomie użytkownika. | Za ciężki bundle, opóźnione renderowanie, przesunięcia układu, zbyt wolne odpowiedzi. | Lab nie odda w pełni zachowania realnej sieci i realnych urządzeń. |
W takim układzie Playwright albo Cypress dobrze sprawdzają się jako warstwa E2E, a szybkie testy komponentowe przejmują większość codziennej kontroli regresji. To po prostu bardziej opłacalne niż próba zrobienia wszystkiego jednym narzędziem. Sama lista testów jednak nie wystarczy, jeśli nie ma procesu, który utrzyma je w ryzach.
Jak ułożyć proces QA krok po kroku
Ja zwykle dzielę pracę na pięć etapów, bo inaczej zespół bardzo szybko zaczyna testować „wszystko”, czyli w praktyce nic istotnego.
- Zmapuj krytyczne przepływy - najpierw zapisuję te ścieżki, które naprawdę mają znaczenie biznesowe: logowanie, wyszukiwanie, formularz, dodanie do koszyka, płatność, zapis zmian, wylogowanie.
- Zdefiniuj macierz stanów - dla każdego flow sprawdzam osobno stan pusty, loading, sukces, błąd, brak uprawnień i odświeżenie po wejściu z deep linka.
- Odseparuj dane testowe od losowości - seedowane dane, stabilne fixture'y i mocki API zmniejszają flakiness bardziej niż dokładanie kolejnych retry. Kontrakty API, czyli sprawdzenie, czy frontend i backend nadal rozumieją te same pola, warto trzymać blisko tej samej warstwy.
- Ustal, co musi przejść przed merge - smoke testy powinny być krótkie i bezlitosne. Ich zadanie jest proste: odpowiedzieć, czy produkt nadaje się do dalszego testowania.
- Dodaj krótką eksplorację manualną - raz na jakiś czas trzeba po prostu przejść po aplikacji jak użytkownik, bez skryptu. To nadal najlepiej wyłapuje dziwne interakcje i nieoczywiste błędy użyteczności.
W takiej strukturze łatwiej też ustalić odpowiedzialność: co blokuje release, co trafia do sprintowego regresu, a co jest tylko sygnałem ostrzegawczym. Kolejny krok to zrozumienie, gdzie SPA łamie się najczęściej, bo tam warto skoncentrować najwięcej uwagi.
Gdzie takie aplikacje najczęściej się psują
Routing i historia przeglądarki
W SPA bardzo często pęka nie sam ekran, lecz nawigacja. Jeśli router nie reaguje poprawnie na zmianę adresu, użytkownik widzi jeden widok, a URL sugeruje coś innego. To później wychodzi przy odświeżeniu, udostępnieniu linka albo po użyciu przycisku wstecz. Testuję więc nie tylko wejście w ekran, ale też deep link, back, forward i powrót do poprzedniego stanu po zmianie ścieżki.
Tu szczególnie ważne są mechanizmy historii przeglądarki, czyli `pushState`, `replaceState` i zdarzenie `popstate`. Jeśli router ich nie ogarnia, aplikacja wygląda na sprawną, dopóki ktoś nie wykona realnej nawigacji. Taki błąd bywa zdradliwy, bo na środowisku testowym często przechodzi, a w produkcji uderza w zwykłe zachowanie użytkownika.
Asynchroniczne dane i wyścigi
SPA żyje z danych pobieranych w locie, więc wyścigi między requestami są codziennością. Jeden ekran może pokazać stare dane, jeśli odpowiedź przyjdzie za późno, albo zgubić stan formularza po szybkim przełączeniu zakładek. Sprawdzam wtedy nie tylko szczęśliwą ścieżkę, lecz także opóźnienia, błąd serwera, ponowienie żądania i sytuację, w której użytkownik zmienia widok zanim API odpowie.
Najwięcej problemów widzę w miejscach, gdzie aplikacja próbuje być sprytna, na przykład przy optimistic UI. To dobry wzorzec, ale tylko wtedy, gdy ma sensowny rollback po błędzie. Bez tego użytkownik widzi sukces, którego system nigdy nie potwierdził.
Przeczytaj również: Model V w QA - jak działa i jak uniknąć błędów?
Dostępność i fokus
Dostępność w SPA często bywa traktowana jako „dodatkowy temat”, a potem okazuje się krytyczna. Jeśli modal zabiera fokus i nie oddaje go po zamknięciu, test funkcjonalny może przejść bez zastrzeżeń, a użytkownik klawiatury utknie. Dlatego sprawdzam kolejność tabulatora, widoczność fokusu, logiczne etykiety pól i to, czy komunikaty błędów są odczytywalne przez czytnik ekranu.
To właśnie te trzy obszary najczęściej odróżniają aplikację, która tylko sprawia wrażenie stabilnej, od produktu, z którego da się korzystać bez frustracji. Następny krok to pomiar jakości po wdrożeniu, bo samo testowanie przed releasem nie daje pełnego obrazu.
Jak mierzyć jakość po wdrożeniu
Wydajności w SPA nie mierzę wyłącznie na lokalnym buildzie. Lab pomaga wykryć regresję wcześniej, ale dopiero dane z produkcji pokazują, jak aplikacja zachowuje się na realnych urządzeniach, realnych sieciach i realnym obciążeniu. web.dev przypomina, że Core Web Vitals obejmują trzy główne metryki: LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1. Ja traktuję te progi jako minimum jakościowe, a nie jako dekorację w raporcie.
W SPA ważne jest też monitorowanie po trasach, a nie tylko na stronie głównej. Jedna aplikacja może mieć bardzo szybki start, ale fatalny drugi ekran albo ciężki formularz, który działa świetnie na desktopie i rozsypuje się na telefonie. Dlatego śledzę osobno błędy JavaScript, timeouty API, liczbę nieudanych akcji, czas pierwszego sensownego renderu i zachowanie po soft nawigacji, czyli przejściu między ekranami bez pełnego przeładowania.
Jeśli field data pokazuje, że wartości mieszczą się w rekomendowanych progach dla co najmniej 75% wizyt, mam znacznie większą pewność, że release nie rozjedzie się po wejściu na produkcję. To ważne, bo w SPA część problemów wychodzi dopiero wtedy, gdy użytkownik zaczyna działać poza ścieżką z briefu. Zostaje więc ostatni etap: krótki, ale bezlitosny przegląd przed samym wdrożeniem.
Co sprawdzam tuż przed releasem w aplikacji SPA
Przed wdrożeniem sprawdzam pięć rzeczy: logowanie i odświeżanie sesji, cofanie i ponawianie nawigacji, działanie na wolnym łączu, zachowanie po błędzie API oraz pełną obsługę klawiatury na najważniejszych ekranach. Jeśli produkt ma transakcyjne flow, dokładam jeszcze test ścieżki przerwanej w połowie, bo właśnie tam użytkownicy najczęściej porzucają zadanie. Taki krótki gate wyłapuje więcej problemów niż rozbudowany, ale źle dobrany zestaw przypadkowych testów.
W dobrze ustawionym procesie QA nie chodzi o to, żeby wszystko testować wszędzie. Chodzi o to, żeby testy były powiązane z tym, jak aplikacja naprawdę żyje: przez stan, routing, dane asynchroniczne, użyteczność i pomiar po wdrożeniu. Jeśli te elementy są pod kontrolą, SPA przestaje być ryzykowną architekturą, a staje się po prostu przewidywalnym produktem.
