Czyli odpowiadamy na Wasze pytania.
PYTANIE:
Jak bardzo powinniśmy schodzić w szczegóły implementacji lub acceptance criteria funkcjonalności zgłaszając defekty?
Przykłady:
1.Specyfikacja mówi o loginie ale nie precyzuje jego długości. Czy zgłaszając taki defekt nie dostaniemy ujemnych punktów za „defekt, który nie jest realnie defektem”
2.Specyfikacja mówi o haśle, które jest jawnie wyświetlanie (nie wykropkowane) czy zgłaszając sugestie, że hasło powinno być wykropkowane to nie będzie potraktowane jako Invalid Defect (może klient na prawdę chce jawnie wyświetlane hasło?)
3.Specyfikacja zakłada, że użytkownik zgłaszający defekt do systemu powinien wypełnić formularz. W formularzu jest pole tytuł i opis. Z doświadczenia wiemy, że podane pola powinny być uzupełnione ale specyfikacja nie mówi jasno, że pola muszą być walidowane.
Sytuacje gdzie specyfikacja ewidentnie pokazuje złe praktyki. A my nie mając kontaktu z klientem nie możemy określić czy use case opisany w specyfikacji jest rzeczywiście uzasadniony. Nie chcielibyśmy tracić punktów stąd nasze pytanie.
ODPOWIEDŹ:
Specyfikacja jest napisana przez klienta biznesowego, który nie ma pełnej wiedzy informatycznej i zleca wytworzenie produktu specjalistom. W specyfikacji nie ma czytelnych kryteriów akceptacji.
Ad 1. W takim przypadku zostaną przyznane ujemne punkty. Idąc tym tropem można by zgłosić defekt, że nie ma zdefiniowanej dopuszczalnej liczby znaków specjalnych, cyfr, dużych i małych liter.
Ad 2. Nie przewidujemy „sugestii”. Zgłaszane mają być TYLKO defekty specyfikacji. Jeśli klient napisze, że hasło ma być niewykropkowane znaczy to, że takie jest jego wymaganie. Ponieważ nie jest to defekt to pojawiłyby się ujemne punkty.
Ad 3. Możemy bazować na tym co dostaliśmy od klienta – specyfikacja. Trudno robić założenia dla walidacji w systemie nie mając wiedzy o danym systemie, wytwórcy czy też kliencie.
PYTANIE:
Na stronie: http://testingcup.pl/koniec-zapisow-na-zawody-beda-kwalifikacje/ „Odnalazłem następujący komentarz: Defekt w specyfikacji jest problemem powiązanym z tym, że coś jest niejasne.
Możliwe są następujące zdarzenia: – pojedynczy błąd w specyfikacji powoduje pojedynczą niejasność – przygotowujemy jeden raport – grupa błędów przekłada się na jedną niejasność – przygotowujemy jeden raport – pojedynczy błąd powoduje szereg niejasności – przygotowujemy jeden raport z silnym wskazaniem przyczyny źródłowej – grupa błędów przekłada się na szereg niejasności – przygotowujemy raporty osobno dla każdej niejasności Przykład: “Orpogramwanie ma być zgodne z WCAG 2.0′′ – jest podwójną literówką w jednym słowie – jeden raport “Orpogramwanie ma by zgdone z WCAG 2.0′′ – jest niejasnością wynikającą z wielu literówek – jeden raport. Wszędzie gdzie się da próbujemy redukować do jednego raportu. Raport pod tytułem “Literówki” z wypisanymi wszystkimi miejscami z literówkami będzie traktowany jako błędny.” Proszę o potwierdzenie, że w tym konkretnym przypadku słowo raport jest użyte w kontekście pojedynczego błędu (defektu) a nie na poziomi pliku tekstowego który to ma być wysłany(w obecnej formie sugeruje ten zapis konieczność przygotowania wielu plików tekstowych z raportami a to by stało w bezpośredniej sprzeczności z informacjami z e-mail-a otrzymanego po potwierdzeniu rejestracji. Dodatkowo chciałem potwierdzić czy moje rozumienie powyższego przykładu jest poprawne przedstawiając poniżej przykład dotyczący dokumentacji MrBuggy: W dokumencie MrBuggy-wymagania.pdf na stronie 4 paragraf 2: Ekran 2 – Zakładanie konta super administratora w kolumnie Komentarz występuje opis : „W przypadku błędnej walidacji pojawi się informacja o problemie.” Z mojego punktu widzenia dla specyfikacji pól tekstowych powyższy komunikat jest niedoprecyzowany ergo konieczne jest zgłoszenie błędu/błędów. Moje pytanie jest następujące jak ma się moja interpretacja przedstawionego prze mnie problemu do opisu zawartego w komentarzu na początku tego maila. Czy w przypadku przykładu z MrBuggy należy zgłosić 3 niezależne błędy przedstawiające poniższe charakterystyki: – Błąd dotyczący niespecyfikowania komunikatu w przypadku przekroczenia minimalnej/dopuszczalnej wartości pola tekstowego – Błąd dotyczący niespecyfikowania komunikatu w przypadku wpisania niedopuszczalnych znaków – Błąd dotyczący niespecyfikowania komunikatu w przypadku niewypełnienia pola wymaganego – Błąd dotyczący sposobu wyświetlenia komunikatu – czy komunikat pojawia się po naciśnięciu przycisku czy ad-hoc (problem nie związany z MrBuggy ponieważ jest to desktop ale dla web jak najbardziej możliwy do wystąpienia)
Czy też należy zgłosić jeden błąd dotyczący niespecyfikowania komunikatu dla pola wymieniając 3 powyższe charakterystyki? Dodatkowo, jeśli zgłaszamy błąd w kontekście pola to co w przypadku jeśli ten sam błąd (związany z niespecyfikowaniem komunikatu) występuje na innych polach? Czy potraktować to zbiorczo wymieniając listę pól oraz charakterystyki komunikatu dla każdego z pól czy może podejść do tematu w jeszcze inny sposób?
ODPOWIEDŹ:
Potwierdzamy, że niefortunnie użyto słowa „raport”. Chodzi o „pojedyncze zgłoszenie defektu”.
Podany przykład pokazuje jeden błąd ponieważ dotyczy jednego nieczytelnego zapisu.
Jeśli zostaną zgłoszone osobne defekty zostaną one potraktowane jako jeden, a punkty zostaną przyznane raz.
Nie zakładamy, że klient definiujący specyfikację ma wiedzę informatyczną i niekoniecznie wie jak może wyglądać walidacja. Jeśli nie ma w tym obszarze wytycznych wykonawca aplikacji może to wykonać zgodnie ze swoją praktyką.
Wychodzimy z założenia, że jeśli czytając w specyfikacji opis dla funkcji tester nie będzie wiedział jak ją zweryfikować to wskazuje to na potencjalny defekt specyfikacji.
PYTANIE:
Skoro specyfikacja jest rozsyłana w PDF to raport nie może być w jakimś znośnym formacie (czyt. PDF)?
ODPOWIEDŹ:
Raport może zostać przesłany jedynie w pliku TXT.
Nie ma potrzeby formatowania tekstu, robienia zrzutów ekranu więc nie ma też potrzeby stosowania specjalnych formatów pliku.
Dodatkowo format ma być edytowalny tak by zanonimizować go przed oceną.
PYTANIE:
„Specyfikacja zostanie przesłana mailem z adresu […]. Dokumentacja będzie dostarczona w pliku .PDF.
Raport powinien być odesłany na ten sam adres.”
Dlaczego mailem? Mail ma to do siebie, że mogą być problemy z jego otrzymaniem, filtry antyspamowe (zwłaszcza firmowe) mogą go odrzucić. W szczególności nie wszyscy dostaną tego maila jednocześnie, co spowoduje nierówne szanse w kwalifikacjach. Czy nie moglibyście umieścić dodatkowo tej specyfikacji na stronie www? Tak, aby o godzinie 18, był gotowy do pobrania.
ODPOWIEDŹ:
Mail jest głównym kanałem dotarcia. Rozesłanie w modelu jeden do wielu daje większe szanse na dostarczenie pliku w tym samym czasie. W przypadku połączenia wielu do jednego istnieje ryzyko przeciążenia serwera, na którym znajduje się plik.
Przetestowaliśmy oba rozwiązania i okazało się, że pierwsze podejście było stabilniejsze, co nie zmienia faktu, że plik będzie dostępny do pobrania z Google Drive.
PYTANIE:
Czy należy wypełnić wszystkie pola w raporcie?
ODPOWIEDŹ:
TAK.
Brak uzupełnienia nawet pojedynczego pola będzie skutkował przyznaniem zerowej liczby punktów.
PYTANIE:
Proponuję uruchomić na czas zawodów ogólnodostępny zegar, do którego każdy z nas będzie miał dostęp. Wówczas zminimalizujemy ryzyko pomyłek przy wysyłaniu maila “po czasie” ze względu na zegary systemowe.
ODPOWIEDŹ:
Prosimy aby odnosić się do czasu, który wskazuje zegar dostępny tutaj: http://time.is/Poland
Uwaga: Dziś wszyscy zawodnicy otrzymają od nas ponownie wiadomość dotyczącą jutrzejszych kwalifikacji z przypomnieniem wszystkich ważnych informacji.