Autorzy: Mateusz Radkiewicz, Marcin Czajka, Paweł Guździoł

Testwarez to prawdopodobnie największe coroczne wydarzenie dla społeczności testerskiej w kraju. Dlatego też na tegorocznej edycji konferencji Testwarez 2014 nie mogło zabraknąć naszych reprezentantów. Kainos był również sponsorem wspierającym tegoroczną edycję konferencji

Wydarzenie było interesujące nie tylko ze względu na lokalizację (konferencja odbyła się częściowo na promie Gdynia-Karlskrona-Gdynia), ale również ze względu na tematy prezentacji, które w większości skupiały się na automatyzacji.

O swoim doświadczeniu w dziedzinie automatyzacji opowiadali również nasi pracownicy, czyli Michał Sierzputowski z prelekcją „Zautomatyzuj swoje testy automatyczne Selenium” oraz Tomasz Świderek z prezentacją „Jak zbudować autorski framework do automatyzacji testów. Tips&hints”.

Dowiedz się jak było na Testwarez z perspektywy członków naszej załogi.
IMG_1076

Od lewej: Michał Sierzputowski, Marcin Czajka, Paweł Guździoł, Mateusz Radkiewicz, Tomasz Świderek

Dzień 1

Główna część pierwszego dnia konferencji odbyła się w Pomorskim Parku Naukowo-Technologicznym w Gdyni. Dzień zaczął się od warsztatów i egzaminu ‚Agile Tester’. Następnie odbyły się prelekcje i panele dyskusyjne. W przerwach uczestnicy mieli okazję zajrzeć m.in. na stoisko Kainosa. Oto podsumowanie prezentacji z pierwszego dnia:

„ATF – Nietypowe podejście do automatyzacji w systemie rozproszonym” – Daniel Dec

Prelegent przedstawił autorskie podejście do stworzenia frameworka testów automatycznych, które zastosowano w jednym z projektów prowadzonych w jego firmie.

Koncepcja charakteryzowała się kilkoma ciekawymi aspektami. Testowany system jest zbudowany w oparciu o architekturę microservices (wiele serwisów komunikujących się za pomocą REST API). Framework został zaprojektowany w podobny sposób, tak aby każdy serwis aplikacji miał swój odpowiednik w postaci modułu frameworka testowego odpowiedzialnego za jego walidację.

Poszczególne testy nie ograniczają się do wąskiego sprawdzania oczekiwanego rezultatu, a do weryfikacji stanu całego systemu. Stan systemu jest zdefiniowany m.in. jako zbiór transakcji bazodanowych, danych na wejściu i wyjściu w poszczególnych serwisach, stan systemu plików.

Po wykonaniu każdego testu porównywany jest stan faktyczny z oczekiwanym. Interpretacja różnic pozostaje w gestii testera. Ponadto framework wspiera testy automatyczne na wszystkich poziomach: GUI, serwisów, unit testów. Testy projektowane są zgodnie z koncepcją piramidy testów: najwięcej testów unitowych, jako tych najszybszych i najtańszych w utrzymaniu, a najmniej testów GUI.

Autor: M.R.

„Mutation Testing” – Michał Chudy

Michał jest programistą i jego prezentacja skierowana była przede wszystkim dla innych programistów. W swoim wykładzie poruszył zagadnienie testowania mutacyjnego, które może być jednym z narzędzi do określania jakości testów jednostkowych pisanych przez inżynierów oprogramowania.

Swoją prezentację Michał zaczął od przedstawienia typowych problemów związanych z oceną testów poprzez stosowanie metryki pokrycia kodu. Według autora (z czym się oczywiście zgadzam) pokrycie kodu może być bardzo mylącym kryterium oceny testów.

Z drugiej strony developerzy mogą pisać testy, tylko po to aby pokryć nimi kod, niekoniecznie dodając jakąś wartość. W przedstawionej koncepcji testowania mutacyjnego, kod poddawany jest modyfikacjom, a następnie uruchamiane są testy, które zgodnie z ideą powinny się zakończyć w takim wypadku błędem.

W dalszej części zostało zaprezentowane narzędzie PIT, które realizuje testowanie mutacyjne dla Javy. Niestety testowanie mutacyjne, jak autor sam przyznał, powinno być raczej pomocniczym narzędziem, a nie częścią procesu typu continues integration. Może to rodzić niestety różnego rodzaju problemy, chociażby z wymuszaniem takiego podejścia wśród innych członków zespołu.

Autor: M.C.

„Behaviour Driven Development is not about tools is about communication” – Bartosz Szulc

Bartosz Szulc w swojej prelekcji opowiedział nam o BDD. W bardzo interesujący sposób opowiedział o drodze, którą przebył w celu poznania i zrozumienia, czym tak naprawdę jest BDD.

Opisując swoje doświadczenia przedstawił jak stopniowo udało się osiągnąć założone cele i zaczęto czerpać korzyści płynące z zastosowania praktyki BDD wewnątrz jego zespołu. Punktem zwrotnym w podejściu do testowania był fakt, że duża liczba testów automatycznych nie gwarantowała spełnienia wszystkich wymagań i oczekiwań istotnych z punktu widzenia biznesu. Rozwiązaniem takiego problemu może być właśnie zastosowanie BDD.

Tak jak mówi tytuł prelekcji, oraz co moim zdaniem udało się autorowi obronić, w BDD najważniejsza jest komunikacja. Aby jak najlepiej zrozumieć oczekiwania biznesu podczas definiowania wymagań cech produktu zaangażowane oraz entuzjastycznie nastawione do współpracy muszę być wszystkie strony tzn. biznes, tester, deweloper.

Pozwala to rozwiązać większość wątpliwości oraz maksymalnie zdefiniować cechy produktu jeszcze zanim programiści zaczną implementować kod funkcjonalności. Owocem takich spotkań są wymagania zdefiniowane w postaci scenariuszy testowych. Scenariusze te napisane w Gherkin’ie (język naturalny zrozumiały przez osoby nietechniczne o typowej składni Given…, When…, Then..) są następnie implementowane do postaci akceptacyjnych testów automatycznych.

BDD wymaga zaangażowania i komunikacji od wszystkich, dlatego też wydaję się być doskonałą praktyką do zastosowania w zespołach pracujących w oparciu o metodologie zwinne.

Autor: P.G.

„Jak zbudować autorski framework do automatyzacji testów – tips & hints” – Tomasz Świderek

Tomasz swoją prezentację rozpoczął od krótkiego przedstawienia podstawowych informacji o Kainos a następnie płynnie przeszedł do głównego tematu prelekcji.

Bazując na swoim doświadczeniu zdobytym w różnorodnych projektach opowiedział jakich błędów należy unikać budując swoje repozytorium testów automatycznych. Kilka dobrych praktyk i przykładów, które mogłyby wydawać się oczywiste dla bardziej doświadczonych testerów automatycznych, na pewno pomogą uniknąć wielu błędów przy wdrażaniu automatyzacji przez mniej doświadczonych testerów.

Tomasz opisał sytuację, w której trafiając do jednego z projektów zastano delikatnie zaniedbaną automatyzację. Naprawianie sytuacji rozpoczęto od przejrzenia wszystkich zautomatyzowanych przypadków testowych. Pozwoliło to zredukować liczbę testów o testy nieaktualne lub o niskim priorytecie, skupiając się głównie na tzw. happy paths. Kluczowe w procesie automatyzacji oraz późniejszym utrzymaniu testów jest dbanie o jakoś kodu skryptów testowych, dlatego też code review wydaje się być niezbędne.

Bardzo ważne jest również nazewnictwo oraz chaining (łączenie wywołań metod), ponieważ znacząco zwiększa to czytelność kodu i skraca czas poświęcony na debugowanie testów. Wspólnie wypracowane standardy warto spisać w postaci guildelines, co znacząco zmniejszy koszt wejścia w automatyzacje w projekcie, ale również utrwali dobre praktyki.

Dependency Injection, Page Object Pattern, wrapper dla WebDriver’a czy też klasy abstrakcyjne dla page objects i testów to coś, bez czego trudno sobie wyobrazić dobrze napisany nowoczesny framework testowy.

Autor: P.G.

Po wysłuchaniu prelekcji Tomka Świderka uczestnicy zostali przewiezieni na terminal promowy, skąd wypłynęliśmy w kierunku Szwecji. Wieczór był długi, urozmaicony szantami oraz długimi rozmowami na tematy związane z jakością oprogramowania :)
IMG_0708Od lewej: Michał Sierzputowski, Marcin Czajka

Dzień 2

Drugi dzień zaczął się mocnym akcentem w postaci piosenki „Sailing” Roda Stewarta odegranej o 6 rano w każdej kajucie. Po śniadaniu oraz podziwianiu szwedzkiego wybrzeża z promowego pokładu, udaliśmy się na prelekcje, panele dyskusyjne i warsztaty zlokalizowane w salach konferencyjnych na promie.

„Automatyzacja jako panaceum na wszelkie bolączki (panel dyskusyjny )” – Adam Marciszewski

Panel dyskusyjny odbył się w kameralnej salce konferencyjnej z widokiem na bezkresny Bałtyk. Spotkanie początkowo miało zachęcić do rozmowy na temat automatyzacji testów jako sposobie na rozwiązanie wszelakich problemów, jednak dyskusja szybko potoczyła się swoimi torami.

Podczas wymiany doświadczeń i spostrzeżeń wynikło kilka kwestii, których zwolennicy i przeciwnicy starali się argumentować swoje racje. Niektóre z poruszonych problemów to:

– dane testowe powinny być generowane dynamicznie czy może powinny być statyczne przy każdym wykonaniu testu
– testy GUI (np. Selenium) powinny testować tylko tzw „happy paths” a większa część walidacji powinna odbywać się na niższych warstwach systemu czy może testy GUI powinny pokrywać możliwie dużo scenariuszy
– powinno się dążyć w kierunku keyword driven testing i umożliwienia osobom nietechnicznym tworzenia dużej ilości testów automatycznych czy może tworzyć i utrzymywać ograniczoną i łatwą do kontrolowania liczbę testów.

Mimo, że czas zaplanowany na panel dyskusyjny został znacznie przekroczony, w wielu tematach daleko było do wypracowania wspólnego punktu widzenia. Sama dyskusja skłaniała jednak do zreflektowania swojego podejścia do poruszanych kwestii.

Autor: M.R.

„Testowanie systemów wbudowanych i krytycznych dla bezpieczeństwa” – Bogdan Bereza

Bogdan przedstawił nam świat systemów wbudowanych, który dla większości z nas był czymś raczej mało znanym. Wykład był interesujący przede wszystkim ze względu na inność tego świata.

Wiele podejść stosowanych w bardziej tradycyjnych systemach nie ma zastosowania w przypadku takiego oprogramowania. Chyba najciekawszym slajdem, był ten na którym przekreślone były narzędzia, z których korzystamy (selenium, cucumber), niestety nie ma dla nich miejsca i zastosowania w tym obszarze. Przedstawiony świat jest pełen różnych norm, specyficznych dla gałęzi przemysłu.

Testowanie w tym wypadku jest procesem o wiele bardziej żmudnym i odpowiedzialnym. Bardzo przemawiające do wyobraźni były koszty niektórych błędów, niestety czasem było to ludzkie życie.

Autor: M.C.

„The future of testing” – Tilo Linz

Na zakończenie konferencji odbyła się prelekcja traktująca o przyszłości testowania. Według autora obecne i przyszłe nowinki naukowe i technologiczne w znacznym stopniu wpłyną na to jak będziemy testować za kilkanaścia/kilkadziesiąt lat. Osiągnięcia m.in. takie jak autonomiczne pojazdy, roboty, internet przedmiotów (IoT) czy rozszerzona rzeczywistość wymuszą zmiany w procesach testowania.

W efekcie może dojść do realizacji zaskakujących scenariuszy. Jedna z przedstawionych hipotez stwierdza, że testowanie w obszarze internetu przedmiotów i automicznych pojazdów może doprowadzać do wielu wypadków w przestrzeni publicznej. Powodem będzie fakt, że niemożliwe będzie stworzenie testowego środowiska, które w wystarczającym stopniu modelować będzie świat rzeczywisty i testy będą musiały odbywać się od razu ‚na produkcji’, czyli np. na publicznych drogach.

Autor: M.R.

P1040995

Konferencja zakończyła się w momencie przypłynięcia promu do portu w Gdyni. Bez wątpienia pomysł przeprowadzenia konferencji na promie był strzałem w dziesiątkę. Morska sceneria sprzyjała pozawykładowej wymianie doświadczeń i opinii z zakresu testowania.

W wielu prezentacjach poruszane były problemy, z którymi sami się spotkaliśmy i dość optymistyczny był fakt, że rozwiązywaliśmy je w podobny sposób. Jak pokazał przekrój prezentacji, automatyzacja jest coraz powszechniej stosowana.

Mam nadzieję, że w przyszłym roku ponownie się pojawimy i przedstawimy efekty naszych prac, tym bardziej że obecnie temat automatyzacji jest jednym z gorących topiców w Kainosie.