Zapraszamy na nasze pierwsze powakacyjne spotkanie, które na pewno będzie wyjątkowe. Odwiedzi nas dwójka rewelacyjnych prelegentów z Gdańska – Kasia Balcerzak oraz Bartek Szulc. Jeśli już same nazwiska was nie przekonują to na pewno zrobią to tematy: Kasia opowie o Root Cause Analysis (czyli o tym jak uczyć się i zapobiegać błędom), a Bartek o Wiremocku (czyli będzie o testowaniu mikroserwisów, mockowaniu, stubowaniu, ….) . Nie wyobrażamy sobie, iż mogłoby zabraknąć dla kogoś z was miejsca, dlatego też po raz drugi w naszej historii odwiedzimy Politechnikę Poznańską, która zapewni nam salę na 150-200 osób.
Kiedy: 14 września (piątek), start godz: 18:00
Gdzie: Sala CW1, Instytut Informatyki Politechniki Poznańskiej, Piotrowo 2, 60-965 Poznań
Rejestracja: brak!!!!
Nauka na błędach – root cause analysis w praktyce.
W metodyce Agile zawsze podkreślana jest rola retrospektyw w procesie udoskonalania się zespołu. To retrospektywy pozwalają zespołowi wyciągać wnioski z poprzednich iteracji, znaleźć słabe strony i obszary konieczne do poprawy stabilności zespołu. Co iterację zespół znajduje czas, aby podsumować to, co wydarzyło się i wyznaczyć kierunek, w jakim będzie rozwijał się w kolejnym.
Jednak co najczęściej dzieje się kiedy występuje incydent w produkcie?
Często zespół ogranicza się do wrzucenia na poprawki. Testerzy dopisują kolejne testy lub aby wykryć ponowne wystąpienie tego błędu.Jednak nadal nie wiadomo co spowodowało problem i jakie akcje należy wdrożyć, aby zaadresować przyczynę, aby podobnej klasy incydenty już nam się nie przytrafiły. To źródło może być odkryte poprzez wykorzystanie Root Cause Analysis. Ta analiza może być wykorzystana przez zespoły odpowiedzialne za jakość w taki sam sposób, w jaki zespoły deweloperskie wykorzystują retrospektywy.
W trakcie tej prezentacji chciałabym:
– Opowiedzieć jak może wyglądać root cause analysis dla przykładowego defektu.
– Dlaczego warto jest tworzyć osi czasu dla incydentu.
– Jakie są korzyści z root cause analysis.
– Jakie informacje możemy uzyskać z analizy.
– Jakie wnioski, i na ich podstawie akcje, możemy zaproponować, żeby uniknąć problemu w przyszłości.
Kasia Balcerzak – Archeolog, specjalizujący się w odkrywaniu przeszłości aplikacji. Zawsze chętna do odkrywania skarbów skrytych w produktach. Swoje pierwsze kroki w testowaniu stawiała w Poznaniu. Obecnie wyemigrowała do Gdańska gdzie pomaga dweloperom w Spartezie w zapewnianiu stabilności dla klientów Enterprise.
Codziennie szuka nowych rzeczy do nauki i pomaga innym jako mówca i trener.
Wiremock
Słyszałeś o mockowaniu? Obiło ci się o uszy test double? Implementowałeś double za pomocą mockito przy testowaniu jednostkowym, ale nie wiesz jak implementowanie double przekłada się na pracę z microserwisami. Zaprezentuje narzędzie, które pozwala w łatwy sposób zastąpić na potrzeby testowania rzeczywisty serwis lekką jego implementacją. Opowiem skąd ten pomysł, jakie przyświecają mu cele, jakie wiążą się z nim konsekwencje i ryzyka. Przedstawię również możliwości narzędzia, takie jak stubowanie, weryfikacja, proxy, transformacje, itp. Jeżeli systemy z którymi pracujesz stają się coraz bardziej rozproszonymi, bądź chciałbyś się dowiedzieć jak wykorzystać Wiremock przy eksploracji, ta prezentacja przypadnie ci do gustu.
Bartosz Szulc – Tester z zamiłowania. Od początku swojej kariery zawodowej związany z automatyzacją testów. Trener w infoShare Academy. Obecnie zajmuje się projektowaniem strategii, architekturą, dostarczaniem framework’ów oraz środowisk testowych zarówno dla pojedynczych stron, jak i na potrzeby responsywnych aplikacji. Zaangażowany w działalność lokalnych społeczności testerskich i prelegent najpopularniejszych konferencji branżowych w Polsce. Od niedawna członek zespołu firmy Spartez, gdzie wspiera projekt Atlassian pod kątem szkoleń i mentoringu oraz udowadnia, że programiści mogą być dobrymi testerami. Dotychczasowa praca nad produktami o skomplikowanej architekturze, zawierającymi duże bazy danych, ustąpiła miejsca zainteresowaniom w tematach analizy danych i problemów związanych ze skalą w automatyzacji. W codziennej pracy Bartosz stara się połączyć psychologiczne aspekty testowania z cyframi i automatyzacją.
