Zarządzanie defektami

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

1. 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.

O automatyzacji testów słów kilka

Hejo,

W dzisiejszym poście chciałbym podzielić się przemyśleniami nt. automatów testowych. Chciałbym odpowiedzieć, dlaczego nie wszędzie automaty się sprawdzają, dlaczego rozwijają myślenie oraz dlaczego w większych projektach są bardzo opłacalne ekonomicznie.

Ja sam naukę automatyzacji rozpocząłem stosunkowo szybko, na własną rękę, czy to posilkujac sie tutorami, czy to ucząc się na własnych błędach, kierując się intuicją podczas tworzenia skryptów dla tamtejszych projektów. Można powiedzieć, iż uczyłem się pisać automaty podczas rozwiązywania tamtejszych aktualnych, komercyjnych projektów. Drugą sprawą był oczywiście fakt, iż tamte automaty z biegiem czasu trzeba było przepisać od nowa (albo chociaż bardzo dobrze zoptymalizować). Nie można jednak ująć faktu, iż najszybciej szlifuje/zdobywa się umiejętności podczas aktywnego rozwiązywania kolejnych problemów.

Pierwszą aplikacją, której strukturę w całości pokryłem (razem z napisaniem test case'ów etc.) była aplikacja mobilna na Androida, dla dużego i poważnego klienta, gdzie nasz zespół zajmował się wtedy jej wsparciem (aktywnym i szybkie wprowadzanie nowych i skomplikowanych funkcjonalności). Okay.. Jeszcze wcześniej zajmowałem się automatami dla Frontendu ale nie liczę tych pierwszych, udanych test case'ów ponieważ nie były one komercyjnym projektem.

Podczas pracy nad wyżej wspomnianym projektem szybko okazało się, że fajnie byłoby mieć skrypty, które same sprawdziłyby “całą” aplikację (przede wszystkim jej podstawowe, core'owe cechy, bez których apka nie pracowałaby prawidłowo) po każdym nowym buildzie, dzięki czemu zaoszczędziliśmy wiele czasu oraz nerwów, poprzez wyłapywanie nowo powstałych defektów ad-hoc.

Używałem już wtedy Elipsa (Mars Edition jeśli dobrze pamiętam) - do dzisiaj to moje ukochane IDE -  razem z TestNG (chyba ten Framework preferuje bardziej, niźli jUnit), Selenium WD oraz Appium jako proxy dla emulatora z Android SDK. Moje wczesne doświadczenia były bardzo pozytywne, proces automatyzacji nie okazał się (na początku) AŻ tak trudny. Problemy zaczęły się, kiedy pokryć trzeba było struktury odpowiadające za bardziej złożone i wymagające mechanizmy czy funkcjonalności, niż te proste 'klikacze'. I to właśnie clue automatów, a raczej tego, dlaczego ich pisanie może być angażujące i po prostu fajne.

Dla mnie pisanie automatów to nie sztuka sama w sobie (tak słyszałem od jednego z deweloperów). To możliwość rozwiązywania ciekawych problemów, gdzie nie tylko musisz dobrze rozplanowany przez się tesc case przełożyć na język maszynowy, ale i dodatkowo poszczególne kroki musisz przecież dobrze rozplanować, przewidując wszystkie wyjątki, kombinacje i odskocznie od reguły, krok po kroku (stąd testowanie testów).

Takie testy możesz wzbogacić o nowe funkcjonalności. Z czasem postawilem na wieksza randomowość danych wejściowych, pokrywałem zależnosci pomiedzy nimi, a danymi wyjściowymi, sprawdzałem algorytmy po UI, ostatecznie bawiąc się w programistę-amatora, gdzie za pomocą Aplikacji, którą sprawdzam tworzę jednocześnie osobne algorytmy, testując je w pamięci komputera. Wiem, że brzmi to skomplikowanie ale jeśli posiadasz już techniczne doświadczenie to bez problemu to zrozumiesz. O, doczepiłem do testów również automatycznie generowane screenshoty przy wykryciu błędu oraz automatyczne nagrywanie oraz zapisanie VIDEO dla egzekucji tychże. Może kiedyś opiszę dokładniej, na przykładzie na czym to polega (dla niecierpliwych - zapraszam na mojego Gita).

Wspominam o tym, ponieważ chcę pokazać, iz automatyk również jest programista (i tutaj pojawi się wielkie BUM! albo śmieszki kolejnego dewelopera), ponieważ dzięki pisaniu czystego i zrozumiałego kodu, dzięki wiedzy nt. używanych przezeń narzędzi oraz umiejętności pokrywania i egzekwowania kolejnych struktur/funkcjonalności kodu, dzięki intuicji i umiejętności uczenia się na “błędach” (dosłownie) oraz zupełnie innym sposobie myślenia, niźli programista stricte -  automatyk na pewno nie ma się czego wstydzić.

W mojej opinii automaty są przede wszystkim dobre dla testów regresji stricte. Nie warto implementować ich, czy pokrywać struktur w projektach, które są nastawione na częste i szybkie zmiany. Polecałbym je przy budowaniu  full-stockowych serwisów i pisanie już po UI, gdzie dla fajnego, poważnego frontendu mogą być nadal wprowadzane kolejne funkcjonalności na życzenie klienta. Podobnie sytuacja wygląda zresztą z apkami mobilnymi (praktycznie ze znaczną ich większością).

A co do samej ekonomii testów? Cóż. Na własnym przykładzie napiszę, iż kiedyś z czystej ciekawości obliczyłem stosunek manualnego przeklikania sprawdzenia funkcjonalności dla sklepu internetowego (formularze, koszyk zakupowy, drag&drop, iframe itd.). Znając dokładnie cały front end sprawdzenie manualne “zajęło” mi ponad 6 minut. Mojemu automatowi niecałe 21 sekund. I to razem z wygenerowaniem raportu dla 3 popularnych przeglądarek.

To by było na tyle w tym tygodniu,

Best,

bindy.