Opis prelekcji

Warsztat: Wprowadzenie do Page Object Pattern

Jakub Rosiński, Patrycja Tomaszewska

Od pierwszego testu w selenium w formie spaghetti code z przykładami problemów z wielokrotnym użyciem raz napisanych testów, do tych ładnie skonstruowanych, zorganizowanych z zachowaniem zasad Page Object Pattern. Omówienie i przećwiczenie zasad, pokazanie łatwości utrzymania, podejścia do PO w projektach, wielokrotne użycie raz napisanych "słów kluczowych".
Warsztat w JAVIE - polecamy uczestnikom posiadać podstawy programowania w tym języku i lokalizowania elementów na stronach internetowych.

Na przykładzie bardzo prostej strony internetowej przygotowane zostaną w czasie warsztatu dwa lub trzy testy (mające wspólne fragmenty) w formie "spaghetti code". Kod powstawać będzie w JAVIE na dostarczonych przez prowadzących wirtualnych maszynach ze skonfigurowanym środowiskiem.
Przedstawimy teorię używania metod dostarczanych przez selenium, warto jednak umieć lokalizować elementy na stronach internetowych i znać podstawowe seleniumowe metody. Przyda się też odświeżyć podstawy programowania w JAVIE – do dziedziczenia. Jesteśmy jednak gotowi tłumaczyć każdą linijkę przedstawianego kodu.
Następnie przedstawione i omówione zostaną zasady tworzenia Page Objectów – najpierw w formie teorii, a następnie uczestnicy stworzą nowe testy przerabiając swój „spaghetti code” na ten z zachowaniem obiektów. Pokażemy jak stworzona dodatkowa warstwa poprawia czytelność testów dla mniej technicznych osób – tak testerów, jak i analityków, czy kierowników. Ułatwiając też wykonywanie testów samym tworzącym.
Wszystkie stworzone testy zostaną poddane próbie zmian w testowanej aplikacji – uczestnicy na własnym przykładzie ocenią pracochłonność utrzymania wcześniej stworzonego kodu w obu wersjach.


Warsztat: Fluent Interfejs w testach automatycznych

Tomasz Bonior

Testy automatyczne, które tworzymy w naszych projektach, jak każde dobre oprogramowanie potrzebują standardów, aby ich utrzymanie było możliwe. Fluent Interfejs wprowadzony w warstwie testów narzuca dyscyplinę pisania testów oraz Page Objectów. To samo z siebie już zwiększa utrzymywalność testów. Co więcej, testy napisane w FI są dużo bardziej czytelne i przede wszystkim prowadzą twórcę testu za rękę w tworzeniu przypadków testowych. Jest to alternatywa do testów pisanych w Gherkinie.

Jeśli wiesz, że w Twoim przypadku Analitycy jednak nie będą pisać testów, to powinieneś zadać sobie pytanie czy dodatkowa warstwa w Twoim frameworku, obsługująca Cucumber lub inne biblioteki jest potrzebna? Najważniejsze abyś wiedział, że można napisać testy, które są czytelne dla osoby nietechnicznej i nie są oparte o Gherkina, tylko o czystą Javę.

Czego nauczymy się na warsztatach:

  1. Podstawowe zasady Fluent Interfejsu w testach
  2. Zasadę działania Page Objectów po modyfikacji do FI
  3. Jak używać asercji w FI
  4. Jak używać mini scenariuszy jako kroków w testach

Wymagania:

  1. Znajomość Javy w stopniu podstawowym (klasy, obiekty, typy,  interfejs)
  2. Znajomość wzorców Page Object i Page Factory
  3. Umiejętność tworzenia selektorów

Środowisko:

  1. IntelliJ
  2. Java
  3. WebDriver

Warsztat: FOREVO – Efektywniejsza automatyzacja przy użyciu narzędzi opensource

Łukasz Burczak

ForEvo jest rozwiązaniem do automatyzacji między platformowych testów regresji. Framework zawierający Selenium Webdriver, Sikuli oraz Autoit-a umożliwia wykonywanie testów automatycznych dla niemal wszystkich technologii, od aplikacji webowych po aplikacje mobilne. ForEvo jest frameworkiem, który można rozszerzyć na inne rozwiązania i technologie.

Celem warsztatów jest ukazanie jednego ze sposobów usprawnienia tworzenia testów automatycznych przy użyciu rozwiązań open source.

ForEvo ułatwia zarządzanie obiektami oraz danymi, które wykorzystywane są przy tworzeniu skryptów testowych.

Agenda:

  • Ogólne informacje dotyczące narzędzi open source wykorzystywanych w automatyzacji testów.
  • Wstęp do Sikuli i Autoit-a
  • Integracja Selenium, Sikuli i Autoit-a.
  • Przedstawienie funkcjonalności narzędzia ForEvo.
  • Wykorzystanie ForEvo przy automatyzacji wybranych scenariuszy testowych.
  • Odpowiedzi na pytania.

Wymagania:

  • Komputer umożliwiający podłączenie do sieci poprzez wifi. Komputer powinien posiadać aktywny port USB, min. 4GB pamięci RAM oraz 20 GB wolnej przestrzeni na dysku.
  • VirtualBox

Warsztat: Wprowadzenie do Selenium WebDriver w RobotFramework

Jan Sabak

Celem warsztatu jest przedstawienie jednego ze sposobów automatyzowania testów. Warsztat obejmować będzie podstawy teoretyczne z zakresu automatyzacji testów oraz warsztaty praktyczne polegające na budowie frameworka testowego. Głównym założeniem kursu jest nauka samodzielnego tworzenia testów automatycznych za pomocą Selenium WebDriver oraz RobotFramework.
Agenda warsztatu:

  1. Podstawy teoretyczne automatyzacji
  2. RobotFramework
  3. Lokalizowanie elementów
  4. Podstawy Selenium WebDriver

Uczestnicy proszeni są o przyniesienie na warsztaty własnych laptopów o konfiguracji sprzętowej minimum Intel Core i5, 4GB RAM. Na laptopach powinien być zainstalowany RobotFramework w najnowszej wersji oraz RIDE. Alternatywnie może zostać zainstalowany VirtualBox, ponieważ na warsztaty zostanie dostarczona maszyna wirtualna ze wszystkimi potrzebnymi narzędziami.

Maszynę wirtualną z narzędziami można pobrać tu.

Udział w warsztatach ułatwi znajomość następujących technologii: HTML, XML, XPath, CSS, Regex oraz podstawowa umiejętność programowania.

Prezentacja: Automation in the world of projects -  a few thoughts from a business perspective

Zbigniew Moćkun

Podczas prezentacji chciałbym was przenieść do świata firmy projektowej i wyzwań przed nią stojących. Ostatnich kilka lat to dla Cognifide ciągły rozwój, ale też i wiele zmian. Jednym z większych obszarów, do którego zmieniliśmy podejście to automatyzacja testów. W swojej prezentacji skoncentruję się nad trzema elementami z nią związanymi:

  • Sprzedaży automatyzacji oraz rozmowy o niej z klientem biznesowym
  • Re-używanie kodu czy wewnętrznych narzędzi między projektami dla różnych klientów
  • Kto powinien i kiedy pisać testy automatyczne?
  • Czy istnieje mityczne “whole team approach”?

Dla każdego z punktów przedstawię problemy, które napotkaliśmy oraz rozwiązania ich.


Prezentacja: Siedem grzechów głównych automatyzacji

Marcin Stachowicz

Od pięciu lat zajmuję się automatyzacją testów w wielu różnych projektach, metodykach i zespołach. Pracuję w firmie gdzie zespół testowy to ponad setka ludzi. Widziałem już wiele sposobów automatyzacji i moje przemyślenia po pracy w tych projektach nasunęły mi dużą analogię do kwestii religijnych. W moim wystąpieniu biorę 7 grzechów głównych religii chrześcijańskiej i do każdego z nich dołączam przykładowe błędy lub niepoprawne podejścia do automatyzacji testów.
Dla przykładu:
1.       Pycha
- Wiara w cuda: Automatyzacja jako panaceum na niską jakość oprogramowania
- Relacja tester-developer
- Testy end-to-end wystarczą!
2.       Chciwość
- Automatyzujmy wszystko!
- Minimalizowanie kosztów przy pomocy testów automatycznych
3.       Nieczystość
- Clean Code
- Wzorce projektowe
- Nagrywanie testów: testowanie bez kodowania, utrzymanie nagranych testów, migracje
…i tak dalej dla kolejnych grzechów 😉
Co z tego wyszło? Czy Twoje działania czasem nie wpisują się w jeden z tych obszarów?
Zapraszam do rozmowy i refleksji nad własną automatyzacją.


Prezentacja: How to successfully start test automation in selenium from the scratch ?

Filip Słomski

In my professional work I was responsible for creating selenium test framework from the scratch few times now. The ultimate goal was to start the whole test automation concept in a project. I would like to talk about the potential risks and how to overcome them in terms of code & CI aspects.

I would like to talk about starting test automation in selenium and all the risks that are connected to this matter. I would like this presentation to be structured as a list of steps / potential risks to consider when developing selenium test automation in a project. For each risk I would like to suggest a solution that I have found to be the most effective or at least present possible ways of reducing that risk. The list of topics I would like to cover:

  • framework architecture [universal steps, page object pattern, screenplay pattern [pros & cons]
  • representing page elements in code layer [dividing into classes]
  • how to improve selenium tests stability [both codewise and processwise]
  • framework extensions [logging, docker & more]
  • test placement in the development cycle
  • enabling Pull Request testing - githubpullrequest jenkins plugin tips

Prezentacja: Architektura frameworka testowego - E2E aplikacji webowych

Tomasz Konieczny

Architektura frameworka testowego ukierunkowanego głównie na funkcjonalne testy regresji aplikacji webowych. Całość zaprojektowana pod kątem prostoty używania oraz szybkości tworzenia nowych scenariuszy testowych. Nie zapomniano jednak o czasie wykonywania testów oraz przydatności nie tylko z punktu widzenia QA ale również developerów czy „biznesu”.

Na początku przedstawienie głównych założeń oraz celów, które miały zostać osiągnięte. Następnie przedstawienie struktury katalogów oraz opisanie ważniejszych plików, omówienie configów w celu wysokopoziomowego pokazania możliwości. Następnie „metody”, jakie framework udostępnia.

Omówione zostaną tematy uznawane za problematyczne - waity, identyfikacja elementów, validatory, obsługa danych testowych, zrównoleglenie wykonywania testów czy uzyskanie czystego stanu przeglądarki.

Zostaną opisane raporty, które powinny być przydatne nie tylko dla QA, ale również dla „biznesu”. Omówione będą logi, które powinny umożliwiać developerom identyfikację czy odtworzenie ewentualnych błędów – od wysokopoziomowych, jak Gherkin czy screenshoty, aż do bardziej niskopoziomowych, jak Browser console log, Driver log czy HTTP Archive (HAR).

Poszczególne zagadnienia zostaną przedstawione na przykładzie frameworka dostępnego jako open-source, jednak same założenia nie są specyficzne dla tego konkretnego przykładu, a dosyć uniwersalne.

Od strony technologii: JavaScript (Node), WebDriverJS, Cucumber-js, BrowserMob Proxy, NPM, GNU Make, Xvfb, Docker, Linux.


Prezentacja: Wdrażanie automatyzacji w dynamicznie rozwijającej się firmie sektora finansowego

Łukasz Rzońca

Swoją przygodę z IPF Digital rozpocząłem ponad półtora roku temu i trwa ona do dziś. Moim jednym z wielu zadań było opracowanie podejścia oraz strategii do szeroko pojętej automatyzacji testów.
Zacząłem ambitnie od Robot Frameworka z celem zaangażowania testerów manualnych w procesie automatyzacji testów. Już po kilku miesiącach wiedziałem, że to podejście nie działa, a powodów było wiele. Podjąłem wspólnie z przełożonymi decyzję o całkowitej zmianie strategii automatyzacji, budowaniu ekspertskiego zespołu automatycznych testów, a nawet o zmianie frameworka. Podczas mojej prezentacji pokażę, gdzie Selenium nie zadziałało i trzeba było się z niego wycofywać. Opiszę jaką przebyliśmy drogę od małej do dużej organizacji oraz jak zmiany w firmie wymusiły olbrzymią adaptację do nowych zadań i wyzwań. Opowiem również o naszych ambitnych planach na przyszłość – Zapraszam na prezentację.


Prezentacja: Dobre praktyki automatyzacji testów

Piotr Ślęzak

Wiele firm jest zmuszonych do automatyzowania testów funkcjonalnych. Powodów automatyzacji jest wiele jednakże nie każdy podchodzi do tego tematu z rozsądnym przemyśleniem co i jak należy zrobić. Nie chcę pokazywać kolejnego frameworka czy narzędzia do automatyzacji. Są ich setki a filmów i przewodników jak z nich korzystać można znaleść w internecie tysiące.

Od 15 lat zajmuję się doradztwem w zakresie jakości w IT i miałem okazję zobaczyć wiele projektów automatyzacji, które kończyły w koszu. Czemu tak się dzieje? Kto popełnia błędy i z czego one wynikają? jak dobrze ustawić proces i kto jest w niego zaangażowany poza testerami od automatyzacji? Jak szacować automatyzację, czym jest strategia automatyzacji, po co ją tworzyć i co powinna zawierać? jak powiązać proces testów manualnych z automatycznymi aby nie zrobić wyspy pod nazwą „automatyzacja”? Pytań jest wiele a na niektóre z nich odpowiedzi są nietrywialne.

Przedstawię również studium przypadku z projektu automatyzacji jaki robiliśmy dla jednego z naszych klientów gdzie założeniem było zautomatyzowanie regresji 15 dużych procesów biznesowych działających w różnych technologiach od SAP do aplikacje mobilne. Co nie zadziałało, co poszło nie tak i dlaczego na końcu wszyscy byli zadowoleni?