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.

Organizator czasu to fajna sprawa

Hejo,

Właśnie uświadomiłem sobie, że jest czwartek. Okay, będąc zupełnie szczerym to uświadomił mi to todoist. Dzisiaj dzień pisania posta. I właśnie temu cudownemu programowi (może nie niemu stricte ale ogólnie organizatorom czasu) chciałbym poświęcić tego krótkiego posta.

Kiedyś spotkałem się z opinią, że używanie 'organizatorów czasu' to oznaka słabości i braku samokontroli nad sobą. Nie trwałem w tym przekonaniu, zdanie to było mi obojętne, zwłaszcza, że nie pamiętam nawet, kto dokładnie przytoczył te słowa.

Nie zdawałem sobie sprawy z tego, jak produktywnym mozna byc w 24h. Nie zdawałem sobie sprawy z tego, że pomimo tego, iż każdy z nas posiada taka sama ilość czasu w dobie - zarówno ten, ktorego stac na wiele, który osiągnął tak zwany sukces, jak i ten, który nie osiągnął nic narzekając na to, jak to niczego sie nie dorobil. Trwałem w blogiej nieswiadomosci, dopóki nie trafiłem na podcast Marcina Iwucia z Finansow Bardzo Osobistych (swoja droga polecam bardzo jego aktywność w sieci i poza nią - jesli chcesz miec kontrole nad swoimi pieniędzmi ofc). Marcin przeprowadził rozmowę z CEO Nozbe. Rozmowa dotyczyła zagadnień z organizacji czasu jak i produktywności (nie zgadliście, co?) I tak właśnie się zaczęło. Na początku korzystałem właśnie z Nozbe (warto zaznaczyć, iż to Polska inicjatywa), niemniej todoist umożliwia mi synchronizację pomiędzy moimi wszystkimi urządzeniami, oferuje system karmy (który akurat mnie mobilizuje wyśmienicie) oraz, co najważniejsze posiada prosty system faworyzacji i priorytetyzacji zadań razem z ich intuicyjną automatyzacją.

Nie ukrywam również, że ważnym był fakt, iż oferował w wersji FREE o wiele więcej przydatnych funkcjonalności, niźli konkurencyjny odpowiednik.

Po tygodniowym już używaniu aplikacji jakimś cudownym zbiegiem okoliczności (a jakże!) - znalazłem czas na wiele zadań - zarówno w pracy (często nadprogramowych, związanych z rozwojem moich kompetencji), czas na sport, porządki, relaks, spotkania ze znajomymi, wyjścia z domu etc. Dodatkowo naprawde rzadko mozna mnie spotkac po prostu leżącego na kanapie (a jezeli juz leze, to pewnie z książką albo jakimś podcastem). Lubię nowego siebie. Czas ucieka szybko ale ja rowniez czuje jego postęp, jako dobrze wykorzystany, produktywny oraz motywujący do dalszego działania. Ach, poczucie coraz większej kontroli nad swoim życiem to uczucie, którego nie zastąpi żadna imitacja strefy komfortu.

To nie jest tak, ze polecam todoist. Polecam organizer czasu - jakikolwiek. Wiele z nich ma wersje próbne, może zatem warto się przemóc i spróbować rzucić wyzwanie samemu sobie?

Mi się udało, skoro na todoist mam już poziom eksperta.. ;)

Cheers,

F.

Mój git jest git (projekty tworzone 'w biegu')

*Co nie zmienia faktu, że starałem się, aby były na tyle czytelne i profesjonalne, na ile miałem weny i zapału, by to zrobić.

 Nie oznacza to również faktu, że nigdy nie wrócę do tych projektów - pewnie czasem będę commitować w ramach treningu kolejne linie - tak, by pasek aktywnosci rocznej chociaż w niewielkiej częsci został pokryty w różnych odcieniach zielni.

Znajdziecie tutaj moje przykładowe prace i problemy z jakimi się zmierzyłem. Pisanie kodu, mimo wszystko jest jak pisanie dobrego opowiadania. Najpierw jest pomysł, potem logiczne ułożenie wszystkiego do sensownej postaci, by następnie czysto warsztatowo dokończyć dzieła.

 Oczywistym jest fakt, że im więcej kodu napiszesz (działającego lub nie - zawsze możesz zrobić fix ;)), tym lepszy będziesz. Znowu parafrazując mistrza pisarzy S. Kinga - "aby być dobrym pisarzem musisz 3 h czytac i 3 h pisać - dzennie".

Aż tyle czasu nie mam ale nadal - w przypływie weny commituję dzielnie.

Proszę:

https://github.com/bindydijurido

 Tak, wiem, ze obiecałem artykuł o rekrutacji w IT. Kiedys będzie, promise.

Byłem na wakacjach. Małych. Kameralnych. Fajnych. Muszę jeszcze dojsć do siebie.

Cheers,
F.

Ps. Tak, post sklejony na kolanie. Lepszy rydz, niż nic, czy cos.

Mogę napisać swoje imię na zakurzonym body - doprowadzam bloga do porządku!

Hejo!

Trochę to smutne, bo dawno mnie tutaj nie było, a moje doświadczenia i przygody związane z tematem rosną wprost proporcjonalnie do upływu czasu. Nie. W sumie mogę stwierdzić, iż wraz z mijającym czasem moje doświadczenia rosną szybciej, niż miesiąc temu w tym samym przedziale.

Dlaczego?

Otóż wkręciłem się w programowanie. Ale po kolei.

Idąc do tej branży od początku zakładałem, że chciałbym zostać programistą. Moja ścieżka kariery była z góry ustalona - chcę być testerem, z początku manualnym i małymi kroczkami uczyć się automatyzacji (nie miałem wtedy o tym zielonego pojęcia). Z grubsza tak właśnie to wyglądało. Z grubsza, bo niuansów jest cała masa, a każdego dnia dochodzą nowe.

Los był mi łaskaw i miałem możliwość przydzielenia poniekąd samego siebie jako osobę w pełni odpowiedzialną za jakość oraz testy aplikacji mobilnych (iOS i Android) oraz front end w firmie, dla której pracuję. Moja droga z mobilkami jest o tyle ciekawa, że mam przyjemność odpowiadać za produkt służący pewnemu ogromnemu klientowi w zwiększaniu jego przychodu. Odpowiadam tu za jakość, funkcjonalność, przejrzystość oraz bezbłędność - jeśli mogę tak to ująć.

Więcej aktualnie nie napiszę - zostawiłem swojego personalnego kompa w pracy, a san aktualnie podłączam w biegu PS VR, czeka mnie basen i super weekend z dziewczyną.

Obiecuję przede wszystkim sobie, że będę tutaj co tydzień dzielić się randomową informacją/przygodą/zagadnieniem dotyczącym mojej pracy. Pomoże mi to usystematyzować wiedzę, podobnie jak wtedy, kiedy uczyłem się do ISTQB. Jak dawno to było.. 

Wiecie, jak spojrzy się z perspektywy czasu na to, gdzie byłem, gdzie jestem teraz i kiedy pomyślę o tym, gdzie mogę być w przyszłości to nachodzi mnie satysfakcja, że udało się już tyle osiągnąć, że rozwijam się w zadowalającym jak dla mnie tempie. Jednocześnie pojawia się głód kolejnych wyzwań i dążenia do realizacji nowych zadań/projektów. Właściwie to w dużym uogólnieniu o to w tej branży chodzi - o niekończącą się satysfakcję.

I tak, można się w tym zagubić. Też o tym wspomnę w jednym z postów.

Ps. Kiedyś kolega z mojego zespołu powiedział, że mam tutaj wspomnieć z jakimi debilami pracuję - to wspominam. Pozdrawiam śmieszka ^_^

Ps. 2. Wybaczcie moją składnie - jestem na odwyku nikotynowym.. Po raz 1231414123.

Trzymajcie się i do szybkiego następnego!

F.