Testowanie

Kwalifikacje do Testing Cup 2017 – refleksje

Poniższy tekst bazuje na moim zdobytym dzisiaj doświadczeniu.

Jednocześnie informuję, że jedynym celem tekstu jest zwrócenie uwagi na to, jak ważna podczas zakończonych już Kwalifikacji do Testing Cup 2017 była (lub nie była) weryfikacja gotowej aplikacji z jej opisem funkcjonalnym.

Dodam również, że całą ekipę Testing Cup wraz z Radkiem Smilgin na czele darzę ogromnym szacunkiem. Ich otwartość, pomocność i profesjonalizm stoją na najwyższym, wymagającym uznania poziomie. 🙂

Refleksje

Przez blisko 7 lat pracy w zawodzie Testera Oprogramowania zostałem nauczony, że jedną z najważniejszych rzeczy podczas testów aplikacji jest jej weryfikacja zgodności z dokumentacją techniczną/funkcjonalną.

Niestety, odniosłem wrażenie, że tym razem ta dobra praktyka, której stosowanie wymaga się (tu zaryzykuję!) od wszystkich zawodowo pracujących testerów, nie była potrzebna do otrzymania przepustki do zawodów Testing Cup.

Wszystkie zgłoszone błędy były poddawane ocenie: za jeden zgłoszony błąd można było uzyskać od 1 do 10 punktów.

PRZYKŁAD 1

Jeden z zapisów opisu funkcjonalnego testowanej podczas kwalifikacji aplikacji brzmi:

“brak możliwości wklejenia danych do specyficznych pól tekstowych – textarea”

Okazuje się jednak, że jest to nieprawda i ISTNIEJE możliwość wklejana danych do pól tekstowych typu = textarea.

Tak więc, tę niespójnie zrealizowane ogranicznie zgłosiłem jako błąd. Ku mojemu zdziwieniu, Komisja Sędziowska Testing Cup nie wykazała tego błędu w globalnym spisie błędów. Dopiero po opisaniu przeze mnie problemu na Facebooku, Komisja Sędziowska zdecydowała się przeanalizować zgłoszenie i ostatecznie został mi przyznany jedynie jeden punkt, gdy kilka innych zgłoszeń, zdecydowanie mniej rzutujących na aplikację (moim zdaniem!), zostało ocenionych wyżej.

Zgłoszenie poniższego błędu warte było dwa punkty:

“Opis: Błędny log w konsoli przeglądarki podczas drugiego (i kolejnych) generowania danych w trybie dopisywania – “Unable to generate data!”

Tym samym błąd, który w specyficznym przypadku wrzuca do consoli linijkę logu, nie mając żadnego wpływu na funkcjonalność ani użyteczność aplikacji, jest oceniany dwukrotnie wyżej od błędu wynikającego ze źle zaimplementowanej funkcjonalności opisanej w opisie funkcjonalnym aplikacji.

W głowie rodzi się pytanie: czy testowanie oprogramowania pod kątem jego zgodności z dokumentacją aby na pewno jest ważne?

PRZYKŁAD 2

Kolejną rzeczą budzącą moje wątpliwości jest defekt, za którego zgłoszenie było przyznawane aż 10 punktów:

Tytuł: Blokowanie form. na stronach www przez dodatek – 10PKT
Opis: Blokowanie formularzy na zewnętrznych stronach. Formularze przestają działać lub działają
niepoprawnie, np. http://admin.nazwa.pl

Powody moich wątpliwości co do zasadniczości oraz punktacji powyższego błędu:

1. W regulaminie kwalifikacji nie było jasno wyspecyfikowane, czy błędy funkcjonalne, które są zgłaszane podczas kwalifikacji mają być błędami funkcjonalnymi znalezionymi podczas testów funkcjonalnych na poziomie modułowym czy/i błędami funkcjonalnymi znalezonymi podczas testów funkcjonalnych na poziomie systemowym (w tym przypadku dodatkowo, “system” można rozumieć jako przeglądarkę Firefox lub jako system Windows – punktowane było również zgłoszenie z kopiowaniem danych do systemowego schowka).

2. Losowe występowanie tego błędu. W moim przypadku błąd wystąpił na 1 z 5 testowanych przeze mnie miejsc (ponowny brak szczęścia?). Błąd, jak się okazuje, nie występuje przy następujących formularzach logowania do webowych wersji aplikacji: allegro.pl, mbank.pl, logowanie.play.pl, drumcenter.pl. Jedynym miejscem w którym stwierdziłem, że coś jest nie tak (i faktycznie, tam błąd występuje), była strona logowania Facebooka. Niestety dla mnie jednak, zgodnie ze wskazówkami autorów testowanej aplikacji, tj.: “aplikacje oparte na rozwiązaniach Java Script oraz pochodnych mogą uniemożliwić wklejenie danych lub wyświetlenie menu kontekstowego“, uznałem, że Facebook jest wystarczająco dużą “kobyłą” skryptów, w efekcie czego tematu opisywanego błędu nie ciągnąłem dalej

Niestety – ponownie nie udało mi się “wstrzelić” w klucz odpowiedzi stosowany przez Komisję.

PODSUMOWANIE

Ten post jest próbą podniesienia tematu ustalania ważności zgłaszanych błędów (dodam, że na fanpage’u Testing Cup również pojawiły głosy innych użytkowników z tym związane) oraz promowania przez stosowanie na tym znaczącym wydarzeniu testerskim w Polsce, jakim jest Testing Cup, realnych i szeroko stosowanych w świecie testowania praktyk i metodyk testerskich, wraz z maksymalnie zrozumiałym i jasnym, minimalnie wymaganym stopniem ich zastosowania na zbliżającym się wydarzeniu Testing Cup 2017.

Więcej informacji o Testing Cup:

Share this Story
  • Top 10 modułów Xposed

    Jako zwolennik czystego Androida i modyfikowania systemu stricte pod wymagania użytkownika, przedstawiam swój ranking rozszerzeń Xposed, które codziennie ułatwiają mi życie i...
  • Kwalifikacje do Testing Cup 2017 – refleksje

    Poniższy tekst bazuje na moim zdobytym dzisiaj doświadczeniu. Jednocześnie informuję, że jedynym celem tekstu jest zwrócenie uwagi na to, jak ważna...
  • NIK Collection – darmowe HDR od Google’a

    Tak naprawdę to nie tylko HDR – NIK Collection zawiera w sobie kilka pluginów (kombajnów) do obróbki zdjęć w Photoshopie. Przykład...
Wczytaj więcej postów

Komentarze

Sprawdź także

Top 10 modułów Xposed

Jako zwolennik czystego Androida i modyfikowania systemu stricte pod...

O mnie

Rafał Mianowicz


Nazywam się Rafał Mianowicz i bywam technologiczym geekiem.

Gram na perkusji w Moron, zawodowo testuję oprogramowanie w ITSG, lubię uśmiechać się do ludzi.

Kategorie

Ta strona używa cookies. Korzystając z niej wyrażasz zgodę na ich używanie. O co chodzi?

Moja strona korzysta z ciasteczek (ang. cookies). Jeśli w dalszym ciągu chcesz korzystać z mojej strony, bez zmiany ustawienia plików cookie kliknij przycisk "Akceptuję" poniżej. Będzie to oznaczać Twoją zgodę na używanie ciasteczek. :)

Zamknij