Bart Szulc
PL
Tester z powołania. Ktoś mógłby powiedzieć, że zrodzony do testowania.
Odkąd rozpoczął profesjonalną karierę zawsze związany z automatyzacją i skryptowaniem. W ciągu ostatnich lat pomagał tworzyć strategie, proponować architektury, dostarczać rozwiązania, narzędzia i środowiska, do testowania aplikacji internetowych i mobilnych. Zaangażowany w rozwój lokalnych społeczności testerskich. Prezentuje na popularnych konferencjach testerskich i programistycznych w Polsce i Europie.
Bart, odkąd dołączył do firmy Spartez, pomaga programistą firmy Atlassian zostać lepszymi testerami. Uczy jak poznać produkt i zrozumieć jego jakość poprzez eksploracje. Zakochany w przetwarzaniu danych, naukowym podejściu przy eksperymentowaniu i analizie statystycznej. Dąży do wyznaczenia jednego wzoru, który będzie opisywał temat tak skomplikowany jak jakość w procesie wytwarzania oprogramowania.
EN
Tester at heart. One could say, born to test.
Keeping hands dirty with automation and scripting since started professional career.
Designing strategies, architecting, delivering frameworks and test environments for web and mobile applications. Actively involved in local testing communities. Presenting on most popular testing and development conferences in Poland and Europe.
Since joined Spartez, helping developers at Atlassian become better testers. Teaching them how to learn products and understand their quality by exploration. In love with big data, scientific method, and statistical analysis. In pursuit of quantifying quality in Software Development with a single formula.
Warsztat (Workshop)
Shift left. Findings bugs before they’re implemented
The longer it takes to find a bug the more it costs to fix it. Everyone knows that. That’s why we’re trying to bake high quality into implemented software instead of assuring it after it’s coded. But what if you could spot bugs before they’re even implemented? Would you be interested in preventing them before they’ve materialised in code when they exist in a form of invalid assumption or unknown unknowns? Would you like to learn tools and techniques that can help you with spotting bugs at such early stage?
We’re going to present you several ways of exploring problem space in order to find unproven assumptions, unknown unknowns, and risks, which not addressed may manifest as bugs during and after development.
We often hear Quality Assurance Shifts Left, but what does it really mean? We will show you how at Spartez and Atlassian we’ve moved testing to the very edge of left of software development process. The left where there is nothing more left. You will learn techniques that support learning process and help grow mutual understanding of a problem and expectations. Equipped with them you will be able together with your colleagues, developers, product owners, other quality specialists, better what kind of problem feature is trying to address and what are the risks related to it.
You will look at a feature from various perspectives to find issues. You will analyse architecture, user experience and domain meanders to understand how it can affect the feature delivery and its quality. You will identify relevant risks, propose ways of managing them, create quality strategy. All this done by playing specially crafted cards!
What are the three biggest takeaways you will take from the workshop?
- Learn about Spartez and Atlassian Quality Assistance model and how it works.
- Learn what Feature Kickoff is and how to use a deck of specially to drive it.
- Learn about feature decomposition techniques which unveil complexity, unknowns, and risks related to the feature.
How this workshop is going to affect you?
- You will learn how to Shift Left and help your organisation benefit from your critical mind and thinking as soon as feature idea is conceived.
- You will start looking at a feature from various perspective and find even more relevant risks and scenarios worth exploring.
Who is this workshop for?
- For people of all levels and all roles (Quality Specialist, Tester, Developer, Product Manager, DevOps, Designer, Support). Technical knowledge is not required but is welcomed as exercises will involve system architecture.
Język warsztatu (Workshop language): English
Poziom słuchaczy (Attendee level): wszyscy (all)
Prezentacja (Presentation)
Wychowanie do życia w jakości / Quality-ed: or the art of letting things happen
PL
Od jakiegoś czasu mamy wrażenie, że każdego tygodnia miejsce ma rozgrzana dyskusja odnośnie przyszłości testowania. Mniej więcej ludzie biorący udział w dyskusji zgadzają się, że testowanie ma przyszłość, nie jest jasne jednak jaką przyszłość czeka zawód czy rola testera. Opowiemy wam historię, gdzie w ramach przemyślanego procesu, rola testera przestała istnieć i nie spowodowało to kataklizmu.
Relacje pomiędzy testerem a programistom w zespole można porównać do relacji pomiędzy rodzeństwem w rodzinie. Jako testerzy znajdujemy problemy i prosimy programistów o ich rozwiązanie. Podobnie jak starsze rodzeństwo, wytykamy błędy młodszemu rodzeństwu.
Wygląda na to, że jest nam dobrze z testowaniem czyjegoś kodu. Czy podobnie byłoby, gdy ciągle, przez całe nasze życie, mielibyśmy się opiekować rodzeństwem? Na pewno nie. Chcielibyśmy, aby stali się niezależni, żeby umieli sobie poradzić w życiu. Dlatego w ramach zespołów pracujemy coraz bliżej z programistami jako Agile Testerzy, czy Quality Assurance.
Nie jest łatwo oddać innym coś w czym czujemy się bardzo dobrze, ale staramy się to czynić jako Quality Assistance. Przekazujemy odpowiedzialność za testowanie programiście, trenując i monitorując rozwój umiejętności. Ale czy byłbyś w stanie pozbyć się odpowiedzialności całkowicie? W końcu, aby ktoś stał się kompetentny, musi zostać pozostawiony samemu sobie, musi przejąć kontrole. W rodzinie nadchodzi ten moment kiedy pozostawiamy rodzeństwo same sobie, czy w przypadku zespołu może być podobnie?
Opowiemy o tym jaką zmianę przeszliśmy, aby osiągnąć ciągłe dostarczanie na produkcję. Jak zmiany w kulturze pracy uzupełnione o innowacyjne sposoby udostępniania nowych wersji produktu użytkownikom spowodowały, że odpowiedzialność za jakość przeszła całkowicie w ręce programistów. Opowiemy o tym, jak przeniesienie odpowiedzialności za testowanie oraz ogólne utrzymanie i rozwój jakości, chociaż ciężkie z początku, pozwala usprawnić dostarczany produkt oraz rozwinąć się tobie jako inżynierowi. Jak czasami dobrze jest sobie odpuścić, żeby spojrzeć na standardowe problemy z innej perspektywy, zacząć kwestionować rzeczy, w które do tej pory wierzyliśmy bezsprzecznie. Jak naprawdę to co robimy przypomina taniec. Taniec z ryzykiem. Gdzie testowanie to tylko jeden z możliwych kroków, których jest więcej. Jak różne sposoby wdrażania oprogramowania, tworzenie kultury, gdzie porażka jest doceniana jeżeli wyciągane są z niej lekcje, które pozwalają na usprawnienie. Każdy krok dopełnia poprzedni. Im bardziej kreatywny twój taniec jest, tym lepiej idzie ci w prowadzeniu go, nie poddawaniu się ryzyku.
EN
It seems like every week we have a heated discussion about future of testing. More or less people all agree testing has a future, but they’re not sure about the role of tester. We’re going to tell you a story where due to a thought out process tester as a role ceased to exist, and things didn’t fall apart.
You can compare testers and developers relation to relation between siblings. As testers we find problem and ask developers to fix it. Similarly to older siblings finding issues in youngers behaviour. While we’re fine with testing others code, would we ever wanted to look after our siblings forever? Definitely not. We would want them to become self-sufficient so they can get by in life. That’s why in development teams we tend to work closer with developers, either as Agile Testers or Quality Assurance folks.
It ain’t easy to let go of a thing you’re best at and leave it to others, but we try to do so as Quality Assistants. Leave testing to developers, and coach them and monitor their progress. But would you ever be ready to let go completely? After all in order to make one competent you need to let them do things on their own, take control. At some point of time we leave our siblings to let them be… can we do that with developers?
We’re going to talk about transformation that needed to happen for us to achieve continuous deployment. How changes in work culture mixed with innovative ways software got deployed to users, caused quality to get fully owned by developers.
We’re going to tell you how delegating responsibility for testing and other quality related activities, hard at first, will help you improve delivered product and grow you as engineer. How by letting things go, you will learn new perspectives, start questioning things you took for granted. And how everything we do is like a dance. Dance with risk. Where testing is just one of the steps you can take, but there are others. Like various deployment techniques, creating a culture where failure is encouraged as long as you can learn from mistakes to improve. Each step complements other. And the more diverse your dance is, the better you’re leading it and not giving it up to risk.
Język prezentacji (Presentation language): slajdy po angielsku, prezentacja po polsku (slides in English, talk in Polish)
Poziom słuchaczy (attendee level): wszyscy (all)