Selekcja błędów/wad w testowaniu oprogramowania

⚡ Inteligentne podsumowanie

Selekcja usterek to spotkanie, na którym kierownik testów, kierownik ds. rozwoju oraz kierownik projektu klasyfikują każdy zgłoszony błąd według jego wagi, priorytetu i ryzyka, a następnie przypisują właścicieli i uzgadniają realistyczny harmonogram napraw.

  • 🔘 Cel: Oceń, ustal priorytety i przypisz każdy nowy defekt, aby nic ważnego nie zostało pominięte.
  • Częstotliwość: Zazwyczaj dwa lub trzy spotkania w tygodniu, dostosowane do harmonogramu projektu i liczby błędów.
  • Uczestnicy: Obowiązkowym udziałem w spotkaniu są kierownik projektu, lider zespołu testowego, kierownik techniczny i lider zespołu programistów.
  • 🧪 Poważność i priorytet: Stopień istotności mierzy się wpływem problemu na produkt, priorytet decyduje o kolejności napraw.
  • 🛠️. Wyniki spotkania: Metryki segregacji usterek są liczone w minutach i są wykorzystywane do następnej sesji segregacji.
  • Obróbka: Każda decyzja jest rejestrowana w pamięci urządzenia tracsystem królewski, aby ślad audytu przetrwał spotkanie.

Proces triażu błędów i usterek w testowaniu oprogramowania

Co to jest „segregacja usterek”?

Selekcja usterek to proces, w którym każdemu błędowi przypisuje się priorytet na podstawie jego wagi, częstotliwości, ryzyka itp. Termin „selekcjonowanie” jest używany w Testowanie oprogramowania / Zapewnienie jakości w celu określenia stopnia ważności i priorytetu nowych defektów.

Nazwa pochodzi z medycyny ratunkowej, gdzie triaż polega na sortowaniu pacjentów według pilności, gdy zasoby są ograniczone. Zespół ds. zapewnienia jakości (QA) stoi przed tym samym ograniczeniem: lista usterek jest zawsze dłuższa niż czas dostępny do daty wydania, więc ktoś musi zdecydować, co naprawić teraz, co później, a co odłożyć. Triaż to spotkanie, na którym decyzja jest podejmowana i dokumentowana.

Dlaczego potrzebujemy „segregacji usterek”?

Celem Bug Triage jest ocena, ustalenie priorytetów i wyznaczenie rozwiązania defektów. Zespół musi zweryfikować istotność defektu, wprowadzić zmiany zgodnie z potrzebami, sfinalizować rozwiązanie defektów i przydzielić zasoby. Stosowany głównie w zwinnym zarządzaniu projektami.

Bez triażu wady pozostają w tracker z dowolną powagą, jaką wybrał tester raportujący, a programiści wybierają zadania ze względu na osobiste preferencje, a nie wpływ na biznes. Poniższy baner podsumowuje powody, dla których zespoły umieszczają spotkanie w kalendarzu.

Dlaczego w projekcie zapewnienia jakości (QA) potrzebna jest analiza błędów i usterek

Jak często w wydaniu należy przeprowadzać selekcję usterek?

Częstotliwość spotkań w sprawie segregacji usterek nie jest stała. To zależy od sytuacji w projekcie.

Oto kilka ważnych czynników decydujących o częstotliwości spotkań w sprawie selekcji usterek:

Te ważne czynniki to:

  • Zgodnie z harmonogramem projektu
  • Liczba usterek w systemie
  • Wpływ na harmonogramy dostępności członków zespołu
  • Ogólny stan projektu

Zwykle dwa lub trzy razy w tygodniu odbywają się spotkania w sprawie selekcji usterek.

Rytm się zacieśnia w miarę zbliżania się premiery. Zespoły pracujące w krótkich odstępach czasu Scrum: iteracje często włączają krótką selekcję do codziennej rutyny podczas ostatniego sprintu, podczas gdy projekt w dłuższym cyklu opartym na planowaniu może być poddawany selekcji raz w tygodniu aż do testy regresji rozpoczyna się faza.

Kim są obowiązkowi i pozostali uczestnicy „Defect Triage”?

Uczestnicy obowiązkowi

Poniżej członkowie projektu zawsze biorą udział w spotkaniach dotyczących selekcji defektów.

  • Menadżer Projektu
  • Lider Zespołu Testowego
  • Prowadzenie techniczne
  • Lider Zespołu Rozwoju

Uczestnicy opcjonalni

  • Programiści
  • Testerzy
  • Analitycy Biznesowi

Uczestnicy nieobowiązkowi są zapraszani, gdy konkretny defekt wymaga ich wkładu, na przykład gdy analityk biznesowy musi potwierdzić, czy zgłoszone zachowanie rzeczywiście sprzeciwia się wymaganiu, czy też jest zamaskowaną prośbą o zmianę.

Role i obowiązki uczestników podczas „segregacji usterek”.

Każdy z obowiązkowych uczestników przybywa z innymi obowiązkami, a spotkanie trwa tylko wtedy, gdy wszyscy trzej przygotują się wcześniej.

Lider Zespołu Testowego

  • Zaplanowane spotkanie dotyczące selekcji błędów i wysyłania powiadomień o spotkaniu dla uczestników.
  • Utwórz raport o defektach i wyślij go wszystkim uczestnikom przed spotkaniem.
  • Przypisz priorytet i surowość wad.
  • Przeprowadź prezentację, aby inni członkowie zrozumieli pierwotną przyczynę wady.
  • Każda notatka ze spotkania jest rejestrowana i wysyłana do uczestników spotkania.

Lead Development

  • Pomaga w ustaleniu priorytetów usterek.
  • Omów trudność wady i wyjaśnij ryzyko związane z tą wadą.
  • Przydziel pracę związaną z naprawą usterek odpowiednim programistom.
  • Zaktualizuj rozwiązanie problemu i dołącz uwagi programistyczne na wypadek, gdyby brakowało jakichkolwiek informacji lub gdyby programiści potrzebowali dodatkowych informacji.

Menadżer Projektu

  • Pomoc w ustaleniu priorytetów usterek.
  • Omów datę wydania kolejnej iteracji dla kontroli jakości.
  • Należy upewnić się, że powiązani przedstawiciele użytkowników są również zaproszeni na spotkanie dotyczące selekcji błędów.

Data wydania jest ustalana przez kierownika projektu, więc decyzja o ostatecznym rozstrzygnięciu sporu dotyczącego usterki zwykle należy do tej osoby, jak pokazano poniżej.

Obowiązki kierownika projektu na spotkaniu triażowym dotyczącym usterek

Co dzieje się podczas spotkania poświęconego segregacji usterek?

  • Lider zespołu testowego wysyła raport o nowych defektach. Podczas spotkania w sprawie segregacji usterek każda usterka jest analizowana w celu sprawdzenia, czy przypisano jej właściwy priorytet i wagę.
  • W razie potrzeby zmienia się priorytety.
  • Wady są analizowane i oceniane według stopnia ich nasilenia.
  • Obejmuje to dyskusję dotyczącą złożoności wady, ryzyka, odrzucenia, ponownego przypisania błędów.
  • Aktualizacje są rejestrowane w błędach tracsystem królewski.
  • Inżynier ds. kontroli jakości dokona zmian w każdej usterce i omówi je z każdym uczestnikiem.
  • Pole „Uwagi” jest poprawnie aktualizowane poprzez odnotowanie istotnych punktów spotkania.

Większość dyskusji skupia się na dwóch obszarach, które najłatwiej pomylić. Ważność i priorytet są ustalane niezależnie, a defekt może uzyskać wysoką ocenę w jednym z nich, a niską w drugim.

WYGLĄD Dotkliwość Priorytet
Co mierzy Jak bardzo wada uszkadza produkt lub jego funkcjonalność Jak szybko należy naprawić usterkę w porównaniu z innymi pracami
Normalnie ustawiane przez Tester zgłaszający wadę Uzgodniono w ramach triażu z kierownikiem projektu i liderem strony produktu
Prowadzony przez Wpływ techniczny i ograniczona funkcjonalność Wpływ na działalność firmy, widoczność dla klientów i data wydania
Przykład niezgodności Wysoka powaga, niski priorytet: awaria funkcji, z której nikt nie będzie korzystał do następnego kwartału Niska waga, wysoki priorytet: błędnie napisana nazwa firmy na stronie docelowej

Wskazówka: Omów krótko pojedynczy defekt. Jeśli problemu nie da się rozwiązać w ciągu kilku minut, odłóż go na później, przypisz osobę odpowiedzialną za jego zbadanie i wróć do następnej sesji, zamiast pozwolić, aby jeden defekt zdominował całe spotkanie.

Jaki jest wynik „sekcji usterek”?

Na koniec każdego spotkania zostaną przygotowane i przekazane wszystkim uczestnikom wskaźniki segregacji usterek. Raport ten pełni funkcję protokołu posiedzeń, który będzie pomocny podczas przyszłych posiedzeń.

Raport jest punktem, w którym triaż łączy się z szerszą proces zarządzania defektamiZespoły zazwyczaj uwzględniają w nim następujące elementy:

  • Podczas sesji sprawdzane są usterki, ustalana jest ich waga i priorytet.
  • Nowo przypisane wady wraz z deweloperem, który teraz jest ich właścicielem.
  • Wady odroczone, odrzucone lub oznaczone jako duplikaty, wraz z odnotowanym powodem.
  • Liczba otwartych usterek według ich ważności, umożliwiająca śledzenie trendu pomiędzy sesjami.
  • Działania przeniesione na następne spotkanie.

Ponieważ każda zmiana jest zapisywana z powrotem w tracker, stan każdego elementu pozostaje zgodny z jego pozycją w cykl życia wady, a następna sesja zaczyna się od dokładnej listy, a nie od nieaktualnej.

FAQ

Ogranicz czas do trzydziestu do sześćdziesięciu minut. Raport o usterce rozesłany wcześniej stanowi obszerną lekturę, więc sama sesja służy jedynie potwierdzeniu decyzji. Wszelkie elementy wymagające dogłębnej analizy technicznej są odkładane u właściciela i oddawane na następne spotkanie.

Zespoły Agile przeprowadzają triaż w krótkich, częstych sesjach, często powiązanych z codziennymi spotkaniami, ponieważ horyzont czasowy sprintu wynosi tylko dwa tygodnie. Projekty oparte na planach rzadziej odbywają się w ramach dłuższych, formalnych spotkań, z obszerniejszą dokumentacją i szerszą listą interesariuszy.

Odłożony defekt pozostaje otwarty, ale zostaje przeniesiony poza bieżącą wersję, zazwyczaj z zarejestrowaną wersją docelową. Odrzucony defekt jest zamykany z pisemnym uzasadnieniem – niemożliwym do odtworzenia, działającym zgodnie z przeznaczeniem lub duplikującym się – dzięki czemu decyzję można później ponownie rozważyć.

Jeden raport jest zachowywany jako główny, a pozostałe są z nim powiązane i zamykane jako duplikaty. Ich ciche zamknięcie powoduje utratę informacji, dlatego link ma znaczenie: zachowuje każdy krok reprodukcji i szczegóły środowiska dostarczone przez osoby raportujące.

Każdy tracker z zapisanymi filtrami i zbiorczą edycją działa. Zespoły zazwyczaj wybierają Jira deska lub Modliszka podgląd przefiltrowany pod kątem nowych usterek, edytowanie ich ważności, priorytetu i przypisanego pracownika na żywo podczas spotkania.

Modele uczenia maszynowego grupują podobne raporty, aby wykryć duplikaty, sugerują wagę usterki na podstawie sformułowań dotyczących poprzednich defektów i kierują każdy element do właściciela komponentu. Traktuj wynik jako pierwszy szkic — spotkanie i tak potwierdza każdą decyzję.

Tak, pośrednio. Drugi pilot GitHub można podsumować stos trace. opracować test reprodukcyjny i wyjaśnić kod, którego dotyczy problem, co skróci dochodzenie przeprowadzane przez właściciela po triażu, zamiast zastępować samo spotkanie.

Kierownik projektu, ponieważ dogrywka jest decyzją biznesową, a nie techniczną dotyczącą daty premiery. Kierownik ds. rozwoju dostarcza szacunkowy nakład pracy, a kierownik ds. testów – dowody wpływu, które wpływają na tę decyzję.

Podsumuj ten post następująco: