Kalendarz letni 2022 – Na tropie błędu!

Dzień 1. Witajcie!!!

Kochani!

Nadszedł czas na kalendarz letni! Tematem kalendarza letniego jest „Na tropie błędów”. Przez cały sierpień pochylimy się nad szerokim tematem błędów. Zadania oraz materiały będą publikowane codziennie wieczorem na tej stronie. Porcje materiałów podzielone zostaną na dni, zadań nie trzeba wysyłać, odpowiedzi będą publikowane co weekend!

Serdecznie zapraszam wszystkich, a w szczególności osoby, które szykują się do udziału w projektach testerskich Cherry-IT!

Dzień 2. Czym jest błąd?

Kochani!

W pierwszym tygodniu będziemy zastanawiali się nad tym czym jest błąd. Dziś na rozgrzewkę zadanie, znajdź błąd na ulubionej stronie internetowej. Spróbuj go opisać ? Będziemy na nim pracować przez kolejne 3-4 dni!

Zdradzę, że w kolejnych tygodniach zajmiemy się:

• narzędziami do zgłaszania błędów,
• analizą błędów,
• nauką prawidłowej opieki nad błędami (workflow, spotkania).

Dzień 3. Kilka informacji o błędzie!

Kochani!

Wczoraj znaleźliście swojego kandydata do tytułu błędu 🙂 Dziś pochylimy się nad definicją błędu oraz jego cyklem życia! Zachęcam do zapoznania się z materiałami, gdyż przydadzą się w kolejnych dniach!

Dzień 4. Elementy składowe zgłoszenia błędu!

Kochani!

Pomimo, że zgłaszanie błędów jest raczej czynnością kreatywną, każde zgłoszenie powinno składać się z określonych elementów obowiązkowych oraz wszystkich informacji, które mogą pomóc przy naprawie 🙂

Elementy składowe zgłoszenia błędu, które są obowiązkowe:

1. Id
2. Nazwa
3. Opis (kroki reprodukcji, aktualny rezultat, oczekiwany rezultat)
4. Przeglądarka + wersja
5. Środowisko testerskie
6. Wersja testowanego systemu
7. Print screeny

Jako, że jutrzejszy dzień zapowiada się wybitnie pracowicie, dzień 5 został dodany wcześniej 😉

Dzień 5. Zgłoszenie błędu!

Kochani! Pamiętacie błąd z dnia drugiego? Zadaniem na dziś jest przepisanie go w formie wskazanej w dniu 4 🙂 Dodatkowo proszę pamiętajcie o tym  błędzie, gdyż przyda nam się w tygodniu narzędziowym!

W sobotę pojawi się przykład zgłoszenia błędu, a w niedzielę temat, w którym często widzę błędy/ nieścisłości w zgłoszeniach u Juniorów!

Dzień 6. Raport ze zgłoszenia błędu!

W kolejnych tygodniach zapoznamy się z narzędziami, które dedykowane są raportowaniu błędów. Dziś zgłoszenie błędu zostanie przedstawione w formie podstawowej 🙂

Błąd, który zgłoszony jest poniżej zauważyłam w maju na popularnej stronie informacyjnej (błąd już nie występuje 😉 ), ale mam wrażenie, że będzie dobrym przykładem, gdyż do jego znalezienia użyłam DevTools 🙂

ID: BUG-1 //tu najczęściej pierwszym członem jest skrót nazwy projektu, modułu lub funkcjonalności
NAZWA: Przy wejściu na pierwszy artykuł z listy artykułów otrzymujemy komunikat Service temporarily unavailable.
OPIS
Kroki reprodukcji:
1. wejdź na stronę <tu adres środowiska testowego> // czasem ten krok się pomija jako zbyt trywialny, ale nie jest błędem dodawanie go
2. kliknij w pierwszy artykuł z listy artykułów

Aktualny rezultat:
pojawiła się informacja o czasowej niedostępności serwisu:
<code>{
"error": {
"message": "(#2) Service temporarily unavailable",
"type": "OAuthException",
"is_transient": true,
"code": 2,
"fbtrace_id": "AOukjwgx875tLj-c6fFM3Wz"
}
}</code>

Oczekiwany rezultat:
poprawne załadowanie strony bez informacji Service temporarily unavailable // tu można dodawać linki do dokumentacji projektu, aby dokumentować prawidłowe działanie

Przeglądarka
Chrome wersja: <wersja przeglądarki, na której został błąd znaleziony>

Dzień 7. Środowisko.

W wielu projektach komercyjnych (w szczególności anglojęzycznych) środowisko traktowane jest jako środowisko testerskie, czyli instancja systemu, który testujemy. Jednak coraz częściej wśród Juniorów obserwuję interpretację środowiska jako ekosystemu błędu (system operacyjny, przeglądarka, narzędzia itd.). Bardzo proszę o zwrócenie na to uwagi, gdyż często na tym polu dochodzi do niezrozumienia między seniorami a juniorami kształconymi poprzez kursy i uTest 🙂

Podsumowując:

• środowisko != środowisko testowe,
• environment = środowisko testowe (w 99,9% obserowanych przeze mnie przypadków),
• środowisko testowe = instancja testowanego systemu 🙂

Dzień 8. Narzędzia do zgłaszania błedów.

W poprzednim tygodniu uczyliśmy się czym jest błąd, jak go zweryfikować i jak powinno wyglądać podstawowe zgłoszenie błędu. W tym tygodniu czas na poznanie narzędzi, w których takie zgłoszenie możemy stworzyć.

A dla ciekawości, poniżej zestawienie 18 najpopularniejszych bugtrackerów na świecie:

• Backlog
• Katalon TestOps
• QACoverage
•  BugHerd
• Userback
• Marker.io
• Bugzilla
• JIRA
• Mantis
• Trac
• Redmine
• Micro Focus ALM/Quality Center
• FogBugz
• IBM Rational ClearQuest
• Lighthouse
• Zoho Bug Tracker
• The Bug Genie
• BugHost

Źródło: http://www.softwaretestinghelp.com/popular-bug-tracking-software/

W naszym kalendarzu w kolejnych dniach zajmiemy się trzema narzędziami, które są bardzo popularne w projektach komercyjnych!

Dzień 9. JIRA

W moim odczuciu to najczęściej używane narzędzie do zgłaszania błędów w polskich i zagranicznych projektach, dlatego postanowiłam od niego zacząć 🙂

Dziś chciałabym Wam przedstawić podstawowe informacje o JIRA (przepraszam za skaczące paski, ciągle obiecuję sobie, że nagram nową wersję, ale w projektach nadal dużo pracy 😉 )

Dzień 10. Zgłoszenie błędu w JIRA

Kochani!

W dniu dzisiejszym czekają Was dwa zadania:

• założenie bezpłatnego konta w JIRA,
• przepisanie w formularzu JIRA pierwszego błędu!

Dzień 11. Czas na pytania!

W trakcie trwania kalendarza zauważyłam, że ze względu na to, że do kalendarza nie ma dedykowanego slacka, to nie każdy ma możliwość zadania testerskiego pytania! Jeśli masz takie pytanie zadaj je tu, ja odpowiem na nie w formie filmu, postu, artykułu 🙂 Jeśli pytanie będzie dotyczyć kalendarza, odpowiedź pojawi się w trakcie trwania kalendarza! Jeśli nie będzie dotyczyć materiału zawartego w kalendarzu to odopowiedź pojawi się zaraz po zakończeniu kalendarza! Zachęcam do zadawania pytań!!! 🙂

Dzień 12. Bugzilla

Kolejne narzędzie, któremu się przyjrzymy to Bugzilla. Według asperit.com jest to jeden z 5 najczęściej używanych bugtrackerów! Zadanie na dziś jest dosyć skomplikowane, a polega na ściągnięciu narzędzia, abyśmy jutro mogli zgłosić tam błąd 🙂

Zadanie:

Przygotuj Bugzillę do pracy: https://www.bugzilla.org/download/

Dzień 13. Zgłoszenie błędu w Bugzilli!

Na dziś zaplanowane jest zgłoszenie błędu w Bugzilli!

Dzień 14. Na złapanie oddechu

Dzisiejszy dzień poświęcony jest na złapanie oddechu i nadrobienie zaległości. W przyszłym tygodniu pojawią się natomiast pprzykładowe zgłoszenia błedów w narzędziach, które omawiamy oraz w planach są małe tutoriale, aby dobrze narzędzia poznać 😉

Dzień 15. Przygotowanie kolejnego narzędzia!

Dziś będę Was prosić o założenie bezpłatnego, trialowego konta w narzędziu Mantis. Jest to dosyć często używane w projektach narzędzie! Waszym zadaniem będzie założenie konta i zapoznanie się z narzędziem 🙂

Jeśli masz pytania przypominam o formularzu do pytań! Odpowiedzi pojawią się wkrótce!

Link do znalezienia triala: https://www.mantisbt.org/demo.php

Dzień 16. Kolejne zgłoszenie błędu!

Czas na zgłoszenie błędu w Mantisie! To zadanie na dziś! 🙂

Dzień 17. Analiza błędu

W poprzednich dniach przeanalizowaliśmy trzy narzędzia do zgłaszania błędów, które bardzo często pojawiają się w projektach komercyjnych. Przykłady zgłoszeń w tych narzędziach wraz z dobrymi radami zostaną zamieszczone w sobotę i niedzielę w tym tygodniu. Natomiast od jutra rozpoczniemy duży temat związany z analizą błędów, którą wykonywać możemy w każdym etapie życia błędu 🙂 A czym dla Ciebie jest analiza?

Dzień 18. Pierwsza analiza

Pierwszą rzeczą, którą powinniśmy przeanalizować po znalezieniu błędu jest zasadność zgłoszenia. Czy to co znaleźliśmy jest błędem? Możemy to zrobić na dwa sposoby:

• jeśli mamy szczęście to projekt ma dokumentację. Aby zweryfikować czy nasze znalezisko jest błędem należy zobaczyć czy działa w taki sam sposób w jaki jest opisany w dokumentacji. Jeśli tak jest to nawet w przypadku, jeśli jest to nielogiczne, nie możemy uznać znaleziska za błąd. Jest to bardzo ważne, gdyż bardzo często, w szczególności Juniorzy, wierzą bardziej swojej intuicji lub logicznemu myśleniu niż dokumentacji 🙂 Jeżeli natomiast znajdziemy w dokumentacji coś nielogicznego, należy to zgłosić Analitykom, którzy wyjaśnią dane zagadnienie z Klientem lub innymi Analitykami 🙂
• pytamy! W pierwszej kolejności zawsze pytamy Product Ownera lub Analityków, później możemy zasięgnąć również rady Deweloperów. Ale miejscie proszę na uwadze, że informacje pozyskane od Programistów mogą być stronnicze, gdyż oni już jakiś czas z danym, błędnym rozwiązaniem obcowali i niechcący mogą wpłynąć na nasze postrzeganie tego błędu!

I tu moja dobra rada: Nigdy nie bójcie się pytać! Nawet jeśli coś jest w dokumentacji, ale jest niejasne – pytajcie!

Dzień 19. Analiza duplikatów

Jesteśmy już po pierwszej analizie, wiemy, że nasze znalezisko jest błędem. Co dalej? Należy przeanalizować, czy wcześniej już takiego błędu ktoś nie zgłosił. Najczęściej pomagają nam w tym etykiety, labele i nazwy bugów ze znacznikami, po których przeszukujemy zgłoszone błędy. Dobrą praktyką jest również zapytanie innych testerów, czy taki błąd kojarzą 🙂

Jeśli błąd nie jest duplikatem to sytuacja jest prosta, po prostu go zgłaszamy.

Jeśli błąd już istnieje to dobrą praktyką jest przeczytać tamto zgłoszenie i jeśli mamy dodatkowe informacje, które mogą pomóc w rozwiązaniu problemu dodajemy je albo w komentarzu, albo w opisie zadania!

A co jeśli zgłosimy błąd i okaże się, że to duplikat? Wtedy najczęściej linkujemy nasze zgłoszenie z tym zduplikowanym i zamykamy ze stanem Duplicated 🙂 Analiza ta jest wybitnie ważna, gdyż pomaga w pracy każdego członka Zespołu. Programiści nie muszą w kółko zastanawiać się czy coś już takiego robili, Analitycy nie denerwują się z powtórek, a Testerzy mogą efektywnie testować 🙂

Dzień 20. Dzień na nadrobienie zaległości!

Co dziesiąty dzień w kalendarzu poświęcony jest nadrabianiu zaległości z poprzednich dni 🙂

Dzień 21. Dzień odpoczynku

Dzień na załpanie oddechu.

Dzień 22. Analiza priorytetów

W niektórych projektach za nadawanie priorytetów błędom odpowiedzialny jest tester zgłaszający (w kolejnych dniach przeanalizujemy też inną sytuację, gdy zespół jest odpowiedzialny za nadawanie priorytetów). Z doświadczenia wiem, że jest to jeden z najtrudniejszych etapów tworzenia zgłoszenia. Najczęściej wyróżniamy:

• bloker – to błąd, który blokuje aplikację przed dalszymi testami,
• krytyczny – uniemożliwia nam prawidłowe korzystanie z systemu,
• wysoki /ważny – wpływają na funkcjonalność, ale nadal możemy korzystać z systemu,
• normalny/ średni – nie utrudniają w znacznym stopniu korzystania z systemu
• mało ważny
• trywialny.

Osobiście zawsze zachęcam, aby w razie wątpliwości zawsze pytać Analityków lub Product Ownera!