PODOBAŁ CI SIĘ TEN ARTYKUŁ?

Sprawdź inne teksty

Tworzenie zgłoszeń defektów jest nieodzownym elementem pracy testerskiej, nic więc dziwnego, że pytanie jak go poprawnie stworzyć nie przestaje padać z ust osób aspirujących na stanowisko testera. W tym wpisie zamierzam omówić wspominane w tytule informacje, które wciąż bywają pomijane przez kandydatów podczas rozmowy kwalifikacyjnej. W tym wpisie poznasz również dodatkowe miary szacowania jak Wpływ i Prawdopodobieństwo. Nauczysz się dobrze interpretować wagi defektu oraz poprawnie je przypisywać. Na koniec stworzysz pełne zgłoszenie błędu na specjalnie przygotowanym formularzu.

Niedoskonała budowa zgłoszenia defektu

Jednym z często pojawiających się pytań na rozmowie rekrutacyjnej jest "Jak zgłosisz następujący defekt". Do zadania załączony jest wybrany wyjątek z aplikacji, który jednoznacznie wskazuje na zupełne przerwanie działania aplikacji. Kandydat jest dobrze przygotowany z samej struktury przypadku testowego i słychać, że wie o czym mówi podając:

• Temat zgłoszenia
• Środowisko, wersję aplikacji
• Opis z krokami do reprodukcji defektu
• Rezultat rzeczywisty i oczekiwany
• Załączniki, w tym zrzuty ekranu, logi, gify.

W porządku. Ale całkowicie pomija przy tym priorytet, o ważności już nie wspominając! Zgłaszając defekt pamięta, jak dobrze go udokumentować i wyczerpująco opisać, a zapomina o najważniejszym aspekcie - sklasyfikowaniu jego priorytetu wykonania. Jednak z rozmowy jasno wynika, że tester pracuje w projekcie w którym używa się narzędzi do zarządzania testowaniem ze skonfigurowanymi priorytetami.

Moim zdaniem wynika to z tego, że szacowanie priorytetów w projektach bardzo często wykonuje się "na wyczucie" i bez odpowiedniego przeszkolenia pracownika. Albo w projekcie istnieje zwyczaj pytania starszych doświadczeniem kolegów, jaki priorytet może mieć zagadnienie. Tester po pracy w takim projekcie przychodzi na rozmowę rekrutacyjną i jeżeli już zna priorytety, to działa intencjonalnie zamiast rozważyć problem zgodnie z praktyką.

Problem zarządzania defektami

Wyobraź sobie następującą sytuację. Jesteś testerem, który dopiero rozpoczął pracę w projekcie, a w aplikacji właśnie zaczął się cykl testów eksploracyjnych. Z pewnością znajdziesz całe mnóstwo błędów do zgłoszenia. Na początku wszystkie będą wydawały się kluczowe do naprawienia, w końcu aplikacja ewidentnie sypie się na Twoich oczach.

Załóżmy teraz, że z każdym przyrostem aplikacji następuje zwiększenie pokrycia testami i projekt rozwija się zgodnie z planem. W kolejnych cyklach zagęszczenie błędów znacząco maleje, a Ty zaczynasz sprawdzać mniej używane komponenty aplikacji, znajdując przy tym więcej corner case'ów (przypadków brzegowych), kosmetycznych niedociągnięć i literówek. Jak nad tym wszystkim zapanować i wyczuć, które zagadnienie ma jaką wagę?

Zastosuj sprawdzone wagi zagadnień. Priorytet i Ważność.

Priorytet staje się podstawową miarą, skupiając się na biznesowej stronie aplikacji. Są to te wszystkie funkcjonalności, których działanie jest kluczowe dla klienta. Znalezione w tych obszarach defekty mogą zagrażać biznesowemu powodzeniu projektu. Odpowiada na pytanie "Jak szybko musimy to naprawić". Z reguły waży się go następująco:

P1. Krytyczny/Bloker - Blokuje biznesowy proces aplikacji i powinien być zrealizowany w pierwszej kolejności.

P2. Wysoki - Defekt jest istotny, należy go monitorować i podjąć działania ograniczające możliwość wystąpienia w przyszłości.

P3. Średni - Do naprawienia w najbliższym możliwym czasie.

P4. Niski - Defektem można się zająć, kiedy nie będzie zadań w iteracji.

Następnym czynnikiem jest Ważność. Ta jest często utożsamiana z priorytetem i w wielu projektach zastępuje go swoją skalą. Tymczasem skupia się ona zupełnie na innym aspekcie, tj. jak znaleziony defekt wpływa na testowany system pomijając biznesową stronę zagadnienia. Odpowiada na pytanie "Jak szkodliwy jest ten defekt". Jest to więc bardziej techniczny czynnik. W moich projektach ważność stopniuje się następująco:

S1. Krytyczny/Blokujący - Defekt całkowicie uniemożliwia dalsze testowanie funkcjonalności. Z reguły wpływa na kluczowe procesy biznesowe i zagraża dostarczeniu funkcjonalności.

S2. Bardzo wysoki - Defekt wpływa na kluczowe procesy biznesowe i zagraża dostarczeniu funkcjonalności, jednak możliwe jest obejście przy pomocy zastosowania ścieżki alternatywnej .

S3. Wysoki - Defekt wpływa na jeden lub więcej komponent aplikacji. Uniemożliwia przy tym jego testowanie, jednak możliwe jest obejście przy pomocy zastosowania ścieżki alternatywnej.

S4. Średni - Defekt nie dotyczy kluczowych procesów, możliwe jest dalsze testowanie, a w razie problemu również obejście przy pomocy zastosowania ścieżki alternatywnej.

S5. Niski/Trywialny - Defekt o minimalnym wpływie na testowany system.

Mając wiedzę na temat tych dwóch czynników jesteś w stanie bardziej kompleksowo podejść do problemu. Jeżeli rozrysowalibyśmy problem na macierzy, np. wykresie X (Ważność) Y (Priorytet) można podzielić go na:

• Wysoka Ważność i Wysoki Priorytet - Podczas wykonywania przelewu w aplikacji bankowej ta traci połączenie i urywa transakcję. Całkowicie wpływa na funkcjonalność systemu, nie ma możliwości obejścia problemu. Z biznesowej strony firma traci wizerunek i zaufanie.
• Wysoka Ważność i Niski Priorytet - Aplikacja bez problemu wytrzymuje pulę 100 000 połączeń, ale po przekroczeniu tej liczby całkowicie się wyłącza. Problem zostaje zgłoszony, ale nie musi być natychmiast naprawiany.
• Niska Ważność i Wysoki Priorytet - Podczas tworzenia strony dla Pepsi, wstawione zostaje logo Coca Coli. Nie wpływa na funkcjonalność systemu, natomiast mocno wpływa na biznesową wartość projektu.
• Niska Ważność i Niski Priorytet - Literówka na podstronie aplikacji webowej, na którą rzadko ktokolwiek zagląda. Nie wpływa na funkcjonalność systemu oraz ma niską wartość biznesową.

Zrozumienie ww. korelacji może znacząco zwiększyć Twoje szanse podczas rozmowy technicznej!

Poznanie dwóch dodatkowych czynników pozwoli Ci jeszcze szerzej spojrzeć na zagadnienie. Są częścią pracy Kierowników Testów i służą do analizy i oceny ryzyka. To Wpływ i Prawdopodobieństwo.

Wpływ

Wpływ jest to potencjalna szkoda, jaką może wyrządzić defekt, kiedy już wystąpi. Jest to tak naprawdę zapis ważności w konkretnym, zdefiniowanym stopniowaniu. Używając tak zadeklarowanego stopniowania pozwala oszacować plan działania dla testowanego komponentu oraz, jeśli to możliwe podjąć działania ograniczające wystąpienie defektu w przyszłości.

Prawdopodobieństwo

Prawdopodobieństwo wraz z wpływem pozwala obliczyć poziom ryzyka, jaki może wywołać dany defekt. Biorąc pod uwagę wpływ i prawdopodobieństwo można użyć metody analizy ryzyka PRisMa. Podobnie jak w przypadku Priorytetu i Ważności, podzieli Wpływ i Prawdopodobieństwo na:

• Wysoki Wpływ i Wysokie Prawdopodobieństwo - Czynności zapobiegające. Podczas wykonywania przelewu w aplikacji bankowej ta traci połączenie i urywa transakcję.
• Wysoki Wpływ i Niskie Prawdopodobieństwo - Przekazanie ryzyka innej stronie. Np. przekazanie sprawy firmie ubezpieczeniowej.
• Niski Wpływ i Wysokie Prawdopodobieństwo - Monitorowanie i działania ograniczające przyszłe wystąpienia ryzyka.
• Niski Wpływ i Niskie Prawdopodobieństwo - Zignorowanie i zaakceptowanie ryzyka. Wspomniana literówka na podstronie aplikacji webowej.

Takie informacje nie będą zawarte w zgłoszeniu defektu, jednak ich wyliczenia opierają się na wcześniej zdefiniowanej w testowanym zagadnieniu ważności. Pokazuje więc istotne połączenie między tymi podejściami pozwalające Kierownikom Testów prawidłowo szacować pracę w projekcie, a następnie podejmowanie odpowiednich działań.

Umiem już oszacować priorytet i ważność zgłoszenia defektu. Ale do kogo je przypisać?

Zauważam tendencję do częstego nadużywania tego pytania celem "zagięcia" kogoś w dyskusji. Jest co najmniej kilka opcji realizacji tego problemu i tak naprawdę w każdym projekcie może to wyglądać inaczej. Sposoby z jakimi ja się spotkałem to:

1. Jeśli pracujesz w zespole zwinnym i przestrzegana jest u Ciebie zasada zwinnego podejmowania zadań z tablicy: zgłaszasz defekt nie przypisując do zagadnienia nikogo. Podczas spotkania zespołu informujesz o nowo napotkanym błędzie i jego priorytecie/ważności względem waszej iteracji.Opcjonalnie: Narzędzie do zarządzania testowaniem takie jak Jira może być domyślnie skonfigurowane tak, aby automatycznie przypisywać zagadnienia do Product Owner'a/Managera, Team Leadera.
   Przykład: Obecnie pracuję dla dwóch zespołów w swoim projekcie. W jednym z nich zagadnienia są domyślnie nieprzypisywane do osoby, a w drugim automatycznie przypisują się do Product Managera. W obydwu projektach pracuje ten sam Product Manager.
2. Jeśli wiesz, kto jest odpowiedzialny za funkcjonalność: przypisz do niego zagadnienie. Najczęściej posiadamy wiedzę, kto pracował nad zagadnieniem lub pochodną jego częścią i jesteśmy w stanie wskazać odpowiedniego programistę. Często jest to oczywiste dla osób, które mają okazję pracować z programistami w jednej lokacji, ale niejasne w przypadku zmiany projektu na umieszczony w różnych lokalizacjach. Wtedy zawszę doradzam opcję trzecią:
3. Jeśli nie wiesz, do kogo przypisać zagadnienie: przypisz je do Product Owner'a/Managera, Team Leadera zespołu. Następnie poproś o eskalację problemu (i ew. sprawdzenie wagi zadania).

Wszystkie wymienione wyżej podejścia mogą wciąż budzić wiele kontrowersji, ponieważ role zarządzające jakością w projekcie potrafią mieć różne nazwy. Dobrą praktyką będzie oprzeć się na teorii ISTQB i podczas rozmowy rekrutacyjnej odpowiedzieć na to pytanie poprzez wskazanie roli "Kierownika Testów".

Jak więc będzie wyglądało poprawne zgłoszenie defektu?

Poznając zagadnienie Priorytetu i Ważności prawidłowo zważysz zgłoszone defekty. Rozwijając swoją wiedzę poprzez poznanie metody analizy i identyfikacji ryzyka zobaczysz jak można spojrzeć na  zagadnienie z szerszej perspektywy. Mam nadzieję, że artykuł pomoże Ci lepiej ważyć zagadnienia z uwzględnieniem okoliczności wystąpienia defektu oraz na jakie obszary wpłynął.

Mając powyższą wiedzę można ją wykorzystać do zbudowania szczegółowego zgłoszenia znalezionego defektu. Liczne narzędzia ułatwiają ten proces poprzez domyślne definiowanie pól, jednak dobrze jest nauczyć się i zapamiętać najważniejsze informacje, które powinny znaleźć się w każdym zgłoszeniu defektu. A są to:

• Identyfikator zgłoszenia
• Krótki i rzeczowy tytuł zgłaszanego defektu
• Data wystąpienia defektu
• Zgłaszający zespół
• Autor zgłoszenia
• Przypisany do
• Identyfikacja elementu testowego i środowiska
• Faza cyklu życia oprogramowania, w której zaobserwowano defekt. Z reguły (Dev, Test/QA, Prod)
• Opis z krokami do reprodukcji defektu oraz warunkami wstępnymi (danymi testowymi)
• Oczekiwane i rzeczywiste rezultaty
• Ważność
• Priorytet
• Status w narzędziu do zarządzania testowaniem, np. otwarty, odroczony, powielony, oczekujący na poprawkę,oczekujący na testowanie potwierdzające, ponownie otwarty, zamknięty
• Załączniki.

A na koniec zadanie dla Ciebie :) Wyobraź sobie, że testujesz aplikację, która po rejestracji użytkownika umożliwia odbieranie kodów rabatowych na wybrane artykuły. Podczas testowania formularza rejestracji wyskakuje następujący błąd:

Stwórz poprawne zgłoszenie defektu używając poniższego formularza. Jeśli chcesz, wyślij do mnie wypełniony przez siebie formularz, a chętnie go sprawdzę!

DOWIEDZ SIĘ, JAK ZOSTAĆ TESTEREM

REMIGIUSZ BEDNARCZYK

Znajdź mnie na mediach społecznościowych

Polityka prywatności