Trained archaeologist who nowadays specializes in discovering history of applications. Always eager to learn secrets of legacy products. Kasia is currently a Software Engineer at Dynatrace, where she assists 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.
(Lightning Talk (4-7min))
Johnny Cash once said, "You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it." Probably, he didn't know that this quote will perfectly describe organizations that work according to the "fall fast, fail often" mantra.
Incidents are a new normal. Part of the development process. We are seeing an increase in canary releases, feature flags adoption, monitoring to mitigate incidents. While smaller, these are still cuts. How can we avoid our business getting killed by thousands of mitigated problems?
There are a lot of techniques at our disposal, but in this talk, the focus is on not repeating mistakes. I will describe how to benefit from past incidents and encourage engineers to embrace and participate in failures.
Kasia Balcerzak, Bart Szulc
Do you have this feeling certain features will yet again start failing in upcoming release? When you catch a bug, does it seem like a deja vu? Incidents happen. Most of us think of them as materialised risks, but they also can be considered as opportunity. Opportunity to learn and improve. Would you be interested to learn how to draw conclusions from failures, propose corrective and preventive actions, and with them improve your development process and grow quality mindset in your team? This is a workshop for you.
We are all agile nowadays, thus we all strive to self improve iteration over iteration. Regular retrospectives help flush out issues with delivery process, compare current iteration with previous, identify things need addressing, areas worth investing in to increase velocity.
However, what happens when we catch a bug? Do we sit together as a team to identify what went wrong as we would normally do seeing a drop in our velocity in current sprint? I don’t think so. Most likely team will fix the bug and move on with feature development. Probably new regression tests will be added to prevent the bug from happening in future.
Regression doesn’t prevent bugs from happening. It helps with catching recurring symptoms of deeper problems, before they reach our customer and our users. Tests alone don’t address root causes. We’re like doctors prescribing yet another drugs. Not spending enough time on doing patient interview to find problems with lifestyle. Missing nutrients in our team diet.
You will learn how to spot and prevent sources of bugs. We’ll walk you through Root Cause Analysis process on a real life incident you can relate to. Help you understand all vital parts of such analysis, and show you how you can conduct similar process next time you catch a bug.
During workshop you will learn:
-techniques helping build context in which incident happened,
-how to build timeline and why it’s important to have one,
-how to identify causal factors and how they differ from root cause,
-techniques helping figure out root cause,
-what are preventive and corrective actions,
-how root cause analysis can not only help prevent bugs from recurring but improve your testing skills.
- what is root cause analysis
- what are causal factors and how they are different from root causes
- techniques helping identify root cause, propose preventive and corrective actions
- how being better in identifying root causes can help you become better tester by focusing your attention on most likely broken parts of your system