W celu powtórki z rozrywki kilka następnych postów bedzie glownie wiedza poparta praktyka. By zaoszczędzić sobie i Tobie czasu od razu przejdźmy do konkretów.
Czym jest bug?
Jest on konsekwencją czy też wynikiem złego “kodowania”.
Czym jest defekt?
Defekt jest odchyleniem w zachowaniu/wyglądzie/funkcjonalności etc. rzeczywistego produktu w porównaniu do jego pierwotnych wymagań z punktu widzenia biznesowego.
Warto zauważyć, iż te dwie definicje mają pomiędzy sobą bardzo cienką granice. Niemniej w branży obydwa przypadki są błędami/odchyleniami/faulami, które trzeba naprawić.
Podczas wykonywania test case’u tester może spotkać się z wynikiem pewnych funkcjonalności (f.e.) softu, który jest zupełnie inny od oczekiwanego (zachowania określonego w dokumentacji - czy to produktu, czy to UI, czy to określonego przez klienta biznesowego). Takie odchylenia są określane jako Defekt Software'u. Są one zresztą nazywane różnie, w zależności od firmy, w jakiej pracujecie bądź będzie pracować, ich nazewnictwo może być preferowane w różny sposób. Dla przykladu mozna je nazwac po prostu 'problemem', bądź usterką ('issue'), bądź bugiem ('bug'), bądź incydentem.
Raport defektu zgłaszany do dewelopera powinien zawierac nastepujace informacje:
- Defect ID - Unikatowy numer identyfikacyjny dla danego defektu,
- Defect description - Jak najbardziej szczegółowy opis defektu zawierający informacje o module/środowisku w którym defekt został znaleziony,
- Version - Wersja aplikacji w której znaleziono błąd,
- Steps - Szczegółowe kroki (najlepiej poparte screenshotami), dzięki którym deweloper będzie mógł odtworzyć defekt i go zreprodukować,
- Date Raised - data wykrycia defektu,
- Reference - miejsce w którym możesz wskazać poprawne zachowanie dla modułu, w jakim pojawia się defekt. Poprzeć je możesz np. screenshotami z dokumentacji technicznej, dostępnymi wymaganiami biznesowymi dla produktu etc. tak, by deweloper jeszcze łatwiej i klarowniej mógł zrozumieć charakter błędu z jakim będzie się mierzyć,
- Detected By - Twoja nazwa kodowa _w_ firmie/ID testera, który wywołał/znalazł defekt,
- Status - pole dla statusu defektu (in progress/to do/under review/etc.),
- Fixed by - Nazwa/ID dewelopera, który naprawił błąd,
- Date Closed - data, w którym issue/defekt został zamknięty,
- Severity - krótko opisuje wpływ defektu na cały soft/aplikacje,
- Priority - opisuje stopień konieczności naprawy defektu w czasie/sprincie. Severity Priority może przybrać wartości High/Medium/Low, które odwołują się bezpośrednio do wpływu defektu na aplikacje, a co za tym idzie do pilności naprawy konkretnego buga.
Wyobraźcie sobie następującą sytuację jako Test Manager:
Twój team znajduje bugi podczas testowania projektu x.
Tester: Póki co znaleźliśmy 56 defektów w projekcie x,
Test Manager: Dobrze, poinformuje o tym team deweloperów.
Po tygodniu deweloperzy odpowiadają Test Managerowi:
Deweloper: Naprawiliśmy 45 defektów,
Test Manager: Dobrze, poinformuje o tym mój Test team,
Po kolejnym tygodniu tester odpowiada:
Tester: Faktycznie te 45 defektów jest załatane ale znaleźliśmy dodatkowe 10.
Na podstawie powyższego przykładu możecie zauważyć, iż jeśli komunikacja pomiędzy dwoma zespołami jest prowadzona werbalnie, rzeczy bardzo szybko staną się bardzo skomplikowane i ich nawarstwienie będzie tylko kwestią czasu.
By efektywnie kontrolować i zarządzać bugami zaleca się przystosowanie do tak zwanego DLC (defect life cycle).
Defect Management Process
- Discovery
Na etapie wykrycia defektu Team testerów stara się wykryć jak najwięcej defektów, tak by końcowy użytkownik był od nich ‘wolny’. Wykryty i zgłoszony defekt zmienia swój status na accepted, kiedy poinformowany o nim deweloper akceptuje go za pośrednictwem narzędzia zarządzającego pracą w zespole/projektami/śledzeniem błędów.
W scenariuszu z Team Leaderem testerzy wykryli 54 defekty w projekcie x.
Spójrzmy na sytuację przedstawioną poniżej - Twój Test Team wykrył błędy w projekcie x. Błędy te powodują defekty i są zgłaszane do Dev Teamu, pojawia się jednak konflikt:
W tej sytuacji to Test Manager powinien przejąć rolę ‘sędziego’ i zadecydować czy powstały problem jest defektem, czy też nie.
W tej sytuacji rozwiązanie zaproponowane przez Test Managera powinno prowadzić do rozwiązania konfliktu.
2. Categorization
Kategoryzacja defektu pomaga deweloperom w priorytetyzacji ich zadań. Oznacza to, że ten typ priorytetyzacji pozwala deweloperom zadecydować, którym z defektów mają zająć się w pierwszej kolejności.
Critical - defekty, które muszą zostać naprawione jak najszybciej, ponieważ mogą powodować poważne szkody w powstającym produkcie,
High - Defekty, które mogą wpływać na główne feature’y w produkcie,
Medium - Defekty, które powodują minimalne odchylenia od dokumentacji opisującej wymagania powstającego produktu,
Low - Defekty, które mają drobny wpływ na jakość produktu.
Defekty zazwyczaj są kategoryzowane przez Test Managera.
Przykładowa priorytetyzacja defektów przedstawia się następująco:
Opis: Performance strony internetowej jest zbyt wolny,
Priorytet: Wysoki,
Wyjaśnienie: Powstały defekt może powodować niedogodności podczas korzystania z produktu przez końcowego użytkownika.
---
Opis: Funkcjonalność logowania nie działa poprawnie,
Priorytet: Krytyczny,
Wyjaśnienie: Logowanie jest jedną z najważniejszych funkcjonalności na stronie internetowej (np. strona bankowa).
---
Opis: GUI strony internetowej nie jest poprawnie wyświetlane na smartphonie,
Priorytet: Średni,
Wyjaśnienie: Defekt występuje tylko wśród użytkowników, którzy korzystają z produktu za pośrednictwem smartphonów.
---
Opis: Strona internetowa nie zapamiętuje sesji logowania,
Priorytet: Wysoki,
Wyjaśnienie: To poważny defekt dla użytkownika, który doprawdy będzie mógł się zalogować ale nie będzie mieć możliwości przeprowadzenia dalszych operacji dostępnych dla zalogowanego konta.
---
Opis: Niektóre z hiperłączy nie działają poprawnie (brak poprawnych adresów w odnośnikach),
Priorytet: Niski,
Wyjaśnienie: To bardzo prosty w naprawie defekt, poza tym użytkownik wciąż ma dostęp do serwisu internetowego.
3. Resolution
Kiedy defekty są zaakceptowane przez dev team i pokategoryzowane następują kolejne kroki w ich łataniu.
Assignment: Przypisanie zadania dla konkretnego dewelopera,
Schedule fixing: Deweloperzy tworzą swoisty plan naprawy (trudność naprawy, czas, jaki jest potrzebny na naprawdę itd.) zaakceptowanych defektów, w zależności od ich priorytetyzacji,
Fix the defect: Kiedy Dev Team naprawia defekty, Test Manager śledzi cały proces naprawy na podstawie utworzonego planu naprawy,
Report the resolution: Test Manager otrzymuje raport od Dev Teamu, kiedy defekty zostaną wyeliminowane.
4. Verification
Kiedy Dev Team naprawił oraz oddał raport naprawy Test Managerowi Test Team weryfikuje, iż naprawione błędy faktycznie zostały wyeliminowane.
Dla przykładu w powyższym scenariuszu, kiedy Dev Team zgłosi, że naprawili 45 defektów Test Team sprawdza je ponownie, by stwierdzić, czy faktycznie zostały one naprawione.
5. Closure
Kiedy defekty zostaną wyeliminowane oraz ich naprawa zostanie zweryfikowana to status defektu zmienia się na zamknięty (closed). Jeśli nie Test Manager wysyła je do ponownego sprawdzenia konkretnego defektu przez Dev Team.
6. Reporting
Tak zwana ‘góra’ czyli management board ma prawo, by znać statut zarządzania defektami w projekcie oraz ich naprawy. Muszą dodatkowo rozumieć cały proces zarządzania defektami, by wspierać Test Managera w projekcie. Tak, czy siak - Test Manager musi raportować im aktualną sytuację tak, by móc od nich dostać szybki feedback.
---
Ważne metryki defektów
Wracając do wcześniejszego scenariusza. Dev oraz Test Team wzajemnie recenzują zgłoszone defekty. Oto, jak może wyglądać taka przykładowa dyskusja:
Jak zmierzyć i ocenić jakość pracy testerów?
To pytanie na które Test Manager musi znać odpowiedź. Są dwie opcje, jakie warto wziąć pod uwagę:
W powyższym wariancie Test Manager może przeliczyć Defect Rejection Ratio (DRR) i jest to: 20/84 = 0.238 (23.8%).
Kolejnym wariantem jest Defect Leakage Ratio (DLR) - załóżmy, że w produkcie znaleziono 64 defekty ale Test Team wykrył tylko 44 z nich, tzn. Pominęli oni 20 defektów, które wykryli np. Deweloperzy. DLR obliczamy wg. Wzoru: 20/60 = 0.312 (31.2%).
Ostatecznie otrzymamy dwie procentowe wartości określające jakość pracy testerów:
Im mniejsza wartość procentowa DRR oraz DLR tym lepiej. Jaka wartość procentowa dla tych dwóch parametrów powinna być akceptowalna? Ta wartość jest definiowana oraz bazowana na wartościach z poprzednich projektów o podobnym zakresie.
W tym przykładowym projekcie zalecana wartość DRR oraz DLR jest akceptowalna w granicach 5 ~ 10 %. To oznacza, że jakość pracy testerów jest niska. Rozwiązaniami dla Test Managera w tej sytuacji może być:
- Polepszenie testowych umiejętności członków Test Teamu,
- Spędzenie większej ilości czasu na egzekucji testów, zwłaszcza podczas recenzowania wyników egzekucji testów.
