Co powinno zawierać poprawne zgłoszenie defektu?

---

Jeden na kilka dni lub kilka na jeden dzień. Częstotliwość zgłaszania defektów przez testerów jest różna, jednak jedno jest pewne — nikogo to nie ominie. Dlatego też należy dołożyć wszelkich starań, aby zgłoszenia zawierały wszystkie najważniejsze informacje, a dzięki czemu będziemy mogli je uznać za poprawne zgłoszenie defektu.

Prosty sposób na sprawdzenie jakości swoich zgłoszeń

Aby stwierdzić, czy nasze defekty są zgłaszane w prawidłowy sposób, oraz zawierają odpowiednią ilość informacji, najlepiej posłużyć się statystykami: ile było zapytań dotyczących naszych zgłoszeń, na x ostatnich. Jeśli ta wartość jest w granicach np. 10%, jest dobrze, jeśli jednak osiąga 50%, czy 70%, to czas najwyższy wyciągnąć wnioski i wdrożyć poprawki.

Co powinno zawierać poprawne zgłoszenie defektu?

Poniżej przedstawiam elementy, które powinno zawierać zgłoszenie defektu. Aby zapoznać się ze szczegółowym opisem każdego puntu, kliknij na niego. W detalach ująłem szersze informacje dotyczące elementu, jak również opis czy jest to pole obowiązkowe, czy nie.

Tytuł

Obowiązkowy. Jest to wbrew pozorom bardzo istotny punkt każdego zgłoszenia defektu, gdyż programiści oraz inni członkowie zespołu projektowego, będą go widzieli w backlogu projektu. Dodatkowo podstawowym zadaniem tego elementu jest naprowadzić odbiorcę na konkretny obszar wystąpienia defektu oraz jego rodzaj. Osobiście preferuję dodawanie na początku w nawiasach kwadratowych słowa kluczowego, które definiuje obszar wystąpienia tego defektu.

Wersja oprogramowania

Obowiązkowy. Jest to informacja, na której wersji oprogramowania zostały wykonane testy. Jeśli na obiekt testów składa się więcej niż jedno oprogramowanie, powinny zostać wypunktowane wersje oprogramowania wszystkich testowanych elementów.

Wersja sprzętu

Obowiązkowy. Z racji, że skupiamy się na testowaniu Embedded, jest to element obowiązkowy, na równi z wersją oprogramowania. Podobnie i w tym przypadku, jeśli mamy więcej niż jeden element sprzętowy — umieszczamy wszystkie wersje sprzętów.

Wersja frameworka testowego / Szablon przypadku testowego

Obowiązkowy. W przypadku testowania manualnego jest to odniesienie do konkretnego szablonu przypadku testowego. Natomiast, jeśli uruchamiamy testy automatyczne, należy umieścić informacje o konkretnej wersji frameworka testowego. Dodatkowo można tutaj umieścić informacje dotyczące innych urządzeń, które nie były testowane, lecz testowały.

Podstawa testu

Opcjonalny. Jest to informacja, która mówi, skąd tak naprawdę wziął się test. Najlepiej podać wersję specyfikacji, na której bazujemy, ale może to być również wersja konkretnego wymagania.

Punkt został oznaczony jako opcjonalny, ze względu na fakt, że czasami nie mamy wglądu do specyfikacji, a testy odbywają się na podstawie doświadczenie testera.

Data testu

Obowiązkowy. Data wykonania testu. Obecnie wszystkie systemy zarządzające testowaniem, automatycznie logują utworzenie danego zgłoszenia.

Dane o testerze

Obowiązkowy. Informacja bardzo istotna, gdyż w przypadku nieścisłości czy pytań, wiadomo do kogo się zwrócić. Jest to również logowane automatycznie w systemach zarządzania defektami.

Priority

Opcjonalny. Punkt zaznaczony jako opcjonalny, gdyż w niektórych firmach wszystkie defekty są traktowane jednakowo. Jednak w przypadku większych projektów takie podejście się nie sprawdza i konieczne jest ustalanie priorytetów. Priorytet mówi nam które zgłoszenia defektów powinny być naprawiane w pierwszej kolejności. Najczęściej spotykany podział to:

• Krytyczny
• Wysoki
• Normalny
• Niski

Severity

Opcjonalny. Podobnie jak w punkcie wyżej, jest to element opcjonalny. Często jest łączony z Priority, lecz nie jest to dobre podejście, gdyż oba parametry mówią o czymś innym. Jest to informacja o tym, jak szkodliwy dla systemu jest dany defekt.

Warunki początkowe

Obowiązkowy. Umieścić tutaj należy dane dotyczące stanu systemu przed rozpoczęciem wykonywania danego testu. Powinno się tutaj znaleźć wszystko, co należy zrobić przed uruchomieniem testów, aby test przebiegł bezproblemowo. Zaliczyć tutaj należy wszelkiego rodzaju zależności, konfiguracje oraz wszystkie inne istotne elementy.

Kroki odtworzenia testu

Obowiązkowy. Element obowiązkowy, a jedyne, nad czym się można zastanawiać to forma przedstawienia kroków odtworzenia testów. Czasami wystarczy słowny opis, jednak osobiście polecam rozpisanie kroków w punktach. Dzięki temu informacja jest czytelniejsza oraz dodatkowo w komentarzu czy rezultatach mamy możliwość odniesienia się do konkretnego kroku.

Rezultat testu

Obowiązkowy. Umieszczamy tutaj informacje o rezultacie otrzymanym po wykonaniu kroków. Informacja ta powinna być odpowiednio zwięzła i konkretna. Polecam używanie równoważników zdań.

WAŻNE. Nie umieszczamy tutaj żadnych zbędnych informacji, w szczególności dotyczących jakichkolwiek opinii.

Rezultat testu

Obowiązkowy. Podobnie jak w powyższym punkciej, lecz z tą różnicą, że nie umieszczamy tu rezultatu otrzymanego, a oczekiwany, Jest to punkt obowiązkowy ze względu, że dopiero różnica w rezultacie otrzymanym a oczekiwanym świadczy, że dane zachowanie jest błędne.

Częstotliwość występowania

Opcjonalny. Informacja dotycząca tego, czy defekt występuje za każdym razem po wykonaniu testu, czy tylko sporadycznie. Jeśli defekt nie występuje zawsze, uznałbym umieszczenie tej informacji za obowiązkową. Dobrze jest podać częstotliwość reprodukcji.

Załącznik

Opcjonalny. Jeśli mamy taką możliwość można tutaj załączyć wszystkie pliki zawierające:

• logi
• zdjęcia
• filmy

Taksonomia defektów

Opcjonalny. Taksonomia defektów służy do klasyfikowania defektów zgodnie z przyjętym kluczem. Element jest istotny szczególnie pod kątem kolejnych projektów oraz usprawniania procesu.

Komentarz

Opcjonalny. Jeśli są jakieś dodatkowe informacje, których nie zawarliśmy w żadnym z powyższych punktów, powinniśmy je umieścić tutaj. Jest to dobre miejsce do opisania naszych dodatkowych spostrzeżeń, na przykład, że defekt jest podobny do tego z innego projektu lub spostrzeżenia dotyczące przyczyny powstania defektu, oraz wszystkie inne informacje, które mogą pomóc w działaniach naprawczych.

PODSUMOWANIE

Zgłoszenia defektów są bardzo istotnie z punktu widzenia podnoszenia jakości dostarczanego produktu, dlatego też bardzo ważne jest, aby zawierały wszystkie istotne informacje. Poprawne zgłoszenie defektu znacznie skraca czas reakcji. W zgłoszeniu może znaleźć się wiele elementów obowiązkowych lub opcjonalnych. Większość narzędzi śledzących defekty (np. Jira), zbiera część informacji automatycznie, a co do innych podpowiada nam które pola muszą być obowiązków wypełnione, a które są opcjonalne. Podstawowym kryterium przy zgłaszaniu defektów powinna być polityka testowania w firmie, jednak dobrze jest robić cykliczne przeglądy oraz wdrażać odpowiednie usprawnienia.