Gdy aplikacja działa poprawnie na papierze, a mimo to gubi dane, zwalnia albo pozwala wykonać niedozwoloną operację, potrzebne jest sprawdzenie jej zachowania podczas pracy. Analiza dynamiczna polega na uruchomieniu programu i obserwowaniu jego reakcji na konkretne działania, dane oraz obciążenie. Pokażę, jak ten proces wykorzystać w QA, czym różni się od testów statycznych, jakie narzędzia stosować i gdzie najczęściej pojawiają się błędy organizacyjne.
Najważniejsze informacje o testowaniu aplikacji podczas działania
- Runtime oznacza sprawdzanie programu w czasie jego rzeczywistego wykonywania.
- Testy dynamiczne wykrywają błędy widoczne dopiero po wykonaniu określonej ścieżki lub operacji.
- DAST koncentruje się na bezpieczeństwie aplikacji działającej w środowisku testowym.
- Najlepsze rezultaty daje połączenie testów dynamicznych, statycznych i automatycznych.
- Raport z testu powinien zawierać kroki odtworzenia, dane wejściowe, wynik oczekiwany i rzeczywisty.
Na czym polega analiza dynamiczna w procesie QA
W praktyce uruchamiam aplikację, wykonuję zaplanowane działania i sprawdzam, co dzieje się z jej stanem, odpowiedziami, logami oraz zasobami systemowymi. Nie oceniam więc wyłącznie kodu, lecz zachowanie gotowego programu w warunkach możliwie zbliżonych do rzeczywistych.
Tester może na przykład zalogować użytkownika, dodać produkt do koszyka, zmienić ilość, przerwać płatność i wrócić do aplikacji po kilku minutach. Każda z tych czynności zmienia stan systemu. Błąd może pojawić się dopiero po określonej sekwencji zdarzeń, dlatego samo przejrzenie kodu albo wykonanie pojedynczego testu jednostkowego nie zawsze wystarczy.
Najprostszy schemat wygląda tak:
- uruchomienie aplikacji lub konkretnego komponentu,
- przygotowanie danych i warunków testowych,
- wykonanie scenariusza przez człowieka albo automaty,
- obserwacja odpowiedzi, interfejsu, logów i zużycia zasobów,
- porównanie wyniku z kryterium akceptacji,
- opisanie błędu i ponowne sprawdzenie poprawki.
Największa wartość tego podejścia pojawia się tam, gdzie problem wynika z interakcji kilku elementów. Przykładem może być poprawny moduł płatności, poprawna baza danych i poprawna obsługa sesji, które razem powodują podwójne naliczenie zamówienia po odświeżeniu strony.
Co można wykryć dopiero po uruchomieniu programu
Testy wykonywane w runtime sprawdzają między innymi funkcjonalność, integracje, wydajność i bezpieczeństwo. Ich wspólną cechą jest to, że tester obserwuje system w ruchu, a nie tylko analizuje jego strukturę.
Błędy funkcjonalne i integracyjne
Najbardziej typowy przypadek to funkcja, która działa dla danych podstawowych, ale zawodzi na granicy. Formularz przyjmuje poprawny numer telefonu, lecz odrzuca numer z prefiksem kraju. API zwraca kod 200 zamiast 400, gdy klient przesyła niekompletne dane. Koszyk działa, dopóki użytkownik nie otworzy dwóch kart przeglądarki jednocześnie.
W takich sytuacjach sprawdzam nie tylko ekran aplikacji, ale też komunikację między usługami. Przydatne są logi, identyfikatory żądań, treść odpowiedzi HTTP i dane zapisane w bazie. Dzięki temu można odróżnić błąd interfejsu od problemu w backendzie.
Wydajność i stabilność
Program może zwracać poprawne wyniki, ale robić to zbyt wolno albo tracić stabilność pod obciążeniem. Testy dynamiczne pozwalają obserwować czas odpowiedzi, zużycie pamięci, obciążenie procesora i liczbę błędów przy określonej liczbie użytkowników.
Nie ma jednego uniwersalnego progu akceptacji. Dla wyszukiwarki sklepu czas odpowiedzi poniżej 1 sekundy może być celem, ale dla raportu generowanego raz dziennie ważniejsze będzie ukończenie operacji w ciągu kilku minut bez błędów. Kryteria powinny wynikać z umowy, wymagań produktu albo ustalonego SLA, a nie z przypadkowej liczby.
Problemy bezpieczeństwa
Wariant bezpieczeństwa, znany jako DAST, wysyła żądania do działającej aplikacji i sprawdza, jak reaguje ona na nietypowe lub złośliwe dane. Można w ten sposób wykrywać między innymi błędy kontroli dostępu, nieprawidłową walidację danych, podatności typu XSS oraz problemy z konfiguracją sesji.
Narzędzie nie widzi całej logiki wewnętrznej, dlatego działa podobnie do zewnętrznego użytkownika i często jest określane jako test czarnoskrzynkowy. To zaleta przy ocenie realnej powierzchni ataku, ale również ograniczenie. Skaner może nie trafić do niepołączonego endpointu, nietypowej ścieżki biznesowej albo funkcji dostępnej dopiero po kilku krokach.
Czym różnią się testy dynamiczne od statycznych
Testy statyczne badają kod, konfigurację lub artefakty bez uruchamiania aplikacji. Testy dynamiczne wymagają działającego programu i sprawdzają jego faktyczne reakcje. Nie traktuję tych metod jako konkurencyjnych, ponieważ każda odpowiada na inne pytanie.
| Obszar | Testy statyczne | Testy dynamiczne |
|---|---|---|
| Moment wykonania | Przed uruchomieniem aplikacji | Podczas działania aplikacji |
| Co jest obserwowane | Kod, zależności, konfiguracja i struktura | Odpowiedzi, zachowanie, logi i zużycie zasobów |
| Typowe problemy | Błędy składni, niebezpieczne wzorce, znane podatności bibliotek | Błędy procesów, integracji, uprawnień, wydajności i obsługi stanów |
| Największa zaleta | Wczesne wykrywanie problemów | Ocena zachowania z perspektywy użytkownika |
| Ograniczenie | Nie pokazuje pełnego zachowania systemu | Wymaga środowiska, danych i działającego programu |
W dobrze poukładanym procesie najpierw wychwytuję tanie do naprawienia problemy podczas przeglądu kodu i skanowania zależności, a później sprawdzam zachowanie aplikacji. Sam skaner nie zastąpi testera, bo nie rozumie wszystkich reguł biznesowych, zależności między kontami ani nietypowych scenariuszy użytkownika.
Podobnie test dynamiczny nie pokaże każdej przyczyny znalezionego błędu. Może ujawnić, że użytkownik otrzymuje dane innego konta, lecz dopiero analiza kodu lub logiki autoryzacji wyjaśni, dlaczego tak się dzieje.
Jak zaplanować skuteczny proces krok po kroku
1. Zacznij od ryzyka, nie od narzędzia
Najpierw ustalam, które funkcje mogą przynieść największą stratę, frustrację użytkownika albo problem prawny. W sklepie internetowym będą to płatności, ceny, rabaty i uprawnienia administracyjne. W systemie medycznym ważniejsze okażą się poufność danych, ciągłość działania i poprawność historii zmian.
Takie podejście pomaga ograniczyć pozorne pokrycie. Lepiej dobrze sprawdzić 10 krytycznych scenariuszy niż automatycznie wykonać setki przypadkowych kliknięć, które nie dotykają najważniejszych ryzyk.
2. Przygotuj środowisko i dane
Środowisko powinno mieć znaną wersję aplikacji, przewidywalną konfigurację i dane, które można bezpiecznie odtworzyć. Dla testów uprawnień potrzebne są co najmniej dwa konta o różnych rolach, a dla testów płatności osobne dane testowe i jasno określone zachowanie operatora.
Unikam testowania na produkcji, chyba że istnieje formalnie zatwierdzony scenariusz, ograniczony zakres i plan wycofania. Błędnie skonfigurowany skaner bezpieczeństwa albo test obciążeniowy może zakłócić pracę prawdziwych użytkowników.
3. Zdefiniuj obserwowalne kryteria
Opis „aplikacja ma działać poprawnie” jest zbyt ogólny. Lepsze kryterium brzmi: po dwukrotnym kliknięciu przycisku zamówienie powstaje tylko raz, klient widzi jeden numer zamówienia, a API zwraca ten sam identyfikator.
W kryteriach warto uwzględnić kod odpowiedzi, komunikat, zmianę danych, czas wykonania i log audytowy. Dzięki temu wynik testu nie zależy wyłącznie od subiektywnego wrażenia testera.
4. Połącz automaty i testy eksploracyjne
Automaty dobrze sprawdzają powtarzalne ścieżki regresji, na przykład logowanie, wyszukiwanie i zakup. Test eksploracyjny pozwala natomiast szybko zbadać obszary, których nikt wcześniej nie opisał, oraz reagować na nietypowe zachowanie programu.
W mojej ocenie najrozsądniejszy układ to automaty dla scenariuszy stabilnych i krytycznych oraz ręczna eksploracja dla nowych funkcji, skomplikowanych procesów i miejsc o dużej liczbie zależności. Automatyzacja bez dobrego scenariusza tylko szybciej powtarza złe założenia.
Przeczytaj również: Karty kontrolne Shewharta - Stabilność procesu w QA
5. Zapisuj dowody i wykonuj retest
Dobry raport powinien wskazywać wersję aplikacji, środowisko, dane testowe, kroki odtworzenia, wynik oczekiwany, wynik rzeczywisty oraz załączniki, takie jak logi lub nagranie. Sam zrzut ekranu rzadko wystarcza, szczególnie przy błędach zależnych od kolejności zdarzeń.
Po wdrożeniu poprawki wykonuję retest scenariusza, a potem krótki test regresji w obszarach powiązanych. Naprawa limitu płatności może przecież wpłynąć na koszyk, faktury, zwroty i raportowanie.
Jakie narzędzia wspierają testowanie w runtime
Dobór narzędzia zależy od rodzaju aplikacji, poziomu automatyzacji i pytań, na które chcemy odpowiedzieć. Innego zestawu użyję dla interfejsu webowego, innego dla API, a jeszcze innego dla aplikacji mobilnej lub usługi działającej pod dużym obciążeniem.
| Potrzeba | Przykładowe rozwiązanie | Co sprawdza |
|---|---|---|
| Interfejs webowy | Playwright lub Selenium | Widoki, formularze, nawigację i scenariusze użytkownika |
| Testy API | Postman, Newman lub podobne narzędzia | Żądania, odpowiedzi, autoryzację i walidację danych |
| Bezpieczeństwo webowe | OWASP ZAP lub Burp Suite | Podatności widoczne podczas komunikacji z aplikacją |
| Wydajność | k6, JMeter lub Gatling | Czasy odpowiedzi, obciążenie i stabilność usług |
| Obserwowalność | logi, tracing i monitoring | Przebieg żądania między usługami oraz przyczyny awarii |
Narzędzie wybieram dopiero po opisaniu celu. Jeśli chcę sprawdzić, czy użytkownik z rolą „edytor” nie może usunąć danych, potrzebuję scenariusza autoryzacji i odpowiednich kont, a nie tylko automatycznego skanera. Technologia pomaga zbierać dowody, ale nie zastępuje modelu ryzyka.
W przypadku DAST trzeba pamiętać o konfiguracji logowania, obsłudze tokenów, ograniczeniu ruchu i sprawdzeniu endpointów, których skaner nie odkryje samodzielnie. OWASP zwraca uwagę, że narzędzia tego typu mogą mieć problem z niepowiązanymi ścieżkami i parametrami, dlatego mapa aplikacji oraz testy ręczne nadal są potrzebne.
Najczęstsze błędy, które obniżają wartość testów
Pierwszy problem to testowanie wyłącznie szczęśliwej ścieżki. Użytkownik nie zawsze wpisuje poprawne dane, nie zawsze ma stabilne połączenie i nie zawsze wykonuje czynności w kolejności przewidzianej przez projektanta.
- Brak danych granicznych, takich jak pusta wartość, maksymalna długość, wartość ujemna lub bardzo duża liczba.
- Pomijanie ról i uprawnień, mimo że różni użytkownicy widzą różne funkcje.
- Brak testów połączeń między usługami, przez co błąd pojawia się dopiero w pełnym procesie.
- Ignorowanie logów, które często pokazują przyczynę problemu szybciej niż interfejs.
- Traktowanie zielonego raportu jako dowodu jakości, mimo że scenariusze nie obejmują krytycznych ryzyk.
- Testowanie tylko jednej przeglądarki, urządzenia lub wersji systemu, gdy produkt ma szerszą grupę odbiorców.
Drugim błędem jest brak rozróżnienia między awarią środowiska a defektem aplikacji. Niedziałający serwer testowy, wygasły certyfikat albo brak danych w bazie może dać czerwony wynik, ale nie oznacza jeszcze błędu w kodzie. Dlatego każdy incydent powinien mieć sprawdzalny kontekst techniczny.
Trzeci problem to mierzenie wyłącznie liczby wykonanych testów. Sto scenariuszy nie daje dużej wartości, jeśli wszystkie sprawdzają tę samą ścieżkę. Znacznie lepiej analizować pokrycie ryzyk, liczbę defektów znalezionych przed wydaniem, błędy wykryte przez użytkowników i czas potrzebny na ich usunięcie.
Jak wyciągnąć z testów wnioski przydatne dla zespołu
Sam raport błędów to za mało. Po zakończeniu testów porządkuję wyniki według wpływu na użytkownika, prawdopodobieństwa wystąpienia i łatwości odtworzenia. Dzięki temu zespół widzi, które problemy blokują wydanie, które wymagają poprawki przed kolejnym sprintem, a które można świadomie odłożyć.
Dobrą praktyką jest śledzenie kilku prostych wskaźników, takich jak defekty znalezione po wdrożeniu, czas od zgłoszenia do retestu, stabilność testów automatycznych i pokrycie najważniejszych procesów biznesowych. Liczby mają sens tylko wtedy, gdy prowadzą do decyzji, na przykład zmiany scenariusza, poprawy danych testowych albo dodania monitoringu.
Warto też analizować wzorce. Jeżeli podobne błędy powtarzają się przy integracjach, problemem może być brak kontraktów API. Jeżeli regularnie zawodzą testy po zmianach konfiguracji, zespół potrzebuje lepszego zarządzania środowiskami, a nie kolejnych przypadkowych przypadków testowych.
Najbardziej dojrzały proces traktuje testy dynamiczne jako część cyklu dostarczania, a nie kontrolę wykonywaną tuż przed premierą. Testy uruchamiane w pipeline mogą szybko zatrzymać wadliwą zmianę, natomiast ręczna analiza nadal jest potrzebna tam, gdzie liczy się logika biznesowa, bezpieczeństwo i doświadczenie użytkownika.
Najwięcej zysku daje połączenie obserwacji i dobrych pytań
Testowanie działającej aplikacji odpowiada na pytanie, czy system zachowuje się poprawnie w konkretnych warunkach. Nie gwarantuje znalezienia każdego błędu, ale pozwala zobaczyć problemy, których nie widać w samym kodzie ani w pojedynczych testach jednostkowych.
Jeśli miałbym wskazać jedną zasadę, byłaby prosta: zaczynaj od ryzyka, definiuj mierzalny wynik, zbieraj dowody i łącz automaty z myśleniem eksploracyjnym. Wtedy runtime przestaje być tylko etapem wykonywania testu, a staje się źródłem konkretnych decyzji o jakości produktu.
