Czas na kolejne podsumowania po zawodach TestingCup 2016.
Otrzymaliśmy od Was sporo wiadomości z pytaniami o to jak Wam poszło, co się udało i jak możecie poprawić swój wynik w kolejnych Mistrzostwach. Wiemy jak ważne jest otrzymanie informacji zwrotnej dlatego też Komisja przygotowała podsumowanie swoich prac. Mamy nadzieję, że pomoże Wam ono odpowiedzieć na przynajmniej część nurtujących Was pytań oraz rozwieje wątpliwości.
Chcielibyśmy też spotkać się z Wami online. Spotkanie „Zadaj pytanie Komisji Sędziowskiej” odbędzie się w najbliższą środę o godz. 12:00.
OD KOMISJI
Czytanie zgłoszeń i raportów z prac zawodników TestingCup to z jednej strony świetne testerskie doświadczenie, a z drugiej bardzo niewdzięczna praca. Czasami zgłoszenia są genialne, a ścieżki reprodukcji oczywiste, choć trudne do zrealizowania. Dodanie komuś 5 punktów jest pozytywną stroną tej pracy. Czasami jednak zgłoszenia są niezgodne z założeniami konkursu, gdzie widać testerski błąd i trzeba przyznać minus pięć punktów.
Przyszło nam przeczytać ponad 1000 zgłoszeń i ponad 140 raportów. Większość z nich była przedmiotem dyskusji, a ta przeradzała się w próbę znalezienia wspólnej interpretacji dla defektu.
W tym roku wyjątkowo niewiele było duplikatów (trafił się duplikat dla „to nie jest defekt”). Pokazuje to, że zespoły były nieźle zorganizowane, a raportowanie jedynie przez Kapitana pomagało wychwycić te same lub bardzo podobne zgłoszenia. Niezbyt dużo było też zgłoszeń, które były niezrozumiałe.
Próbowaliśmy wszystkimi siłami identyfikować co autor(ka) miał(a) na myśli, jednak dla części zgłoszeń musieliśmy się poddać. Największym zaskoczeniem (na początku) była olbrzymia ilość zgłoszeń, które wpadały do kategorii „to nie jest defekt”. Było ich tak wiele, że zastanawialiśmy się, czy zadanie nie było zbyt trudne. Postanowiliśmy zmienić interpretację dla części defektów na kategorię „tester nie musi wiedzieć, że to nie jest defekt”. Takie zgłoszenie wróciłoby w projekcie do testera z komunikatem, że „to nie jest defekt”, ale i tak wycofaliśmy się z przyznawania za nie ujemnych punktów.
W niektórych przypadkach musieliśmy ocenić prace negatywnie. Wszystkie ujemne punkty były długo dyskutowane w gronie komisji.
W pracy testera jest kluczowe aby odróżniać defekty od sugestii więc zgłoszenia (oznaczone jako „defekt”) typu „Chciałbym funkcję…” albo „Proszę dodać możliwość…” były odrzucane.
Część zgłoszeń odnosiło się do rzeczy wyłączonych z testowania i za nie przyznawaliśmy ujemne punkty. Przykłady:
. „Dane w tabeli się nie sortują”. Gdzie wśród rzeczy wyłączonych z testowania znalazł się zapis: „Sortowanie danych w poszczególnych zakładkach.”
. „Aplikacja nie jest użyteczna w obszarze” Gdzie wśród rzeczy wyłączonych z testowania znalazł się zapis: „Cechy użyteczności, bezpieczeństwa i wydajnościowe aplikacji”
Były też zgłoszenia, które dotyczyły niedostępnych funkcji jak „Na ekranie startowym uruchamiam analizę strony testingcup.pl…”.
Część błędów wynikała z nieprzygotowania lub niezrozumienia reguł analizy. Odrzucaliśmy zgłoszenia odnośnie braku generowania się struktury mapy w Wersji 3 analizy ponieważ konfiguracja analizy była ustawiona na „nie wyświetlaj mapy”. Byli też zawodnicy, którzy nie zrozumieli sposobu przygotowania wersji analiz. Tutaj pojawiały się “nie-defekty” mówiące o złej dacie i godzinie analizy oraz defekty typu, że wszystkie analizy są nieukończone. Dokumentacja mówiła iż były przygotowane wcześniej dlatego te zgłoszenia nie były traktowane jako defekty.
Większość rzeczy staraliśmy się interpretować na korzyść zawodników i jeśli nie był to oczywisty “nie defekt” określaliśmy je jako „literówka”. „Literówka” na koniec stała się największym zbiorem zgłoszeń. Wynika to z faktu, że była to jedyna opcja na przyznanie zera punktów. Nie zmienia to faktu, że klasyczna „literówka” pojawiała się również w zgłoszeniach choć zapowiadaliśmy, że nie da się za to zdobyć punktów.
Sugestii było dużo, ale niewystarczająco. Jedna z reguł mówiła, że za sugestię przyznajemy 1pkt, a wielu zawodników nie wykorzystało tego miejsca do łatwego zdobycia punktów. Co prawda dawały one maksymalnie trzy punkty, ale gdyby przykładowo druga drużyna w zawodach zaraportowała dwie sugestie więcej mieliby Mistrzostwo.
Znalezionych zostało trochę nowych defektów, których nie znaliśmy przez zawodami. Było ich jednak mniej niż w ubiegłych latach. Nie za wszystkie przyznawaliśmy punkty, co nie zmienia faktu, że dobrze się znów przekonać, że ile by się nie testowało to i tak nie znajdziemy wszystkich defektów.
Naszą ekstra funkcję znalazło procentowo niewiele osób, ale ci, którzy ją znaleźli mieli szanse na dodatkowe punkty. Mr Buggy The Game mógł ich dać nawet 5. Jednej drużynie udało się znaleźć zupełnie nowy defekt w grze, mimo to, że graliśmy w nią godzinami.
Tak jak prace pierwszej rundy były miejscami rozczarowujące tak raporty w drugiej rundzie były na dobrym poziomie. Widać było, że część raportów było napisanych wcześniej i jedynie uzupełnione o dane z samego testowania. I bardzo dobrze. Przecież dobre wzorce staramy się powielać.
W podsumowaniu. Mamy przekonanie, że zadanie w tym roku było bardzo trudne i zyskali Ci, którzy się do zawodów przygotowali. A dobre przygotowanie było świetnie widać w zaraportowanych defektach i w raportach. Przecież w dowolnych zawodach miejsce jakie się zajmuje silnie zależy od treningów i dobrze przygotowanego sprzętu.
Najważniejsze miejsca do poprawy dotyczą braku umiejętności czytania ze zrozumieniem i marnowania czasu na rzeczy, których nie należało testować, a na końcu raportować. Zrzucamy to na stres jaki towarzyszył wielu osobom.
Część osób nie wykorzystało czasu jaki został przeznaczony na czytanie dokumentacji. Wśród zawodników było widać takich, którzy po jednokrotnym, pobieżnym przeglądnięciu dokumentu czekali na loginy i hasła. To się później zemściło.
Na koniec dziękujemy za Wasz wysiłek uczestnictwa w TestingCup. Dostarczyliście nam wielu doświadczeń i mamy przekonanie, że nauczyliśmy się czegoś nowego o naszych zawodach i znaleźliśmy miejsca do usprawnień.
Komisja Sędziowska TestingCup w składzie:
Natalia Krawczyk – była uczestniczka, która zobaczyła jak konkurs wygląda z drugiej strony i przyjęła nową perspektywę zawodów – „ciągle gorzej niż ZSPM”
Dariusz Olszewski – miłośnik dobrych zgłoszeń i dobrych raportów – „chciałbym dać punkt, ale nie mogę”
Maciej Zaborowski – zawsze chętny do polemiki na temat defektów – „zgadzam się z Tobą, ale…”
Michał Zacharuk – odpowiedzialny za reprodukcję nowych zgłoszeń – „jak oni to zrobili?!”
Grzegorz Libor – współtwórca aplikacji, analityk i tester w jednym, reprezentujący i biznes i programistów – „to tak działa”
Łukasz Gałuszka – ojciec chrzestny TestingCup, najostrzejszy, ale jednocześnie najsprawiedliwszy – „dajemy wszystkim równo po… zero punktów”
Radek Smilgin – pomysłodawca – „sprawdzać szybciej!”
*) opisy członków komisji z często pojawiającymi się wypowiedziami
P.S. Chcielibyśmy z całą stanowczością podkreślić, że wszystkie prace zostały rzetelnie ocenione. Przez wielokrotne sprawdzanie zgłoszeń oraz definiowanie i omawianie listy kontrolnej dla raportów minimalizujemy prawdopodobieństwo ryzyko popełnienia błędu przed ogłoszeniem wyników. Po zakończeniu Mistrzostw Wasze prace są ponownie czytane w celu przygotowania podsumowania i zbudowania materiału edukacyjnego, który zostanie wkrótce udostępniony. Warto podkreślić, że analiza ta nie wykazała żadnej pomyłki w ocenach przyznanych przez Komisję Sędziowską.
