Agenda:
Wykonanie testów

Wykonanie testów

Wykonanie testów jest implementacją strategii i planu testów w projekcie.
Zawiera:

• Wykonanie
• Kontrolę
  • Monitorowanie
  • Nadzór
• Raportowanie

PLANOWANIE – Podejścia do testów

Podejścia do testów:

• Analityczne – oparte na ryzyku. Testowanie skupia się na obszarach o największym ryzyku,
• Oparte na modelach – wykorzystuje informacje statystyczne na temat współczynników awarii lub wykorzystania oprogramowania,
• Metodyczne – oparte na:
  • awariach,
  • doświadczeniu,
  • listach kontrolnych,
  • atrybutach jakościowych,
• Zgodne ze standardem lub procesem (Scrum),
• Dynamiczne i Heurystyczne – testowanie eksploracyjne, testy wykonywane bez planu,
• Konsultatywne – testy sterowane głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego
• Regresywne – minimalizacja regresji

Projektowanie i implementacja

Projektowanie (jak testujemy?) i Implementacja (czy jesteśmy gotowi do rozpoczęcia testów?)

Projektowanie to czynność, podczas której:

• tworzone są przypadki testowe,
• przypadki testowe grupowane są w zbiory,
• Identyfikowane są dane testowe,
• projektowane jest środowisko testowe

Implementacja – podczas niej odbywa się

• Utworzenie skryptów testów automatycznych
• Tworzenie procedur testowych i nadanie priorytetów
• Tworzenie zestawów testów,
• Budowa środowiska testowego,
• Przygotowanie danych testowych

Wykonanie testów:

•  Sprawdzenie czy środowisko testowe zostało poprawnie skonfigurowane,
•  wykonanie przypadków testowych w zaplanowanej kolejności,
• zapisywanie rezultatów testów wraz z:
  •  jednoznacznym identyfikatorem,
  • wersją testowanego oprogramowania,
  • narzędzi testowych,
  • użytych danych testowych,
•  porównywanie wyników rzeczywistych z wynikami oczekiwanymi
•  raportowanie rozbieżności jako błędy w dedykowanym narzędziu
• analiza w celu ustalenia ich przyczyny:
  • błędu w kodzie,
  • błędu w danych testowych,
  • błędu analitycznego,
  • pomyłki w trakcie wykonywania testów.
• powtórne wykonanie testów z wynikiem negatywnym,
• potwierdzenie naprawy defektu (testowanie potwierdzające),
• wykonanie poprawionych testów,
• wykonanie testów w celu weryfikacji czy w niemodyfikowanych częściach oprogramowania nie pojawiły się błędy lub, czy naprawa błędów nie ujawniła innych defektów (testowanie regresywne),
• raportowanie wyników testów wraz z rekomendacją zakończenia fazy testów (pozytywna, negatywna).

Wykonanie testów – Monitorowanie i Nadzór

Monitorowanie wykonania testów to sprawdzanie, czy idziemy w dobrym kierunku, czy wszystko idzie zgodnie z zakładanym planem.
Przykładowe metryki do monitorowania testów:

• stosunek ilości zadań zakończonych do zadań zaplanowanych w danym okresie,
• liczba pozytywnie zakończonych przypadków testowych,
• liczba zgłoszonych błędów czy liczba naprawionych błędów.

Nadzór to podejmowanie konkretnych decyzji i działań- w momencie, kiedy sytuacja w projekcie odbiega od tej pożądanej, wprowadzane są decyzje, które mają na celu poprawienie sytuacji.



Źródło do materiałów: SJSI Sylabus ISTQB FL

Rozszerzenie lekcji 9: Bug

Agenda:
•       Cykl życia błędu
•       Co powinien zawierać poprawnie zgłoszony bug?
•       Severity vs. Priority
•       Warsztaty

Cykl życia błędu

Nowy – błąd został znaleziony i zgłoszony przez testera
Przydzielony – znaleziony błąd zostaje przydzielony do developera/zespołu developerskiego. W Scrum jako, że zespół jest samoorganizujący się – developerzy sami wybierają sobie błąd. W Waterfall często robi to kierownik testów.
Odroczony – zgłoszenie jest błędem, jednakże nie będzie rozwiązane od razu – może być przeniesione, np. na kolejną iterację – najprostszą przyczyną może być brak czasu na poprawę błędu.
Odrzucony – błąd nie występuje lub „to nie bug, to feature”, developer odrzuca błąd i zamyka.
Powielony – błąd został już wcześniej zgłoszony i ponowne zgłoszenie jest niedopatrzeniem lub jeśli pracujemy w zespole z większą ilością testerów – błąd został zgłoszony przez innego developera.
Otwarty – przypisany developer zapoznaje się ze zgłoszeniem testera.
Analiza – występuje, gdy błąd jest skomplikowany i developer musi najpierw przeanalizować zgłoszenie zanim przystąpi do naniesienia poprawek.
Development – właściwa praca developera nad likwidacją błędu.
Code Review – inny programista z zespołu przegląda kod w celu oceny czy można go przekazać na retest.
Przekazanie do testów – status gotowy do testów, oczekuje na retest testera.
Retest – tester dokonuje weryfikacji czy błąd jest naprawiony i dana funkcjonalność działa jak powinna.
Ponowne otwarcie – błąd po weryfikacji okazał się nie rozwiązany – wraca do programisty na development ponownie do poprawy.
Gotowe (Zamknięte) – błąd został poprawnie rozwiązany i zamknięty.

Co powinien zawierać poprawnie zgłoszony bug?

•       Tytuł zgłoszenia
•       Środowisko Testowe
•       Warunki wstępne
•       Dane testowe
•       Kroki reprodukcji – szczegółowy opis interakcji z systemem
•       Rezultat
•       Oczekiwany efekt
•       Załączniki

Dodatkowo:

• ID
• Severity
• Priority
• Powtarzalność
• Autor

Przykład zgłoszenia błędu:                                                          *wykorzystana strona phptravels.net



Przykład zgłoszenia błędu:                                                        *wykorzystana strona phptravels.net
Załącznik:



Jak napisać buga i nie zrazić do siebie developerów? 😊
•       Miej pewność, że to bug!*
•       Błąd nie siedzi naprzeciwko monitora 😊 (CTRL + F5)
•       Pisz wiersze nie powieści
•       Pisz po polsku J Albo w innym wymaganym języku
•       Czemu to jest błąd?
•       Jeden błąd na jedno zgłoszenie
•       Zasada ograniczonego zaufania – retestuj!
•       Idź schematem – miej szablon błędu!
* Jeśli nie masz pewności i nie masz jak lub z kim potwierdzić, lepiej zgłoś J

Severity vs. Priority

Dotkliwość (Severity):

• Krytyczna – przez defekt przestaje działać cały system lub istotnej części – istnieje ryzyko uszkodzenia danych – nie istnieje żadna alternatywna metoda by działał prawidłowo.
• Duża – wystąpienie defektu powoduje, że system przestaje działać lub nie działa przynajmniej jeden element – funkcjonalność nie może być używana, natomiast istnieje inna metoda, która jest akceptowalna jako alternatywa.
• Umiarkowana – przez defekt system nie przestaje działać, jednak używanie go przyczynia się do osiągania nieprawidłowych wyników.
• Nieduża – wystąpienie defektu nie powoduje, że system nie działa ani nie został uszkodzony, natomiast oczekiwany rezultat można osiągnąć poprzez obejście defektu.
• Kosmetyczna – poprawa systemu – często związana z aspektami wizualnymi systemu.

 
Priorytet (Priority):

• Wysoki – defekt należy naprawić najszybciej jak to jest możliwe – ma istotny wpływ na działanie aplikacji.
• Średni – defekt może być rozwiązany w ramach normalnego trybu prac – może poczekać np. na kolejne wydanie oprogramowania.
• Niski – defekt jest zauważalny i może powodować dyskomfort użytkownika końcowego, natomiast nie jest to istotny defekt – można odłożyć na późniejszy etap prac.

*Bug, Błąd, Defekt, Awaria – warto wiedzieć, że w codziennym życiu testerskim te słowa używane są naprzemiennie – samo ISTQB wykazuje się nieścisłością w tym aspekcie. Rozgraniczenie tych pojęć jest istotne w ramach certyfikacji.