2 grudnia 2021 na Wydziale Chemii Uniwersytetu Warszawskiego odbyła się prezentacja pod tytułem „Podstawy testowania (teoria testów)” w ramach projektu „Podaj dalej programowanie”. Katarzyna Javaheri-Szpak

1. PODSTAWY TESTOWANIA
OPROGRAMOWANIA
Katarzyna Javaheri-Szpak
2 grudnia 2021
Uniwersytet Warszawski
#podajdalejprogramowanie

2. O mnie
Katarzyna Javaheri-Szpak
• absolwentka fiolologii orientalnej (2007)
• 2007-2016 – praca związana z Bliskim Wschodem
(nauczanie, konsulting, biznes),
• od 2016 informatyczne studia podyplomowe oraz
pierwsze zlecenia w branży IT

3. Moja ścieżka do QA Automation Inżyniera
• od 2016 – zlecenia jako WordPress Admin i Junior Developer
• od 2017 – praca w software house jako WordPress Developer i specjalista
bezpieczeństwa WordPressa
• od 2018 – tester manualny i automatyzujący (Python, Selenium, później
i JavaScript)
• obecnie pracuję dla izraelskiego startupu Kaholo oraz krakowskiego
narzędzia do windykacji płatności – FlowMo
• po godzinach robię strony na WordPressie i uczę języka perskiego 

4. Testowanie oprogramowania
Czym jest testowanie oprogramowania?
Jest to część procesu wytwarzania oprogramowania.
Rozpoczyna się zwykle już w momencie spisywania specyfikacji wymagań (czyli, gdy
wiemy jak ma działać aplikacja).
Praca testera (testowanie) polega na znalezieniu niezgodności w wymaganiach,
wykryciu potencjalnych luk oraz błędów.
Testowanie buduje zaufanie do tworzonego kodu  przetestowany kod = mniej
potencjalnych problemów.

5. Testowanie oprogramowania
Walidacja i weryfikacja = testowanie
walidacja  sprawdzamy czy oprogramowanie jest zgodne
z oczekiwaniami użytkownika
weryfikacja  sprawdzamy czy oprogramowanie jest zgodne z
wymaganiami, specyfikacją

6. tester / QA / inżynier ds. jakości
ZAPEWNIANIE JAKOŚCI
TESTOWANIE
QA = Quality Assurance
zapewnianie jakości
testowanie = część procesu
zapewniania jakości

7. proces wytwarzania oprogramowania
planowanie wykonanie weryfikacja wdrożenie ulepszenie
m.in. testowanie
zapewnianie jakości

8. Kiedy można powiedzieć,
że jakość została zapewniona?
Gdy projekt jest zakończony sukcesem,
czyli gdy został zrealizowany:
w przyjętym budżecie,
w akceptowalnym terminie
a gotowy produkt spełnia oczekiwania klienta.

9. Co to jest jakość?
ogół cech i właściwości obiektu decydujących o ich zdolności do
zaspokajania stwierdzonych i przewidywanych potrzeb
(PN-EN ISO 8402:1996. Zarządzanie jakością i zapewnienie jakości. Terminologia.)
zbiór inherentnych* właściwości spełniających wymagania
(PN-EN ISO 9000:2001. Systemy zarządzania jakością. Podstawy i terminologia.)
*nieodłącznych

10. Cechy dobrego jakościowo oprogramowa
• funkcjonalność (functionality)  przydatne funkcje
• niezawodność (reliability)  bez awarii i opóźnień
• użyteczność (usability)  przyjazne użytkownikowi
• wydajność (efficiency)  szybkość działania
• łatwość utrzymania (maintanability)  zrozumiałe, proste
rozwiązania, łatwe do zrozumienia i naprawienia
• przenośność (portability)  kompatybilność systemu i
danych z wieloma rozwiązaniami, także nowymi

11. https://memy.jeja.pl/1095,proste-zlecenie.html

12. BUG / BŁĄD
• bug czyli błąd, który powoduje
nieprawidłowe działanie aplikacji /
oprogramowania.
Bugi najczęściej zgłaszane są:
• przez użytkowników (np. na pierwszej
linii pomocy)
• przez testerów,
• przez programistów,
• przez product ownerów, project
managerów

13. Dlaczego błąd nazywamy bugiem?
Bug czyli po angielsku
“robak, owad, robal”
W IT (także po polsku): błąd w kodzie
Nazwa pochodzi od prawdziwego
“buga” – ćmy znalezionej w 1947 r.
w komputerze na Harvardzie
Źródło: https://en.Wikipedia.Org/wiki/software_bug

14. Kiedy pojawia się bug?
błąd człowieka
bug w kodzie
zły kod
nieoczekiwane
działanie
awaria
systemu

15. Przyczyny błędów ludzkich
w oprogramowaniu (przykłady)
•Wysoki stopień skomplikowania kodu
•Praca pod dużą presją czasu
•Zaawansowana technologia
•Przemęczenie, choroba, “zły dzień”

16. Zasady testowania – wg ISTQB
7 zasad testowania według ISTQB
Co to jest certyfikat ISTQB?
International Software Testing Qualifications Board = ISTQB
Międzynardowa organizacja działająca od 2002 roku, która ustandaryzowała procesy i techniki
testowania.
Organizacja wydaje certyfikaty na poziomie podstawowym i zaawansowanym (różne ścieżki).
https://www.istqb.org/

17. Zasady testowania – zasada 1
Testy wykrywają błędy, ale nie jest możliwe znalezienie
WSZYSTKICH błędów
Testy wprawdzie wykrywają błędy, ale nie są w stanie potwierdzić, że
w oprogramowaniu nie ma już żadnych błędów.

18. Zasady testowania – zasada 2
Nie jest możliwe przetestowanie wszystkiego
Nie jesteśmy w stanie przetestować wszystkiego – wszystkich
przypadków testowych i nietypowych zachowań użytkowników.
Testowanie, w zależności od czasu jaki mamy na testy i od budżetu,
powinno obejmować najbardziej krytyczne funkcje.

19. Zasady testowania – zasada 3
Rozpoczęcie wczesnych testów oszczędza czas i inne środki
Jeśli zaczniemy testować już na etapie tworzenia wymagań, a
później tworzenia kodu, to koszt usunięcia błędów na wczesnym
etapie będzie niższy niż usunięcie błędów
z produktu już oddanego użytkownikom.

20. Zasady testowania – zasada 4
Zasada Pareto 80/20 - błędy lubią się kumulować w jednym miejscu
80% wszystkich błędów skupia się w 20% całego kodu
znajdując błąd lub dwa w jakimś komponencie, możemy
przypuszczać, że znajdziemy ich więcej

21. Zasady testowania – zasada 5
Zasada paradoksu pestycydów – uodparnianie na testy
Jeśli ciągle uruchamiamy te same testy to tracą one zdolność do
znajdywania nowych błędów
Należy ciągle zarządzać testami, ulepszać je, a nie tylko stworzyć
zestaw testów i używać ich bezrefleksyjnie

22. Zasady testowania – zasada 6
Testowanie zależy od kontekstu
W zależności od tego jakiego typu oprogramowanie testujemy, to
kontekst wyznacza podjęcie odpowiednich kroków.
Należy dopasować podejście do testów do konkretnej aplikacji.

23. Zasady testowania – zasada 7
Błędne przekonanie o braku błędów 
Samo naprawianie błędów nie sprawi, że aplikacja będzie przyjazna
użytkownikom.
Oprogramowanie powinno być dostowane do oczekiwań osób z
niego korzystających. Jeśli zostało źle zaprojektowane to naprawa
nawet setki błędów nie sprawi, że jego jakość wzrośnie.

24. Przykłady prostych bugów

25. ZNAJDŹ BUGA 🐞
Dokumentacja
Strona logowania do konta
Użytkownik wprowadza prawidłowy e-
mail i hasło
Użytkownik klika w przycisk “zaloguj”
Oczekiwany rezultat:
Użytkownik loguje się do konta

26. ZNAJDŹ BUGA 🐞
Bug:
Brak przycisku “zaloguj”
Użytkownik nie ma jak się zalogować
do konta
ZALOGUJ

27. Czy to bug?
(przykłady)

28. CZY TO BUG?

29. CZY TO BUG?
To nie błąd
Taki komunikat pojawia się na
Facebooku, gdy mamy mało znajomych
i mało obserwowanych stron i zjedziemy
na sam dół “walla”

30. CZY TO BUG?

31. CZY TO BUG?
To jest błąd
Taki komunikat pojawia się na Facebooku
w aplikacji mobilnej,
gdy mamy mało znajomych i mało
obserwowanych stron i zjedziemy na sam
dół “walla”
Powinien pojawić się ten sam komunikat co
na komputerze

32. jakiś czas temu
w apce
bankowej…

33. “SŁYNNE BUGI”?

34. Testowe
wiadomości push
od mBanku
mBank wyszedł z
tego obronną ręką


35. Tzw. millenium bug
Na przełomie 1999/2000 wiele
systemów informatycznych uległo
awarii lub podawało błędną datę
1 stycznia 1900 roku.
Problem ten spowodowany był przez
sposób zapisu daty w programach
komputerowych
Te które miały rok zapisany
np. 00 zamiast 2000
mogły omyłkowo “wrócić” do roku
Pod koniec 1999 roku, prasa
dodatkowo szukała sensacji
Pisano o końcu świata w związku z
wejściem w rok 2000
(Komputery miały przejąć kontrolę nad
ludźmi)

36. PRACA TESTERA

37. DZIEŃ Z ŻYCIA TESTERA – NARZĘDZIA
Narzędzia do zarządzania zadaniami (JIRA, Trello)
Narzędzia do pisania scenariuszy testowych
Narzędzia do robienia screenshotów i nagrywania
ekranu
Przeglądarki internetowe z funkcjami
programistycznymi (Chrome, Safari, Mozilla…)
Komunikatory internetowe (Slack, Teams)
Zoom lub Google Meet do spotkań online
Edytory kodu (testerzy automatyzujący)

38. DZIEŃ Z ŻYCIA TESTERA
– ZADANIA CODZIENNE
o Uczestniczenie w codziennych spotkaniach (daily)
o Uczestniczenie w spotkaniach: planowaniu, prezentacjach
produktu, podsumowaniach
o Wymiana wiedzy z innymi programistami lub testerami
(warsztaty, prezentacje)
o Doszkalanie się, szukanie nowych rozwiązań i ulepszeń

39. DZIEŃ Z ŻYCIA TESTERA
– ZADANIA CODZIENNE
o Wykonywanie przypisanych zadań, zgodnie z kolejnością wyznaczoną przez
menedżera / product ownera
 Testowanie nowych funkcji lub modułów
 Ponowne testowanie naprawionych bugów
 Testowanie całej aplikacji lub programu, tzw. testowanie regresyjne
 Pisanie dokumentacji testowej (scenariusze, raporty z testów)
 Pomoc obsłudze klienta w rozwiązywaniu problemów zgłoszonych przez
użytkowników
 Pisanie testów automatycznych (programowanie testów)
 Przygotowanie środowisk testowych i danych potrzebnych do
przeprowadzenia testów
 Analiza dokumentacji pod kątem przyszłych testów

40. TESTOWANIE MANUALNE
I AUTOMATYCZNE
Testowanie manualne (ręczne)
- testy wykonywane są ręcznie
przez wyznaczoną osobę
(testera),
- testerzy manualni
przeprowadzają testy w oparciu
o przypadki testowe,
- dopuszczalne jest również
testowanie ad hoc lub przez
użytkowników końcowych
- mogą być zawodne (pierwiastek
ludzki)
Testowanie automatyczne
- testy wykonują się automatycznie w
oparciu
o wcześniej stworzone skrypty
testowe (w różnych językach
programowania lub narzędziach
low-code),
- ograniczona rola człowieka
i co za tym idzie niezawodność
(skrypty nie chorują i nie są
zmęczone 

41. TESTOWANIE FUNKCJONALNE
I NIEFUNKCJONALNE
Testowanie funkcjonalne
- testy funkcji, jakie pełni system,
- bazują na wymaganiach,
specyfikacjach
- skupiają się na zewnętrznym
działaniu systemu (to, co widzi
użytkownik)
CO ROBI SYSTEM?
Testowanie niefunkcjonalne
- testy te nie są powiązane
z funkcjonalnością systemu,
- testujemy jak system działa,
- testują: wydajność,
niezawodność, bezpieczeństwo,
użyteczność, dostępność
JAK DZIAŁA SYSTEM?

42. TESTOWANIE BIAŁO-
I CZARNO- SKRZYNKOWE
Testy białoskrzynkowe
- osoba testująca zna budowę
system, jego strukturę,
- osoba testująca analizuje kod,
- wymagana jest co najmniej
podstawowa wiedza na temat
programowania.
Testowanie czarnoskrzynkowe
- osoba testująca nie wie, jak
skonstruowany został testowany
system
- system jest postrzegany jako „czarna
skrzynka”,
- podstawą tego typu testów jest
dokumentacja – musimy wiedzieć
jakie kroki podjąć i co jest
oczekiwanym rezultatem

43. TESTY REGRESJI I RE-TESTY
Testy regresji
- sprawdzamy cały system lub
najważniejsze części,
- sprawdzamy czy nowe zmiany
nie zepsuły czegoś
w istniejących
funkcjonalnościach,
- są to testy powtarzalne, najlepiej
jest je zautomatyzować
Re-testy
- sprawdzamy czy zgłoszony bug
został naprawiony
- dotyczą pojedynczych
zagadnień
- zwykle testowane manualnie

44. PRZYPADEK TESTOWY
(TEST CASE)
To zbiór instrukcji odpowiadający na pytanie “Co testujemy?”
Instrukcje te są nam potrzebne, by sprawdzić poprawność działania danej
funkcjonalności.
Najczęściej składa się z:
- warunków początkowych,
- kroków odtworzenia (czyli co musimy zrobić w systemie),
- oczekiwanego rezultatu (musi być jednoznaczny!),
- dodatkowych informacji: wymagane środowisko, priorytet

45. PRZYPADEK TESTOWY - PRZYKŁAD
Nazwa: Poprawne dodanie komentarza pod postem
Warunki początkowe:
W systemie istnieje post, który można skomentować
Kroki odtworzenia:
• wpisz swój kometarz w pole pod postem
• kliknij przycisk “Wyślij”
Oczekiwany rezultat:
Komentarz został dodany pod postem.

46. PRZYPADEK TESTOWY - PRZYKŁAD
Nazwa: Niepoprawna próba dodania komentarza pod postem
Warunki początkowe:
W systemie istnieje post, który można skomentować
Kroki odtworzenia:
• nie wpisuj nic w pole komentarza
• kliknij przycisk “Wyślij”
Oczekiwany rezultat:
Komentarz nie został dodany pod postem.

47. SCENARIUSZ TESTOWY
W uproszczeniu to zbiór przypadków testowych, który testuje np. daną ścieżkę w
systemie.
Przykład:
- logowanie
- dodanie produktu do koszyka
- sprawdzenie koszyka
- złożenie zamówienia
- sprawdzenie poprawności zamówienia

48. PRZYKŁAD DOBORU TESTÓW
Produkt: edytor makiet 3D online
Charakterystyka: istnieje od 6 lat, dużo funkcji, niezmienna “baza” funkcji,
3 razy w tygodniu dodawane drobne poprawki, a także nowe funkcjonalności
Testy: oprócz testów nowych funkcjonalności, należy przed każdym wydaniem nowych
zmian, przetestować cały system pod kątem regresji
Nieefektywne podejście:
Testy manualne regresji: zajmują 3-4 godziny, wykonywane co dwa dni, żmudne i
męczące dla testera (po roku pracy wykonuje 156 praktycznie identycznych sesji)
Efektywne podejście: zautomatyzowanie powtarzalnych ścieżek, manualne testowanie
tylko nowych funkcjonalności

49. PRZYKŁAD DOBORU TESTÓW
Produkt: innowacyjna platforma do inwestycji
Charakterystyka: istnieje od 3 miesięcy, co chwilę zmienia się koncept jej działania,
autorzy poszukują wciąż nowych rozwiązań
Testy: testy nowych funkcjonalności i testy całego systemu po każdej większej zmianie
koncepcji
Nieefektywne podejście:
Automatyzacja każdej nowej funkcjonalności – podejście kosztowne, a bez gwarancji,
że w przyszłości te funkcjonalności będą nadal częścią systemu
Efektywne podejście:
Testowanie manualne, zarówno przez zawodowych testerów, jak i np.
w ramach programu wczesnego dostępu – przez użytkowników

50. DZIĘKUJĘ ZA UWAGĘ!  PYTANIA
KATARZYNA.JAVAHERI@GMAIL.COM
HTTPS://JAVAHERI.PL

52. QUIZ
Z NAGRODĄ