Prezentacja, która powstała na potrzeby webinaru "Jak poprawnie zgłaszać błędy?".
Podczas webinaru omówione zostały poniższe zagadnienia:
- rodzaje incydentów,
- cykl życia incydentu,
- odbiorcy zgłoszeń,
- zawartość raportu,
- priorytetyzacja zgłoszeń,
- narzędzia pomocne przy dokumentowaniu zgłoszeń
Prezentacja z webinaru dostępna jest jako kolejny slajd po wyświetlonym filmie.
10. • Odrzucenie przez programistę
• Niezrozumienie
• Prośba o dodatkowe informacje (strata czasu..)
• Długie dochodzenie gdzie jest faktycznie błąd
Nieczytelne zgłoszenie =
11. “The point of writing problem
report (bug report) is to get
bugs fixed”
Cem Kaner
12. • datę zgłoszenia, zgłaszającą organizację oraz autora
• wyniki oczekiwane oraz rzeczywiste
• wskazanie na element testowy (element konfiguracji) oraz
na środowisko
• proces cyklu życia oprogramowania lub systemu w którym
incydent został zaobserwowany
• opis incydentu, w celu umożliwienia odtworzenia i
rozwiązania, włącznie z logami, zrzutami baz danych oraz
zrzutami ekranu
• obszar lub stopień wpływu na interesy interesariuszy
• stopień wpływu na system
• pilność, priorytet naprawy
Zawartość raportu błędu wg sylabusa ISTQB
13. • status incydentu (np. otwarty, odłożony, duplikat,
oczekujący na naprawę, naprawiony i oczekujący na
retest, zamknięty)
• podsumowania, rekomendacje oraz zgody
• zagadnienia globalne, takie jak inne obszary, na które
mogą mieć wpływ zmiany związane z incydentem
• historia zmian, np. ciąg czynności podjętych przez
członków zespołu w celu wyizolowania incydentu, jego
naprawy oraz potwierdzenia tej naprawy
• referencje, włączając w to identyfikator specyfikacji
przypadku testowego, który wykrył problem
Zawartość raportu błędu wg sylabusa ISTQB cd.
14. Zawartość raportu błędu
Tytuł (Title/Summary)
Opis sytuacji (kroki
reprodukcji)
Opis
środowiska
testowego
Typ zgłoszenia
(bug, new
feature, task,
improvement)
Priorytet
Oczekiwany /
aktualny
rezultat
Załączniki
(screenshoty,
filmy, logi,
dane testowe,
etc.)
Obszar/komponent,
waga,
reprodukowalność,
etc…
15. TYTUŁ
Nie działa edycja danych użytkownika
Podczas modyfikacji danych użytkownika nie zapisuje się adres
do korespondencji
16. TYTUŁ
Nie działa edycja danych użytkownika
Podczas modyfikacji danych użytkownika nie zapisuje się adres
do korespondencji
[Profil] [Firefox] Podczas modyfikacji danych użytkownika nie
zapisuje się adres do korespondencji
17. TYTUŁ
OK NIE OK
Krótki i jednoznaczny Długi i niejednoznaczny
Wskazuje na konkretny problem Zbyt abstrakcyjny
Pokazuje wagę problemu Ważność trudna do odszyfrowania
Zrozumiały „dla każdego” „Nie wiadomo o co chodzi”
Bezstronny Emocjonalny
18. KROKI REPRODUKCJI
Jak chcę zapisać zmiany to nic się nie dzieje
1. Wejdź na stronę główną aplikacji http://www.aplikacja.pl/
2. Zaloguj się na konto użytkownika
3. Idź do profilu użytkownika http://www.aplikacja.pl/profile
4. Zmień dane w adresie do korespondencji
5. Zapisz zmiany klikając w przycisk „Zapisz”
19. KROKI REPRODUKCJI
Jak zapisuję zmiany to nic się nie dzieje
1. Wejdź na stronę główną aplikacji http://www.aplikacja.pl/
2. Zaloguj się na konto użytkownika
3. Idź do profilu użytkownika http://www.aplikacja.pl/profile
4. Zmień dane w adresie do korespondencji
5. Zapisz zmiany klikając w przycisk „Zapisz”
21. KROKI REPRODUKCJI
1. Wejdź na http://www.aplikacja.pl/
2. Zaloguj się na konto użytkownika
3. Idź do {Moje konto}
4. Idź to Moje dane > Dane kontaktowe > Adres
korespondencyjny
5. Zmień dane w polach <Ulica> i <Miasto>
6. Kliknij [Zapisz]
23. OCZEKIWANY I AKTUALNY
REZULTAT
Aktualny rezultat:
Adres korespondencyjny nie został zapisany poprawnie –
dane pozostały nie zmienione
Oczekiwany rezultat:
Adres korespondencyjny zostały poprawnie zapisane
Reprodukowalność:
50%
24. ŚRODOWISKO TESTOWE
• System operacyjny (np. Windows 8.1 64-bit, Android 5.0.1)
• Hardware / urządzenie (np. procesor Intel Core i5 / Huawei P8)
• Wersja przeglądarki (np. Chrome 50.0.25661.102 m)
• Rozdzielczość ekranu
• Prędkość łącza internetowego (np. ADSL 10MB, LTE etc.)
• …
27. Priorytetyzacja zgłoszeń
Blocker
•Aplikacja nie uruchamia się, występują częste crashe, nie działają podstawowe funkcjonalności, nie
ma możliwości testowania aplikacji
•Błąd powinien być naprawiony natychmiastowo
Critical
•Nie działają krytyczne (biznesowo) funkcjonalności, ale jest możliwość testowania innych
funkcjonalności
•Błąd powinien być naprawiony asap
High
•Nie działają kluczowe funkcjonalności, ale istnieje możliwość obejścia; błąd pojawia się sporadycznie
(np. aplikacja się zawiesza raz na jakiś czas), istnieje możliwość testowania kluczowych
funkcjonalności
•Błąd powinien być naprawiony zaraz po blockerach i criticalach
Medium
•Brakuje funkcjonalności (nie kluczowej), nie działa, ale jest workaround. Błąd nie ma większego
wpływu na ogólne działanie aplikacji
•Błąd może być naprawiony po poprawce ważniejszych błędów
Lowest
•Błąd „kosmetyczny”, literówki, niezgodność w UI (ale funkcjonalność jest OK)
44. • Błędy zgłaszamy po to, aby były NAPRAWIONE
• Dlatego muszą być opisywane ZROZUMIALE
• Zgłoszenie zostanie lepiej zrozumiane i szybciej
naprawione, jeżeli dołączymy DOWODY
• Badając jakość czyjejś pracy dbajmy też o
JAKOŚĆ SWOJEJ PRACY
Podsumowując