Menu

Sztuka raportowania błędów: jak sprzedawać i naprawiać błędy?

art bug reporting

Dlaczego istnieje potrzeba marketingu błędu?



Pierwsze, co przychodzi mi do głowy, kiedy zaczynam pisać ten artykuł, to słowa Cem Kaner - „Najlepszy tester to nie ten, który znajduje najwięcej błędów lub wprawia w zakłopotanie większość programistów. Najlepszym testerem jest ten, który naprawia większość błędów ”.



Teraz - jaka jest różnica między znajdowanie większości błędów i naprawa większości błędów ?

Czy nie jest oczywiste, że jakikolwiek błąd zarejestrowany w system zarządzania błędami powinien zostać naprawiony przez programistę? Odpowiedź brzmi: nie. Czynniki takie jak czas wprowadzenia produktu na rynek, czas ukończenia projektu zgodnie z harmonogramem oraz praca deweloperów niepraktyczne napięte harmonogramy itp. zmuszają firmy do wypuszczenia produktu z kilkoma błędami, które nie będą miały dużego wpływu na użytkowników.



Sztuka zgłaszania błędów

[wizerunek źródło ]

Kto daje pewność kierownictwu m, twierdząc, że błędy obecne w produkcie nie wpłyną na zaufanie klienta, niezawodność i interes interesariuszy? - Inżynier ds. Testów lub zespół testujący - obowiązkiem każdego inżyniera ds. Testów jest naprawienie błędów, które mogą mieć negatywny wpływ na jakość produktu.



Priorytet błędu Moim zdaniem w dużej mierze zależy to od tego, jak tester przedstawi problem zespołom programistycznym i zarządzającym.

Pomyśl o tym jak o reklamie lub marketingu - obejmuje to 2 kroki:

  1. Pisz lub zgłaszać błędy poprawnie
  2. Dowiedz się wszystkiego o błędzie, aby móc lepiej wyjaśnić dalsze szczegóły

Czego się nauczysz:

Sztuka zgłaszania błędów

Tak, zgłaszanie błędów to sztuka . Sposób, w jaki został napisany błąd, pokazuje umiejętności techniczne, wiedzę specjalistyczną i możliwości komunikacyjne inżyniera testów.

Zwykle błąd powinien zawierać następujące informacje:

  • Podsumowanie błędów
  • kroki ku reprodukcji
  • Załączniki (migawki, pliki dziennika itp.)
  • Odtwarzalność błędów
  • Waga błędu
  • Wersja oprogramowania, informacje o środowisku
  • Inne informacje w oparciu o wymagania organizacyjne.

Ważna uwaga: Zawsze kop głębiej, aby znaleźć główną przyczynę problemu i zgłoś ją. Na przykład prosty błąd logowania z poprawną kombinacją nazwy użytkownika i hasła może mieć różne przyczyny, takie jak:

  1. Dane logowania nie zostały w ogóle zweryfikowane
  2. Problemy z przekroczeniem limitu czasu sieci w przypadku zdalnego logowania
  3. System może traktować wszystkie DUŻE LITERY jako inne niż LITERY.

Tak więc jako tester powinieneś być w stanie rozszyfrować różnice, postępując zgodnie z instrukcjami podsumowania błędów:

  • „Nie można zalogować się przy użyciu poprawnej nazwy użytkownika i hasła”
  • „Nie można zalogować się przy użyciu poprawnej nazwy użytkownika i hasła, gdy nazwa użytkownika lub hasło zawiera kombinację liter CAPS i innych niż wielkie litery”.

Ta ostatnia jest bardzo jasnym opisem problemu i jest jednoznaczna. Dzięki temu nie tylko zwiększasz swoją wiarygodność jako testera, ale także zgłaszasz rzeczywisty problem zamiast objawu.

Przyjrzyjmy się teraz każdemu polu, którego dotyczy zgłoszenie błędu i omówimy ważne aspekty każdego z nich:

# 1. Podsumowanie błędów

Podsumowanie błędu powinno zapewniać szybki obraz tego, na czym dokładnie polega problem. Musi być precyzyjny i dobrze ukierunkowany.

Przykład :

Oprócz teorii spróbuję wyjaśnić na przykładach.

jak stworzyć ogólną tablicę w java

Załóżmy prosty moduł logowania. Załóżmy, że problem jest taki, że nowy użytkownik odwiedzający witrynę internetową nie może zalogować się przy użyciu domyślnego hasła. Kiedy przedstawiłem ten sam scenariusz wielu uczniom, których szkoliłem w początkowej fazie szkolenia, otrzymałem kilka odpowiedzi jako podsumowanie błędu. Poniżej podano kilka przykładów tego, jak wyglądało podsumowanie:

' Nowy użytkownik nie może się zalogować ”

„Logowanie użytkownika nie działa zgodnie z oczekiwaniami”

„Użytkownik nie może zalogować się przy użyciu prawidłowego hasła”

podsumowanie błędu złe i poprawne

Czy z powyższych przykładów możesz wybrać jedno stwierdzenie, które faktycznie opisuje problem? Nie sądzę. Podsumowanie powinno zawsze zawierać pełne informacje o scenariuszu, który się nie powiódł.

Rozważ następujące stwierdzenie:

„Nowy użytkownik nie może zalogować się przy użyciu domyślnego hasła podanego w wiadomości e-mail lub SMS”

Jak widać, z powyższego oświadczenia programista może jasno zrozumieć, na czym polega problem i gdzie jest problem.

Spróbuj więc znaleźć właściwe słowa, aby opisać podsumowanie, które dałoby bezpośrednio informacje. Należy unikać ogólnych stwierdzeń, takich jak „nie działa prawidłowo”, „nie działa zgodnie z oczekiwaniami” itp.

# 2. Kroki do odtworzenia i załączników

Niepowtarzalne błędy zawsze zajmują tylne miejsce, nawet jeśli mogą być znaczące. Dlatego postaraj się napisać kroki poprawnie i opisowo.

Kroki powinny być dokładne i dokładnie takie same, jak te, które doprowadziły do ​​problemu. Poniższy przykład jest najlepszym przykładem błędów związanych z funkcjonalnością.

Przykład :

Rozważ tę samą kwestię, co w poprzedniej sekcji.

  1. Utwórz nowego użytkownika za pomocą opcji Zarejestruj się na stronie głównej. (Przykładowa nazwa użytkownika: HelloUser)
  2. Otrzymamy e-mail i SMS z domyślnym hasłem. Identyfikator e-mail i numer telefonu komórkowego dla wiadomości SMS są podawane podczas tworzenia użytkownika w kroku 1. (Przykładowy e-mail: HelloUser@hello.com , Przykładowy numer telefonu komórkowego: 444-222-1123)
  3. Wybierz opcję Zaloguj się na stronie głównej.
  4. W polu tekstowym nazwy użytkownika podaj przykładową nazwę użytkownika podaną w kroku 1.
  5. W polu hasła podaj domyślne hasło otrzymane w wiadomości e-mail lub SMS.
  6. Kliknij przycisk Zaloguj się
  7. Spodziewany wynik: Użytkownik powinien mieć możliwość zalogowania się przy użyciu podanej nazwy użytkownika i hasła oraz przejścia do strony konta użytkownika.
  8. Aktualny rezultat: Wyświetlany jest komunikat „Nieprawidłowa nazwa użytkownika / hasło”.

kroki zgłaszania defektów

jak pisać skrypty testów automatyzacji

Jeśli którakolwiek z informacji nie została podana w powyższej próbce, to będzie skutkują lukami komunikacyjnymi a programista nie będzie w stanie odtworzyć problemu. Kroki muszą być konkretne i szczegółowe z przykładowymi danymi używanymi podczas testowania.

Jeśli to możliwe lub w stosownych przypadkach, należy zapewnić migawka tego, co dokładnie widzisz na ekranie. W ten sposób nie tylko zapewni programistom dobry pogląd na problem, ale także dowód wyniku testu.

Plik niefunkcjonalne przypadki testowe, takie jak przypadki testów warunków skrajnych, stabilności lub wydajności, oprócz powyższych szczegółów, informacje o scenariuszu powodującym stres w systemie mogą być raportowane w takiej postaci, w jakiej są. Ponadto istnieje kilka systemów, które raportują dzienniki dla każdej wykonywanej operacji. Dzienniki to zwykle instrukcje drukowania dostarczone przez programistów w ich kodzie. Za każdym razem, gdy moduł jest wykonywany, odpowiednie dzienniki zostaną wydrukowane lub wyświetlone. Gdy są dostępne dzienniki, pomogłoby to programistom w dużym stopniu w odtworzeniu problemu.

# 3. Odtwarzalność błędów

Zagadnienie, które jest duże lub małe, będzie traktowane priorytetowo na podstawie powtarzalności. Widać to zawsze, czasami, rzadko lub nawet raz. Problem powielany „zawsze” będzie miał wyższy priorytet niż reszta.

nie może odtworzyć wady

Zatem obowiązkiem inżyniera ds. Testów jest dokładne śledzenie scenariusza dla problemu, który jest zawsze odtwarzany. Czasami może wystąpić kilka problemów poza kontrolą inżyniera testów, co spowodowałoby powielenie problemu tylko kilka razy, ale w wielu próbach. W takich przypadkach zawsze podawaj liczbę prób, wykonywany jest konkretny scenariusz oraz liczba przypadków wystąpienia problemu podczas tych prób.

To z kolei zwiększyłoby wiarygodność wspomnianego przez Ciebie raportu o błędzie. Ponownie, poprawiłoby to twoją reputację jako testera. Później powiem ci, dlaczego masz dobrą reputację.

# 4. Waga błędu

Severity jest niewątpliwie jednym z największych czynników wpływających na priorytetyzację Bugu.

Poniżej przedstawiono różne kategorie dotkliwości. Należy pamiętać, że są to tylko ogólne próbki i różnią się one w zależności od firmy.

  1. Poziom ważności 1 - Show Stopper - w przypadku błędów, które są katastrofalne, bez ich naprawienia użytkownik nie będzie mógł kontynuować korzystania z oprogramowania i nie ma możliwości obejścia tego problemu
  2. Poziom ważności 2 - wysoki - w przypadku błędów podobnych do poziomu ważności 1, ale istnieje obejście
  3. Poziom 3 - średni
  4. Poziom 4 - niski
  5. Poziom 5 - trywialny.

Na przykład porównajmy dwa podobne problemy.

W naszych dekoderach niewielu dostawców usług dostarcza informacje o częstotliwości usługi w aktualnie dostrojonej formie. Załóżmy, że częstotliwość jest wyświetlana jako 100 MHz zamiast 100,20 MHz. Może to nie wpływać na przeglądanie usług przez użytkownika, ale może mieć wpływ na diagnostykę monitorowania dekoderów. Dlatego można to przedstawić jako problem o poziomie ważności 3.

Zakładając podobny problem w domenie bankowej: jeśli saldo Twojego konta jest wyświetlane jako 100 USD zamiast 100,20 USD, wyobraź sobie wpływ problemu. To musi być wada o poziomie ważności -1. Jak widać w obu przypadkach, problem jest bardzo podobny, ponieważ interfejs użytkownika nie wyświetla cyfr po przecinku. Ale wpływ różni się w zależności od domeny.

Efektywny udział w spotkaniach kontroli wersji oprogramowania

Zwykle każda organizacja ma swój własny proces badania i priorytetyzacji błędów. Ogólnie rzecz biorąc, w określonych odstępach czasu podczas projektu odbywały się spotkania w celu omówienia błędów i ustalenia ich priorytetów.

Proces podczas takich spotkań wygląda następująco:

  1. Zapytaj o listę błędów z systemu zarządzania zgodnie z ich wagą.
  2. Zapoznaj się z podsumowaniem i omów wpływ błędu na doświadczenie użytkownika podczas korzystania z oprogramowania.
  3. Na podstawie oceny ryzyka i wpływu ustaw priorytet i przypisz błąd do odpowiedniego dewelopera w celu jego naprawienia.

Podczas kroku 2 konieczne jest, aby każdy inżynier testowy opowiedział się za wpływem błędu na wygodę użytkownika, jeśli błąd nie uzyska priorytetu, na jaki zasługuje. W końcu to my testujemy inżynierów, którzy biorą pod uwagę punkt widzenia użytkownika, pisząc przypadki testowe i testując produkt.

Rozważ powyższy przykładowy problem niewyświetlania cyfr po przecinku w domenie bankowej. Dla dewelopera może się to wydawać mniej poważnym problemem. Mógłby argumentować, że zamiast zadeklarować zmienną jako liczbę całkowitą, zadeklarowałby to jako zmiennoprzecinkową, aby rozwiązać problem, a zatem mniej poważną.

Ale Twoja rola jako testera polega na wyjaśnianiu sytuacji klienta. Chodzi o to, jak użytkownik skarżyłby się w tym scenariuszu. Tester powinien powiedzieć, że wywoła to panikę wśród użytkowników, ponieważ klient traci pieniądze w centach.

Wpływ niewłaściwego wprowadzenia błędu na rynek

Jeśli błąd nie zostanie prawidłowo sprzedany, spowoduje problemy takie jak:

  • Nieprawidłowy priorytet defektu
  • Opóźnienie w rozwiązywaniu ważnych problemów
  • Wydanie produktu z poważnymi wadami
  • Negatywne opinie klientów
  • Dewaluacja wartości marki

Wpływ niewłaściwego wprowadzenia błędu na rynek

Oprócz wszystkich wymienionych powyżej powodów, bardzo ważne jest, aby zbudować swój reputacja inżyniera testów . To bardziej przypomina budowanie wartości marki dla siebie.

W początkowej fazie kariery, jeśli możesz utrzymać liczbę „Nie można odtworzyć”, „Potrzebuję więcej informacji” lub „Nieprawidłowy błąd” lub zmiany wagi na jak najniższym poziomie, na pewnym etapie błędy nie zostaną zbadane w ogóle i zostaną bezpośrednio przypisani do odpowiedniego dewelopera do naprawy.

Aby rozwinąć taką wartość marki i zdobyć zaufanie swojego zespołu i zespołów programistycznych / lub zarządzających, musisz rozwinąć pewne umiejętności techniczne w zakresie testowania wiedzy, domeny i umiejętności komunikacyjnych.

Wniosek

Każdy produkt lub usługa, zarówno duża, jak i mała, zawsze kończy się niepowodzeniem bez odpowiedniej reklamy. Gdy marka jest już ugruntowana, każdy mały produkt może stać się wielkim hitem wśród odbiorców.

Mimo to nadreklamowanie produktu może również zaszkodzić reputacji.

Dlatego błąd powinien być zawsze napisany w sposób jasny, zwięzły i precyzyjny, tak aby podał dokładną lokalizację błędu w obszernej / wyczerpującej mapie oprogramowania. Powtarzam, że to nie tylko poprawia jakość oprogramowania, ale także znacznie obniża koszty testowania i rozwijania oprogramowania.

Teraz nie jest za późno! Zacznijmy od razu i naprawmy błędy!

rekomendowane lektury

^