Wymagania niefunkcjonalne na frontendzie - jak do nich podejść?

Każdy projekt informatyczny składa się z funkcjonalności. Część z nich jest mniej lub bardziej dokładnie opisana w historyjkach, natomiast pozostała część jest domyślna. Domyślne wymagania są powtarzalne na przykład dla każdej podstrony w aplikacji i stanowią ważną wartość dla klienta. Ich spełnienie, jest konieczne do tego, by praca została uznana za wykonaną.

Przykładowe wymagania niefunkcjonalne na które możesz napotkać się na frontendzie:

• Jeśli w aplikacji pojawia się akcja usunięcia, powinna być potwierdzana przez okno dialogowe
• Podstrony powinny obsługiwać tryb tylko do podglądu
• Każda strona powinna posiadać skiplinki i breadcrumbsy (nawigację okruszkową)
• Przyciski w każdym miejscu aplikacji powinny mieć animację
• Możliwa jest nawigacja i obsługa aplikacji jedynie z użyciem klawiatury
• Aplikacja posiada tryb ciemny
• Prawidłowo obsłużone są błędy z backendu
• Podczas ładowania danych pokazywane są loadery
• Strona jest responsywna i spójna z innymi stronami

Jak odpowiednio podejść do wymagań niefunkcjonalnych jako front-end developer?

Moim zdaniem, warto spisać te wymagania w jednym miejscu (na przykład na zespołowym wiki, chociaż może być to dowolny udostępniony dokument). Z wymaganiami powinni być zapoznani zarówno testerzy, jak i deweloperzy. Spisanie wymagań niefunkcjonalnych w jednym miejscu znacznie ułatwi także wprowadzenie nowych osób do zespołu.

Podczas rozwoju funkcjonalności musisz być świadomy tego, co oznacza, że praca jest skończona. Przykładowo, jeśli masz zrobiony nowy ekran, skopiuj sobie wymagania niefunkcjonalne do pliku tekstowego i po kolei sprawdzaj z niego, czy wymagania zostały spełnione, wykreślając jeden punkt po drugim. 

Dzięki temu, będzie mniejsze ryzyko że Twoja funkcjonalność będzie wracała od testera. 

Implementacyjnie - starajmy się wyodrębniać jak najwięcej powtarzalnych reużywalnych komponentów.

Wydaje mi się, że ta metoda jest równie przydatna dla osób zajmujących się zapewnieniem jakości. Scenariusze testowe rzadko kiedy obejmują sprawdzanie całego flow aplikacji osobno na przykład w trybie ciemnym.