Napis Znalazłeś błąd krytyczny? Czy na pewno jest on krytyczny?
Znalazłeś błąd krytyczny? Czy na pewno jest on krytyczny?

Cześć! Czasami tak jest, że wymyślę sobie scenariusz do przetestowania. Dobiorę dane tak, by sprawdzały wartości brzegowe. Klikam przycisk i … no właśnie JEST. Błąd. Nie byle jaki błąd, ale duży babol. Ekscytacja, zadowolenie z siebie (bo wymyśliłem i jest) razem wzięte mogą sprawić, że źle ocenię ważność błędu. Dzieje się tak, ponieważ w takiej chwili zwyczajnie jaram się dobrze wykonaną robotą i nie do końca patrzę na kontekst znalezionego błędu. Na szczęście wraz z upływem lat, nabyte doświadczenie sprawia, że ważność błędów oceniam znacznie lepiej :).

Dzisiaj postaram się odpowiedzieć na pytanie, czy faktycznie wszystko, co wydaje się nawet bardzo poważnym problemem w testowanej aplikacji, rzeczywiście takim jest.

Co sprawia, że określamy błąd jako krytyczny?

Z reguły błąd krytyczny jest wówczas, gdy po jego wystąpieniu aplikacja przestaje działać. Jednak nie każdy crash systemu powinien być zgłaszany jako krytyczny. Na to, czy takim jest wpłynąć może to, gdzie został znaleziony i jak wpływa na pracę użytkowników.

Na to, czy błąd jest krytyczny, wpływa również to, jak ważny jest on dla klienta, jak wpływa na działanie biznesowe aplikacji. Stąd nie musi to być zawsze crash systemu.

Zanim zgłosisz błąd krytyczny, pomyśl o tym, jaki jest jego kontekst.

Co mam na myśli, mówiąc kontekst? Wszystko to, co otacza błąd. W jakiej sytuacji on występuje? Jakie jest prawdopodobieństwo, że użytkownik aplikacji go znajdzie? Jak ważny do poprawienia jest ten błąd z punktu widzenia klienta?

Dlaczego kontekst błędu jest tak istotny?

Pierwszym powodem jest to, że jeśli prawie na pewno wiadomo, że użytkownik aplikacji nie znajdzie błędu i nie odczuje jego skutków, to nie opłaca się go poprawiać. Tak dobrze przeczytałeś. Koszt naprawy błędu wynika z cyklu jego życia defektu, wchodzą w niego takie czynności jak:

  • Weryfikacja programisty, czy błąd występuje.
  • Poprawienie błędu.
  • Retest błędu po stronie testera i możliwe sprawdzenie, czy naprawienie błędu nie zepsuło czegoś w funkcjonalności.

Kolejnym powodem, dlaczego kontekst jest ważny, może być fakt, że w obecnych czasach jedna i ta sama aplikacja może być dostępna na wielu urządzeniach i różnych przeglądarkach.

To, że robimy aplikację dla użytkowników, którzy później z niej korzystają i zapewne płacą za jej używanie w ten czy inny sposób – mam nadzieję, jest jasne i nie trzeba nikogo uświadamiać, że nie ma nic za darmo.

W takim razie nie powinno Cię zdziwić, że często aplikacje mają odpowiadać na potrzeby konsumenta. Możliwe, że pamiętasz, jak robiłem badania rynku pod kątem wydawanego produktu w moim sklepie. To samo na większą skalę dzieje się przed podjęciem decyzji o stworzeniu aplikacji, którą później firmy z branży IT obsługują i starają się stworzyć.

No właśnie te firmy po dogłębnym researchu wiedzą, że nie jesteśmy w stanie zrobić tak, żeby aplikacja była idealna dla każdego. Dlatego też przeważnie a wręcz powiedziałbym, że zawsze mamy informację początkową odnośnie do wspieranych urządzeń, przeglądarek itp. itd.

Jeżeli znajdę błąd, który odnosi się tylko i wyłącznie do platformy, niewspieranej przez aplikację no to ważność dramatycznie leci w dół. Żeby nie powiedzieć, że wręcz potrafi ona spaść do 0 – oczywiście dobry poszukiwacz baboli powinien dobrze zweryfikować czy na pewno nie występuje na wspieranych urządzeniach ?.

Przykłady błędów krytycznych na pierwszy rzut oka, a nie poprawionych ze względu na kontekst ich wystąpienia:

Jedna z gier hokejowych. Gracz, który zebrał wystarczającą ilość pieniędzy, mógł kupić dowolnego bramkarza dostępnego w grze. Jeśli powtarzał ta czynność wiele razy, to mógł doprowadzić do sytuacji, w której nie było w grze dostępnych bramkarzy. Błąd nie został poprawiony.

Gra symulująca amerykański football. Gra mogła zawiesić się, jeśli została uruchomiona w odpowiednim trybie i rozgrywki zostały ustalone na pewną konkretną sobotę. Błąd został poprawiony na konsolę PlayStation i Xbox-a. Błąd nadal występuje na konsoli GameCube, nie został poprawiony, ponieważ uznano, że nikt na niej w tę grę nie będzie grać.

To tylko dwa przykłady błędów można by myśleć krytycznych, które nie zostały poprawione. Polecam obejrzenie nagrania na YouTube, w którym omawiane są błędy krytyczne zignorowane przez twórców, oraz takie, które nie zostały znalezione, a powinny być.

No i właśnie to jest dobry przykład tego, że bug, który wydaje się masakryczny, może być pomijalny.

Z drugiej strony. Czy wiesz, że literówka może być błędem krytycznym, blokującym wydanie aplikacji? No to zapewne właśnie Cię uświadomiłem, że tak może być 😉

Wystarczy popełnić tę literówkę w nazwie firmy zamawiającej aplikację.

Kliknij by zobaczyć szczegóły dotyczące e-booka

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Ten post ma 2 komentarzy

  1. Klaudia

    Świetny artykuł uświadamiający jak ważna jest dobra ocena buga 🙂
    A co do literówek, to znalazłam dwie w artykule, co prawda nie krytyczne, ale jednak. W przykładzie gry hokejowej słowo ‚bramkaż’ powinno być zastąpione słowem ,bramkarz’ tak samo jak ‚wielerazy’ powinno być zastąpione słowem ‚wiele razy’.
    Piszesz mega kontent i tak trzymaj, czekam z niecierpliwością na kolejny artykuł 🙂
    Pozdrawiam serdecznie

    1. Waldemar Szafraniec

      Dziękuję za miłe słowa 🙂
      Odnośnie literówek to już niestety jest efekt uboczny tego co robię, przeważnie tworzę 3-4 artykuły i wrzucam je potem na przestrzeni miesiąca. Taka ilość tekstu zawiera literówki, które przeważnie po zgłoszeniach poprawiam 🙂
      Także już zabieram się za poprawę literówek 🙂
      Pozdrawiam serdecznie

Dodaj komentarz