This document discusses best practices for a large first Python and Selenium automation project. It recommends determining the available documentation, scope of testing, tools and infrastructure, design patterns, and project workflow before beginning coding. It also stresses the importance of non-coding tasks like choosing tools, designing architecture, and collaborating with other teams. The document provides examples of good practices like following PEP style guides, adding a README file, managing dependencies, hiding credentials, using waits instead of sleeps, designing independent parallel tests, and customizing reports.

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