Prezentacja przedstawiona 29 czerwca 2023 w ramach projektu "sprintED: odkryj IT". Podstawy testowania oprogramowania

1. TESTOWANIE
OPROGRAMOWANIA
Katarzyna Javaheri-Szpak
29 czerwca 2023
sprintED: odkryj IT!

2. O mnie
Katarzyna Javaheri-Szpak
• obecnie: Senior QA Automation Engineer w
izraelskiej firmie Promo.com
• w branży IT od 2016 roku
• zapewniam jakość produktu
i automatyzuję testy oraz procesy
zapewniające jakość

3. Testowanie oprogramowania
Тестування Програмного Забезпечення
Czym jest testowanie oprogramowania?
Jest to część większego procesu  procesu wytwarzania oprogramowania.
Testowanie może się zacząć już w momencie spisywania specyfikacji wymagań
(czyli, gdy wiemy jak ma działać program lub aplikacja).
Praca testera (testowanie) polega na znalezieniu niezgodności
w wymaganiach, wykryciu potencjalnych luk oraz błędów.

4. 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ą

5. Quality Assurance vs. testowanie
ZAPEWNIANIE JAKOŚCI
Забезпечення якості
TESTOWANIE
Тестування
QA = Quality Assurance
zapewnianie jakości
testowanie = część procesu
zapewniania jakości

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

7. QA Engineer vs. Software Tester
• osoby pracujące na obydwu wymienionych stanowiskach
przeprowadzają testy
• różnica w zakresie obowiązków:
• celem QA Engineera jest ulepszanie i automatyzowanie procesów,
by zapewnić jak najwyższą jakość
• celem Software Testera jest znajdowanie i zgłaszanie błędów,
minimalizacja liczby błędów w oprogramowaniu

8. Kiedy możemy 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. Czym jest jakość? - formalnie
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. Czym jest jakość? – własnymi słowami
jakość wiąże się ze spełnianiem
wymagań i oczekiwań
zarówno tych biznesowych,
jak i oczekiwań użytkowników
(określonej grupy odbiorców 
nie jesteśmy w stanie zadowolić “wszystkich”)

11. Cechy dobrego jakościowo oprogramowa
• funkcjonalność (functionality)  przydatne funkcje
• niezawodność (reliability)  bez awarii
• 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 nowszymi

12. BUG / DEFEKT / БАГ
• bug czyli defekt, 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. Kiedy pojawia się bug?
błąd człowieka
bug w kodzie
zły kod
nieoczekiwane
działanie
awaria
systemu
💥

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

15. 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/

16. Zasady testowania – zasada 1
Testy wykrywają bugi,
ale nie jest możliwe znalezienie WSZYSTKICH
Testy wprawdzie wykrywają bugi, ale nie są w stanie potwierdzić, że
w oprogramowaniu nie ma już żadnych defektów.

17. 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ć najważniejsze funkcje.

18. 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 defektów na wczesnym
etapie będzie niższy niż usunięcie ich
z produktu już oddanego użytkownikom.

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

20. 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 defektów.
Należy ciągle zarządzać testami, ulepszać je, a nie tylko stworzyć
zestaw testów i używać ich bezrefleksyjnie.

21. 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 lub strategii.
Należy dopasować podejście do testów do konkretnej
aplikacji/konkretnego produktu.

22. Zasady testowania – zasada 7
Błędne przekonanie o braku defektów
Samo naprawianie bugó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 bugów nie sprawi, że jego jakość wzrośnie.

23. Dobra rada dla początkujących
Nie starajmy się na siłę szukać jak największej liczby bugów - przygotowujmy
testy tak, by wyeliminować potencjalne błędy ludzkie na jak najwcześniejszym
etapie wytwarzania oprogramowania.
Przykład: dokumentacja jest niejasna
Co robić? Poprosić o wyjaśnienie, jeszcze zanim programiści zaczną pracę.

24. PRZYKŁAD DOKUMENTACJI I BUGA

25. Dokumentacja i projekt:
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
ZALOGUJ

26. ZNAJDŹ BUGA 🐞
Rezultat i bug
Brak przycisku “zaloguj”
Użytkownik może się wprawdzie
zalogować na konto klikając ENTER po
wpisaniu danych, jednak wielu
użytkowników nawet na to nie wpadnie
Dobry przykład na to, że funkcjonalność “działa”, ale
jakość tego rozwiązania jest niska.

27. PRACA TESTERA

28. DZIEŃ Z ŻYCIA TESTERA – NARZĘDZIA
Narzędzia do zarządzania zadaniami (JIRA, Trello)
Narzędzia do rozpisywania testów (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)

31. PRZEGLĄDARKI - DEVTOOLS
Bardzo ważną umiejętnością, nawet dla początkującego testera, jest znajomość
tzw. Devtools (funkcje programistyczne).
Devtools to narzędzie wbudowane w przeglądarkę, które służy do analizy
aplikacji webowej lub strony, a także do jej tymczasowej edycji “w locie”.
Jest to narzędzie niezbędne w pracy testera, przydatne zwłaszcza przy
identyfikacji problemów/bugów.
Najbardziej znane są Devtoolsy Chrome, ale inne przeglądarki posiadają takie
same możliwości (mogą się lekko różnić nazewnictwem).

32. Jak włączyć Devtools?
1. sposób
klikamy prawym przyciskiem myszy na stronie i z
menu wybieramy Inspect / Zbadaj
2. sposób
na Windows, Linux: Ctrl + Shift + C lub F12
na MacOS: Cmd + Option + C lub Fn + F12

35. 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ń

36. 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 (retesty)
 Testowanie całej aplikacji lub programu po wprowadzeniu zmian, tzw.
testowanie regresyjne

37. DZIEŃ Z ŻYCIA TESTERA
– ZADANIA CODZIENNE
 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

38. WYMAGANE UMIEJĘTNOŚCI
 dociekliwość, chęć zrozumienia “jak to działa”
 cierpliwość
 systematyczność, konsekwencja działania
 chęć do ciągłego doszkalania się
 komunikatywność (praca w zespole)
 minimalna wiedza techniczna z zakresu budowy
oprogramowania
 wiedza z zakresu teorii testów (ISTQB)
 znajomość metodyk zwinnych (Scrum, Kanban)
 język angielski (w większości przypadków)

39. 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,
- użytkownicy też “testują”
aplikację używając ją
- 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 

40. 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?

41. TESTOWANIE BIAŁO-
I CZARNO- SKRZYNKOWE
Testy białoskrzynkowe
- osoba testująca zna budowę
systeum, 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

42. 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

43. TESTY APLIKACJI MOBILNYCH
Czym testowanie aplikacji mobilnych różni się
od testowania aplikacji webowych?
Zasadniczą różnicą jest to, że do testów
potrzebujemy symulatora/emulatora urządzenia
mobilnego lub fizycznego urządzenia (telefonu,
tabletu).
Aplikację webową można przetestować praktycznie
na każdym urządzeniu, które ma przeglądarkę
internetową.

44. TESTY APLIKACJI MOBILNYCH
Uwaga!
testowanie aplikacji mobilnych to nie to samo co testowanie mobilnej wersji aplikacji webowej
APLIKACJA
MOBILNA
(POBRANA ZE
SKLEPU)
APLIKACJA
WEBOWA
NA TELEFONIE
(PRZEGLĄDARKA)

45. aplikacja mobilna
to aplikacja napisana pod dany system
mobilny (Android / iOS)
mobilna wersja aplikacji webowej
to po prostu zwykła aplikacja działająca w
przeglądarce, dostosowana do
rozdzielczości mobilnych

46. 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  od czego zacząć?
- kroków odtworzenia  czyli co musimy zrobić?
- oczekiwanego rezultatu  musi być jasny i jednoznaczny!
- dodatkowych informacji: wymagane środowisko, priorytet

47. PRZYPADEK TESTOWY
PRZYKŁAD POZYTYWNY (TZW. HAPPY PATH)
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.

48. PRZYPADEK TESTOWY
PRZYKŁAD NEGATYWNY
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.

49. 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

50. PIRAMIDA TESTÓW
testy e2e
(użytkownika końcowego)
testy integracyjne /
testy serwisów
testy jednostkowe /
unit testy (na poziomie kodu)

51. SYSTEMY
LOTNISKOWE
PRZYKŁAD
INTERGRACJI
RÓŻNYCH
SERWISÓW
ROZKŁADY
OPÓŹNIENIA
ODPRAWA
BILETY
NADANIE BAGAŻU
I JEGO TRANSPORT

52. ROLE I ŚCIEŻKI ROZWOJU

53. TESTER MANUALNY
- najniższy próg wejścia
- zakres obowiązków:
- najczęściej – testowanie gotowych funkcjonalności, testy front-endu
(czyli tego, co widzą użytkownicy)
- testy manualne na różnych urządzeniach, także mobilnych
- testerzy manualni mogą testować także
- backend (wszystko, czego nie widzą użytkownicy  “testowanie od
kuchni”)
- bazy danych
- dostępność (sprawdzenie na ile możliwe jest używanie
oprogramowania przez wszystkich użytkowników, w tym przez
osoby z niepełnosprawnościami)

54. TESTER AUTOMATYZUJĄCY
- wyższy próg wejścia, wymagana znajomość języków programowania lub
narzędzi typu low-code (rzadziej)
- zakres obowiązków:
 pisanie skryptów testowych według:
o własnych przypadków testowych
o zleconych przypadków testowych (np. przez menadżera testów)
 automatyzacja procesów testowania
Testerzy automatyzujący często testują także manualnie.

55. QA ENGINEER
- wyższy próg wejścia, wymagana dobra znajomość procesu wytwarzania
oprogramowania
- zakres obowiązków:
o zapewnianie jakości w trakcie całego procesu wytwarzania
oprogramowania
o projektowanie testów, testowanie
o optymalizacja procesów, opracowanie dokumentacji
o w przypadków QA Engineera automatyzującego: automatyzacja
opracowanych procesów oraz testów

56. TESTER BEZPIECZEŃSTWA / PENTESTER
- wysoki próg wejścia, wymagana znajomość języków programowania
- zakres obowiązków:
 wyszukiwanie luk w zabezpieczeniach systemów operacyjnych, aplikacji
i programów
 testowanie systemów pod kątem ataków hackerskich (“etyczne
hackowanie”)

57. TESTER APLIKACJI MOBILNYCH
- specjalizacja testera manualnego lub automatyzującego skupiająca się na
testowaniu aplikacji mobilnych (dla systemów iOS, Android)
- testowanie aplikacji:
- natywnych (napisanych na daną platformę)
- hybrydowych (jedna aplikacja na kilka systemów)
- wymagana wiedza o na temat aplikacji mobilnych oraz dostępnych
możliwości (np. testowanie na realnych urządzeniach lub symulatorach,
automatyzacja iOS różni się od automatyzacji dla Androida itp.)

58. TESTER SYSTEMÓW WBUDOWANYCH
(EMBEDDED)
- specjalizacja dotycząca testów na systemach wbudowanych, czyli
urządzeniach, w których sprzęt i oprogramowanie są ściśle ze sobą
powiązane (np. bankomaty, drukarki, smartwatche, maszyny produkcyjne)
- w przeciwieństwie do testów programów na popularne systemy lub testów
aplikacji webowych, testowanie embedded obejmuje testy urządzenia i
oprogramowania – są one od siebie zależne
- testy na symulatorach mogą dawać błędne wyniki, dlatego ważne jest
testowanie oprogramowania na konkretnym modelu urządzenia

59. MENADŻER / KIEROWNIK TESTÓW
- wymagana szeroka wiedza o testach i doświadczenie w tym zakresie,
- zakres obowiązków:
- koordynowanie procesów testowych,
- tworzenie planów testów na podstawie wymagań
- opieka nad dostępnością środowisk testowych, zapewnianie danych
testowych
- przygotowywanie raportów z wyników testowania.

60. LIDER TECHNICZNY / TECH LEAD
- wysoki próg wejścia, wymagana wiedza z zakresu pełnego procesu
wytwarzania oprogramowania oraz znajomość języków programowania
- zakres obowiązków:
- dobór najlepszych technologii rozwiązań do projektu
- tworzenie dokumentacji technicznej
- nieustanna nauka i bycie na bieżąco z nowościami technologicznymi
- mentoring członków zespołu

61. WIĘCEJ OBOWIĄZKÓW W FORMIE GRAFICZNEJ
https://roadmap.sh/qa

62. DZIĘKUJĘ ZA UWAGĘ!
katarzyna.javaheri@gmail.com
javaheri.pl