3 Najgorsze nawyki dotyczące zgłaszania usterek i sposoby ich przełamania

3 worst defect reporting habits

Usterki to poważna sprawa, a drobne błędy mogą być kosztowne.

Wiesz, co zrobić, gdy znajdziesz usterkę. Zgłoś to; albo w Tracker defektów / Narzędzie do zarządzania defektami lub w arkuszu Excel. Podstawowe zasady są takie same dla obu metod.

Narzędzia do zarządzania defektami nie gwarantują lepszego raportowania. To dobre praktyki ratują dzień.

Aby docenić dobro, musimy rozpoznać, czego nie ma.

Czego się nauczysz:

• 3 Najgorsze nawyki dotyczące zgłaszania usterek i sposoby ich przełamania
• # 1) Lenistwo
• # 2) Pośpiech
• # 3) Brak kreatywności
• rekomendowane lektury

3 Najgorsze nawyki dotyczące zgłaszania usterek i sposoby ich przełamania

Tutaj idzie:

# 1) Lenistwo

Nie poświęcasz czasu na zrobienie wszystkiego, co możesz.

To jest proces śledzenia defektów obserwowane w większości zespołów:

(Uwaga- kliknij dowolny obraz, aby wyświetlić powiększenie)

Jak widać, kierownik testów sprawdza usterki przed wysłaniem ich z zespołów kontroli jakości.

Ta recenzja obejmuje potwierdzenie:

• Ważność - czy to błąd?
• Kompletność - tytuł, kroki, dane, zrzut ekranu itp.
• Duplikaty
• Powtarzalne czy nie… itd.

Wiem z pierwszej ręki, że prowadzenie kontroli jakości nie może być w 100% dokładne.

Zatem podejście: „Zgłoszę problem tak, jak chcę. Kierownik kontroli jakości może ponownie sprawdzić. On może zdecydować, czy wada jest ważna / kompletna, czy nie ”to koniec Twojego zespołu ds. Kontroli jakości i Twojej wiarygodności.

Czy wiesz, że niektórzy klienci mają umowy SLA dotyczące liczby akceptowalnych nieprawidłowych defektów? Gdy liczba przekroczy liczbę, zaczną karać wykonawców za każdą zgłoszoną nieważną wadę?

Zaradzić: Dbaj o swoją należytą staranność i bądź odpowiedzialny za swój produkt. Usterka powróciła z powodu niewystarczającej ilości informacji lub że nie jest to błąd? Nie zawsze jest to wina zespołu programistów. Nie chodzi o to, że nie chcą być właścicielami problemów w aplikacji. To może być prawdziwy bałagan w zespole kontroli jakości. Nie pozwól na to.

# 2) Pośpiech

Zróbmy to zprzykład.

Poniżej znajduje się zrzut ekranu OpenEMR's ekran tworzenia pacjenta. Jest to system zarządzania szpitalem typu open source.

Na tym ekranie użytkownik może wprowadzić datę urodzenia pacjenta za pomocą kalendarza. To nie ogranicza wpisu do wyboru z kalendarza. Chodzi mi o to, że możesz wybrać datę urodzenia, powiedzmy, „31 marca 1983” z kalendarza. Później zmień to na „31-luty-1983”.

Dlaczego 31 lutego? Wdrożenie zgadywanie błędów i wypróbuj negatywne dane w terenie; o co chodzi w testowaniu, prawda?

Po zakończeniu klikam „Utwórz pacjenta”. Ponieważ data jest nieprawidłowa, oczekuję, że system wyświetli błąd i nie utworzy pacjenta. Ale tak się nie dzieje. Tworzy pacjenta jak poniżej.

Zwróć uwagę na pola wieku i daty urodzenia na poniższym ekranie:

Podczas testowania możesz spróbować tego kilka razy i zdecydować, że:

• To jest błąd.
• Jest powtarzalny.
• To nie jest duplikat (skontaktuj się ze swoim zespołem, aby potwierdzić)
• Znasz dokładny opis problemu
• Znasz również dokładne kroki, które to umożliwiają.

Teraz, gdy masz już surowiec, możesz iść.

Zaczynasz to zgłaszać. Przypisywanie wagi defektu jest obowiązkowym krokiem, a Twój zespół może używać czegoś podobnego do poniższa tabela w celach informacyjnych:

Ponieważ ta wada nie powoduje awarii systemu ani nie blokuje istotnej funkcjonalności ani nie uniemożliwia testowania innych obszarów aplikacji, możemy wybrać „Niski”.

Wygląda, prawda?

ŹLE. Z danych pacjenta wynika, że ​​wszystkie szczepienia i inne przypomnienia są spóźnione. To może być prawda lub nie. Również wiek pacjenta określa, czy zgłasza się do pediatry, czy lekarza ogólnego itp.

Wpływa na dawki leków i wiele innych obszarów leczenia, o których być może nawet nie wiemy.

Tak więc mam zamiar wybrać „Wysoki”. Zgadzam się, że jest mało prawdopodobne, aby personel szpitala źle wpisał datę urodzenia pacjenta. Ale niech to będzie czynnik wpływający na priorytet, kiedy należy rozwiązać problem.

Moim zadaniem jako testera jest upewnienie się, że przedstawię powagę problemu najlepiej, jak potrafię.

Zaradzić: Nie spiesz się ze zgłoszeniem. Bądź w 100% pewien, że rozumiesz wpływ problemów z wielu perspektyw. To największa wartość dodana, jaką mogą zapewnić testerzy. Nie mówimy tylko: „Coś nie działa”. Mówimy również: „Oto, co się stanie, jeśli to nadal nie zadziała”. Mnóstwo różnicy, prawda?

# 3) Brak kreatywności

Testerzy mają wspaniałą możliwość zgłaszania sugestii dotyczących ulepszenia oprogramowania.

W Twoim Narzędzie do zarządzania defektami możesz również zgłosić błąd typu „Sugestia dotycząca ulepszenia”. Tutaj możesz wykazać się kreatywnością.

Zaradzić: Myśl nieszablonowo. Jeśli uważasz, że jakiejś funkcji brakuje czynnika „Wow” i wiesz, jak to zrobić, przedstaw pomysł. W najgorszym przypadku może zostać odrzucony i to jest w porządku. Ważna część to próba.

Ostrożnie używaj tej super mocy. Staraj się nie robić komentarzy typu „Nienawidzę koloru banera, proszę go zmienić”.

Tutaj jest dobrzeprzykładsugestii ulepszenia, na którą się natknąłem: Zastąpienie opcji „E-mail do sprzedawcy” opcją „Rozmawiaj ze sprzedawcą” w witrynie salonu samochodowego. Przewiduje się, że zwiększy ruch w sprzedaży.

Żałuję, że nie jestem tak kreatywny! Ale może wszyscy możemy nad tym pracować.

Oto bonus. Lista kontrolna, aby uwolnić się od tych złych nawyków:

1. Czy mój tytuł jasno i zwięźle przedstawia problem?
Na przykład:„Tworzenie pacjenta nie działa” nie jest dobrym tytułem. „Tworzenie pacjenta kończy się niepowodzeniem, nawet jeśli wszystkie pola wejściowe zawierają prawidłowe wartości”.

2. Jaki jest współczynnik odtwarzalności?
Innymi słowy, czy to się zawsze zdarza? Czy znam dokładną sekwencję czynności, które spowodują powtórzenie problemu?

3. Czy problem dotyczy konkretnej platformy, przeglądarki lub użytkownika?

Cztery. Czy wszystkie kroki zostały zakończone i doprowadziły Cię do problemu?

5 . Czy mam zrzut ekranu?

6. Czy muszę dodawać adnotacje do mojego zrzutu ekranu, aby wyróżnić określone obszary?

7. Czy nazwa załączonego pliku obrazu ma charakter opisowy?
Nie używaj czegoś takiego jak „Untitled.jpg”. Nadaj mu opisową nazwę.

8. Czy załączyłem dane testowe?
Na przykład:W przypadku defektu w module administracyjnym, który wymaga poświadczeń autoryzacji, uwzględnij je. Zespół programistów może mieć dostęp do środowiska kontroli jakości lub nie. Nie chcesz opóźnienia i kontynuacji czegoś tak podstawowego, jak to.

9. Czy mogę podać inne szczegóły, aby wzmocnić moją wadę?
(Przykład:odniesienie do FRD lub rozmowa z klientem itp.)

10. Czy rozumiem, jak poważny jest problem z różnych perspektyw?

jedenaście. Czy znam pierwotną przyczynę problemu? Jeśli tak, czy mam dowody (na przykład pliki dziennika) i czy mogę je dołączyć? Pamiętaj, że nie zawsze możesz to wiedzieć lub musisz to wiedzieć. Ale jeśli to zrobisz, uwzględnienie tego nie zaszkodzi.

12. Czy zgłoszenie usterki jest wolne od problemów gramatycznych, formatowych, ortograficznych i interpunkcyjnych?

sql server pytania i odpowiedzi do rozmów kwalifikacyjnych przez 5 lat doświadczenia

13. Czy znam sposób na ulepszenie produktu?

Czy myślisz, że jest to czasochłonne? Cóż, kiedy stanie się nawykiem, już nim nie będzie.

Rootowanie na lepsze zgłaszanie defektów procedury!

O autorze: Ten artykuł został napisany przez członka zespołu STH Swati.

Zapraszam do zamieszczania swoich zapytań / komentarzy poniżej.

rekomendowane lektury

• Dlaczego zgłaszanie błędów to sztuka, której powinien się nauczyć każdy tester?
• Co to jest cykl życia defektów / błędów w testowaniu oprogramowania? Samouczek dotyczący cyklu życia wady
• Przykładowe raporty o błędach dla aplikacji internetowych i produktów
• Co to jest technika testowania oparta na defektach?
• Proces zarządzania defektami: jak skutecznie zarządzać defektem
• Proces selekcji defektów i sposoby radzenia sobie ze spotkaniem selekcyjnym defektów
• Jak napisać dobry raport o błędzie? Porady i wskazówki
• 3 Strategie radzenia sobie z defektem blokującym