Menu

Śledzenie błędów projektu na żywo, wskaźniki testowe i podpisywanie testów - bezpłatne szkolenie z kontroli jakości - dzień 6

  • Główny
  • Śledzenie Błędów
  • Śledzenie błędów projektu na żywo, wskaźniki testowe i podpisywanie testów - bezpłatne szkolenie z kontroli jakości - dzień 6

live project bug tracking

Wypróbuj Nasz Instrument Do Eliminowania Problemów

To jest ostatnia część naszego „ Szkolenie z testowania oprogramowania w projekcie na żywo ' seria.

Będzie dotyczył defektów, a także kilku pozostałych tematów, które będą oznaczać zakończenie fazy wykonywania testów w STLC.

w poprzedni artykuł podczas wykonywania testu napotkaliśmy sytuację, w której oczekiwany wynik przypadku testowego nie został spełniony. Ponadto zidentyfikowaliśmy nieoczekiwane zachowanie podczas testów eksploracyjnych.

Śledzenie błędów projektu na żywo, wskaźniki testowe i podpisywanie testów

Co się dzieje, gdy napotkamy te odchylenia?

Oczywiście musimy je rejestrować i śledzić, aby upewnić się, że te odchylenia zostaną obsłużone i ostatecznie naprawione w AUT.

# 1) Odchylenia te są określane jako Defekty / błędy / problemy / incydenty / błędy / usterki.

#dwa) Wszystkie poniższe przypadki mogą zostać zarejestrowane jako usterki

  • Brak wymagań
  • Nieprawidłowo działające wymagania
  • Dodatkowe wymagania
  • Niezgodności dokumentów referencyjnych
  • Problemy związane ze środowiskiem
  • Sugestie ulepszeń

# 3) Rejestrowanie defektów odbywa się głównie w arkuszach programu Excel lub za pomocą oprogramowania / narzędzia do zarządzania defektami. Aby uzyskać informacje na temat radzenia sobie z usterkami za pomocą narzędzi, spróbuj skorzystać z poniższych linków:

Czego się nauczysz:

Jak skutecznie rejestrować defekty

Spróbujemy teraz zobaczyć, jak zarejestrować defekty, które napotkaliśmy w poprzednim artykule, w arkuszu programu Excel. Jak zawsze ważny jest wybór standardowego formatu lub szablonu.

jak napisać dobry raport o błędzie

Zwykle następujące kolumny stanowią część raportu defektu:

  • Identyfikator wady: Do niepowtarzalnej identyfikacji.
  • Błędny opis: To jest jak tytuł, który krótko opisuje problem.
  • Moduł / sekcja AUT: Jest to opcjonalne, aby zwiększyć jasność wskazania obszaru AUT, w którym napotkano problem.
  • Kroki ku reprodukcji: Jaka jest dokładna sekwencja operacji, które należy wykonać na AUT w celu odtworzenia błędu, ma być wymieniona tutaj. Ponadto, jeśli jakiekolwiek dane wejściowe są specyficzne dla problemu, należy je również wprowadzić.
  • Surowość: Wskazanie intensywności problemu i ostatecznie wpływu, jaki może to mieć na funkcjonowanie AUT. Wytyczne, jak przypisać i jakie wartości przypisać w tym polu, można znaleźć w dokumencie planu testów. Więc zapoznaj się z Dokument planu testów z artykułu 3 .
  • Status: Zostanie omówione dalej w artykule.
  • Zrzut ekranu: Migawka aplikacji pokazująca błąd, kiedy to się stało.

To tylko niektóre z pól, które trzeba mieć. Ten szablon można rozszerzyć (np. W celu uwzględnienia nazwiska testera, który zgłosił problem) lub zawrzeć umowę ( Na przykład, nazwa modułu została usunięta) w razie potrzeby.

Postępując zgodnie z powyższymi wskazówkami i korzystając z powyższego szablonu, przykładowy dziennik / raport defektów mógłby wyglądać następująco:

Przykładowy raport usterki dla projektu OrangeHRM Live:

Raport wady OrangeHRM

=> Kliknij tutaj, aby pobrać raport dotyczący usterek projektu na żywo

Poniżej znajduje się przykładowy Raport Defektu utworzony w narzędziu qTest Test Management: (Kliknij obraz, aby powiększyć)

Przykładowy raport wady

Wady nie są dobre, gdy je rejestrujemy i przechowujemy dla siebie. Będziemy musieli przypisać je w odpowiedniej kolejności, aby zainteresowane zespoły działały na nich. Proces - kogo przypisać lub jaką kolejność przestrzegać można również znaleźć w dokumencie planu testów. Jest głównie podobny do (Kliknij obraz, aby powiększyć)

Cykl defektu:

Cykl życia wady 1

Z powyższego procesu można zauważyć, że błędy przechodzą przez różnych ludzi i różne decyzje w procesie identyfikacji do naprawienia. Aby śledzić i ustalić przejrzystość co do dokładnego stanu danego błędu, w zgłoszeniu błędu używane jest pole „Status”. Cały proces nazywany jest „cyklem życia błędu”. Aby uzyskać więcej informacji na temat wszystkich statusów i ich znaczenia, zapoznaj się z tym Samouczek dotyczący cyklu życia błędów .

Kilka wskazówek podczas śledzenia błędów

  • Kiedy jesteśmy nowicjuszami w kreatywnym zespole / projekcie / AUT, zawsze najlepiej omówić napotkany problem z rówieśnikiem, aby upewnić się, że nasze zrozumienie tego, co naprawdę powoduje wadę, jest poprawne, czy nie.
  • Do podaj wszystkie informacje co jest konieczne do odtworzenia problemu. Wada, która wraca do zespołu testującego ze statusem „Za mało informacji”, nie odbija się na nas zbyt pozytywnie. Sprawdź ten post - Jak naprawić wszystkie błędy bez etykiety „Nieprawidłowy błąd” .
  • Sprawdź, czy podobny problem został podniesiony przed utworzeniem nowego. „Duplikaty” problemów to także zła wiadomość dla zespołu ds. kontroli jakości.
  • Jeśli pojawia się problem, który pojawia się losowo i nie znamy dokładnych kroków / sytuacji, w których możemy go odtworzyć - zgłoś go jednakowo. Ryzyko, że problem zostanie ustawiony na „Nie do odtworzenia / niewystarczające informacje” - nadal musimy się upewnić, że wszystkie możliwe awarie zostały rozwiązane w jak największym stopniu.
  • Ogólna praktyka polega na tym, że zespół ds. kontroli jakości tworzy wady każdego z nich w arkuszu programu Excel w ciągu dnia i konsoliduje je pod koniec dnia.

Pełny cykl życia wady

W przypadku naszego projektu na żywo, gdybyśmy mieli śledzić cykl życia wady dla wady 1,

domyślna brama nie jest dostępna windows 10 wifi
  • Kiedy ja (tester) go tworzę, jego status to 'Nowy”. Kiedy przypisuję go do kierownika zespołu ds. Kontroli jakości, status nadal jest „Nowy”, ale właściciel jest teraz kierownikiem ds. Kontroli jakości.
  • Kierownik ds. Kontroli jakości przeanalizuje problem i po ustaleniu, że jest to ważny problem, zostanie on przypisany do kierownika ds. Deweloperów. Na tym etapie status to 'Przydzielony' a właścicielem jest Dev Lead.
  • Kierownik ds. Deweloperów przydzieli następnie ten problem programiście, który będzie pracował nad rozwiązaniem tego problemu. Status będzie teraz 'Praca w toku' (lub coś podobnego), właściciel jest deweloperem.
  • W przypadku usterki 1 programista nie jest w stanie odtworzyć błędu, więc przypisuje go z powrotem do zespołu ds. Kontroli jakości i ustawia status jako 'Nie może się rozmnażać”.
  • Alternatywnie, jeśli programista byłby w stanie nad tym popracować i naprawić problem, stan zostanie ustawiony na 'zdecydowany' a problem zostanie ponownie przydzielony zespołowi ds. kontroli jakości.
  • Zespół ds. Kontroli jakości odbierze go, ponownie przetestuje problem i jeśli zostanie naprawiony, ustawi status na 'Zamknięte' . Jeśli problem nadal występuje, stan jest ustawiony na 'Otworzyć na nowo' i proces trwa.
  • W zależności od innych sytuacji stan można ustawić jako 'Odroczony' , 'Brak wystarczających informacji', 'Duplikować' , 'działa zgodnie z przeznaczeniem' itp. przez programistę.
  • Ta metoda rejestrowania defektów, raportowania i przypisywania ich, zarządzania nimi jest jedną z głównych czynności wykonywanych przez członków zespołu QA w fazie wykonywania testów. Odbywa się to codziennie, aż do zakończenia określonego cyklu testowego.
  • Po zakończeniu pierwszego cyklu zespół programistów zajmie dzień lub dwa na skonsolidowanie wszystkich poprawek i przebudowanie kodu do następnej wersji, która będzie używana w następnym cyklu.
  • Ten sam proces jest również kontynuowany dla cyklu 2. Pod koniec cyklu istnieje szansa, że ​​w aplikacji nadal mogą występować problemy „otwarte” lub nieusunięte.
  • Na tym etapie - czy nadal kontynuujemy cykl 3? Jeśli tak, kiedy przestaniemy testować?

Kryteria wyjścia dla testowania projektu OrangeHRM na żywo

Tutaj stosujemy to, co nazwalibyśmy „Kryteriami wyjścia”. Jest to wstępnie zdefiniowane w dokumencie planu testów. Jest to po prostu lista kontrolna, która określi, czy zakończymy testowanie po cyklu 2, czy też przejdziemy na jeszcze jeden cykl. Wygląda na to, że poniższe po wypełnieniu z uwzględnieniem hipotetycznych odpowiedzi na następujące pytania dotyczące projektu OrangeHRM:

Kryteria zakończenia testu

Kiedy uważnie przyjrzymy się powyższej liście kontrolnej, zobaczymy, że są tam wspomniane metryki i podpisy, o których wcześniej nie rozmawialiśmy. Porozmawiajmy teraz o nich.

Metryki testowe

Ustaliliśmy, że na etapie wykonywania testów raporty są wysyłane do wszystkich pozostałych członków zespołu projektowego, aby dać jasny obraz co dzieje się w fazie wykonania kontroli jakości . Informacje te są ważne dla każdego, aby uzyskać potwierdzenie ogólnej jakości produktu końcowego.

Wyobraź sobie, że donoszę, że przeszło 10 przypadków testowych lub wykonano 100 przypadków testowych - te liczby to tylko surowe dane i nie dają bardzo dobrej perspektywy na temat tego, jak się sprawy mają.

Metryki odgrywają istotną rolę w wypełnianiu tej luki. Metryki są w prostych słowach, inteligentne liczby, które gromadzi i utrzymuje zespół testujący . Na przykład, jeśli powiem, że przeszło 90% przypadków testowych, ma to więcej sensu niż powiedzenie, że przeszło 150 przypadków testowych. Prawda?

Na etapie wykonywania testów zbierane są różne rodzaje metryk. Jakie dokładnie metryki mają być gromadzone i utrzymywane przez jaki okres - informacje te można znaleźć w dokumencie planu testów.

Poniżej przedstawiono najczęściej zbierane metryki testowe dla większości projektów:

  • Procent zaliczenia przypadków testowych
  • Gęstość wad
  • Procent defektów krytycznych
  • Wady, wielkość mądra liczba

Sprawdź Raport o stanie załączony do tego artykułu aby zobaczyć, jak te dane są używane.

Raport z podpisania / zakończenia testu

Ponieważ musimy powiadomić wszystkich interesariuszy, że testy już się rozpoczęły, obowiązkiem zespołu ds. Kontroli jakości jest poinformowanie wszystkich o zakończeniu testów i udostępnienie ich wyników. W związku z tym zazwyczaj wysyłany jest e-mail od zespołu ds. Kontroli jakości (zwykle kierownika zespołu / kierownika ds. Zapewnienia jakości) z informacją, że zespół ds. Zapewnienia jakości podpisał się z produktem, dołączając wyniki testów i listę otwartych / znanych problemów.

Przykładowy e-mail z podpisem testu:

Do: Klient, PM, zespół deweloperski, zespół DB, BA, zespół QA, zespół ds. Środowiska (i wszyscy inni, którzy muszą być uwzględnieni)
E-mail: Witaj drużyno,

Zespół ds. Kontroli jakości podpisuje oprogramowanie OrangeHRM w wersji 3.0 po pomyślnym zakończeniu 2 cykli testów funkcjonalnych strony internetowej.

Przypadki testowe i wyniki ich wykonania są dołączane do wiadomości e-mail. (Lub wspomnij o lokalizacji, w której się znajdują. Jeśli korzystasz z oprogramowania do zarządzania testami, podaj szczegóły dotyczące tego samego).

Lista znanych problemów jest również dołączona do wiadomości e-mail. (Ponownie, można dodać wszelkie inne odniesienia, które mają sens).

Dzięki,
Kierownik zespołu QA.

Załączniki: Końcowy raport z wykonania, Końcowy raport o problemie / usterce, Lista znanych problemów

Gdy e-mail potwierdzający test zostanie wysłany przez zespół ds. Kontroli jakości, oficjalnie zakończymy proces STLC. Nie musi to oznaczać zakończenia fazy „Testu” SDLC. Wciąż mamy do zakończenia testy UAT, aby tak się stało. Odnaleźć więcej szczegółów na temat testów UAT tutaj .

Po zakończeniu UAT SDLC przechodzi do fazy wdrażania, w której jest uruchamiana i jest dostępna dla swoich klientów / użytkowników końcowych do wykorzystania.

Otóż ​​to!

To był nasz wysiłek, aby zapewnić naszym czytelnikom najbardziej realistyczne wrażenia z projektu QA. Przekaż nam swoje uwagi i pytania dotyczące tej bezpłatnej serii szkoleń online z zakresu kontroli jakości oprogramowania.

rekomendowane lektury

^