Testowanie na 101 sposobów - od backendu do testów aplikacji mobilnych

1. TESTOWANIE NA 101 SPOSOBÓW
OD BACKENDU
DO TESTÓW APLIKACJI MOBILNYCH
Katarzyna Javaheri-Szpak
12 maja 2022
sprintED: zostań testerem_ką

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 Senior QA Automation Inżyniera
• od 2016 – zlecenia jako WordPress Admin i Junior Developer
• od 2017 – praca w software house jako WordPress Developer i
specjalista ds. bezpieczeństwa WordPressa
• od 2018 – tester manualny i automatyzujący (Python + Selenium,
incydentalnie Swift i JavaScript)
• obecnie pracuję dla izraelskiej firmy Promo.com oraz po
godzinach dla krakowskiego narzędzia do windykacji należności
Flobo

4. Testowanie oprogramowania
Czym jest testowanie oprogramowania?
Jest to część procesu wytwarzania oprogramowania.
Może rozpocząć się 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
Dlaczego testowanie jest tak ważne?
Testując nie jesteśmy w stanie znaleźć wszystkich błędów,
ale jesteśmy w stanie ograniczyć kosztowne konsekwencje tych
błędów, które uda się znaleźć, i/lub którym uda się zapobiec.
Im wcześniej w procesie wytwarzania oprogramowania znaleziony
zostanie dany defekt – tym tańsza będzie jego naprawa.

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
i
utrzymanie
m.in. testowanie
zapewnianie jakości

8. TESTOWANIE BACKENDU
API
METODY HTTP

9. Czym jest backend?
- silnik aplikacji/strony internetowej po stronie
serwerowej = “od kuchni”
- wszystko czego użytkownik nie widzi
(w przeciwieństwie do frontendu)
- backend powstaje najczęściej przed częścią
frontendową

10. Backend
Frontend

11. API
- interfejs programowania aplikacji (Application
Programming Interface) - ”pośrednik”/”tłumacz”
- zbiór instrukcji zapewniający łączność i wymianę danych
między aplikacjami, a także człowiekiem
- funkcjonalności zakodowane w warstwie backendu,
publikowane są w formie API
- frontend i backend tej samej aplikacji to tak naprawdę
dwie osobne aplikacje! Komunikują się właśnie za
API

12. KLIENT
(człowiek/użytkownik)
API
(przyjmuje instrukcje
i zwraca odpowiedzi)
SERWER
BAZA DANYCH
(komunikuje się z API)
zamawia potrawy kelner przyjmuje zamówienie
dostarcza zamówione potrawy
szef kuchni
przygotowuje potrawę zgodną
z zamówieniem

13. testowanie
backendu
testowanie
frontendu
- nie ma warstwy wizualnej – nie da się “wyklikać”
- testowanie odpowiedzi serwera i weryfikacja ich
poprawności
- wyższy próg wejścia dla testera
- można ”przeklikać” ręcznie
- niski próg wejścia (dla testów manualnych)
- można napisać testy automatyczne e2e (end-to-
end) symulujące zachowanie użytkownika

14. Obecnie testowanie backendu staje się coraz bardziej
popularne.
Dlaczego?
- w projektach pojawia się coraz więcej mikroserwisów
(kiedyś jedna aplikacja “robiła wszystko”, nie była
podzielona na mikroserwisy)
- mikroserwisy to oddzielne części tej samej aplikacji
- mikroserwisy komunikują się między sobą w ramach
aplikacji za pomocą API
- wykrycie błędów na etapie powstawania backendu jest
znacznie tańsze niż czekanie na etap,
gdy gotowy jest także frontend

15. Co to jest REST API?
• REST to styl architektury definiujący kształt API,
• REST API to API zgodne z architekturą RESTową,
• REST działa w oparciu o protokół HTTP
HTTP
• protokół komunikacji, z którego korzystamy codziennie podczas
przeglądania stron internetowych
• HTTPS to bezpieczniejsza, szyfrowana wersja protokołu HTTP

16. Co to jest SOAP API?
• SOAP to oparty na XML protokół przesyłania wiadomości
(nie jest stylem architektonicznym jak REST)
• wymaga większej ilości danych i zapewnia wysoki poziom bezpieczeństwa,
• jest najczęściej wykorzystywany w interfejsach programowania aplikacji
przeznaczonych dla instytucji finansowych

17. JAK TESTUJEMY BACKEND?
najczęściej testujemy requesty (zapytania) i sprawdzamy czy
odpowiedź jest zgodna z oczekiwanym rezultatem
• narzędzia używane do wysyłania requestów, m.in.:
• Postman (najbardziej popularny, wersja podstawowa jest
bezpłatna, w płatnej można zautomatyzować zapytania)
• Insomnia
• własne rozwiązania w tym automatyczne
• dodatkowo: Swagger UI – wizualizuje zasoby API, ułatwia
testowanie i zrozumienie architektury serwisu

18. CO TO SĄ REQUESTY?
- request to żądanie/zapytanie do serwera, na podstawie
którego serwer generuje odpowiedź (response)
- zapytania wysyłane są wraz ze zdefiniowaną
jedną z metod protokołu HTTP

19. CZYM SĄ METODY HTTP?
w zależności od celu naszego zapytania do serwera, używamy różnych
metod HTTP
GET
pobieranie danych, np. otwarcie wybranej strony
internetowej
POST
wysyłanie danych, dodawanie nowych elementów,
np. nowego użytkownika
PUT
podobna do POST, całkowita aktualizacja zasobu –
istniejące dane są nadpisywane
DELETE
skasowanie zasobu, np. skasowanie użytkownika z bazy
danych
PATCH podobna do PUT, ale aktualizuje tylko część danych,

20. przykład zapytania
cel: chcemy otworzyć stronę https://http.cat/
jako “zwykły” użytkownik po stronie frontendu:
- wpisujemu adres https://http.cat/ w przeglądarkę,
a odpowiedzią jest wyświetlona strona
po stronie backendu:
- wysyłamy zapytanie metodą GET https://http.cat/
- otrzymujemy odpowiedź z kodem 200 OK

23. bardziej skomplikowane zapytania
• składają się z nagłówka (header) oraz ciała (body)
• nagłówek:
• określenie metody HTTP
• określenie adresu URL
• ciało:
• dane, które wysyłamy do serwera
• z zasady jest opcjonalne, ale może być potrzebne by
otrzymać prawidłową odpowiedź

24. BODY /
CIAŁO ZAPYTANIA
HEADER / NAGŁÓWEK

25. kody odpowiedzi HTTP
• dane wysyłane z serwera w postaci kodu
• kod informuje o sposobie realizacji zapytania
(czy jest udane, czy nie)
• do kodu dołączony jest także opis słowny

26. najbardziej popularne kody (od 1xx do 5xx)
1xx Kody informacyjne
2xx Kody powodzenia
200 OK
3xx Kody przekierowania
301
trwale przeniesiony (gdy zasób/strona została przeniesiona
inne miejsce)

27. najbardziej popularne kody (4xx)
4xx Kody błędu po stronie klienta/użytkownika
400
nieprawidłowe zapytanie
(np. błędna składnia w body)
403
zabroniony – serwer nie może zwrócić zasobu, ze względu
konfigurancję bezpieczeństwa
404 nie znaleziono – serwer nie odnalazł zasobu

28. najbardziej popularne kody (5xx)
5xx Kody błędu po stronie serwera
500 wewnętrzny błąd serwera
503
usługa niedostępna
(może być to stan czasowy, np. ze względu na

29. kody odpowiedzi przedstawione jako koty 
 https://http.cat/

30. ŚRODOWISKA
W WYTWARZANIU OPROGRAMOWANIA

31. Proces wytwarzania oprogramowania
związany jest ze środowiskami:
developerskimi, testowymi, przejściowymi i
produkcyjnymi.

32. Środowiska mogą mieć różne rozmiary:
od stacji roboczej indywidualnego
programisty (komputer lub laptop),
po środowiska produkcyjne, które mogą
obejmować wiele maszyn rozproszonych
geograficznie
(w tym rozwiązania chmurowe)

33. Zagadnienie różnych środowisk i ich rola w
zarządaniu wdrażaniem aplikacji jest
powiązane ściśle
z CI/CD
(Continous Integration/
Continous Delivery)
[Ciągła Integracja/
Ciągłe Dostarczanie]

34. Ogólnie założenie polega na tym,
by stworzyć możliwość częstego
dostarczania przetestowanych,
bezpiecznych i sprawdzonych
zmian w kodzie.
CI/CD jest częścią metodyki DevOps

35. Poszczególne etapy wytwarzania
oprogramowania przeprowadzane są na
różnych środowiskach.
Środowiska są czasami nazywane
”instancjami” (np. instancja testowa).
Uwaga!
W różnych organizacjach podział środowisk może mieć
indywidualny kształt i się od siebie różnić.

36. środowisko opis
lokalne (local) lokalne środowisko na komputerze developera
developerskie
(dev / develop)
serwer developerski, na którym można wykonywać automatyczne
testy jednostkowe
często środowiskiem deweloperskim jest po prostu środowisko
lokalne programisty
testowe
(test / testing / QA)
środowisko, na którym można przeprowadzać testy interfejsu
użytkownika. Ze środowisk testowych korzystają głównie testerzy i
inżynierowie QA, by sprawdzić nowe funkcjonalności, a także
upewnić się, że nowy kod nie zepsuł czegoś w istniejących
funkcjonalnościach (testy regresji). Ze środowisk testowych
korzystają także programiści, gdy chcą sami przetestować swoje
rozwiązanie.

37. środowisko opis
pośrednie
(staging / pre-prod /
demo)
kopia środowiska produkcyjnego (docelowego)
w idealnym świecie powinna być to kopia 1:1
środowiska pośrednie mają na celu ostateczne sprawdzenie kodu
przed wrzuceniem go na serwery produkcyjne (czyli dla
użytkowników końcowych)
produkcyjne
(production / live)
środowisko produkcyjne lub “live” to środowisko, na którym
znajduje się ostateczna wersja oprogramowania, udostępniona
użytkownikom końcowym

38. TESTOWANIE APLIKACJI MOBILNYCH

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

40. Uwaga!
testowanie aplikacji mobilnych
to nie to samo co
testowanie mobilnej wersji aplikacji webowej

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

42. aplikacja
mobilna
vs.
mobilna
wersja
aplikacji
webowej

43. APLIKACJE MOBILNE
aplikacja natywna
- musi być napisana pod daną
platformę (Android, iOS)
- osobna wersja na system
operacyjny Android
(w językach Java lub Kotlin)
i osobna na iOS (w językach
Objective-C lub Swift)
aplikacja hybrydowa
- pozwala na stworzenie jednej aplikacji na
kilka systemów, z której część jest
współdzielona, a część napisana
indywidualnie pod daną platformę,
- tworzy się je na platformach opartych na
natywnych komponentach, np.
ReactNative, Flutter (język Dart) lub
Xamarin, które korzystają ze wspólnej
warstwy oraz natywnych komponentow
napisanych
w odpowiednich językach

44. Ze względu na różnice w natywnych
komponentach, teaoretycznie takie same
aplikacje mogą się różnić wizualnie, a
nawet mieć różne funkcjonalności na
Androidzie i na iOSie.

45. Android iOS
Huawei P
Smart iPhone 6s

46. Jak testujemy?
- na symulatorach na komputerze
np. z użyciem Appium lub Xcode
- w zewnętrznych narzędziach typu
BrowserStack lub SauceLab (emulatory lub
prawdziwe urządzenia udostępnione
chmurowo)
- na fizycznych urządzeniach

47. Największe wyzwania
- na symulatorach i emulatorach nigdy nie
mamy pewności, że są w 100%
odzwierciedleniem prawdziwych urządzeń
- mnogość różnych urządzeń mobilnych i
systemów – nie da się sprawdzić wszystkich

48. Największe wyzwania
- testy automatyczne dla Androida i iOSa będą
różnić się
- testowanie na iOSie wymaga trochę więcej
“zachodu” (konta developerskie, konfiguracje
związane z bezpieczeństwem)

49. SYSTEMY
PRZEGLĄDARKI

50. Tak jak w przypadku aplikacji mobilnych, także
aplikacje webowe mogą być testowane na różnych
systemach (Windows, MacOS, Linux)
Ułatwieniem jest tu fakt, że ich działanie jest
uspójnione w przeglądarkach internetowych i
teoretycznie na każdym z systemów powinny one
działać tak samo lub w bardzo podobny sposób.

51. Nie testujemy aplikacji webowej na wszystkich
możliwych systemach i przeglądarkach.
Najczęstszym z podejść jest określenie wspieranych
przeglądarek wraz z ich wersjami (np. Chrome i
Safari, dwie najnowsze wersje)
i testowanie tylko na tych wybranych.

52. Decyzję o wspieranych przeglądarkach najczęściej
podejmują osoby odpowiedzialne za produkt/aplikację, na
podstawie:
danych pochodzących z ogólnodostępnych źródeł (np.
statystyki użycia danych przeglądarek w wybranych krajach)
lub
danych analitycznych użycia tej konkretnej aplikacji (np.
gdy wiemy, że większość użytkowników używa Firefoxa,
testujemy na Firefoxie).

53. Co zrobić, gdy musimy przetestować coś na systemie lub
przeglądarce, której nie mamy na własnym komputerze?
Na rynku jest wiele narzędzi typu cross-browser,
oferujących dostęp do wszystkich ważniejszych systemów i
przeglądarek (także w starszych wersjach).
np. BrowserStack, SauceLab, Lambda Test
możemy je także wykorzystywać w testach automatycznych

54. DEVTOOLS

55. 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).

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

59. Najważniejsze funkcje Devtools
elements – zawiera renderowany kod HTML (drzewo DOM)
oraz style w CSS
możemy tutaj sprawdzić jakie elementy znajdują się
na stronie, określić lokatory dla testów automatycznych,
sprawdzić style i zarazem zmienić je tymczasowo w naszej
przeglądarce (np. kolory, krój pisma = fonty), sprawdzić z
jakich źródeł pochodzą obrazy i wiele innych

60. Najważniejsze funkcje Devtools
elements – analiza wersji mobilnej
zakładka elements posiada opcję symulacji różnych
rozdzielczości w tym dla urządzeń mobilnych – jest to
przedstawiająca tablet i telefon

62. Najważniejsze funkcje Devtools
console – konsola, w której możemy lokalnie wykonywac
kod, ale także odczytać błędy oraz ostrzeżenia (np.
ze skryptami JavaScript)

63. Najważniejsze funkcje Devtools
network (sieć) – tutaj możemy badać ruch sieciowy pomiędzy
serwerem a przeglądarką, w tym zapytania (requesty) oraz
odpowiedzi (response) wraz z kodami HTTP

64. Najważniejsze funkcje Devtools
application – tutaj znajdziemy zasoby ładowane przez
stronę, w tym ciasteczka (cookies) i tokeny
czyszcząc ciasteczka w tej zakładce otrzymamy zupełnie
“czystą” sesję użytkownika

65. ćwiczenie
otwieramy stronę
i widzimy, że jeden z
nie wyświetla się
co można na ten temat
znaleźć w Devtools?

67. Failed to load resource: the server responded with a status of 404 ()
book-4600757_1280-300x200.jpeg:1
404 nie znaleziono – serwer nie odnalazł zasobu
wniosek: zasób (obrazek) najprawdopodobniej został usunięty z serwera

68. Bardzo obrazowe ćwiczenia z devtools – szybkie i za darmo
https://testersplayground.herokuapp.com/devtoolschallenges.php

69. RÓŻNE TYPY I PODEJŚCIA
DO TESTÓW

70. 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 – np. po długim czasie gdy
jedna osoba ciągle przeprowadza te
same testy, czujność takiej osoby
spada)
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 

71. PRZYKŁAD DOBORU TESTÓW MANUALNYCH
I AUTOMATYCZNYCH
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

72. 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
PRZYKŁAD DOBORU TESTÓW MANUALNYCH
I AUTOMATYCZNYCH

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

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

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

76. TESTY JEDNOSTKOWE
- są to testy automatyczne, białoskrzynkowe
- zwykle pisane przez programistów
- sprawdzają ”jednostki” kodu (np. funkcję, klasę),
- są “oderwane od rzeczywistości” czyli nie są
w stanie sprawdzić czy cała aplikacja działa
prawidłowo
- z założenia testów jednostkowych powinno być
najwięcej (patrz: piramida testów - najniższy poziom
testów)

77. TESTY INTERGRACYJNE
- testują interakcje między modułami / mikroserwisami lub
systemami
- sprawdzają funkcjonalność, niezawodność i wydajność
systemu po integracji poszczególnych modułów ze sobą
- przeprowadzane po testach jednostkowych
- mogą być pisane przez programistów lub testerów
automatyzujących
- mogą być przeprowadzane manualnie przez testerów

78. TESTY E2E
- najwyższy poziom testów
- przeprowadzane z punktu widzenia użytkownika
(pełne scenariusze zachowań, od początku do końca)
- mogą być manualne i/lub automatyczne
- przeprowadzane głównie przez testerów
- testów end-to-end powinno być najmniej (najwyższy
poziom testów na piramidzie)

79. PIRAMIDA TESTÓW
testy e2e / testy GUI
testy integracyjne /
testy serwisów
testy jednostkowe /
unit testy

80. SYSTEMY
LOTNISKOWE
PRZYKŁAD
INTERGRACJI

81. DZIĘKUJĘ ZA UWAGĘ!
KATARZYNA.JAVAHERI@GMAIL.COM
JAVAHERI.PL