,

Czym jest incydent, a czym defekt. Jak je poprawnie zgłaszać?

Jednym z celów testowania jest znajdowanie różnic pomiędzy oczekiwanymi a rzeczywistymi wynikami działania systemu – rozbieżności takie muszą być rejestrowane… i są rejestrowane – jako incydenty.

Incydenty powinny podlegać analizie w wyniku której może się okazać, że mamy do czynienia z defektem (Wow! To nie jest to samo? Nie, nie jest ;)).

W zależności od stosowanego procesu obsługi incydentów, takie zgłoszenie może trafić np. do zespołu programistycznego w celu jego analizy. W dotychczasowej karierze spotykałem się głównie z takimi rozwiązaniami, w których incydent w pierwszej kolejności wpadały do zespołu programistycznego. Rzadziej np. do analityka biznesowego. Czasami był to układ hybrydowy tj. programista oraz analityk biznesowy tworzący wspólnie jeden zespół dokonujący wstępnej klasyfikację zgłoszenia. Podejść jest wiele i mogą się różnić pomiędzy poszczególnymi organizacjami, ba nawet pomiędzy projektami w jednej organizacji.

Czym jest zatem incydent ?

Czym jest zatem incydent? Skoro nie jest tym samym czym jest defekt. incydent – to każde zdarzenie wymagające zbadania*.

A czym jest defekt …

Defektem natomiast nazywana jest – wada modułu lub systemu. Wada ta może spowodować, że moduł lub system nie wykona zakładanej czynności np. niepoprawne wyrażenie lub definicja danych. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub system*.

Przykład:

Podczas prowadzenia testów zaobserwowano problem z firmową siecią (uszkodzony router). Objawia się on brakiem możliwości dostępu do strony logowania testowanego systemu – problem ten jest incydentem. Wymaga zbadania i finalnie rozwiązania problemu, ale nie jest defektem testowanego system – jego przyczyna leży poza tym systemem.

Jeżeli natomiast połączenie z systemem byłoby niemożliwe ze względu na wadliwe działanie testowanego system (infrastruktura sieciowa bez zarzutu) mielibyśmy do czynienia z defektem tego systemu (jednocześnie byłby to także incydent).

Raporty o incydentach …

Incydenty zaobserwowane podczas testów powinny być rejestrowane jako raporty o incydentach.

Raport o incydencie powinien pozwalać na zrozumienie problemu który zaistniał podczas testów systemu. Powinien także pozwolić na ukierunkowanie uwagi osób odpowiedzialnych za jego ew. poprawkę na właściwy obszar systemu który spowodował jego zaistnienie. Oczywiście nie zawsze będzie to możliwe wprost i bez dalszej jego analizy po stronie np. programistów czy analityka biznesowego.

Raport o incydencie zgłaszany jest zazwyczaj przez osobę inną niż osoba która incydent będzie później analizowała i ew. poprawiała w systemie (jeżeli okaże się defektem). W związku z tym raport powinien być zgłoszony tak, żeby osoba która go otrzymała do analizy, miała możliwie pełny obraz sytuacji w jakiej dany incydent zaistniał.

Co powinno być zawarte w raporcie o incydencie ?

Co powinno się zatem znaleźć w raporcie o incydencie? (poniższa listę opieram na dotychczasowych doświadczeniach projektowych. Nie jest to lista zamknięta. W zależności od konkretnego projektu dodatkowe elementy mogą być wymagane do zarejestrowania podczas zgłaszania incydentu, niektóre mogą zostać pominięte):

  1. tytuł incydentu – jedno zdanie wskazujące na to czego dotyczy incydent
  2. data i godzina zgłoszenia incydentu 
  3. autor raportu o incydencie
  4. osoba/grupa do której incydent jest przypisany
  5. opis ścieżki którą użytkownik przeszedł w systemie do momentu uzyskania niezgodności w działaniu systemu
  6. oczekiwane w systemie wynik wykonania danej części scenariusza testowego
  7. rzeczywiste wyniki wykonania danej części scenariusza testowego w systemie
  8. odniesienie do scenariusza testowego w ramach którego wykryto incydent (a także jego konkretny krok).
  9. krytyczność (severity) zgłoszenia – wskazuje jak bardzo zgłoszenie jest krytyczne w stosunku do testowanego systemu
  10. priorytet zgłoszenia – wskazuje jak pilne jest rozwiązanie zgłoszonego problemu
  11. wskazanie na instancję systemu na której prowadzono testy – np. środowisko developerskie, testowe, etc.
  12. nazwa użytkownika/rola na którą tester był zalogowany podczas prowadzenia testu
  13. historia/komentarze – opis dotychczasowego przebiegu obsługi incydentu. Zawiera komunikację pomocną dla różnych osób zaangażowanych w obsługę incydentu.
  14. załączniki – np. błędny raport, zrzuty ekranu obrazujące problem, logi z systemu czy bazy danych.

Podsumowując…

Podsumowując raport o incydencie powinien zawierać taki zestaw informacji, żeby jego analiza i poprawa mogła przebiec w jak najbardziej pozbawiony wątpliwości i opóźnień sposób. Warto w tym momencie zwrócić uwagę, że nie jest to widzi mi się formalisty – tylko często rzeczywista oszczędność czasu, a co za tym idzie także pieniędzy potrzebnych na rozwiązanie zgłoszonego problemu.

 

Przykład – raportu o incydencie:

  1. tytuł incydentu:Wybranie opcji “Wyloguj” z menu “Opcje” powoduje wyświetlenie błędu “Nieznane wskazanie 0(null)!” w oknie przeglądarki
  2. data i godzina zgłoszenia incydentu: 12-09-2016 / 11:26
  3. autor raportu o incydencie: Michał Marczak
  4. osoba/grupa do której incydent jest przypisany: Jan Nowik (Dev Lead)
  5. opis ścieżki którą użytkownik przeszedł w systemie do momentu uzyskania niezgodności w działaniu systemu:
    • Zalogowałem się jako użytkownik user1/hasło: pass1 na środowisko testowe: www.testowysystem.pl
    • Z głównego ekranu systemu wybrałem menu “Opcje” oraz pozycję “Wyloguj”.
  6. oczekiwane w systemie wynik wykonania danej części scenariusza testowego:
    • System powinien wyświetlić ekran zawierający wiadomość “Użytkownik został pomyślnie wylogowany z systemu”.
  7. rzeczywiste wyniki wykonania danej części scenariusza testowego w systemie
    • System wyświetlił komunikat  “Nieznane wskazanie 0(null)!” w oknie przeglądarki.
  8. odniesienie do scenariusza testowego w ramach którego wykryto incydent (a także jego konkretny krok).
    • WYLOGOWANIE_POPRZEZ_MENU
  9. krytyczność (severity) zgłoszenia– KRYTYCZNY
  10.  priorytet zgłoszenia – PILNY
  11.  wskazanie na instancję systemu na której prowadzono testy – np. środowisko developerskie, testowe, etc.
    • Środowisko TEST_001
  12.  nazwa użytkownika/rola na którą tester był zalogowany podczas prowadzenia testu
    • Użytkownik: user1 / Rola: Viewer
  13.  historia/komentarze:
    • 12-09-2016 / 13:11 [Jan Nowik] “Poprawka wgrana na środowisko TEST_001 – prośba o weryfikację”
    • 12-09-2016 / 14:09 [Jan Nowik] “Poprawka zweryfikowana na środowisku TEST_001 – nie rozwiązuje problemu, komunikat jak w opisie zgłoszenia wciąż występuje”
  14. załączniki:
    • zalacznik

*Źródło: http://sjsi.org/wp-content/uploads/2014/10/slownik-termin%C3%B3w-testowych-ver-2.3-PL.pdf

Dodaj komentarz