Jak nie przekazywać złych wieści - komunikaty błędów

Źle zaprojektowany komunikat błędu jest gorszy niż błędy programistyczne. Nie dosyć, że nie pomaga użytkownikowi rozwiązać problemu przed jakim staje to dodatkowo potrafi doprowadzić do furii. Klient zlecający wykonanie oprogramowania rzadko kiedy definiuje komunikaty błędów samodzielnie. To wykonawca projektu robi to za niego. Tracą obie strony. Oto kilka przykładów.

Użytkownik popełniając błąd nie chce tego zrobić. Powtórzone wykrzykniki i duże litery to w Internecie symbol krzyku. Pytanie: po co krzyczeć na użytkownika kiedy popełnia błąd? Jest to objaw frustracji ze strony tworzącego oprogramowania. Wystarczy napisać: "Podane hasło nie ochroni bezpieczeństwa danych. Musisz podać hasło zawierające..."



Błędy przy podaniu złego adresu mogą być różne. Źle jest gdy zawierają błędy lub sposób kodowania nie jest odpowiednio zdefiniowany.

Poniżej prezentujemy komunikat po podpięciu się do istniejącej strony z problemami technicznymi. Widzimy, że nie tylko aplikacja ma problem. Również twórca ma problem. Wrzesień - czas do szkoły.


Jeżeli oszukujemy klienta, że może kupić coś czego nie może kupić, to na końcu samo formatowanie komunikatu nie zdenerwuje nas już tak bardzo jak jego treść. "Ja" nie wiedziałem, że muszę kupić za 99PLN aż do przejścia do płatności. Wykrzyknij na końcu sugeruje, że twórcy aplikacji nie podoba się, to co zrobiłem i wysyła mnie do Sklepu. Pozostaje przeprosić, że nie kupiliśmy za 99PLN.





Więcej błędów stron WWW na http://forum.testerzy.pl/viewforum.php?f=28



 

 

 

Najbliższe terminy szkoleń

 

28-30 listopada - Katowice

ISTQB Poziom Podstawowy (Foundation Level)


28 listopada-1 grudnia - Wrocław

Zawód Tester


4-6 grudnia - Warszawa

ISTQB Poziom Podstawowy (Foundation Level)

 

Partnerzy

Narzędzia testerskie