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?
Najpopularniejsze 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 😉 .