To będzie już nasza trzecia edycja Quality Excites. Podobnie jak rok temu, firma Future Processing rozbiła konferencję na dzień poświęcony warsztatom oraz osobny tylko z prelekcjami. My wybraliśmy się tym razem tylko na wykłady. Serdecznie zapraszam do relacji z ostatniej soboty 23 czerwca w Gliwicach!
Rejestracja uczestników
Muszę powtórzyć to co dwa lata temu i rok temu – rejestracja przebiegła szybko i sprawnie, a my otrzymaliśmy identyfikatory oraz notesy z długopisami. Podobno w tym roku pobity został rekord pod względem ilości chętnych, ale miejsca w obiekcie nie wystarczyło dla wszystkich. Przed otwarciem skorzystaliśmy z bogato zastawionych stołów – kawka, ciacho i można powoli przemieszczać się do drewnianej auli na oficjalne otwarcie.
Otwarcie
Jeden z organizatorów powitał wszystkich i przedstawił najważniejsze informacje techniczne dotyczące konferencji, m.in. przedstawienie ścieżek wykładowych, poinformowanie o dostępnych konkursach, hasło do niezbędnego WiFi, a także zachęcenie do korzystania z dedykowanej dla tej edycji aplikacji na telefon. Na koniec przedstawiony został keynote prelegenta Roba Lamberta.
How to thrive as a Software Tester
Rob Lambert otworzył konferencję swoją prezentacją. Motywujący wykład, który po tytule mógłby się wydawać dotyczył testerów, ale tak na prawdę skierowany był do wszystkich, którzy w swoim życiu stawiają na ciągły rozwój. Rob całą mowę oparł o listę celi, które każdy z nas powinien spisać i dążyć do ich osiągnięcia na swojej ścieżce kariery. Otrzymaliśmy 10 porad, które mogą nam to ułatwić:
- Time is NOW – nie znajdziesz lepszego czasu, nie czekaj i nie odkładaj zmian na później
- Have fun with it – niech to co robisz sprawia Ci to radość, jeśli praca nie dostarcza Ci przyjemności to zmień ją
- Decide to thrive – najważniejsza jest sama chęć rozwoju
- Trade your freedom wisely – szukaj firmy, która nie będzie Cie ograniczać
- Ship software – dostarczaj oprogramowanie, wartościowe oprogramowanie i pamiętaj, że to klient jest najważniejszy
- Embrace our differences – pamiętaj, że każdy człowiek jest inny. Jedną z największych zalet liderów jest umiejętność wydobywania z kolegów/pracowników tego co najlepsze. Nie daj się “przebranżawiać na siłę”, jeśli nowe zadania nie sprawiają Ci przyjemności postaraj się znaleźć inne wartości, które jesteś w stanie wnieść w firmę lub zmień pracę
- Mistakes are an opportunity to learn – stale ucz się na swoich błędach i błędach kolegów, a tym samym stawaj się lepszy. Pamiętajmy, że samo popełnianie błędów nie dostarcza nam wiedzy, ale świadomość, że się je popełniło i rozwiązanie ich już tak.
- Learn anything that interests you – czasem warto sięgnąć po książkę z innej działki, żeby dostrzec trochę inne spojrzenie na daną sytuację. Jeśli jesteśmy testerami – sięgnijmy po książkę pisaną przez developera/analityka biznesowego i na odwrót. Wiedza ludzi na tym samym stanowisku często bardzo dobitnie sugeruje jaką drogą iść, a w życiu chodzi też o to, aby stworzyć swoją własną spersonalizowaną ścieżkę kariery. Uczmy się tego, co faktycznie nas interesuje, a nie tego z czego będziemy mieć certyfikat ładnie wyglądający w CV (dobrze wiemy, że to wcale nie odzwierciedla naszego stanu wiedzy).
- Step outside of your job description – nie przypisujmy się sztywno do stanowiska, bądźmy agile. Najlepsze firmy mają duży problem przy krótkim opisie danego stanowiska.
- Ask questions – to nic innego jak testowanie, zadawajmy jak najwięcej pytań, nie bójmy się tego. Zdobyte odpowiedzi to cenna wiedza.
Wybierając firmę, w której chcemy pracować zwróćmy uwagę na panujące tam relacje. To właśnie one są głównym elementem, na którym oparta jest nasza kariera. Technologie, frameworki, metodyki są niczym jeśli nie potrafimy się dogadać w teamie.
Oszczędny Programista czy Hojny Tester?
Daniel Dec wyjątkowo nie w roli organizatora. Tym razem mieliśmy okazję zobaczyć go na scenie opowiadającego o tym jak być organizacją High Performance. Jak duże są koszta tworzenia i utrzymania nieprzemyślanego kodu? Gdzie popełniamy błędy, jak wykrywać i usuwać straty? Większość firm nie patrzy w przyszłość, nie zastanawia się jak ruchy, które zostaną wykonane dzisiaj drastycznie mogą wpłynąć na nasz budżet w przyszłości.
Winter is coming!
Ile razy zdarzyło nam się zrobić w pracy coś, co po czasie zostało zdeptane i wyrzucone do kosza? Biznes się rozmyślił, źle zrozumieliśmy wymagania, a może chcieliśmy myśleć za klienta wierząc, że sami wiemy czego potrzebuje? W przypadku PoC oraz zwinnego dostarczania produktu, takie “niechciane” ficzery szybko zostałyby wycofane zanim zdążylibyśmy poświęcić im za dużo czasu i pieniędzy, ale ile z nas faktycznie zwinnie dostarcza klientowi soft i ma szybki feedback?
Na początku Daniel zrobił krótki test składający się z 4 pytań. Na jego podstawie można było stwierdzić, że większość sali to Medium, ale były też przypadki High jak i niestety Low Performance. Na podstawie leanowego Muda Muri Mura Daniel zwrócił szczególną uwagę na:
- overproduction – ok 64% ficzerów jest rzadko lub nigdy nieużywana
- wszystko co rozpoczęte i nieskończone – to spore straty, wraz z czasem migracja staje się coraz bardziej problematyczna
- overprocessing, extra processing – wszystko co musi być ręcznie utrzymywane
- zbędny transport – przekazywanie zadań do innych działów, zgubienie po drodze wymagań klienta
- zbędne ruchy – nieczytelny kod, a co za tym idzie zawyżone estymacje, wolniejsza praca, małe zmiany trwają dłużej
- czasy oczekiwania – na wymagania, decyzje, deployment, środowiska, testy, pracę innych działów. Jak czekamy to rozgrzebujemy następne zadania, a to z kolei powoduje straty
Nie jest dobrze, ale co możemy zrobić żeby było lepiej? Postawmy na Continous Delivery. Wdrażajmy małe (na prawdę małe) zmiany, to pozwoli nam uzyskać szybki feedback, a także bezproblemowo przywrócić starszą wersję w przypadku pojawienia się błędów.
Nie ma co czekać, aż problemów będzie więcej. Zacznij TERAZ – spróbuj usunąć jakąś stratę!
Riders On The Storm: API Gateways not only for developers
Kompleksowa prezentacja na temat wzorca API Gateway (nasz artykuł na ten temat) została przedstawiona przez Tomasza Skowrońskiego. Była to prelekcja w oprawie Wiedźmińskiej, w której prelegent zaczął od przedstawienia problemu tak zwanych zagadnień przekrojowych (aspektów) takich jak autentykacja, czyli logowanie oraz możliwych rozwiązań tego problemu, np. revers proxy. Innym sposobem rozwiązania tego zagadnienia może być zastosowanie wzorca API Gateway. Autor opowiedział o tym wzorcu, o jego wadach i zaletach, ale również o zastosowaniach.
Następnie pojawiły się gotowe biblioteki implementujące ten wzorzec. Najpopularniejszym rozwiązaniem jest aplikacja Kong. Prezenter przedstawił także TYK i Krakend, ale pojawił się również opisany na naszym blogu Zuul.
API Gateway doskonale sprawdza się w roli narzędzia do kontrolowania ruchu. Możemy nakładać ogarniczenia oraz jednocześnie rozkładać ruch (load balancing) w naszej aplikacji. Mechanizm ten możemy wykorzystać do testownia typu A/B testing, do wdrożenia blue green deployment, czy do releasów kanarkowych. Stosując ten wzorzec warto zadbać także o service discovery (więcej tutaj), aby można było łatwiej łączyć się z innymi serwisami.
Była to bardzo dobra techniczna prezentacja, na której pojawiły się prawie wszystkie zagadnienia związane z API Gateway.
Testing batch and streaming Spark applications
Ze Sparkiem żadne z nas nie miało wcześniej praktycznego do czynienia, ale opis prelekcji nas zaciekawił. Nie zawiedliśmy się, Łukasz Gawron z firmy Perform zaczął od lekkiego wprowadzenia. Pojawiła się też wzmianka o RDD (ang. Resilient Distributed Dataset), która jest podstawową strukturą danych w Sparku. Dane rozproszone są na kilku partycjach, które są przeszukiwane w momencie wykonania zapytania. Następnie, aby lepiej zrozumieć zagadnienie, prelegent przedstawił prosty przykład w stylu “Hello World” (napisany w Scali). Do tego przykładu pisane były różnego rodzaju testy. Ponadto Łukasz przedstawił nam dobre praktyki związane z testowanie Sparkowego kodu.
Konkurs
W porze obiadowej udało nam się odebrać nagrody książkowe. Poniżej nagrodzona fotka wrzucona z hashtagiem #qualityexcites na Twittera i nasze książkowe zdobycze. Dziękujemy Quality Excites za nowe pozycje na naszej półce.
Mocne powiewy wiatru w chmurach
Już na wstępie Bartek Szulc zaznaczył, że prezentacja jest jego własnymi przemyśleniami i nie odwołuje się w niej do żadnych książek i artykułów. Benefity związane ze środowiskiem cloudowym opisać można jako:
- duża ilość ludzi – skalowanie
- dostęp z każdego miejsca
- serwisy komunikujące się ze sobą
- monitoring
- Continous Deployment
Następnie przedstawił, wady i zalety feature flag oraz jak testować aplikacje w takim środowisku. Dużą zaletą tego modelu (cloudowego), jest możliwość monitoringu aplikacji. Dzięki obserwacji wartości oraz reakcji na skrajne sytuacje, możemy testować nasz system na produkcji. Na koniec prelegent podkreślił to, iż powinniśmy zadawać pytanie “dlaczego to testujemy?”.
Konkurs
Kolejna przerwa i Krzysiek w swoim żywiole. Przed kamerą opowiada o konferencji. Dzięki temu CodeCouple ma kolejną książkową nagrodę.
Software Quality Assistance w 40 minut
Wykład prowadzony był przez Przemysława Secha w sposób interaktywny. Czym jest jakość? To wartość dla jakiejś osoby, a więc nie ma jednoznacznej definicji, dla różnych osób będzie inna. Dlaczego właściwie dbamy o jakość? To proste, słabą jakość ciężko sprzedać. No to kolejne pytanie, skoro dla większości jakość jest ważna, to dlaczego tak trudno uzyskać dobrą jakość?
Podczas prelekcji wyjaśniona została różnica między assistance i assurance. Przemek zwrócił uwagę, że traktujemy różne stanowiska jako całkowicie rozłączne role. W przykładowych historiach wymienione były 3 role – developer, ops i tester. W takim podejściu każdy robi swoje, przekazuje zadanie dalej i rozpoczyna następne. W przypadku błędu zadanie jest zwracane do autora i okazuje się, że mamy już dwa, albo więcej zadań rozpoczętych i nieskończonych. Przełączanie się pomiędzy zadaniami jest bardzo czaso i kosztochłonne. Jak możemy to usprawnić? Należy połączyć moce, każda z roli powinna mieć wsparcie u pozostałych. Unikajmy efektu łodzi, w którym dziura nie jest po naszej stronie. Warto tworzyć reużywalne “klocki” w systemie, dostarczać gotowe szablony do innych działów, aby ułatwić im pracę. Nie ma rozłącznych celi dla każdej roli w teamie, jest jeden cel – dostarczenie wartościowego produktu klientowi. Ważna jest rozmowa, a w szczególności zadawanie pytań.
software testing -> asking questions
Wszystko to prowadzi nas jak już wspominał Daniel Dec to osiągnięcia poziomu organizacji High Performance.
Najlepsza według Agnieszki
Testy wydajnościowe w świecie mikroserwisów
Wydajność aplikacji jest bardzo ważna, przekonywał nas o tym Tomasz Dubikowski. Możemy mieć aplikację, która działa świetnie przez cały rok, ale w jednym dniu ilość użytkowników, którzy z niej korzystają w jednym czasie drastycznie wzrasta (np. system z wynikami matur lub zliczający głosy z komisji wyborczych). No i mamy klapę, a przecież te aplikacje wcześniej działały! W tych przypadkach nie mamy konkurencji, ale w momencie kiedy możemy wybrać jedną z wielu aplikacji, które mają podobne ficzery zawsze wybierzemy szybszą. I co najważniejsze, to nie my decydujemy czy nasza aplikacja jest szybka, tylko nasi użytkownicy. Mamy różne rodzaje testów wydajnościowych:
- Peak test
- Load test
- Stress test
- Endurance test
Najlepiej jeśli mamy zaimplementowane w swoich systemach każdy z tych rodzajów.
Testy wydajnościowe trochę omówione, no to czas na ich wprowadzenie w świecie mikroserwisów. Pamiętajmy, że aktualnie hype na mikrousługi niekoniecznie jest słuszny, nie w każdym z przypadków będą się sprawdzać.
Tomek przedstawił nam dwa narzędzia, które pomogą nam testować wydajność naszych aplikacji – jMeter oraz Gatling. Poznaliśmy różnice między nimi, zalety Gatlinga oraz mnóstwo wad jMetera:)
Web Application Security Test Automation
Marek Puchalski starał się nas przekonać do tego, że automatyczne testowanie aplikacji webowych nie jest wcale trudne. Na początek porównane zostały podejścia Agile oraz Waterfall (dłuższe releasy). A jak trudne jest włączenie testów bezpieczeństwa do każdego z tych podejść? W Waterfall nie ma problemu przez to, że mamy dużo więcej czasu. W agilowych sprintach stosować można pentesty (ponieważ są szybkie). Główne problemy z testami bezpieczeństwa są spowodowane brakiem wiedzy i zainteresowania. Koniec końców wszystko zostaje zepchnięte na developerów, którzy są obłożeni innymi zadaniami. Jeśli już się przekonamy do testów security, nie zapomnijmy ich stale automatyzować, powinny one być częścią continuous delivery.
Następnie Marek wspomniał o organizacji OWASP, która zajmuje się zbieraniem najpopularniejszych luk oraz ich rozwiązań. Warto jest je znać, ponieważ dzięki temu lepiej poznajemy technologię, z którą pracujemy. Przykładowo, należy zejść na poziom HTTP. Pamiętajmy o special cases, takich jak TLS.
Na koniec, prelegent pokazał bardzo prosty i sprytny sposób na test naszej aplikacji pod kątem SSL. Możemy napisać test, w którym uruchomimy https://www.ssllabs.com/ i na podstawie otrzymanej litery możemy stworzyć asercję (test SSL za darmo).
Najlepsza według Krzyśka
Automating Assurance: Tools, Collaboration and DevOps
Na zakończenie pojawiła się prezentacja Paula Gerrarda, który jest autorem wielu książek (między innymi “Digital Assurance”, “The Tester’s Pocketbook” czy “The Business Story Pocketbook: Building Better Software with Business Stories”). W Anglii aktualny czas technologiczny określa się mianem Digital. Przedstawił on aktualną wizję testerów/QA w sposób kontrowersyjny (naszym zdaniem). Nie od dziś wiadomo, iż przerzucanie się zadaniami jest nie efektywne. Paul zasugerował, że developerzy powinni testować aplikację oraz pisać testy automatyczne do nowo napisanych funkcjonalności. Testerzy powinni być “nawigatorami”, natomiast developerzy “pilotami”. Jako nawigatorzy powinni znać dobrze domenę biznesową oraz kierunek rozwoju aplikacji. Dla nas, jeśli developerzy mają coraz więcej odpowiedzialności (doszły testy automatyczne), to być może testerzy zamiast w stronę biznesu, powinni iść w stronę developmentu. Ktoś może zarzucić, że co w takim razie ze zrozumieniem biznesu, spokojnie w developmencie mamy przecież DDD. Prelekcja była poprowadzona w sposób bardzo profesjonalny i dała nam inne, zupełnie nowe spojrzenie na współpracę na poziomie developer-QA.
Zakończenie
To już koniec konferencji. Organizatorzy podziękowali prelegentom i uczestnikom za przybycie i zaprosili na afterparty. Konferencja była jak zwykle na najwyższym poziomie, zarówno prelekcje jak i organizacja wydarzenia. Za udział w konkursach można było wygrać bardzo fajne książki z firmy Helion (jeden ze sponsorów) oraz tegoroczne koszulki QE. Była to bardzo atrakcyjna forma zachęcenia do aktywnego uczestnictwa w konferencji.
Dziękujemy i mamy nadzieję, że zobaczymy się za rok!