Prezentacja z prelekcji w ramach Warszawskich Dni Informatyki (8-9 kwietnia 2021).

1. Pierwszy duży projekt w Pythonie i Selenium
Jak uniknąć pułapek?
Katarzyna Javaheri-Szpak
QA Automation Engineer, Promo.com
www.WarszawskieDniInformatyki.pl

2. 2
O mnie
Katarzyna Javaheri-Szpak
Obecnie pracuję jako tester automatyzujący w izraelskiej firmie
Promo.com. Tworzę testy dla platformy do tworzenia krótkich
filmów video.
Na co dzień programuję w Pythonie. Miałam też przygodę z testami
automatycznymi w Swifcie oraz z narzędziami wspomagającymi
automatyzację jak Ranorex, Katalon czy Test Project.
W branży IT pracuję prawie 5 lat. Zaczynałam jako WordPress
administrator, a potem developer. Sentyment do WordPressa
pozostał mi do dziś. Zapewnianiem jakości oprogramowania
zajmuję się 3,5 roku, w tym 2,5 roku automatyzacją.

3. 3
Agenda prezentacji
1. Dla kogo jest ta prezentacja?
2. Dlaczego Python i Selenium?
3. Pierwszy duży projekt – jak zacząć?
4. Nie samym kodem tester żyje
5. Dobre praktyki – stadium przypadku

4. 4
1. Dla kogo jest ta prezentacja? J
Najwięcej z mojej prezentacji wyniosą testerzy automatyzujący na poziomie
początkującym i początkującym+, piszący w Pythonie oraz Selenium.
Testerzy piszący w innych językach również mogą wykorzystać ogólne flow
projektowe.
Skorzystać mogą także inżynierowie bardziej zaawansowani programistycznie,
ale nie mający doświadczenia w pracy zespołowej i projektowaniu rozwiązań
od zera dla większych projektów.
Prezentacja może być również instrukcją dla testerów manualnych, którzy chcą
wprowadzić automatyzację w swoich zespołach lub firmach.

5. 5
2. Dlaczego Python i Selenium?
Python nie jest rynkowym liderem.
Jest to język ze stosunkowo niskim progiem wejścia, ma
intuicyjne frameworki do testów (PyTest) oraz mnóstwo
dodatków I gotówców wspomagających pracę testera
(https://pypi.org/).
Dane z 2020 roku, z applitools.com dotyczące języków
programowania używanych w testach UI.
Python zajmuje 4. miejsce. Liderem jest Java.
Ankieta StackOverflow z 2019 r. Python zajmuje:
2. miejsce w kategorii najbardziej kochanego języka ❤
1. miejsce w kategorii najbardziej pożądanego języka
43%
35%
9%
8%
4%
1%
JĘZYKI PROGRAMOWANIA W
AUTOMATYZACJI TESTÓW
Java JavaScript C# Python Ruby Inne
https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted

6. 6
2. Dlaczego Python i Selenium?
Selenium WebDriver wraz z którymkolwiek ze
wspieranych języków programowania (Python, Java,
Ruby, C#, JavaScript) to najbardziej popularne
narzędzie do automatyzacji testów (ok. 27% rynku wg
raportu enlyft.com).
Poważną konkurencją dla Selenium jest bazujący na JavaScripcie
Cypress oraz rozwiązania typu codeless, które przez ostatnie lata
stały się bardzo popularne, a trend ten będzie wzrastał.
Pomimo tego, Selenium to wciąż mocny zawodnik.
ü darmowe,
ü daje duże możliwości w dostosowaniu do danego projektu,
ü ma ogromne wsparcie społeczności
27%
11%
10%
8%
44%
RYNEK AUTOMATYZACJI
TESTÓW
Selenium
Apache Jmeter
HP Unified
Functional Testing
HP Quality Center
Inne
dane wg enlyft.com

7. 7
3. Pierwszy duży projekt – jak zacząć?
Co to znaczy “duży projekt”?
Na potrzeby niniejszej prezentacji, przyjmuję, że “duży projekt” to projekt oszacowany na co
najmniej 3 miesiące dla 2-osobowego zespołu QA, w którym od zera musimy wybrać
narzędzia, procedury czy metodykę.
Przykłady:
Ø automatyzacja funkcjonalnych testów regresywnych dla gotowego produktu, wraz z
zarządzaniem kontami, uprawnieniami wynikającymi z zakupionych abonamentów, pokrycie
od zera ścieżek krytycznych, typowych ścieżek czynności oraz najważniejszych ścieżek
pobocznych
Ø automatyzacja funkcjonalnych testów dymnych (smoke tests) dla bardzo rozbudowanego,
gotowego produktu, pokrycie typowych ścieżek czynności od zera

8. 8
3. Pierwszy duży projekt – jak zacząć?
Wyzwania i pytania, które należy zadać zanim zaczniemy kodować:
ü określenie dostępnej dokumentacji,
ü określenie zakresu testów,
ü wybór narzędzi i infrastruktury,
ü wybór wzorców projektowych,
ü określenie flow projektowego,
ü procedura egzekucji testów,
ü określenie kolejności kodowania scenariuszy,
ü określenie postępowania po zakończeniu projektu
Komu zadać te
pytania?
- sobie
- w zespole
- seniorowi z innego
zespołu
- product menagerowi
- product ownerowi

9. 3. Pierwszy duży projekt – jak zacząć?
Określenie dostępnej dokumentacji
• Czy jest dostępna dokumentacja
produktowa i testowa (np. specyfikacja,
oczekiwane rezultaty, czy scenariusze
wykonywane manualnie są spisane oraz
utrzymywane, kto jest za nie
odpowiedzialny)
• Czy znane są ścieżki krytyczne i inne
ważne ścieżki z biznesowego punktu
widzenia
Określenie zakresu testów
• Czy wiemy jaki jest główny cel naszego
projektu?
• Jakie biznesowe korzyści mają przynieść
nasze testy?
• Czemu dokładnie mają służyć nasze
testy? Co mają sprawdzać?
• Jakie platformy należy uwzględnić (web,
mobile, aplikacje mobilne)
Uwaga! Nierealne jest pokrycie
automatyzacją tzw. “wszystkiego”.
9

10. 3. Pierwszy duży projekt – jak zacząć?
Wybór narzędzi i infrastruktury
• Jakie narzędzia do automatyzacji będą
najbardziej optymalne?
• Czy mamy zaplecze CI/CD oraz osoby
umiejące zintegrować kod z tymi
narzędziami?
• Środowiska lokalne, zdalne, Selenium
Grid, platformy typu BrowserStack,
SauceLabs
• Projekt powinien być gotowy do
uruchomienia już po zakodowaniu
pierwszego scenariusza
Wybór wzorców projektowych
• Jakie wzorce pozwolą nam na
skalowanie projektu i utrzymanie jego
czytelności?
• Czy przyjęta architektura nie
doprowadzi nas do spaghetti kodu lub
duplikowania kodu?
• Dane testowe, dane logowania – nie
hardkodujemy, nawet w początkowej
fazie „na szybko”.
10

11. 3. Pierwszy duży projekt – jak zacząć?
Określenie flow projektowego
• Nawet do małych projektów warto
stworzyć repozytorium, pracować z GITem
i wypracować flow podobne jak w
przypadku tworzenia „zwykłego”
oprogramowania (code review, testowanie
testów)
• Zasady nazewnictwa branchy,
mergowania (kto będzie miał uprawnienia
merge do master?)
• Określenie wymagań dla kodu, który
będzie wykorzystywany produkcyjnie
(czytelność).
• Nie „przetrzymujemy” kodu u siebie
lokalnie, wszystkie zmiany powinny trafiać
do repozytorium
Procedura egzekucji testów
• Kto będzie uruchamiał testy (człowiek,
narzędzie)?
• Gdzie będą uruchamiane testy (lokalnie,
na zdalnym środowisku)?
• Na jakich środowiskach będą
uruchamiane testy (testowych,
produkcyjnym)?
11

12. 3. Pierwszy duży projekt – jak zacząć?
Określenie kolejności kodowania
scenariuszy
• Określenie priorytetów w kodowaniu
scenariuszy – nie kodujemy „po kolei”
lub wg własnego uznania
• Jeśli nikt nie narzucił priorytetów
odgórnie, na pierwszy ogień powinny
iść:
• Wymagające najczęstszego powtarzania
• Określone przez product ownera (lub innego
przedstawiciela biznesu) jako krytyczne lub
priorytetowe
• Wymagające największego nakładu czasu
przy testowaniu manualnym
Określenie postępowania po
zakończeniu projektu
• Projekt ukończony i co dalej?
• Kto będzie utrzymywał testy, analizował
potencjalne false positivy i false
negativy
• Kto będzie modyfikował i dopisywał
nowe scenariusze w razie potrzeby?
12

13. 4. Nie samym kodem tester żyje
W przypadku, gdy w naszym projekcie nie ma architekta testów,
menedżera testów i/lub pisarza technicznego, umiejętność
kodowania jest tylko (co najwyżej!) połową sukcesu.
Wybór narzędzi, zaprojektowanie architektury, zapewnienie danych testowych (generator,
baza danych), flow projektowe, współpraca z devopsami, developerami i biznesem, praca
koncepcyjna, sporządzanie dokumentacji – są tak samo ważne!
13

14. 5. Dobre praktyki
- studium przypadku

15. 5.1. Dobre praktyki – stosowanie PEP
PEP = Python Enhancement Proposal
Zbiór reguł dotyczących gramatyki Pythona, czyli jak pisać czytelny kod
PEP 8 - Style Guide for Python Code (reguły pisania kodu)
PEP 257 - Docstring Conventions (reguły pisania komentarzy do
segmentów kodu)
Gdzie znaleźć?
https://www.python.org/dev/peps/
15

16. 5.1. Dobre praktyki – stosowanie PEP
PyCharm wspiera PEP – podpowiada, podkreśla
(np. odpowiednie odległości, duplikaty kodu, format komentarzy)
16

17. 5.1. Dobre praktyki – PEP 257 - docstrings
17

18. 5.2. Dobre praktyki – plik readme
Każdy projekt powinien zawierać plik readme z:
- strukturą plików
- opisem użytych technologii, bibliotek
- instrukcją konfiguracji (jeśli dotyczy)
- instrukcją uruchamiania testów, skryptów
- innymi przydatnymi informacjami
18

19. Całość: https://github.com/javaheri2016/parentland_tests_behave/blob/main/README.md
Wskazówki: https://www.makeareadme.com/
19

20. 5.3. Dobre praktyki – plik gitignore
W pliku gitignore zamieszczamy przykładowo:
- pliki konfiguracyjne i systemowe,
- pliki z danymi testowymi (np. zawierające hasła)
- wszelkie pliki „śmieciowe”, cache
- lokalne raporty,
Przyjazny generator: https://gitignore.io/
20

21. 5.4. Dobre praktyki – zarządzanie zależnościami
Plik requirements.txt z listą zależności, które są wymagane by
uruchomić projekt
Dopisywanie zależności ręcznie przy dużym projekcie jest
pracochłonne
Rozwiązanie na wpół automatyczne – pip-tools
https://github.com/jazzband/pip-tools
21

22. 5.4. Dobre praktyki – zarządzanie zależnościami
22

23. 5.5. Dobre praktyki – dane testowe, klucze
23
Nie hardkodujmy danych do kont testowych czy
kluczy w projekcie nawet jeśli nie są to dane niejawne
Ukrywajmy je w zmiennych środowiskowych
(lokalnie, w zmiennych w projekcie na GitLabie itp.)

24. 5.5. Dobre praktyki – dane testowe, klucze
24
Źródło:
BrowserStack

25. 5.6. Dobre praktyki – czekanie na element
- sleep w Pythonie 😒
25
• waity w Selenium (metody czekające) 🙂

26. 5.7. Dobre praktyki – testy równoległe
Jeśli zakładamy wykonywanie testów równoległych, musimy tak
je zaprojektować, by były maksymalnie od siebie niezależne
Przykład test planu:
- 1. scenariusz logowania, zakupu i wylogowania
- 2. scenariusz zmiany hasła
Muszą opierać się na innych kontach użytkownika
26

27. 5.8. Dobre praktyki – być na bieżąco
27
Warto monitorować update’y Pythona, Selenium i bibliotek
Mogą się zdarzyć ostrzeżenia (warnings), które mogą się
przerodzić w błędy (errors)
Przykład:
Selenium 3 + Python 3.9 + scenariusz z uploadem plików

28. 5.8. Dobre praktyki – być na bieżąco
28

29. 5.9. Dobre praktyki – raportowanie
29
Domyślne raportowanie w Pythonie i Selenium jest ubogie
Niejasne raporty opóźniają analizę problemów i identyfikację
wyników fałszywie negatywnych
Warto indywidualnie rozszerzyć raporty według potrzeb
Przykłady:
- PyTest HTML
- PyTest Cov
- Allure (dla PyTest, Behave, Nose)
- dostosowanie testów do narzędzi zewnętrznych (np. skryptami
JavaScript dla BrowserStacka)

30. 5.10. Dobre praktyki – znajdowanie elementów
Stabilne i szybkie znajdowanie elementów to stabilne testy
Należy dobrze dobrać lokatory = wyszukiwanie po:
• ID CSS: find_element_by_id
• klasa CSS: find_element_by_class_name
• nazwa atrybutu: find_element_by_name
• xpath: find_element_by_xpath
• tekst w linku: find_element_by_link_text
• częściowy tekst w linku: find_element_by_partial_link_text
• tag: find_element_by_tag_name
30

31. 5.10. Dobre praktyki – znajdowanie elementów
Xpath absolutny L
/html/body/div[1]/div[2]/div/img
Xpath relatywny J
//IMG[@class="lnXdpd"]
31

32. 5.10. Dobre praktyki – znajdowanie elementów
Własne atrybuty do elementów
Np. data-testid na Facebooku
32

33. 5.10. Dobre praktyki – znajdowanie elementów
Błędy „interception”
Wyskakujące okienka, zasłaniające elementy chat
czy pop-upy.
33

34. 5.11. Dobre praktyki – WebDriver Manager
Wygodne rozwiązanie dla środowiska lokalnego
Zapomnij o aktualizacji driverów – wszystko zrobi się
samo
https://pypi.org/project/webdriver-manager/
34

35. 5.11. Dobre praktyki – WebDriver Manager
35

36. 5.11. Dobre praktyki – WebDriver Manager
36

37. Dziękuję za uwagę!
Katarzyna Javaheri-Szpak
@kjavaheri
37

38. Dziękujemy za oglądanie!
Zapraszamy do zadawania pytań
oraz oceny prelekcji pod nagraniem. ↘
www.WarszawskieDniInformatyki.pl