Cześć, Habr! Testujemy nowe formaty wydarzeń technicznych w Wrike i zapraszamy wszystkich do obejrzenia nagrania naszego pierwszego spotkania online w języku angielskim. o infrastrukturze DevOps do testowania aplikacji webowych, kubkach, Selenium i jego alternatywach.

Historia rozprzestrzeniania się koronawirusa oraz zakazy wszelkich masowych wydarzeń offline w Europie zmusiły nas do zmian, dlatego zaplanowane offline'owe spotkanie testerów i devopów Wrike w Pradze przeniosło się na YouTube.
Uwaga, prezentacje w języku angielskim.
1. Mikhail Levin, Wrike – Selenium — droga do Kubernetes
Pewnego razu Selenium żyło i rozwijało się. To prawdopodobnie najlepsza rzecz, jaka wydarzyła się w automatyzacji QA w ciągu ostatnich dwóch dekad, choć w wielu aspektach nie było to łatwe, w tym związanym z infrastrukturą i stabilnością.
Z wieloletnim doświadczeniem w infrastrukturze Selenium Grid i alternatywach, chciałbym przeprowadzić cię przez niektóre problemy i ograniczenia różnych infrastruktur Selenium aż do naszego nowego, lekkiego rozwiązania.

2. Vitaliy Markov, Wrike – Callisto: jak nauczyliśmy się przestać martwić i pokochać Selenium
Poznaj Callisto — nasze lekkie i otwarte rozwiązanie natywne dla Kubernetes do budowy infrastruktury Selenium. Uruchamiamy dziesiątki tysięcy testów Selenium w ciągu jednej godziny i przetrwamy setki codziennych uruchomień testów Selenium. Chcemy podzielić się naszymi powodami, samym rozwiązaniem oraz szczegółami technicznymi, które poznaliśmy po drodze. Nasze doświadczenie może być przydatne, czy uruchamiasz tyle testów Selenium, czy po prostu masz kilka sesji do uruchomienia w k8s w wielu wątkach.

3. Ivan Krutov, Aerokube – Protokół narzędzi dewelopera Chrome: uruchamianie i skalowanie w Kubernetes
Od wielu lat Selenium jest najpopularniejszym narzędziem do automatyzacji przeglądarek. Jednak protokół Selenium wciąż brakuje wielu ważnych funkcji: analizowania i symulowania żądań HTTP, uzyskiwania informacji o zużyciu pamięci i metrykach wydajności, subskrybowania zdarzeń aplikacji, otrzymywania ostrzeżeń o zabezpieczeniach przeglądarki i wielu innych. Na szczęście wszystko to jest już wspierane przez tzw. protokół narzędzi dewelopera Chrome. Prowadzi się wiele rozmów o tym, jak zacząć używać tego protokołu z bibliotekami klienckimi takimi jak Puppeteer, ale prawie nikt nie mówi, jak skalować to rozwiązanie. Podczas mojej prezentacji chciałbym wyjaśnić, jak skalować protokół narzędzi dewelopera Chrome w klastrze Kubernetes i pokazać kilka rzeczywistych przykładów, jak możesz wykorzystać ten protokół w swoich testach.

Źródło: habr.com
