Najczęściej popełniane błędy przez testerów

1. Najczęściej popełniane błędy przez testerów

2. Brak dociekliwości i dokładności • Błędy: • Błedne założenie ze testowanie powinno dotyczyć tylko tego co jest napisane w specyfikacji: testowanie od – do; sprawdzanie tylko pozytywnych scenariuszy; • Rada dla testera: • bądź dokładny w tym, co robisz – zadaniem testera jest sprawdzić zarówno, czy aplikacja działa prawidłowo, jeśli jest używana zgodnie z przeznaczeniem, jak i co dzieje się, gdy operator zaczyna wykonywać niedozwolone czy nieprzewidziane operacje; • pamiętaj, że osoba projektująca system również może się mylić – nie przyjmuj wszystkiego, co zapisane na wiarę. Bardzo często dokumentacja zawiera błędy, luki i niespójności, które – jeśli pozostawione bez korekty – mogą negatywnie wpłynąć na jakość prac programistycznych i testowania. Zadaniem testera jest sprawdzić również i dokumentację – szczególnie reguły biznesowe i poprawność przepływu procesu; • jeśli nie jesteś pewien, jak ma funkcjonować dany moduł – pytaj i uzyskuj odpowiedzi. Nie pomijaj testowania pewnych obszarów tylko dlatego, że nie rozumiesz ich działania; • nie rób założeń – w szczególności nie zakładaj, że coś działa, ponieważ zwykle działało lub powinno działać. Tester może stwierdzić, iż aplikacja czy jej moduł działa wtedy, kiedy sam to sprawdzi i wyniki testów to potwierdzą; • jeśli uważasz, że odkryłeś błąd lub aplikacja działa nieprawidłowo pod względem użyteczności lub biznesu, a implementacja jest zgodna ze specyfikacją analityczną – zgłoś swoją uwagę analitykom. Ewentualne poprawienie problemu na wczesnym etapie testów jest łatwiejsze i tańsze, niż później.

3. Wykonywanie testów bez zrozumienia działania aplikacji Błędy: • uboga lub niedokładna czy niepełna dokumentacja utrudnia pracę testera; tester domyśla się często jak powinna wyglądać aplikacja i interpretuje funkcjonalność wg własnego uznania, rozumienia • często tester nie potrafi wyczuć jak powinna działać aplikacja i po co ona w ogóle jest - wtedy przydaje się wiedza biznesowa z danego obszaru Rada dla testera: • planując i przygotowując przypadki i scenariusze testowe, opieraj się na udokumentowanej specyfikacji (jeśli takowa istnieje) lub wymaganiach użytkownika; • opisuj błąd - czyli niezgodność z wymaganiami. Powołuj się na konkretne wymaganie czy fragment specyfikacji. Do opisu błędu dołączaj referencję (link, cytat, odniesienie do dokumentacji) do odpowiedniego wymagania; • programista nie jest analitykiem – nie oczekuj od niego decydowania o rozwiązaniu problemu związanego z błędem w specyfikacji. W przypadku jakichkolwiek wątpliwości co do oczekiwanego działania funkcjonalności, konsultuj się w pierwszej kolejności z analitykiem i wyjaśnij kwestię przed zgłoszeniem problemu programiście; • w raporcie problemu używaj sformułowań: powinno działać, jak opisane w dokumentacji <tytuł>na stronie <strona> itp. Pozwoli to również szybciej zidentyfikować źródło problemu, w przypadku, gdy dokumentacja, na której się opierasz, zawiera błędy; • jeśli nie wiesz, jak powinna działać dana funkcja - pytaj. Zadaniem analityka jest nie tylko stworzyć dokumentację systemu, ale i udzielić wszelkich niezbędnych wyjaśnień co do celów i funkcjonowania poszczególnych modułów.

4. Odkładanie zgłaszania błędów na później Rada dla testera: • zaplanuj swoją pracę tak, byś mógł rozpocząć zgłaszanie błędów jak najwcześniej. W pierwszej kolejności wykonuje się testy dymne, które sprawdzają, czy aplikacja jest wystarczająco stabilna i można przeprowadzać regularne testy. Następnie należy wykonać testy weryfikujące wdrożone poprawki i testy regresji. Dopiero po tym przystępuje się do regularnych testów; • zgłaszaj błąd zaraz po jego odkryciu i upewnieniu się, że jest on odtwarzalny. Pozwoli to opisać problem wystarczająco dokładnie, ponieważ błąd i procedura jego reprodukcji będą świeże; • jeśliz jakiegoś powodu nie jesteś w stanie stwierdzić, czy znaleziony problem jest rzeczywiście błędem, zanotuj dokładną procedurę jego odtworzenia i warunki początkowe oraz opis wyników– pomoże to poprawnie napisać zgłoszenie, kiedy uzyskasz potwierdzenie (od analityków, zespołu technicznego, klienta), iż masz do czynienia z niezgodnością. • Błędy: • niektórzy testerzy najpierw testują i zapisują na kartkach a potem wpisują błędy; w tym czasie cały zespół developerski jest bezczynny

5. Zgłaszanie błędu przed upewnieniem się ze to jest rzeczywiście błąd Błędy: • Jeden z najbardziej irytujacychnawyków testerów zgłaszanie zmian jako błędy Rada dla testera: • bądź dokładny w tym, co robisz – zadaniem testera jest sprawdzić zarówno, czy aplikacja działa prawidłowo, jeśli jest używana zgodnie z przeznaczeniem, jak i co dzieje się, gdy operator zaczyna wykonywać niedozwolone czy nieprzewidziane operacje; • pamiętaj, że osoba projektująca system również może się mylić – nie przyjmuj wszystkiego, co zapisane na wiarę. Bardzo często dokumentacja zawiera błędy, luki i niespójności, które – jeśli pozostawione bez korekty – mogą negatywnie wpłynąć na jakość prac programistycznych i testowania. Zadaniem testera jest sprawdzić również i dokumentację – szczególnie reguły biznesowe i poprawność przepływu procesu; • jeśli nie jesteś pewien, jak ma funkcjonować dany moduł – pytaj i uzyskuj odpowiedzi. Nie pomijaj testowania pewnych obszarów tylko dlatego, że nie rozumiesz ich działania; • nie rób założeń – w szczególności nie zakładaj, że coś działa, ponieważ zwykle działało lub powinno działać. Tester może stwierdzić, iż aplikacja czy jej moduł działa wtedy, kiedy sam to sprawdzi i wyniki testów to potwierdzą; • jeśli uważasz, że odkryłeś błąd lub aplikacja działa nieprawidłowo pod względem użyteczności lub biznesu, a implementacja jest zgodna ze specyfikacją analityczną – zgłoś swoją uwagę analitykom. Ewentualne poprawienie problemu na wczesnym etapie testów jest łatwiejsze i tańsze, niż później.

6. Interpretacja specyfikacji lub wyników testów wg własnego uznania • Błędy: • Tester interpretuje specyfikacje wg własnego uznania; testerzy próbują ulepszać aplikację – w czasie przeglądu dokumentacji ma to sens jednak w czasie gdy analiza jest zaakceptowana wprowadza to zamieszanie • Czasami testerzy na swój sposób interpretują wynik testu

7. Zły opis błędów Rada dla testera: • Zgłaszając błąd zawsze podawaj: • Tytuł, krótki opis umożliwiający szybką lokalizację problemu i jego skalę. • Warunki początkowe – np. dane operatora (uprawnienia itp), stan systemu konieczny do odtworzenia błędu (np. w systemie musi istnieć określony klient, klient musi mieć odpowiednią ilość środków na koncie bankowym). • Procedurę odtworzenia – krok po kroku czynności wykonane w celu uzyskania błędu. Wskazane jest również podawanie danych testowych – ponieważ niektóre defekty występują tylko w przypadku użycia określonych danych. • Oczekiwany wynik – co system powinien wykonać po zrealizowaniu powyższej procedury wg specyfikacji? • Rzeczywisty wynik – co system wykonał i dlaczego nie jest to poprawne (odniesienie do dokumentacji, fragment specyfikacji itp.)? • Zrzut ekranu – umożliwia programiście szybkie zorientowanie się, gdzie występuje problem i na czym polega. W bardziej skomplikowanych przypadkach wskazane jest nawet dodawania zrzutów dla każdego kroku procedury odtwarzania problemu. • Priorytet (lub krytyczność) – priorytet powinien być określany zgodnie z ustalonymi zasadami oraz kryteriami tak, aby dawał rzetelny obraz skali problemu. Często testerzy wykazują tendencję do zawyżania priorytetów (myśląc, że tym sposobem szybciej otrzymają poprawki do błędów) – jednak nie powinno to mieć miejsca – gdyż planowanie poprawek odbywa się na podstawie priorytetów problemów, a zbyt duża liczba wysokich priorytetów wprowadza chaos organizacyjny i daje nieprawdziwy obraz kondycji aplikacji. • Wersja systemu – umożliwia odtworzenie i naprawienie błędu w odpowiedniej wersji aplikacji. • Dane osoby zgłaszającej – w przypadku wątpliwości pozwala na skontaktowanie się ze zgłaszającym celem wspólnego odtworzenia błędu lub zasięgnięcia dodatkowych informacji. • Osoba zgłaszająca powinna też zawsze sprawdzić swój błąd po naprawieniu przez programistę • Błędy: • Buttondoesn’twork – opis błedu • Najczestszebłedy w opisach: • Zła nazwa która jest myląca • Brak opisu (kroki) • Brak wyjaśnienia jaki jest problem • Niewłaściwe nadawanie priorytetów • Brak określenia wersji systemu

8. Niewłaściwe zadania postawione przed testami i brak priorytetów • Błędy: • Brak testów dla: • niepoprawnych danych wejściowych (brak wymaganych informacji, niewłaściwy format danych – np. wartość stringw polu numerycznym; • przerwań standardowego przebiegu procesu (np. wywołanie awarii w trakcie wykonywania operacji, anulowanie transakcji); • operacji na bazie danych – np. sprawdzenie, czy zmiana dokonana w jednym rekordzie • ma wpływ na inne rekordy; czy dodanie rekordu nie usuwa przypadkiem • innego itp.; • podobnych lub wzajemnie zależnych operacji wykonywanych równolegle przez operatorów systemu, np. jednoczesne edytowanie tych samych danych przez różne osoby; • prób używania urządzeń niekompatybilnych z systemem (np. innych modeli drukarek niż zalecane) lub wywoływania sztucznych awarii podczas używania urządzeń. Rady dla testera: • zaplanuj testy w taki sposób, aby najbardziej krytyczne i ważne dla poprawnego funkcjonowania aplikacji scenariusze i przypadki testowe były wykonane w pierwszej kolejności. Testowanie Look & feel, udoskonalanie aplikacji i aspekty kosmetyczne mogą zaczekać, aż zrealizujesz krytyczne scenariusze. Aplikacja doskonała pod względem wyglądu nie spełni swojej roli, jeśli nie umożliwi wykonania podstawowych procesów biznesowych. Pamiętaj, że im więcej czasu dasz programiście na naprawienie poważnego błędu, tym lepiej będzie on mógł to zrobić i tym więcej czasu będzie miał na testy deweloperskie; • ścieżki kluczowe powinny sprawdzać, czy podstawowe funkcje systemu działają. Przykładowo – w systemie zarządzania danymi osób kluczowymi funkcjami będzie możliwość dodania nowej osoby, edycji danych osób już istniejących w systemie, czy też zarządzanie zależnościami; • weryfikacja ścieżek krytycznych powinna odbywać się podczas testów dymnych. Jeśli system jest bardzo złożony i obejmuje wiele modułów, testy dymne mogą zająć nawet cały dzień, lecz dadzą pewność, że aplikacja jest wystarczająco stabilna, by podjąć się dalszego, głębszego testowania. Zaniedbanie poprawnego wykonania testów dymnych może skutkować przyjęciem do testów systemu, który zawiera zbyt wiele błędów.

9. Pomijanie testowania dokumentacji Rady dla testera • prace związane z QualityAssurance rozpoczynaj od przeglądu dokumentacji, która będzie podstawą do testowania; • dokonując przeglądu skoncentruj się na sprawdzeniu poprawności logiki biznesowej, zgodności specyfikacji z wymaganiami, spójności i kompletności. Wypunktuj wszystkie elementy, codo których masz wątpliwości lub uwagi, i przekaż Team Leaderowi zespołu lub bezpośrednio analitykowi – twórcy dokumentu. • upewnij się, że każda uwaga czy wątpliwość dotycząca dokumentacji jest rozpatrzona i poddana analizie – powinieneś otrzymać odpowiedź na każde pytanie. Jeśli autor dokumentu lub osoba odpowiedzialna za kontakty pomiędzy zespołem QA a analitykami zwleka z reakcją, sygnalizuj problem przełożonemu wraz z uzasadnieniem – podaniem przyczyn, dla których pomyłka w dokumentacji może mieć negatywny wpływ na jakość produktu; • w przypadku, gdy błąd w dokumentacji zostanie potwierdzony, upewnij się, że jest on poprawiony w kolejnej wersji dokumentacji, i że poprawka rozwiązuje problem. • Błędy: • Brak testów dokumentacji (specyfikacja funkcjonalna, model danych, dokumentacja przypadków użycia, przepływ procesu ); Naprawa błedu wykrytego w wymaganiach jest o wiele tańsza niż jego naprawa w czasie późniejszym

10. Złe zarządzanie błędami Rady dla testera: • przestrzegaj ustalonego porządku obsługi błędów. Procedura zarządzania błędami powinna być zawsze ujęta w planie testów; • pilnuj swoich błędów – kontroluj, czy nowe zgłoszenia są podjęte do poprawki w ustalonym czasie, czy nie pojawiają się odrzucenia błędów z powodu braku wystarczających informacji itp.; • przygotowując się do nowego cyklu testów, przygotuj listę poprawek do sprawdzenia w nowej wesjioprogramowania; • zweryfikuj swoje poprawki możliwie najszybciej po rozpoczęciu testowania nowej wersji systemu. Naprawione problemy zamknij, inne otwórz ponownie z uzasadnieniem, dlaczego rozwiązanie problemu Cię nie satysfakcjonuje; • jeśli poprawka powoduje błędy w innych częściach aplikacji, niż ujęte w oryginalnym zgłoszeniu – stwórz nowe raporty defektów. • Błędy: • Nieprawidłowości z zarządzaniu błędami wynikają: • Braku zainteresowania zgłoszonym problemem • Nieznajomości podstawowego cyklu życia defektu • Znalazłem buga, zgłosiłem i reszta mnie nie interesuje. Czekam na poprawkę

11. Developer twój wróg Rady dla testera: • nie atakuj programisty, kiedy znajdziesz błąd w jego kodzie. Nie zgłaszasz błędu do osoby, a do procesu; • raportując problem, wystrzegaj się sformułowań o brzmieniu emocjonalnym – np. wykrzykników, podkreśleń, kapitalizacji liter. Nie wywołuj zbędnego napięcia i konfliktów; • po otrzymaniu rozwiązania problemu od programisty zadbaj o to, aby jak najszybciej uzyskał on informacje zwrotne – akceptację lub odrzucenie poprawki. W przypadku odrzucenia, wyjaśnij dokładnie przyczynę takiej decyzji – nie używaj sformułowań: nie działa bez konkretnego uzasadnienia; • w przypadku błędów wysokiego ryzyka warto jest przetestować poprawkę przed jej formalnym wdrożeniem. Poproś programistę, aby udostępnił poprawiony fragment aplikacji do Twoich nieoficjalnych testów. Upewnisz się, że rozwiązanie działa tak, jak powinno i zminimalizujesz ryzyko pojawienia się w nowej wersji systemów błędów regresji.