Automatyczne testowanie (IT)Tester interfejsów użytkownika

Jak identyfikować i dokumentować defekty niefunkcjonalne (np. problemy z wydajnością, użytecznością interfejsu lub dostępnością) w procesie testowania manualnego?

Zdaj rozmowy kwalifikacyjne z asystentem AI Hintsage

Odpowiedź

Historia pytania:

Testowanie niefunkcjonalnych aspektów pojawiło się, gdy stało się jasne: nawet idealnie działająca funkcjonalność może być niewygodna, wolna lub niedostępna dla części użytkowników. Takie defekty są trudne do wykrycia automatycznie, dlatego testerzy manualni odgrywają kluczową rolę.

Problem:

Testerzy często koncentrują się tylko na funkcjonalności, ignorując wydajność, użyteczność i dostępność. Defekty niefunkcjonalne są trudne do sformalizowania i wyjaśnienia, ich subiektywność utrudnia uzyskanie jednoznacznej oceny.

Rozwiązanie:

Podczas testowania warto świadomie poświęcić czas na kontrole niefunkcjonalne. Dla wydajności mierz czas reakcji (np. stoperem), dla użyteczności opisuj niedogodności i podawaj przykłady, dla dostępności korzystaj z list kontrolnych lub narzędzi (np. włączając czytnik ekranu).

Kluczowe cechy:

  • Wymagają jasnego sformułowania kryteriów akceptacji.
  • Wyniki oceny są często subiektywne, dlatego ważna jest argumentacja raportów.
  • Nie wszystkie takie defekty są dopuszczalne przed wydaniem — część jest krytyczna.

Pytania z podstępem.

Czy każdy defekt niefunkcjonalny powinien być zgłaszany przez testera jako raport błędu?

Nie zawsze. Jeśli problem jest subiektywny, czasami wystarczy omówić go z zespołem i udokumentować jako sugestię ulepszenia (feature request).

Czy tester powinien sam ustawiać metryki wydajności?

Tylko jeśli nie są one opisane w wymaganiach lub specyfikacji, w przeciwnym razie należy się na nich oprzeć.

Czy konieczne jest posiadanie specjalnego oprogramowania lub narzędzi do testowania niefunkcjonalnego?

Nie, podstawowe kontrole są możliwe ręcznie (np. ręczne pomiary czasu, analiza dostępności według listy kontrolnej).

Typowe błędy i antywzorce

  • Ignorowanie niefunkcjonalnych kryteriów.
  • Subiektywne raporty bez mierzalnych dowodów.
  • Zbyt ogólne lub niejasne nazwy i opisy błędów.

Przykład z życia

Negatywny przypadek

Tester zauważył, że strona katalogu ładowała się dłużej niż 10 sekund, ale nie zgłosił błędu, uznając, że „może tak jest u wszystkich”.

Zalety:

  • Nie zasypywał zespołu kontrowersyjnymi tiketami.

Wady:

  • Zmniejszone doświadczenie użytkownika, klienci są rozczarowani, kierownictwo dowiedziało się o problemie z reklamacji.

Pozytywny przypadek

Tester dokładnie udokumentował, że strona katalogu ładowała się przez 12 sekund przy pierwszym wejściu, dołączył zrzut ekranu ze stoperem, zaproponował możliwe opcje optymalizacji.

Zalety:

  • Zespół otrzymał obiektywny opis problemu i mógł szybko go zdiagnozować.

Wady:

  • Dokumentacja takich błędów zajmuje więcej czasu.