Katarzyna Balcerzak 2019

Z wykształcenia archeolog, który aktualnie specjalizuje się w odkrywaniu historii oprogramowania. Zawsze chętna poznać sekrety produktów. Kasia, jako Quality Engineer w firmie Spartez, wspiera programistów firmy Atlassian w tworzeniu dobrych produktów dobrze.
Znajdziesz Kasię wszędzie tam, gdzie można podzielić się wiedzą i doświadczeniami związanymi z testowaniem i jakością. Zawsze otwarta na poznanie czegoś nowego. Ciągle doskonaląca się jako prelegent i trener, aby pomóc innym odkryć meandry świata zapewniania jakości.

Trained archaeologist who nowadays specializes in discovering history of applications. Always eager to learn secrets of legacy products. Kasia is currently a Quality Engineer at Spartez, where she assists Atlassian developers making the right products right.
Wherever Kasia can get involved in quality and testing you will see her there. Always looking to learn something new everyday. Improves to help others as speaker and trainer.

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 programistą 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)