Jakie błędy najczęściej zgłaszamy?

Testujesz? Eksplorujesz? Oto najczęstsze błędy, jakie będziesz znajdować i zgłaszać na początku swojej pracy jako tester.

Błędy tego typu zwykle mają priorytet mały i raczej nie są ulubionymi do naprawy przez programistów i do zgłaszania przez testerów (duży nakład pracy, mały efekt). Niemniej powinny być zgłaszane i zwykle są poprawiane. Piszę zwykle, ponieważ w testowaniu to zależy 😉 od kosztów naprawy i tego, jak bardzo szkodliwy jest błąd. Inny priorytet i ważność dostanie literówka na stronie głównej produktu sprzedawanego, inny literówka w tekście polityki prywatności. To skrajne przykłady, ale w dobry sposób obrazujące nadawanie priorytetów. Inny przykład to e-book „101 pytań i odpowiedzi” mojego autorstwa, pomimo wielu sprawdzeń i kontroli, w tekście znajdowane są literówki, zgłaszane przez was trafiają na listę, poprawię je i wrzucę razem z wersją 2.0 e-booka, ale nie robię tego po każdym zgłoszeniu, ponieważ proces poprawy jednej literówki to ok godziny pracy (wyszukanie w tekście, poprawa, publikacja jako pdf, logowanie do serwera, podmiana wersji pliku, upewnienie się, że podmieniłem właściwy plik).

Element nie wczytał się poprawnie na stronę.

Strona internetowa wczytuje się, pojawia się tekst, ale brakuje obrazka. Zamiast niego jest „X” albo tekst informujący o błędzie podczas wczytywania elementu.

Priorytet tych błędu zależeć będzie od tego odpowiedzi na kilka pytań:

Co się nie wczytało?

Zanim dobierzesz priorytet, powinieneś odpowiedzieć sobie na pytanie, jak ważny jest obrazek dla strony? Jest to logo a może obrazek dodany do posta na blogu? Ilu użytkowników może na niego natrafić?

Dlaczego element się nie wczytał?

Przykładowym powodem niewczytania elementu może być jego nieistnienie (czyli np. zła nazwa pliku podana), wolno działająca sieć lub wielkością obrazka (zamiast 100 KB waży on 1 MB). Powód niewczytania elementu strony bardzo często widoczny jest w zakładce „sieć” narzędzi programisty w przeglądarce. Błąd zgłaszaj, gdy obrazek jest nieskompresowany lub nie istnieje. Nie zgłaszaj, gdy sieć działa wolno.

Jak nie wczytanie elementu zostało obsłużone?

Wiesz już, że nie wczytanie elementu może być spowodowane wolnym działaniem sieci na przykład, wówczas należy sprawdzić, czy zamiast obrazka wyświetlany jest tekst alternatywny. Tekst alternatywny powinien być ustawiony przynajmniej dla najważniejszych obrazów strony jak logo, obrazki produktów.

Jak nie wczytanie elementu wpłynęło na wczytanie/wygląd pozostałych elementów?

Jeden z ważniejszych czynników decydujących o priorytecie błędów. Nie wczytanie elementu na stronie nie może spowodować jej rozjechania. Pozostałe elementy strony mają być nadal czytelne, strona ma być możliwa do obsługi.

Błąd 404

Strona lub element nie istnieje. Najczęściej spotykany kod odpowiedzi HTML, jaki chyba każdy zna I choć raz w życiu widział. Błąd ten występuje, gdy jako użytkownik chcemy wyświetlić w przeglądarce coś, co nie istnieje już na serwerze. Może to być strona internetowa, która została usunięta, strona, której zmieniono adres z wyszkolewas.com.pl/home na wyszkolewas.com.pl/main_page albo element strony jak obrazek.

Priorytet błędu dla kodu 404

Jak zwykle w testowaniu to zależy ;). Zwykle będzie to jednak priorytet wysoki, ponieważ nawet jeśli zasób (np. strona internetowa) ma się nie wyświetlić to i tak powinno to być obsłużone czy to poprzez komunikat „Wybrana strona już nie istnieje w naszym serwisie, przejdź na stronę główną” lub automatyczne przekierowanie do nowej strony (zastępującej nieistniejącą) albo do strony głównej.

Wyjątek – aplikacja przestaje działać.

Używasz aplikacji, klikasz tu i tam aż tu nagle błąd „Aplikacja przestała działać” albo nawet bez komunikatu, wyłącza się i już. Znalazłeś błąd 🙂 wysoki, a nawet krytyczny. Czasami jest to ogólny błąd aplikacji, łatwy do odtworzenia, a czasami trzeba powtórzyć dokładnie kroki wcześniej wykonane, by wystąpił. Spróbuj go odtworzyć i zgłoś najdokładniej, jak potrafisz, jeśli jego wystąpienie zależy od tego, jak użytkownik używał aplikacji.

Zawieszenia w działaniu aplikacji

Błąd, który wywołuje frustracje, zwłaszcza gdy wystąpił przed zapisaniem danych. Wywołany może być na przykład przez nie zwalnianie zasobów pamięci przez aplikację, przez zapętlenie. Jako tester możesz sprawdzić pierwszy przypadek w menadżerze zadań swojego komputera (jeśli widzisz, że aplikacja działa coraz wolniej, pamięć przez nią zajmowana, stale rośnie). Tego typu błąd powoduje zwykle spowolnienie działania aplikacji lub nawet jej wyłączenie.

Priorytet zwykle wysoki, ponieważ nie dość, że aplikacja przestaje działać, to jeszcze użytkownik traci niezapisane dane.

Wyjątki i nieobsłużone błędy w aplikacji.

Czyli nieobsłużone błędy i komunikaty, jakie aplikacja może wyświetlić użytkownikowi. W tym przypadku często błąd powinien wystąpić i jest spodziewany w aplikacji, ponieważ przykładowo użytkownik podał niepoprawne dane w formularzu, natomiast nieprawidłowe jest jego obsłużenie. Użytkownik powinien otrzymać komunikat informujący go co nie działa, co powinien poprawić, co ma zrobić.

Priorytet tych błędów zależeć będzie od sytuacji, w jakiej występuje, ilu użytkowników na niego natrafi, jak bardzo jest uciążliwy. Zwykle będzie to jednak przynajmniej medium.

Nieprawidłowe wczytanie strony – niemieszczące się na stronie elementy.

Błędy, które często występują na urządzeniach z małym wyświetlaczem (telefon, zegarek, tablet).

Sytuacje, w których musisz przesunąć zawartość ekranu w prawo, by doczytać tekst wpisu, ponieważ strona jest szersza niż ekran, na którym jest wyświetlana.

Należą do nich również błędy, w których elementy są zbyt małe, by mogły być odczytane na małym ekranie.

Wynikają z tego, że mamy wiele rozdzielczości, na których przykładowo strona internetowa ma się wyświetlać i nie zawsze udaje się wszystko idealnie dostosować, by było prawidłowo wyświetlone. Wiele stron internetowych nadal nie jest dostosowana do tego, by wyświetlać je na urządzeniach mobilnych, dlatego wyświetlane są tak, że ręcznie trzeba przesuwać ekran w prawo, by doczytać treść. Błędy te zwykle zgłaszamy, jeśli wiemy, że aplikacja czy strona ma być używana na urządzeniach mobilnych. Testujemy je na rozdzielczościach, na jakich ma ona działać. I jeśli mimo wymagań, aplikacja nie renderuje się poprawnie, zgłaszamy błąd (priorytet od medium wzwyż).

Błędy funkcjonalne.

Moje ulubione. Trzeba znać aplikację przynajmniej w minimalnym stopniu, wiedzieć jak ma działać, by je znaleźć. Błędy funkcjonalne dotyczą nieprawidłowości w działaniu aplikacji, tego, jak ma działać, co powinna robić. Ich priorytet będzie różny, zależnie od tego, czego funkcjonalność dotyczy. Zaczniesz je zgłaszać, jak poznasz specyfikę aplikacji, często na początku nauki testowania błędy funkcjonalne nie są zauważane. Jednak widzę, ze z czasem z praktyką nabytą wyostrza się ten zmysł testerski, który pomaga w ich znajdowaniu.

Podsumowanie

Wydaje mi się, że to jest lista najczęstszych typów błędów, jakie zgłasza tester na początku pracy. Ważniejsze od znalezienia błędu jest to, jak go opiszesz. Pamiętaj o tym i zwracaj uwagę na szczegóły, zgłaszając błąd. Od tego, jak go opiszesz, zależeć będzie czy programista będzie miał problem z jego odtworzeniem. Czy tester retestujący będzie miał problem z jego sprawdzeniem? Czy będziesz musiał poświęcić czas na to, by samodzielnie odtworzyć raz jeszcze błąd i go pokazać programiście osobiście?