Tym z was, którzy postawili już pierwsze kroki w świecie testerskim i tropią defekty oprogramowania zawodowo, z pewnością przydarzyła się sytuacja, w której wykryty bug wrócił z etykietą invalid (nieważny/nieprawidłowy). W takiej sytuacji system działa według określonych specyfikacji mimo zaraportowanego błędu.

Jeśli chcecie dowiedzieć się więcej na temat defektów, to odsyłamy was do naszego posta o cyklu życia buga

Każdy tester powinien dokonywać wszelkich starań, by bugi przez niego raportowane były rozwiązywalne. To wymaga jednak pewnego zasobu umiejętności, w tym sprawności w samym raportowani, które powinno być profesjonalne i jednoznaczne.

Głównym powodem, dla którego pojawia się etykietka invalid, jest „niewystarczające rozwiązanie problemów” przez testera przed zaraportowaniem defektu. I w tym poście właśnie tym zagadnieniem się zajmiemy. Rozwiązywanie problemów pomoże zdecydować, czy niejednoznaczność znaleziona w testowanej aplikacji/oprogramowaniu jest faktycznie bugiem, czy błędem konfiguracji testu.

Pamiętajmy, że prawie 50% bugów zostaje oznaczone etykietką „nieważnych” tylko z powodu niekompletnej konfiguracji testów. Załóżmy, że udało ci się wytropić jakąś dwuznaczność w aplikacji czy oprogramowaniu. Podejmujesz więc pierwsze kroki, by zaraportować ją jako buga. Zastanów się jednak najpierw, czy starałeś się wystarczająco wykryć i rozwiązać problem, zanim przekazałeś do dalej? Czy wykonałeś wszystkie czynności, by potwierdzić, że to naprawdę błąd?

Ciekawi was w jaki sposób znaleść buga w aplikacji? Zapoznajcie się z naszymi tips&tricks

Na jakie pytania powinieneś sobie odpowiedzieć w pierwszej kolejności, po wykryciu niejednoznaczności w trakcie testowania?

  • Co nie działa?
  • Dlaczego nie działa?
  • Jak sprawić by działało?
  • Jakie są możliwe powody porażki?

znak wrong way zła droga czerwony

Najbardziej popularne przyczyny nieważnych błędów i jak ich uniknąć
  • W przypadku korzystania z plików konfiguracyjnych do testowania; upewnij się, że pliki są odpowiednie i zgodne z wymaganiami. Jednym z najczęstszych powodów określania zajścia jako błędu, który w rzeczywistości nim nie jest, jest sytuacja, w której nastąpi niepowodzenie w utrzymaniu pliku zgodnie z wymaganiami oprogramowania lub klienta. By uniknąć takiej sytuacji, zaleca się zastosowanie dodatkowych testów konfiguracji
  • Przed przejściem do testowania komputerowego lub mobilnego, zyskaj pewność, że dostarczona baza danych jest ważna i posiada wszystkie niezbędne dane
  • W przypadku testów automatycznych, przed zaraportowaniem buga, wykonaj test powtórnie, by zyskać pewność, że masz do czynienia z defektem
  • Sprawdź, czy dane, których używasz do uwierzytelnienia, są poprawne
  • Zweryfikuj zgodność wersji oprogramowania
  • Sprawdź, czy dysponujesz prawidłowo zainstalowanymi komponentami oprogramowania oraz, czy wpisy do rejestru zostały wykonane poprawnie
  • Upewnij się, że wymagania wstępne dotyczące sprzętu i oprogramowania są spełnione
  • W przypadku każdej nieprawidłowości zajrzyj do „Przeglądarki zdarzeń systemowych” (System event viewer), by uzyskać więcej szczegółowych informacji
  • Przed rozpoczęciem analizy, upewnij się, iż wszystkie najnowsze wersje plików zostały przesłane do środowiska testowego
Dlaczego unikanie etykiety invalid bug jest ważne?
  • Wydajność testowa spada wraz z liczbą raportowanych nieprawidłowych defektów
  • Nie traci się czasu na śledzenie, rejestrowanie nieprawidłowych błędów i na omawianie ich
  • Kierownictwo nie lubi nieważnych defektów
  • Programiści przestaną traktować poważnie testera, którego raporty zbyt często odsyłane są z etykietą invalid

Błędy przez nas wymieniona nie są wielkie, ale dość często się je popełnia. Jeśli okaże się, że zaraportowany przez was defekt zostanie oznaczony jako „nieważny”, a jego przyczyna pochodzi z powyższej listy, będzie to dość bezmyślny błąd i może zaszkodzić waszemu wizerunkowi. Pamiętajmy więc o tej liście, by uniknąć takich sytuacji 😉 .

20
  •  
    5
    Shares
  • 5
  •  
  •  
  •