Prezentacja przygotowana przez Marlenę Zajdlic, testerkę oprogramowania firmy Fujitsu Poland na potrzeby webinaru w ramach projektu #MamoPracujwIT.

1. 0 © Fujitsu 2018]
Testowanie w praktyce
Podstawy Testowanie Oprogramowania

2. 1 © Fujitsu 2018]
Na czym się skupimy?
 Testowanie w oparciu o user story.
 Jak prawidłowo zgłosić błąd?
 Piszemy pierwszy test case.

3. 2 © Fujitsu 2018]
Testowanie w oparciu o user story
 Co to jest User Story?
 Na początku pracy nad produktem zbierana jest lista wymagań użytkownika,
są one przeważnie gromadzone w postaci „historyjek” (ang. User Stories).
Każda historyjka opisuje jedną cechę systemu. Na bazie historyjek budowany
jest Produkt Backlog.

4. 3 © Fujitsu 2018]
Testowanie w oparciu o user story
 Atrybuty User Story
 Napisana z punktu widzenia użytkownika, zawierają krótki opis interakcji
użytkownika z aplikacją.
 Koncentruje się na wyniku działania jakie powinien otrzymać użytkownik.
 Może być tworzona na różnym poziomie szczegółowości, w razie potrzeby
dzielona na mniejsze historyjki.

5. 4 © Fujitsu 2018]
Testowanie w oparciu o user story
 Format zapisu
 Jako użytkownik X
 Chcę wykonać czynność Y
 Aby osiągnąć cel Z

6. 5 © Fujitsu 2018]
Testowanie w oparciu o user story
 Przykład historyjki
 Jako użytkownik kalkulatora parkingowego
 Chcę mieć możliwość obliczenia kosztu parkowania
 Aby wiedzieć ile zapłacę
adam.goucher.ca/parkcalc

7. 6 © Fujitsu 2018]
Testowanie w oparciu o user story
 Przykład historyjki z kryteriami akceptacji
 Jako osoba planująca wakacje
 Chcę mieć możliwość rejestracji na stronie internetowej Portalu Turystycznego
 Aby móc w pełni korzystać z możliwości portalu
 Potencjalne kryteria akceptacji
 Użytkownik nie może zakończyć procesu rejestracji bez wypełnienia pól
zaznaczonych na czerwono
 Zostanie wyświetlony komunikat o wysłaniu maila potwerdzającego rejestrację
 Użytkownik jest automatycznie zalogowany do aplikacji

8. 7 © Fujitsu 2018]
Testowanie w oparciu o user story
 Przykład historyjki z kryteriami akceptacji
 Jako osoba planująca wakacje
 Chcę mieć możliwość rejestracji na stronie internetowej Portalu Turystycznego
 Aby móc w pełni korzystać z możliwości portalu
 Potencjalne kryteria akceptacji
 Użytkownik nie może zakończyć procesu rejestracji bez wypełnienia pól
zaznaczonych na czerwono
 Zostanie wyświetlony komunikat o wysłaniu maila potwerdzającego rejestrację
 Użytkownik jest automatycznie zalogowany do aplikacji
http://newtours.demoaut.com/

9. 8 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Zawartość raportu błędu:
 Tytuł (Title / Summary)
 Opis sytuacji (kroki reprodukcji)
 Oczekiwany / aktualny rezultat
 Opis środowiska testowego
 Typ zgłoszenia (bug / task / improvement / new feature)
 Priorytet (Priority)
 Dotkliwość (Severity)
 Załączniki (screeny, logi, dane testowe, filmy)
 Obszar, waga, reprodukowalność etc...

10. 9 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 TYTUŁ
OK NIE OK
Krótki i klarowny Długi i niejednoznaczny
Wskazuje na konkretny problem Zbyt abstrakcyjny
Pokazuje wagę problemu Ważność trudna do odszyfrowania
Jasny dla każdego „Co poeta miał na myśli?”
Neutralny Emocjonalny

11. 10 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Kroki reprodukcji:
 Produkt nie jest dodawany do koszyka
1. Przejdź do strony sklepu https://sklepwarsztaty.pl
2. Kliknij button „Dodaj do koszyka” pod dowolnym produktem
3. Przejdź do koszyka

12. 11 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Aktualny rezultat:
 Produkt nie został dodany do koszyka, koszyk jest pusty
 Oczekiwany rezultat:
 Produkt został dodany do koszyka i jest widoczny w koszyku
 Reprodukowalność:
 100%

13. 12 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Środowisko testowe:
 Windows 8.1
 Przeglądarka Chrome Wersja 60.0.3112.101

14. 13 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Priorytet – określa kolejność, w jakiej dane zgłoszenie powinno
zostać rozwiązane. Wskazuje czy danym zgłoszeniem musimy
zająć się od ręki rzucając wszystko inne, nad czym akurat
pracujemy, czy może ono trochę poczekać w kolejce.

15. 14 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Wysoki (High) – defekt musi zostać rozwiązany jak najszybciej (ASAP –
as soon as possibile), ponieważ wpływa na system w rozległy i dotkliwy
sposób. System nie może być użytkowany do momentu naprawy defektu.
 Średni (Medium) – defekt powinien zostać rozwiązany w ramach
normalnej realizacji procesu developerskiego. Rozwiązanie może
zaczekać z wdrożeniem na zbudowanie nowej wersji oprogramowania lub
paczki z poprawkami.
 Niski (Low) – defekt wywołuje irytację, ale jego naprawa może zostać
odłożona w czasie do momentu naprawy bardziej poważnych zgłoszeń
(tych o wyższym priorytecie)

16. 15 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Dotkliwość – wskazuje, do jakich rozmiarów zgłoszony incydent,
defekt może być dotkliwy, przeszkadzający, uniemożliwiający
korzystania z systemu, którego dotyczy. Innymi słowy oznacza
dotkliwość wpływu incydentu czy defektu na system.

17. 16 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Krytyczna (Critical) – defekt uszkadza krytyczne, główne
funkcjonalności systemu. Testy nie mogą być prowadzone, brak
alternatywnej ścieżki prowadzącej do obejścia problemu.
 Przykład:
 Każda próba logowania do systemu kończy się zawieszeniem aplikacji
– niemożliwe korzystanie z aplikacji, brak ścieżki alternatywnej dla zalogowania
do aplikacji.

18. 17 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Duża (Major) – defekt uszkadza główną funkcjonalność systemu lub jego
moduł, ale możliwe jest dalsze testowanie z zastosowaniem, alternatywnej
ścieżki pozwalającej obejść zaobserwowany problem.
 Przykład:
 W systemie rezerwacji biletów lotniczych próba wpisania lotniska startu oraz lotniska
docelowego kończy się „zamrożeniem” strony. Lotniska można jednak wskazać z listy
lotnisk, co nie powoduje zawieszenia się strony i pozwala wyszukać bilety dostępne
na danej trasie – w ten sposób można obejść problem powodowany przez defekt.

19. 18 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Nieduża (Minor) – defekt w funkcjonalności, zwykle w podmodule
systemu. Najczęściej defektem dotknięta jest drobna cecha modułu, co
jednak jest możliwe do obejścia w prosty sposób z poziomu innego
modułu.
 Przykład:
 Brak możliwości edycji imienia klienta z poziomu danych ubezpieczającego na polisie –
brak ikony edycji obok pola zawierającego imię na formularzu systemowym. Wartość
w polu imię możliwe do edytowania z poziomu edycji całego rekordu dotyczącego
ubezpieczającego po kliknięciu przycisku „Edycja” pod sekcją zawierającą wszystkie dane
klient na polisie.

20. 19 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Kosmetyczna (Cosmetic) – defekt dotyczy np. lokalizacji obiektu
w interfejsie systemu (przycisk na formularzu umieszczony tak, że jest
prawie niewidoczny), literówka w nazwie pola na formularzu.
 Przykład:
 Pole „Imię” oraz „Nazwisko” na formularzu wyszukiwania klienta jest widoczne dopiero
po przesunięciu strony przy pomocy paska przesuwania. Wyszukiwanie jest możliwe, ale,
żeby zobaczyć pola „Imię” oraz „Nazwisko” trzeba najpierw przesunąć stronę, co jest
uciążliwe.

21. 20 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

22. 21 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

23. 22 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

24. 23 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

25. 24 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

26. 25 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?

27. 26 © Fujitsu 2018]
Jak prawidłowo zgłosić błąd?
 Logi:

28. 27 © Fujitsu 2018]
Piszemy pierwszy test case.
 Przypadek Testowy (ang. Test case) — zbiór danych wejściowych,
wstępnych warunków wykonania, oczekiwanych rezultatów i
końcowych warunków wykonania opracowany w określonym celu
lub dla warunku testowego jak wykonanie pewnej ścieżki
programu, lub zweryfikowanie zgodności z pewnym wymaganiem.

29. 28 © Fujitsu 2018]
Piszemy pierwszy test case.
 Przypadek testowy niskiego poziomu charakteryzuje się tym, że
dane wejściowe, które określamy w teście są konkretne. To samo
dotyczy się oczekiwanych rezultatów, mając na starcie wiadome
dane i wykonując konkretną czynność, wiemy jaki wynik będzie
prawidłowy.
 Przypadek testowy wysokiego poziomu jest przypadkiem
logicznym. W przeciwieństwie do wcześniejszego przypadku nie
mamy konkretnych danych wejściowych oraz potencjalnych
rezultatów. Inną nazwę, jaką możemy spotkać tego przypadku
testowego to abstrakcyjny przypadek testowy.

30. 29 © Fujitsu 2018]
Piszemy pierwszy test case.
Warunek początkowy: Niezalogowany użytkownik, który znajduje się na stronie z listą produktów
Lp Krok Oczekiwany rezultat
1.
Kliknij button "Dodaj do koszyka" pod
wybranym produktem
Komunikat informujący o pomyślnym dodaniu produktu do
koszyka jest wyświetlony
2. Kliknij "Przejdź do koszyka"
Użytkownik jest przekierowany do strony koszyka, produkt
znajduje się w koszyku
3. Kliknij "Wybierz sposób dostawy" użytkownik jest przekierowany na stronę logowania

31. 30 © Fujitsu 2018]
Piszemy pierwszy test case.

32. 31 © Fujitsu 2018]
Piszemy pierwszy test case.

33. 32 © Fujitsu 2018]
Piszemy pierwszy test case.
https://www.youtube.com/watch?v=cDA3_5982h8

34. 33 © Fujitsu 2018]
Dziękuję za uwagę! 

35. 34 © Fujitsu 2018]
Kontakt:
marlena.zajdlic@gmail.com

36. 35 © Fujitsu 2018]