KraQA #30

Na nasze jubileuszowe spotkanie z okrągłą liczbą 30 (a przy okazji rozpoczynające 5-ty rok istnienia) zaprosiliśmy gości z odległej Łodzi (a dokładniej – Zgierza): Przemka Niedziałkowskiego i Pawła Stopczyka, który na codzień pracują jako automatyzujący testerzy w mBanku. Wstrzeliliśmy się w środek największej fali mrozów tej zimy. Kto szukał wymówki by nie zawitać – znalazł idealną. Kto przyszedł – na pewno nie żałował.

Paweł i Przemek na codzień pracują z automatyzacją testów UI. Jak każdy zaczynali od sprawdzonego Selenium, jednak okazało się, że w przypadku specyfiki aplikacji z którą pracują jest to rozwiązanie niestabilne. Poszukiwania nowego narzędzia zaprowadziły ich do mało znanego rozwiązania nazwanego Canopy (https://lefthandedgoat.github.io/canopy/), które nie dość że niezbyt szeroko rozpowszechnione, to implementowane z użyciem języka F# (tak, naprawdę taki istnieje). F# to funkcyjny język częściowo zorientowany na aplikacje w środowisku .NET, jednakże w połączeniu z Canopy pozwala na tworzenie „lekkostrawnego” frameworku testowego, w którym mają szansę odnaleźć się nawet testerzy z mniejszym doświadczeniem w pisaniu kodu. Czas wejścia nowych, mniej automatyzujących testerów do projektu to około dwa dni. Dodatkową zaletą takiego rozwiązania jest możliwość kompilacji i wyeksportowania swoich testów do pliku *.exe, który można przekazać biznesowi jako część testów akceptacyjnych.

W pierwszej części prezentacji Przemek przybliżył nam ideę stojącą za konwersją z Selenium do Canopy. Niestabilność testów, wysoki próg wejścia do pisania kodu i ciężki framework w Javie to problemy utrudniające życie, a które z powodzeniem rozwiązało Canopy + F#. Pokazano również ciekawy sposób priorytetyzacji testów (smoke/top 100/top 1000), które znacząco poprawiły zaufanie do testów i pozwoliły wyłapać ważne defekty wcześnie. Przemek pokazał też monitoring testów na ekranach, czyli budowanie wspólnej odpowiedzialności za jakość w trakcie developmentu.

Druga część to trochę praktyki, czyli demo. Tym razem pałeczkę przejął Paweł i zaprezentował uruchomienie testów w trybie „normalnym”, debugowym (czyli wolniej oraz z podświetlaniem elementów „klikanych”) a na koniec kilka przykładów kodu. Dla mnie wyglądało to przejrzyście, solidnie i interesująco. Na tyle, bym miał ochotę w przyszłości spojrzeć bliżej na to rozwiązanie.

Podsumowując: kilka ostatnich prezentacji na KraQA miało wymiar „techniczny” i było to odpowiedzią na Wasze prośby o więcej „mięsa” i ta wpisała się w tą konwencję bardzo dobrze!

Pamiętajcie, że 19 marca SkładQA#3!

SkładQA 2018