Opis prelekcji

Warsztat: TIPS&TRICKS ZANIM ZACZNIESZ AUTOMATYZOWAĆ TESTY! SELEKTORY I JAVASCRIPT (poziom podstawowy)

Patrycja Tomaszewska, Jakub Rosiński 

Prowadząc warsztaty automatyzacji, w których uczestniczą bardzo różne osoby zauważamy z pewnym smutkiem, że wiele z nich łączą podobne braki. Nie dotyczą ani samego Selenium, ani języków programowania, w których piszą testy. Mówimy o dwóch umiejętnościach, które co prawda nie są konieczne, by automatyzować, ale zdecydowanie ułatwiają i pomagają w efektywnym wykorzystaniu możliwości, jakie otwiera Selenium.

Mowa o umiejętnym tworzeniu selektorów (tak css, jak i xPath) oraz użyciu javaScriptu jako wsparcia w testach Selenium.

W czasie naszego warsztatu (podzielonego na dwie części, ale jednak nie całkiem rozdzielne) uczestnicy nauczą się pisać krótkie, czytelne i bardziej odporne lokatory, oraz wykorzystywać javaScript aby usprawniać i ułatwiać sobie pracę w Selenium.


Warsztat: SELENIUM + JAVA - PODSTAWY AUTOMATYZACJI APLIKACJI WEBOWYCH (poziom podstawowy)

Jan Sabak, Grzegorz Holak 

Warsztaty składają się w całości z zajęć praktycznych. Program warsztatów:

  1.       Utworzenie i skonfigurowanie projektu
  2.       Otwieranie stron i nawigacja w przeglądarce
  3.       Zmiana kontekstu w okienku przeglądarki
  4.       Screenshoty
  5.       Lokalizacja elementów GUI
  6.       Pobieranie stanu elementów GUI
  7.       Interakcja z elementami GUI
  8.       Obsługa alertów
  9.       Wykorzystanie waitów

Uczestnicy proszeni są o przyniesienie na warsztaty własnych laptopów o konfiguracji sprzętowej minimum Intel Core i5, 8GB RAM, 10GB wolnego miejsca na dysku. Na laptopach powinna być zainstalowana Java w wersji minimum 8 oraz IntelliJ IDEA.

Alternatywnie może zostać zainstalowany VirtualBox, ponieważ na warsztaty zostanie dostarczona maszyna wirtualna ze wszystkimi potrzebnymi narzędziami.


Warsztat: AUTOMATYZACJA TESTÓW - STRATEGIE, METODY, NARZĘDZIA. WARSZTAT PRAKTYKÓW (poziom średniozaawansowany)

Łukasz Burczak, Piotr Ślęzak 

Forma warsztatu to swobodna dyskusja z flipchartem i karteczkami, na których zapisujemy tematy, a potem wspólnie je omawiamy. Stawiamy na otwartą debatę uczestników, w której my obejmiemy funkcję moderatorów, jest to najbardziej efektywny sposób wymiany wiedzy. Uzupełnimy dyskusję swoimi doświadczeniami, znajomością metodyk i narzędzi.

Po warsztacie zbieramy wyniki i opisujemy całość w podsumowaniu warsztatów. Każdy z uczestników dostaje takie podsumowanie z zebraną wiedzą z danego tematu omawianego podczas warsztatów.


Warsztat: OD ZERA DO BOHATERA - TESTY SELENIUM Z WYKORZYSTANIEM FRAMEWORKA SERENITY BDD (poziom zaawansowany)

Maciej Lorenc 

Jak napisać test z wykorzystaniem Cucumbera aby był czytelny dla biznesu i zrozumiały dla zespołu? Jak przygotować implementację scenariusza, aby testy były stabilne i nie wymagały sporych nakładów pracy na ich utrzymanie? Jak dobre praktyki programowania obiektowego można zastosować w automatyzacji testów? Jak stosować obiekty domenowe?

To tylko niektóre pytania, na które odpowiedzi będą efektem naszej wspólnej pracy. Celem warsztatu jest pokazanie jak napisać test end-to-end od A do Z oraz jak sobie radzić z problemami podczas implementacji.

Zakres warsztatu jest bardzo szeroki, dlatego chciałbym, aby to uczestnicy mieli wpływ na jego ostateczny kształt. Co za tym idzie? Uczestnicy warsztatu nie mogą być “kompletnie zieloni” w temacie ;), powinni znać podstawy programowania w Javie oraz doświadczenie w pisaniu testów z wykorzystaniem Selenium.


Prelekcja: Automated Regression Testing with AET in continuous delivery 

Radek Lawgmin, Maciej Laskowski

Testing a site for common errors and tracking visual changes throughout its development may turn out to be a key aspect of continuous software delivery lifecycle. Moreover, regression testing across a range of environments is expensive and time-consuming.

Improve the quality of your site and at the same make your development process more efficient and cheaper. Automate your regression (visual comparison and page health checks) with AET, an open-source selenium-based testing tool for everyone, no matter if you are a QA engineer, a developer or a content author!

AET allows for automated change supervision by comparing the actual version of your site (visual and source regression) to its pattern approved before by the user along with its validation against accessibility and W3C guidelines and testing status codes for HTTP responses.

The tool has been used in various projects realized at Cognifide and our clients for over 7 years and it went open source 2 years ago. During the lecture Radek and Maciej will take you on a journey through test automation experiences showing:

  • how easy you can launch automated tests for your pages with AET,
  • how quickly you can analyze their results,
  • how aptly you can identify issues related to them,
  • benefits of the implementation of AET in various projects realized at Cognifide.

Prelekcja: Piramida testów - geneza i praktyka

Natalia Krawczyk-Grzegorzewicz

Wiele mówi się o piramidzie testów w automatyzacji. Słyszymy, że tak należy robić, że tak trzeba. Niektórzy ślepo próbują ją implementować, z sukcesem lub nie.

Niektórzy wciąż ufają jedynie testom Selenium.

Żeby lepiej zrozumieć piramidę testów na początku opowiem o 2 typowych architekturach: monolitach oraz mikroserwisach.

Zastanowimy się dlaczego wcześniej nie było tak głośno o piramidzie testów oraz jak próbujemy testować aplikacje na mikroserwisach.

Czy od razu udaje nam się wdrożyć piramidę? Jakie błędy popełniamy?  

Podczas prelekcji opowiem o tym jak wygląda taka piramida w praktyce. Etap po etapie. Poziom po poziomie. Z podziałem na to co testujemy na froncie, a co na backendzie.

Na końcu przedstawię przykładową architekturę aplikacji webowej i opowiem jak dzięki piramidzie testów możemy szybciej wdrażać zmiany na systemy produkcyjne.


Prelekcja: Tips for building Selenium framework

Igor Domin (ENG)

There are quite a lot of ready-to-use test frameworks on the market, including open source as well as commercial versions. So why to invest in own “Selenium from the scratch” framework? Adopting existing test framework to all testers’ and managers’ needs is quite time consuming and definitely not an easy task. Moreover, dependency on third-party vendor or community may have a negative impact on testing process.  Selenium, which is based on Java, can be a very powerful tool in terms of creation test scenarios for variety of projects with different structure and test expectations. However, this solution has its own pitfalls so it can ruin all efforts and impression.

At the beginning, tester has to define how to locate elements on a page. Available options are css, xpath, classname, name, id, etc. The most appropriate should be defined according to page structure. But in most cases using just one type is not enough. So tester has to create separate methods to handle different selector types. As an alternative, Selenium class ByAll can be used, when tester can configure element search by several selector types in one go. I’ll also show how to build similar class that will always search elements by all available selector types.

Next point is when selectors are used directly in test methods, which leads to a situation in which test cases immediately became unsupportable. I will show how to build and use locators repository, based on Java properties functionality.

Also, there is a common opinion that Selenium is working really bad on dynamic pages, full of javascript. Just slowing down Selenium execution is not an option here. I will propose a solution of wrapping any interaction with any element in a page with Expected condition wait. For example, wait until element is present on page, is visible, is clickable and so on. However, as this approach is not a silver bullet as well, I will describe situations, when it may fail, and show how it can be addressed with re-trying to perform failed action. As an option, some kind of conditional re-try can be used, when checking page state and deciding if action was performed successfully or it has to be repeated.

Next section will be dedicated to test cases structure and organization. I will briefly describe principles of Page Object (POP) and Page Factory patterns. In some cases this approach totally fits testing needs, but for complex web applications with lots of dynamic page content and layout defining proper Objects and methods will bring quite a big preparation and maintenance overhead. As an alternative I’ll show an approach with several abstract levels, so tests will be separated from implementation like in POP, but implementation level is in Action style. So there is a list of options what can be done on a page, but no info about elements on page is kept and interaction is done only when it is needed.

At the end I will show how to split and reuse created framework. It’s possible to distinguish some part of framework that can be used in several projects. For example it may be a browser creation and managing functionality together with the lowest abstract level of tests. So it can be placed as a separate “base framework” project and used in several test projects as a dependency.


Prelekcja: Loki i Thor - czyli o projektach, które powinny być zautomatyzowane, a nigdy nie zostały

Emil Bakalarz

Każdy chciałby automatyzować testy – tak, wierzmy w to. Bo czemu by nie? Przecież automatyzacja ułatwia i przyspiesza wiele aktywności testerskich. Mimo to, często gdy w salce, na spotkaniu projektowym pada pytanie „Automatyzujemy?” zapada cisza. Dlaczego tak się dzieje? Dlaczego z dwóch, potencjalnie łatwych do automatyzacji projektów tylko jeden dorobi się testów i to dopiero po kilku latach? Na te i podobne pytania odpowiemy sobie na przykładzie dwóch projektów.


Prelekcja: Jak Selenium znajduje elementy?

Maciej Wyrodek

Jeśli Automatyzujesz testy UI to jest wysokie prawdopodobieństwo że używasz Selenium albo bezpośrednio albo jakieś narzędzie które jest zbudowane na bazie selenium.

Ale czy wiesz jak Selenium działa? Jak obsługuje przeglądarkę?

Jak “znajduje elementy?”  - Jeśli chcesz zaspokoić swoją ciekawość to prezentacja dla ciebie!

Ok Ciekawość to za mało? Chcesz więcej powodów? To masz:

Dobre zrozumienie narzędzi to podstawa, musimy rozumieć ich silne strony, słabe jak i ich limitacje.  Gdy to zrozumiemy nagle te dziwne “stale element excepiton” przestają być dziwne.

Pozwala nam to lepiej zaplanować co chcemy zrobić i jak to chcemy zrobić. Dzięki temu nasze automaty są stabilniejsze i szybsze!


Prelekcja: Automatyczne utrzymywanie lokatorów elementów

Vojin Popovic

Wykład będzie zawierał:

  • Krótkie wprowadzenie do Selenium page object model-u
  • Krótkie wprowadzenie do Angular struktury kodu
  • Instrukcje dotyczące analizy Angular kodu w celu znalazinia elementow, które będą zautomatyzowane
  • Demo kodu, który analizuje Angular kod w c#
  • Jak automatycznie generować xPath
  • Demo kodu generującego xPath
  • Jak generować page object modele
  • Jak połączyć testy Selenium z wygenerowanym kodem
  • Demo testów uruchomionych na wygenerowanym kodzie
  • Krótki przegląd, jak osiągnąć to samo z React i MVC
  • Kluczowe zalety tego podejścia
  • Pytania

Prelekcja: BDD with Selenium and SpecFlow using C#

Volodymyr Romanyshyn

This talk will be focused on following goals:

  1. Creating STABLE with understandable code tool for testing
  2. Show advantages of:
    • Lazy implementation
    • PageObject pattern
    • BDD approach (especially using generic steps)
  3. Showing approach how to build clean code tests.

Prelekcja: Docker z perspektywy QA Automation

Tomasz Konieczny

Dlaczego automatyzujemy testy regresji? Jednym z powodów może być chęć zaoszczędzenia czasu w porównaniu do ich powtarzalnego wykonywania w sposób manualny. Dlaczego nie zautomatyzować również procesu tworzenia oraz utrzymania środowisk testowych? Tu pojawia się koncept Infrastructure as Code. Podczas prezentacji zostanie pokazane jak Docker może ułatwić pracę osób zajmujących się automatyzacją testów.

Plan prezentacji:

  • Wprowadzenie do Dockera (czym jest Docker, jak działa, jak może ułatwić pracę projektową, funkcjonalności przydatne dla QA itp.)
  • Infrastructure as Code
  • Docker Compose
  • Reużywalne środowiska developerskie oraz testowe na bazie Docker Compose
  • CI/CD (Drone)

Prelekcja: Java i Appium vs Swift i Kotlin, czyli o samotności testera automatyzującego testy aplikacji mobilnych

Piotr Baran

Automatyzacja testów natywnych aplikacji mobilnych niesie wiele wyzwań. W swoim wystąpieniu zaprezentuję dylematy, przed jakimi stanęliśmy wybierając narzędzia do testów oraz lessons lerrned po przeszło roku tworzenia automatów w Javie z Appium. Czy był to lepszy wybór niż natywne frameworki iOSa (testy UI w Swift) i Androida (np. Espresso)? Jakie zalety i wady ma Appium z perspektywy nie tylko technicznej, ale także organizacji pracy zespołu? Wystąpienie będzie podsumowaniem wniosków wyciągniętych z przeszło rocznej pracy nad frameworkiem do testów UI aplikacji natywnych w Javie.


Prelekcja: BackStopJS - jak uniknąć regresji wizualnej naszej aplikacji www?

Michał Ślęzak

Czy miałeś kiedyś problem z wizualną regresją w swojej aplikacji www? Jeżeli tak ta prezentacja jest dla Ciebie! Zaprezentuje w niej narzędzie jakim jest BackStopJS, które pozwala te regresje wychwytywać pod kątem wizualnym. Próg wejścia również jest prosty, bo do konfiguracji używam głównie jednego pliku .jsonowego. Również po pokazaniu jako konfigurować, pokażę jak spiąć to narzędzie z jenkinsem i otrzymywać raport np. na slacka, jeszcze przed deployem!


Prelekcja: Selenium w służbie Analytics’ów – (nie)zwykłe podejście do zwykłego problemu 

Grzegorz Witek

Techniczne studium przypadku historii implementacji nowego rozwiązania do frameworka opartego na Selenium. Wdrożenie nowego rozwiązania zostało podyktowane wymaganiami klienta, którym była inna grupa dewelopersko-testerska. Projekt miał na celu przeprowadzenie testów poprawności zbierania danych przez aplikację webowa, a następnie wysyłania w ten sposób zgromadzonych danych do Google Analytics.

Pierwsza część prezentacji pokaże standardowe problemy, z którymi można się spotkać w trakcie pracy z klientem podczas tworzenia i rozwijania projektu informatycznego. W tym przypadku dokładniej zostaną ukazane problemy związane ze zbieraniem wymagań od klienta w celu napisania testów automatycznych. Pokazane zostanie, że wyzwaniem może być nie tylko bariera językowa i kulturowa, ale również specyficzne słownictwo używane przez dany zespół. Rozbudowana hierarchia zespołu i komunikacja przez wielu managerów, którzy nie są osobami technicznymi może dodatków utrudnić proces zbierania wymagań i zaciemnić obraz, tego czego oczekuje klient, czyli zespół deweloperski. Tak samo niepełne informacje lub zbyt wielkie uogólnienia mają znaczny wpływ na proces zbierania wymagań, a w dalszej części na estymację projektu.

W tej części zostaną także ukazane narzędzia, które można używać podczas testowania aplikacji webowej i połączenia jej z Google Analytics. Omówione będą narzędzia, które były wykorzystywane przez zespół deweloperski i testerów manualnych w trakcie rozwijania aplikacji. Następnie zostanie pokazana próba przeniesienia sposobu testowania aplikacji przez testerów manualnych na proces automatyczny, tak aby samo wdrożenie automatyzacji nie spowodowało wyrzucenia efektów pracy zespołu manualnego. Zostaną tutaj też pokazane narzędzia i biblioteki do testów automatycznych, które były brane pod uwagę podczas planowania automatyzacji, a następnie użyte podczas tworzenia Proof of Concept. Będzie tutaj także pokazane kilka różnych pomysłów na testy automatyczne Google Analytics, oraz omówione wady i zalety każdego z nich.

W ostatniej części, która będzie bardziej częścią techniczną, zostanie dokładniej omówione ostateczne rozwiązanie, oraz powody dla których zostało właśnie ono wybrane. Dodatkowo pokazana zostanie przykładowa implementacja z wykorzystaniem omówionych bibliotek. Opisane zostanie jak współdziała zaimplementowane rozwiązanie wykorzystujące proxy z Selenium, a także w jaki sposób można zbierać dane z DataLayer, czyli  Tag Manager’a dostarczanego przez Google i używanego w tym konkretnym projekcie. Dalej zostaną omówione możliwości wykorzystania zaimplementowanego rozwiązania w innych rodzajach testów, a także możliwości jego rozwoju. Na samym końcu tej części będzie także zaprezentowane demo działającego rozwiązania na przykładowej stronie internetowej.

W podsumowaniu wyszczególnię błędy jakie zostały popełnione w trakcie trwania projektu, jak można było ich uniknąć i co można jeszcze było poprawić w projekcie. Jakie możliwości dała praca przy tym projekcie, zarówno ze strony technicznej jak i zdobytej wiedzy podczas zbierania wymagań. No i dlaczego 15-osobowa grupa testerów manualnych jest lepsza niż dwóch testerów automatycznych 😉


Prelekcja: Obiekty domenowe w testach e2e

Maciej Lorenc

Obiekt domenowy to reprezentacja pewnych obiektów z domeny testowanej aplikacji. Przykładowo odwzorowanie produktu czy wręcz całego koszyka sklepu internetowego (produkty, ich liczba, cena, itd.). Zastosowanie obiektów domenowych w testach e2e aplikacji może znacznie ułatwić ich tworzenie oraz utrzymywanie, w szczególności upraszczając interfejsy obiektów stron.

W ramach prelekcji zostanie przedstawiona koncepcja użycia obiektów domenowych w testach e2e, przykłady implementacji oraz omówione zalety oraz wady tego rozwiązania.

Treść wystąpienia będzie ideowo przebiegać zgodnie z artykułem opracowany dla portalu justgeek.it dostępnego pod adresem:

https://geek.justjoin.it/obiekty-domenowe-testach-e2e/

 


Prelekcja: Improving Test Run Time moving to AWS Lambda

Varuna Srivastava (ENG)

Over time, we had created a significant set of Selenium tests which we were running over a Selenium Grid. The runtime had reached five hours, and we were feeling the pain in the feedback delays which revealed the need for parallel execution. Previously, we used the Selenium Grid Docker container for each test run. This way, we were able to run 5 concurrent threads for test execution, which took an average of 45 minutes.

We had to scale test but we couldn’t run more than 5 concurrent tests as the containers hit performance issues and we had a hard time getting reliable tests outcome. This led us to move to AWS Lambda.

AWS Lambda is a way of buying compute time as a service in the cloud.

In this talk, I will explain how we started with a very small suite of five tests to first build the AWS Lambda infrastructure, learn to use the tools of working in the new environment and achieve reliability of the test runs over a timeframe of 45 days. I will walk you through how we selected to move all tests in feature-based batches, with a continuous focus on the reliability of the tests. I will explain from our challenges on the way to now run all our tests within the timeframe of the longest test, improving our feedback time significantly.

As part of Demo, I will walk through a sample project in Github where I will explain how we can scale our UI tests using AWS lambda.

Outline/structure of the Session

  1.  Challenges faced in the project and why we moved away from selenium grid to Lambda.
  2.  What is AWS Lambda and How does it work?
  3.  How does AWS Lambda help in scaling tests?
  4.  Demonstration:  
    • How to write a first lambda function
    • How to run and scale the tests
    • How to view results in aws console

Key takeaways:

  • How to get started with writing the first lambda function
  • How to make your existing test run as part of Lambda.
  • How to set up infrastructure in AWS to run tests there
  • How to focus on reliability in small batches
  • What are the differences in running tests on AWS Lambda vs Selenium Grid

Prelekcja: Czas na Flutter! - Wprowadzenie do testów UI

Adam Stasiak

W swojej prelekcji chciałbym dotrzeć do testerów, programistów którzy dopiero zaczynają przygodę z aplikacjami mobilnymi cross-platform, czyli takich które pozwalają na pisanie jednego kodu - który uruchomiony może być na Androidzie i systemie iOS. Pozwala to oszczędzić czas w czasie developmentu i uprościć cały proces wytwarzania aplikacji. Nie chcąc zamykać się na potrzeby programistów - zaprezentowane będą informacje które ucieszą także programistów chcących rozpocząć automatyzację testowania wizualnych rezultatów ich pracy.

Moja prelekcja to połączenie biznesowej zajawki - po co nam w ogóle aplikacje cross-platform, w jaki sposób wpływa to na zespoły oraz jak tego typu produkty radzą sobie na rynku, oraz technicznego zastrzyku wiedzy. W tej narracji chciałbym przedstawić czym jest Flutter i dlaczego powstał. Omówię dlaczego warto zdecydować się właśnie na ten framework a nie np. na Xamarin czy React Native. Opowiem jak wygląda zainteresowanie klientów tą technologią - dlaczego decydują się na Flutter albo na inne technologie.

By pokazać jak wygląda "cross-platformowa" transformacja zespołów opowiem o doświadczeniach developerów z mojej firmy, którzy mając techniczne przygotowanie w natywnej technologii - rozpoczęli pracę w projektach cross-platform.

W części technicznej pokażę, na przykładzie prostej aplikacji jak można zbudować framework testowy dla projektu Flutter. Bazując na doświadczeniu z natywnych oraz cross-platform (React-Native) aplikacji przekażę gotowe recepty na konfigurację systemu CI, uporządkowanie kodu testowego oraz rozwiązywanie typowych bolączek testów UI.

Techniczne demo (live coding) dotyczyć będzie w głównej mierze możliwości FlutterDriver - dedykowanego i rekomendowanego przez twórców podejścia do automatyzacji testów integracyjnych UI.

By nie pozostawiać pozostałych warstw piramidy testowej bez opieki - pokażę jak sporządzić testy podstawowych elementów aplikacji - widgetów. Zbuduję prosty framework , który pokaże jak nie tylko testerzy - ale i programiści mogą zacząć automatyzację testów UI. Fragment prezentacji dotyczący tych testów ma pokazać, że automatyzacja testów wymaga podejścia holistycznego - tak aby rozsądnie dobierając przypadki testowe uniknąć zbędnego narzutu czasu i pracy na pisanie nieefektywnych testów, które lepiej sprawdziłyby się z wykorzystaniem innych technik.

Przygotowując prelekcję posiadam doświadczenie z pracy w projektach React-Native (cross-platform). Rozumiem problemy tej technologii i wiem jak podejść do zaprezentowania możliwości i ograniczeń technologii cross-platform.

Po mojej prelekcji chciałbym aby uczestnicy wynieśli podstawową świadomość dlaczego klienci decydują się na cross-platform. Liczę, że po wysłuchaniu i obejrzeniu jak wygląda wprowadzanie automatyzacji do projektu Flutter, nie będą obawiać się tych technologii (wysokiego progu wejścia, potencjalnych bolączek wieku młodzieńczego). Wierzę, że moja prelekcja pozwoli na przyszłe świadome doradztwo dla potencjalnych klientów - czy cross-platform będzie właściwym podejściem dla ich konkretnego przypadku.