Relacja z QualityExcites 2018


Najlepsza darmowa konferencja w Polsce! Tak testerzy ocenili ubiegłoroczną edycję Quality Excites w Gliwicach. W tym roku odbyła się ona w dniach 22-23 czerwca. Była to już siódma odsłona wydarzenia organizowanego przez firmę Future Processing. Wybrałem się na Śląsk, żeby osobiście sprawdzić, czy jest ono wartościowe dla osób zainteresowanych tematyką testerską.

Sama rejestracja na konferencję miała formę zgłoszenia, w którym należało uzasadnić, dlaczego akurat do mnie organizatorzy mają wysłać zaproszenie. Jak widać, mój opis był przekonujący. 😊

Program pierwszego dnia wypełniły wyłącznie warsztaty. Spośród siedmiu zaproponowanych tematów  wybrałem „Dobre praktyki tworzenia testów Selenium z wykorzystaniem Cucumbera”.

Przed warsztatami przygotowywać trzeba było środowisko InteliJ + Selenium Grida, gdzie odpalane były testy GUI. Warsztaty prowadził Marcin Lorenc, który od kilku lat działa w różnych projektach, stosując BDD w swojej pracy.  Na początek nie zabrakło trochę teorii, a potem uczestnicy mieli napisać przypadki testowe dla sklepu internetowego. Wszystko w Cucumber, który jest narzędziem do współpracy miedzy klientem a inżynierami. Następnie analizowaliśmy nasze przypadki, a na koniec implementowaliśmy według projektu w javie.

 

 

 

 

Dostaliśmy naprawdę dużo wskazówek, jak pisać testy, a jakich antywzorców nie stosować. Na tej podstawie można sformułować kilka żelaznych zasad.

  • Scenariusze przychodzące od klienta są nie do zaakceptowania ze względu na jakość.
  • Przypadki powinny być napisane w taki sposób, aby po wycięciu całej warstwy technologicznej nadal nadawały się do ponownego użycia lub do wykorzystania w testach mobilnych i webowych.
  • Testy mają opisywać funkcjonalność i jej kluczowe zagadnienia.
    • Nie testujemy wszystkiego, a jedynie kluczowe rzeczy.
  • Nie stosujemy danych testowych, click-ów i button-ów.
    • Wszystko trzymamy w warstwach niżej.
  • Testy są autonomiczne – nie zależą od innych np.: sekwencyjnie.
  • Można pomijać Given / When / Then.
  • Unikamy wycieku interface do przypadków testowych, np.: modal logowania.
  • Testy w Cucumber są dodatkiem do testów manualnych.
  • To nie język interface, tylko język problemu.

Struktura

  • Features
  • Definicje kroków <- assercje
  • Kroki
  • Page Object

Dane testowe przemieszczają się miedzy Definicjami kroków a Page Object.

Testy możemy użyć do:

  • komunikacji klienta z nami,
  • wprowadzenia nowych osób do projektu,

Był to warsztaty z dużą dawką wiedzy i teorii, niestety trochę zabrakło praktyki. Czas na nią przeznaczony „rozpłynął się” podczas rozwlekłych dyskusji. Mimo wszystko jestem bardzo zadowolony. Marcin bardzo ciekawie zaprezentował własne przypadki z przeszłości, które pięknie wpisywały się w antywzorce projektowe. 😊

 

Dzień drugi konferencji to już prelekcje oraz panele dyskusyjne. Wszystko odbywało się w budynku Cechowni kompleksu „Nowe Gliwice”. Równolegle prowadzone były dwie ścieżki.

Po rejestracji przeszliśmy do auli na wykład otwierający keynote speakera Roba Lamberta. Było bardzo „amerykańsko” i czuć było pozytywną energię. Rob opowiadał o swojej ścieżce kariery i podkreślał, jak ważny jest dla niego czas, determinujący wybory w życiu zawodowym. Podzielił się ze słuchaczami kilkoma wskazówkami, co należy robić, by dobrze się rozwijać jako tester.

 

  • Sprawdzaj wszystko, co jest aktualnie „trendy”.
  • Wydawaj oprogramowanie. Jeśli ciągle testujesz i blokujesz wydania, nie zarobisz ani ty, ani twój klient.
  • Miej FUN, testując. Jeżeli siedzisz i się wkurzasz, robiąc to, co robisz, zmień to. Zmień nawet firmę.
  • Pamiętaj, aby zrównoważyć pracę w rozwojem i czasem wolnym.
  • Ucz się na błędach. One sprawią, że będziesz lepszy.
  • Czytaj literaturę branżową, ale tylko taką, w której ktoś opisał spektakularne osiągnięcia. Nie czytaj średniaków, szkoda na to czasu.
  • Nie szufladkuj i nie specjalizuj osób, role powinny zostać zamazane, bo problemy rozwiązujemy wspólnie.
  • Zadawaj pytania, jeśli chcesz być najlepszym testerem. Buduj relacje i pytaj czy to co robicie ma sens.

Następnie słuchałem wykładu pt. „Współczesne strategie testowania dla rozwijających się ekosystemów” w języku angielskim. Julian Warszawski przeprowadził nas przez całą piramidę testów, pokazując wszystkie rodzaje testów wraz z ich zaletami i wadami. Niby nic odkrywczego, ale dodał jeszcze do tego podział na testy aplikacji, service. Wszystko stało się bardziej przejrzyste.

Bardzo ciekawe były:

  • Testy A/B, gdzie wprowadzamy dla użytkowników nowy produkt i sprzedajemy równolegle ze starą wersją produktu, a następnie weryfikujemy, jak oni reagują. Po jakimś czasie podejmujemy decyzję o zamknięciu jednego z nich.
  • Canary testing, np. 5% użytkowników dostaje nową wersję funkcjonalności, weryfikujemy za ich pomocą, czy funkcjonalność działa na małej grupie, a w razie awarii blokujemy tylko małą populację spośród wszystkich użytkowników.

Kolejną prelekcja to „Riders On The Storm: API Gateways not only for developers”. Tomasz Skowroński opowiedział o API Gateway w „wiedźmińskiej” oprawie. Każdy slajd oprawiony był w Geraldowską sagę. Z ogromną łatwością można dodawać usługi na potęgę, ale jak to wszystko później kontrolować i zarządzać? Tomek mówił o dostępnych narzędziach do sterowania zbiorem mikroserwisów.

Wyliczał  przy tym:

  • Forward proxy,
  • Rewerse proxy,
  • Backend for frontend,
  • API Gatway, opisywał KONGa, openResty, Tyka,
  • API Managment,
  • Zachęcał również do stworzenia swoich własnych rozwiązań za pomocą zuul lub spring.

Dobre rozwiązanie to takie, które ma kontrolę ruchu poprzez:

  • ucinanie ruchu na środowiskach ze względu na kulejąca wydajność,
  • load balancing,
  • identyfikuje np.: ataki z chin a następnie ucina taki ruch,
  • sprzątanie i zamykanie usług, które nie odpowiadają,
  • circut breakers – wzorzec wyłączający ponowne odpytanie usługi, jeżeli usługa wskazuje, że nie jest to błąd przejściowy.

Było wiele odwołań do jednego z największych „graczy” w tej dziedzienie np.: Netflixa.

Temat zaprezentowany został bardzo dynamicznie, kolejne wątki bardzo szybko przemykały przed oczami. Widać, że Tomek jest pasjonatem i zna się na rzeczy. Jednak forma i tempo prezentacji nie do końca mi odpowiadały.

Kolejna prezentacja – „Testing batch and streaming Spark applications” – mówiła o Apache Spark, czyli o tym, jak testować zbiory danych, które cały czas żyją. Z przykładem Big Data, gdzie cały czas „dolewamy” dane i na ich podstawie kreujemy przyszłe produkty. Analizując dane, musimy je jakoś przetestować, np.: przez Sparka. Było dużo kodu i użycia w metodach – temat ciężki do przedstawienia w formie wykładowej, widziałbym go bardziej w formie warsztatu, gdzie można by było sprawdzić zachowania tego rozwiązania. Pozostaje więc zrobić to w domowym zaciszu. 😊

Kolejny punkt programu: „Testy, które tworzą się same (prawie)”. Arnika zaprezentowała na żywo prosty model tworzenia testów automatycznych. Za pomocą modelu w Mista oraz wyklikanych kroków, które nagrała w Selenium IDE. W szybki sposób wygenerowała przypadki testowe, które mogła wciągnąć do Selenieum WebDriver. Temat do sprawdzenia w akcji, ponieważ według wyliczeń przy zastosowaniu podejścia w testowaniu opartym o model daje on oszczędność 50% przy tworzeniu w sposób tradycyjny (bez dodanego czasu na wdrożenie). Lubię live coding. 😊

 

Software Quality Assistance w 40 minut

Przemek mówił, aby kłaść większy nacisk na Assistance (zapomnijmy o Assurance). Jak widać, jest zwolennikiem zmiany kierunku „w lewo” (left shift). Pokazał problemy, z jakimi borykają się ludzie w organizacjach:

  • zawalanie ticketami dewelopera, ciągłymi nawrotkami,
  • brak komunikacji – komunikacja następuje tylko przez przepinanie ticketów.

 

Zgodnie z jego filozofią liczy się kolektyw ludzi z rolami:

  • usuwamy testerów, a robimy z nich QA, którzy mówią deweloperom, jak testować;
  • deweloperzy robią wszystko sami, ale z ogromną pomocą Opsów i QA;
  • QA stwarzają narzędzia, wykorzystywane przez deweloperów podczas testów;
  • Ops dają narzędzia i komponenty do wdrożeń;
  • Ops dają szablony do monitorowania;
  • QA robią analizę ryzyka.

Testerzy nie są od największej liczby zgłoszonych błędów, a programiści nie są od pięknego kodu. Oni wszyscy są dla klienta i robią wszystko dla klienta – Customer Service.

 

Testy wydajnościowe w świecie mikroserwisów

Prezentacja z Minonkami w tle miała pokazać narzędzie Gatling. We wstępie można było usłyszeć o tym, jak często się zdarza, że testy wydajnościowe są marginalizowane albo zupełnie pomijane w procesie wytwórczym, a włączane dopiero na etapie produkcji, gdy ruch się zwiększa a aplikacja kuleje. Tomek podkreślał rolę klienta końcowego, który ma tak duży wybór wśród aplikacji. Ładowanie funkcjonalności czy strony wydłużone nawet o sekundę może spowodować porzucenie dotychczasowej firmy/strony. W ten sposób klienci odpływają, a firmy tracą.

Tomek wspomniał, że często struktura architektury przekłada się na strukturę w organizacji. Właśnie dlatego mikroserwisy nie są dla wszystkich. 😊

Następnie szybko porównano dwa narzędzia: stary  (nie)dobry Jmeter i właśnie Gatling. Jmeter jako ciężkie, brzydkie narzędzie trudne w utrzymaniu -> XML vs Gatling, gdzie używa się aktorów, scali i testuje w kodzie.

Gatling jest naprawdę szybkim narzędziem do tworzenia testów na większą skalę. Wykonując akcje na przeglądarce, całośc przechodzi przez proxy Galinga z którego dalej generowany jest kod. np.: w Intelij następie uruchamiamy. Narzędzie znalazło się w naszym biurze w krótkim laboratorium, jednak nie przypadło do gustu ze względu na wymagane pewne umiejętności pisania w kodzie osób implementujących testy, np.: scala. U nas używamy Load UI, który tak naprawdę jest przedłużeniem Soap UI.

 

Web Application Security Test Automation

Testy bezpieczeństwa są jeszcze częściej pomijane, nawet częściej niż testy wydajnościowe.

Najczęściej firmy nie mają w swoich strukturach dedykowanych im osób, tylko zlecają prace firmom zewnętrznym. To jest jak najbardziej dobra droga. Jednak Marek chciał pokazać, jak łatwo w trakcie „kilku wieczorów” na podstawie OWASP ASVS można samodzielnie wprowadzić testy bezpieczeństwa do organizacji. Wystarczy checklista i poziom bezpieczeństwa aplikacji, jaki chcemy osiągnąć. Kilka przykładów i okazuje się, że nie taki diabeł straszny, jak go malują. Marek trochę ponarzekał na Agile, że właściwie nie wiadomo, kiedy te testy wykonywać przy tak częstych sprintach. Jedynie można je wrzucić jako automat razem z testami end to end. Może dać to wiele oszczędności w projekcie, a dodatkowo zyskujemy nowe zdolności. 😊

Automating Assurance: Tools, Collaboration and DevOps

Na koniec kolejny KeyNote Paul Gerrard próbował przekonać nas, że przez kilkanaście lat tak naprawdę nic nowego nie wymyśliliśmy w testach. 😊 Testowa piramida i model V są takie same, bo o tym, że trzeba było robić Unit testy wiadomo było już w 1980 roku… Agile niewiele zmienił: dziś tak jak kiedyś automatyzacja jest wyzwaniem.

Paul również jest zwolennikiem Assurance, czyli zasadą: bądź doradcą jakości w swoim zespole. Dziś nie ma czasu na wielkie testy. Wszystko jest tak zmienne, że musimy być z jakością bliżej developerów i klienta. Biznes chce wdrażać codziennie, chce najlepszych aplikacji, a nie najlepszych dostawców. Przy automatyzacji musimy być naprawdę zwinni, regularni i szybcy. Zadajmy sobie pytanie, czy jest jakaś korzyść, gdy wciąż aktualizujemy i utrzymujemy, biorąc nowe narzędzia?

Oprogramowanie tak często się zmienia, że ciężko za tym nadążyć z automatami. Szukajmy różnic miedzy tym, co dziś i wczoraj w regresji zamiast perfekcyjnego testu. Testowanie i automatyzacja testów to problem modelu, a nie narzędzia. Narzędzia pomagają nam, ale one same nie myślą. Nie ma znaczenia, jakiego narzędzia użyjesz, bo nie testujesz samego narzędzia. Zapomnij więc o logice!

Wszystkie testy to eksploracja, a najważniejsze są:

  • źródło wiedzy,
  • zbudowanie modelu testów,
  • informowanie naszych testerów.

Nie testujmy czegoś, jeśli  nie wiemy, jak to zrobić. W BDD chodzi o współpracę, a nie narzędzie.

Testujemy -> powtarzamy lub poprawiamy test lub zmieniamy model, bo są inne wymagania.

„Przełącz się w lewo”, bo źle będziesz testował, jeżeli źle zrozumiesz wymagania. Kieruj się kilkoma zasadami.

  • Story prototype
  • BDD
  • Więcej testów dla developmentu
  • Wspieraj developerów
  • Automatyzuj Unit Testy
  • Rób ręczne testy eksploracyjne

Po warsztatach i wykładach wszyscy wybraliśmy się na After Party do Zbeer w Gliwicach. 😊

W trakcie całej konferencji  odbywał się konkurs firmy Future Processing, w którym trzeba było zapobiec apokalipsie zombie. Brzmi śmiesznie, ale zadania naprawdę były bardzo sprytnie stworzone i trzeba było nad nimi nieźle pogłówkować. Podczas przerw w różnych punktach budynku pokazywało się zadanie do rozwiązania. Co chwilę było widać grupę ludzie przemieszczających się w poszukiwaniu zagadek do rozwiązania. Nawet mi udało się  zostać poskramiaczem zombie i uratowałem swój mózg przed zjedzeniem. 😊

 

Jak wypada podsumowanie gliwickiej konferencji? Całe wydarzenie było bardzo dobrze zorganizowane, a większość prezentacji miała naprawdę wysoki poziom. Ogólnie widać trend kierunku w lewo z testami oraz nacisk na testowanie serwisów. Po dwóch  dniach naprawdę dużej dawki wiedzy byłem całkowicie wypompowany, ale zadowolony z tego, że udało się usłyszeć tyle ciekawych prelekcji.

Bardzo polecam konferencje QE.

 

 


O Michał Czyżykowski

Testowałem manualnie, automatycznie i wydajnościowo w ciągu mojej kariery w SII dla Ateny oraz w Atenie. Miałem jeszcze mały epizod pracy jako deweloper zaraz po studiach, ale testowanie bardziej przypadło mi do gustu :). W tej chwili jest testerem wiodącym w Atenie i zajmuje się pisaniem i utrzymaniem testów usług REST/SOAP. Piszę również automaty GUI w Selenium Web Driver. Prowadzę również szkolenia z narzędzia Soap UI NG wewnętrznie w firmie dla naszego oraz innych biur Ateny. Lubię i gram w planszówki i siatkówkę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *