Odpowiedź.

Testowanie niefunkcjonalne to sprawdzanie systemu nie tylko pod kątem wykonywania funkcji biznesowych, ale także według parametrów wygody użycia (usability), wydajności, bezpieczeństwa, adaptacyjności i dostępności (accessibility).

Historia pytania: Na początku rozwoju testowania skupiano się głównie na "działa/nie działa", ale wraz ze wzrostem konkurencji i wymagań dotyczących jakości produktu zaczęto zwracać uwagę na towarzyszące parametry — wygoda, szybkość działania, dostępność dla osób z ograniczeniami. To wpłynęło na rozwój testowania niefunkcjonalnego.

Problem: Testerzy często nie wiedzą, jak sformalizować i ocenić niefunkcjonalne parametry ręcznie. Pojawia się subiektywność: to, co jest wygodne dla jednego użytkownika, może być niewygodne dla innego. Brak jasnych list kontrolnych i kryteriów tylko pogarsza sytuację.

Rozwiązanie: Tester powinien:

Korzystać ze standardów i zaleceń, takich jak WCAG dla dostępności lub ISO 9241 dla użyteczności.
Wykorzystywać specjalne narzędzia (np. analizator kolorów do sprawdzania kontrastu tekstu i tła, symulator czytnika ekranu do sprawdzania dostępności).
Opracowywać listy kontrolne do oceny doświadczeń użytkownika, nawigacji, czytelności elementów itp.
Angażować rzeczywistych użytkowników z różnym doświadczeniem do testów użytkowników.

Kluczowe cechy:

Praca z "żywymi scenariuszami" użytkownika, a nie tylko na podstawie gotowych przypadków testowych.
Konieczność dokumentowania znalezionych problemów niefunkcjonalnych w sposób jak najbardziej konkretny.
Umiejętność korzystania z zewnętrznych narzędzi do analizy (np. Lighthouse, Axe, NVDA, JAWS, Color Contrast Analyzer).

Pytania z podchwytliwością.

Czy można obejść się bez ręcznego testowania użyteczności, jeśli używa się testów automatycznych?

Nie. Doświadczenie użytkownika jest bardzo subiektywne, a wiele aspektów można wykryć tylko podczas ręcznej analizy lub kontaktu z rzeczywistymi użytkownikami.

Czy wystarczy sprawdzić dostępność (accessibility) tylko za pomocą automatycznych skanerów?

Nie. Automatyczne kontrole zazwyczaj ujawniają tylko 20–30% problemów. Pozostałe można wykryć tylko za pomocą ręcznego interakcji: sprawdzania nawigacji klawiaturą, czytania z użyciem czytnika ekranu itp.

Czy należy testować dostępność, jeśli wśród klientów nie ma osób z niepełnosprawnościami?

Tak. Ustawodawstwo, standardy jakości i perspektywy rozwoju produktu wymagają wysokiej dostępności. Ponadto część użytkowników może mieć tymczasowe ograniczenia (np. kontuzje).

Typowe błędy i antywzorce

Lekceważenie wymagań niefunkcjonalnych z powodu ich niedoceniania.
Dokumentowanie wyników bez odniesienia do standardów.
Opisywanie błędów frazami „niewygodne” lub „niekomfortowe” bez konkretów.

Przykład z życia

Negatywny przypadek

Tester nie zwrócił uwagi na niski kontrast etykiety do przycisku: użytkownicy z zaburzeniami percepcji kolorów nie widzieli tekstu.

Zalety:

Oszczędność czasu na testowaniu.

Wady:

Użytkownicy skarżyli się, wzrosła liczba zgłoszeń do wsparcia, utrata reputacji.

Pozytywny przypadek

Tester użył darmowego narzędzia do sprawdzania kontrastowości i opracował listę kontrolną dostępności.