10 reasons why your bugs are getting rejected
Nie zamierzam jej oszczędzić. Zgłosiłem, że odrzuciła 7 błędów w ciągu ostatnich trzech dni. Wiem, że używa osobistych uraz jako profesjonalnego miecza ……
Kolega z zespołu się wściekał, a dyskusja nagle wybuchła, gdy kilku innych członków zespołu dołączyło do dzielenia się tym samym doświadczeniem z innymi programistami. Spotkanie zespołu zmieniło punkt dyskusji na temat odrzucania błędów. Po krótkiej dyskusji zdecydowaliśmy się wszyscy wykonać proste ćwiczenie, aby w przyszłości uchronić się przed upokorzeniem odrzuconego błędu.
Każdy z nas zaczął notować jako powody odrzucenia ostatnich 10 błędów, zgłoszonych i odrzuconych. Lista tych notatek o odrzuceniu okazała się przydatna do zrozumienia przyszłej ścieżki zgłaszania błędów i tego, jakie było błędne założenie.
Odrzucenie błędu i jego przyczyny
Zamiast ujawniać listę, chciałbym podzielić się punktami końcowymi listy. Oto jest -
# 1) Niezrozumienie wymagań:
Z jakiegokolwiek powodu, jeśli nie zrozumiałeś poprawnie wymagania, na pewno zwróciłbyś uwagę na błędnie zinterpretowane wymaganie w rzeczywistej implementacji, a jeśli go nie znalazłeś, byłby to według ciebie błąd, który ostatecznie zostanie odrzucony.
Przykład z życia wzięty : Po przetestowaniu przepisu okazało się, że jest on bez smaku, ponieważ nie dodano soli, ale nie wiedziałeś, że należy ją dodać w momencie podania, w przeciwnym razie może to wpłynąć na wygląd przepisu.
# 2) Implementacja wymagań:
W ramach wcześniejszej dyskusji zdawaliście sobie sprawę, że określone wymaganie zostanie zaimplementowane w sposób XYZ. Ale w trakcie opracowywania deweloper stwierdził, że nie jest możliwe podążanie ścieżką XYZ, więc podążył ścieżką ABC i nie zostało ci to przekazane.
Ostatecznie zgłosisz błąd, gdy stwierdzisz, że wymaganie nie zostało zaimplementowane w sposób, w jaki zostało omówione.
pytania i odpowiedzi na wywiady z inżynierem devops
Przykład z życia wzięty : Poprosiłeś krawca o przygotowanie koszuli, a kiedy zostałeś poproszony o próbę, odrzuciłeś ją, mówiąc, że nie znalazłeś na niej guzików. Gdyby krawiec wyjaśnił, że założenie guzików z przodu wpłynęłoby na ogólny wygląd koszuli i dlatego umieściłby ją wewnątrz przedniej krawędzi, na pewno byś się zdziwił.
# 3) Brak jasnych wymagań:
Gdy nie ma dostępnych jasnych wymagań, każdy może przyjąć je na swój sposób, a to prowadzi do założenia na poziomie osobistym. Kiedy widzisz, że osobiste założenie nie jest spełnione, oznaczasz to jako błąd.
Przykład z życia wzięty : Musisz narysować cykl, kiedy nauczycielka ogłosiła, że spodziewała się, że uczniowie narysują rower. Po pół godzinie, kiedy sprawdzała wszystkie rysunki, nie znalazła nikogo, kto by odpowiadał jej oczekiwaniom. Każdy wziął niejasne stwierdzenie na swój własny sposób, a rezultatem był trójkołowiec, rower dziecięcy, zbyt wiele cykli, rower z wózkiem inwalidzkim i tak dalej.
# 4) Zmiana wymagań:
Kolejny przykład nieporozumień przez większość czasu. Gdy testerzy nie zostaną poinformowani o zmianach wymagań, zostanie zgłoszonych więcej błędów i ostatecznie odrzuconych.
Przykład z życia wzięty : Zdecydowanie odrzucisz kanapkę, gdy okaże się, że była to chleb miodowy, a nie bananowy, który zamówiłeś. Przynajmniej wiedziałeś, że twój partner zmienił rodzaj chleba do zamówienia, kiedy rozmawiałeś przez telefon i oczywiście nie uznał za konieczne, aby się z tobą podzielić.
# 5) Zrozumienie zakresu:
Podczas testowania zaczynasz testować coś, co nie powinno być uważane za testowalne w określonym momencie lub w ogóle nie jest objęte kryteriami produktu; będziesz ofiarą odrzucenia błędu.
Przykład z życia wzięty : Masz zamiatać pokój i to jest jedyny cel. Jeśli jednak narzekasz na bałagan w innych obszarach, na pewno zostaniesz zignorowany.
# 6) Środowisko testowe:
Aplikacja / produkt to kombinacja wielu wymagań sprzętowych i programowych - zarówno głównych, jak i mniejszych, a gdy nie jest używane odpowiednie środowisko testowe lub brakuje czegoś w środowisku testowym, dochodzi do awarii aplikacji / produktu i zgłaszania krytycznego błędu….
Następnie - dogłębne badanie, ponieważ przez większość czasu nieumyślnie nie dbamy o podanie drobnych szczegółów na temat używanego przez nas środowiska testowego, co zwiększa pracę programisty. Ostatecznie błąd zostaje odrzucony.
Przykład z życia wzięty : Te pyszne babeczki, które próbowałeś w domu przyjaciela przed kilkoma dniami, były niesamowite i po zastosowaniu się do przepisu babeczki nie były nawet bliżej tej, którą miałeś.
Cóż, nie miałeś używać czerstwego masła, ponieważ nie było świeżego masła, nie należało dodawać szczypty mąki gramowej, ponieważ myślałeś, że może to dodać smaku, nie powinno się gotować go na patelni jako piekarnik był niesprawny.
Zalecana lektura => Jak skutecznie przygotować „środowisko testowe”.
rodzaj błędów w testowaniu oprogramowania
# 7) Wykorzystane dane testowe:
Dane testowe użyte do testowania były niezgodne z wymaganiem.
Przykład z życia wzięty : Nawet jeśli wiesz, że kalkulator jest przydatny w przetwarzaniu numerycznym, jeśli próbujesz dodać znaki specjalne i gdy kalkulator reaguje nieoczekiwanie, uważasz, że było to niewłaściwe. Naprawdę?
Zalecana lektura => Wskazówki dotyczące projektowania danych testowych i Techniki zarządzania danymi testowymi .
# 8) Duplikat błędu:
Ktoś już zgłosił ten sam błąd, a ty nie zadałeś sobie trudu, aby sprawdzić to samo przed zgłoszeniem błędu. Znowu odrzucenie.
Przykład z życia wzięty: Osoba obsługująca klienta nie będzie zadowolona, gdy otrzyma wiele telefonów z reklamacjami na ten sam produkt od każdego członka rodziny. Pomyślał, że to nie wystarczy jeden telefon.
# 9) Nieprawidłowy opis błędu:
Kiedy programista nie jest w stanie zrozumieć, co próbujesz przekazać w raporcie o błędzie, spodziewaj się, że zostanie on odrzucony, ponieważ są one również załadowane innymi zadaniami i gdy nie znajdą odpowiedniego opisu i wymaganych szczegółów w raporcie o błędzie, bez względu na sposób krytyczny błąd jest, oczekuje się, że zostanie oznaczony jako odrzucony.
Zalecana lektura => Jak napisać dobry raport o błędzie? Porady i wskazówki.
Przykład z życia wzięty: Musisz odblokować samochód, usiąść i zacząć od przekręcenia kluczyków w kierunku zgodnym z ruchem wskazówek zegara… samochód nie odpalił, więc jesteś zdenerwowany. Czy nie polecono ci sprawdzić benzyny? Aha, błąd w instrukcji gdyż zakładał, że na pewno zrozumiesz, że powinien być domyślnie zaznaczony.
najlepszy darmowy program do czyszczenia rejestru dla systemu Windows 10
# 10) Niepowtarzalne błędy:
Zgłaszając błąd, nigdy nie zdawałeś sobie sprawy, jak ważna jest odtwarzalność błędu. Tylko upewnienie się, że błąd jest powtarzalny zawsze, czy pojawia się losowo, może zaoszczędzić godziny pracy i jeszcze jednego odrzuconego błędu.
Przykład z życia wzięty: Co by sprawdził lekarz, gdy narzekasz na ostre przeziębienie, ale nie stwierdza żadnych objawów. Och, tylko mocno kichałem , nie poprawi sytuacji.
Wniosek
W większości przypadków nasza ludzka natura pozwala nam myśleć negatywnie, gdy zgłoszony błąd zostanie odrzucony. Naprawdę programiści nie widzą konkretnego powodu, aby odrzucić błąd, jeśli jest on prawidłowy.
Więc następnym razem nie skupiaj się na liczbie błędów. Skoncentruj się na jakościowych błędach z odpowiednimi szczegółami, ponieważ ostatecznie liczy się sposób, w jaki pomogłeś w poprawie jakości produktu, a nie liczbę zgłoszonych błędów.
Przeczytaj także => Jak naprawić wszystkie błędy bez etykiety „Nieprawidłowy błąd”?
O autorze: Ten przydatny artykuł został napisany przez członka zespołu STH, Bhumikę Mehtę. Jest kierownikiem projektu z ponad 7-letnim doświadczeniem w testowaniu oprogramowania.
Miłego testowania! Jak zwykle czekam na Wasze opinie na ten sam temat.
rekomendowane lektury
- Jak naprawić wszystkie błędy bez etykiety „Nieprawidłowy błąd”?
- Dlaczego zgłaszanie błędów to sztuka, której powinien się nauczyć każdy tester?
- Sztuka raportowania błędów: jak sprzedawać i naprawiać błędy?
- Dlaczego oprogramowanie ma błędy?
- 7 rodzajów błędów oprogramowania, które powinien znać każdy tester
- 11 sposobów, w jakie wiesz, że jesteś testerem ...
- Przykładowy raport o błędzie
- 5 sposobów na bycie odważnym i pewnym siebie testerem oprogramowania