 Let's talk. This is going to be communicating risk by Jenny Bramble and Dante Hi, I'm Jenny Currently I am a software test creature over at a company called willow tree. We make digital Digital innovation agency we make mobile apps for clients. It is way more fun than I thought it would ever be That's not our office, but I'm trying to argue for a ball pit So my history I was originally a support monkey. I did support loved it Accidentally got into DevOps hated it Went running and screaming back to support then kind of did this weird support QA kind of roll and they finally Drug me kicking and screaming into software testing. How many software testers do I have in the room? Oh, yeah Represent Fantastic, so that's where I'm coming from. I am a QA creature That's how I define myself in my professional life and in my personal life I think of myself as a tester and a questioner and a seeker of things Well enough about me. Let's talk about risk. Oh, right. This is Dante. He trapped himself in the bathroom for 12 hours once Yeah, that was a fun maintenance request to the apartment So, what are we gonna do today? We are going to talk about a bunch of stuff first off We're gonna talk about my job. We're gonna talk about how words are awful Then we're gonna define risk. I'm gonna talk about using that definition I might skip some slides. I will totally provide them afterwards and you can be like, oh, I can't test everything Please don't ask me to test everything. I was in grooming the other day and my principal engineer goes We're going to tell stuff everything and I'm like, no Maybe you want to test everything, but I'm not gonna test everything. I can't My gosh, oh my job. I know you like nice things like the banana bed What is my job, okay, I ask questions I absorb the answers I translate those answers from what I understand to what other people understand I talk to my developers I talk to my software principles. I talked to product owners. I talked to clients. I talked to random people on the street I talked to my mom. I Verify that systems under test perform in all the ways that the stakeholders expect Or help reset those expectations and I find that's becoming a larger and larger part of my job as I'm becoming more senior is saying your expectations are a Thing that you have you might need to think about them I educate other humans about testing and I'm not sure I'll be able to I'll have time to get to that in this talk But if you ever want to talk to me about what testing is, I'm your girl Also, there's some other testers in the room. They're also your humans. I Advocate for quality practices methodologies and thought patterns again as I become more senior in my role I find my job becoming a little more abstract. I don't do quality. I Promote quality. I advocate quality. I defuse bombs usually those are human and I evaluate and communicate risk to the people around me Dante thinks my job also entails petting Dante Yeah, there's gonna be a lot of cat pictures in here if you don't like cats. I Don't have anything for you Everyone knows what risk is right? We all know what risk is my coffee. Sweet. My sister likes her coffee sweet If she gave me sweet coffee, I would die She likes a teaspoon of sugar in hers and I like a Sweet means two different things to two people that are genetically similar When I say risk it means one thing to me It means something entirely different to my product owner something entirely different to my developers something entirely different to my mom These words are terrible words are the absolute worst way that we can possibly communicate There's so much variability in them. There's so much that makes them gooey and weird and squishy These terms have a lot of connotations to us personally and to all the people around us and I can't really predict how you feel about certain words, but We can define terms once we start defining terms. We start being able to communicate across cross functional teams We start using the same words, but most importantly We're using the same meanings for those words if we're using different meanings. They might as well be absolutely different words It gives us the ability to justify our decisions to people outside of our sphere And when I say sphere for me that means my my group of testers. I Can now talk to my product owners. I can talk to developers. I can talk to random people I can talk to my mom. I really need to call my mom today And I can give updates that have depth and that have meaning and when I say depth. I mean, I'm not saying I tested I'm saying I tested this thing and I found it was risky. I found this I found that these terms start to have meaning my status updates Start to have more meaning. I used to find myself a lot of times I'd be in scrum and I'd be like, I'm testing today And they'd be like, good job. I don't do any tests. Well, yeah, I've tested. That doesn't mean anything I could be walking out and getting milkshakes for everybody and for all they know When I start defining terms when I start saying, hey, this is what I mean when I say I'm testing This is what I mean when I start freaking out about things that are risky It starts to have a little bit more color and make a little bit more sense and We can also start determining what resources we need to apply to a project That's gonna become a little bit more clear later. That's sort of a weird place to put that bullet point Once we start to Someone told me I didn't take myself seriously enough and I'm like I'm sorry We can communicate more clearly Precisely because we all know what we're talking about my sister and I had a long discussion about coffee For about a week and now she can make me a sweet coffee I can make her a sweet coffee and that's that's really improved our relationship a lot. Gotta be honest Dante communicates it polisibly inviting and crying lots of crying What is this? Okay, we're back to this topic again. I love this topic. This is anything to go wrong. It's something awful. It's so scary It's a headline bug. It's running out of cat food It's everybody panic production is down. We're all gonna get fired. We're gonna have to work at McDonald's We're gonna go anything it could be so much stuff and I'm Super emotional I communicate almost exclusively through panic attacks and Waving my arms like one of those things you see outside of a Yeah, you're laughing because you're like I know that person A long time I had a lot of trouble communicating with logical people a Lot of the humans I work with think logically they think progressively they think in steps They say this is a thing. This is a reason that thing happened Let's fix that thing and I'm like and I would say things. Oh gosh. Oh Poor baby Jenny. I would say things like I feel bad about this. This feature makes me sad I'm upset and the developers are like You were really squishy and weird and I don't know how to deal with you So I had to bring them into my sphere I had to start teaching them about my emotions Because that's the only way we could communicate. I Mean I was having trouble communicating logically and they could assign meanings to the things I would say like I feel bad Once I started being able to think about defining terms and defining my gut instincts into actual phrases and words that were not just My life got a lot easier everyone around me their lives got a lot easier and a little bit quieter, I'll be honest What is risk risk is the impact of failure and the probability that that failure will occur so simple give or take and A way that I could now say to my product owner. I think this is risky. I think this is dangerous. I am worried This is why these two things make up this term that was nebulous before and now we've hardened it a bit Dante would like to Don't worry. I didn't give him anyone Let's talk impact of failure any potential negative impact contributes to the risk of the application feature or use case are So many different kinds of impact a lot of times we think impact is production goes down There's a hot fix. There's an issue We can have a lot of different kinds of impact We can have technical loss of data and introduction of security laws business What if revenue can't be collected? What if critical functions can't be performed? What if the CEO's name is misspelled? We can have morale issues come up if a user has to utilize a workaround because of something we've introduced That's an impact my previous position most of our users actually worked across the street from us and We had a couple of pitchfork incidents Fire no longer allowed in the office You can also see slowed down workflows any of these impacts that people don't understand why they're happening is Going to be an issue and that's going to be a morale thing We would have some success and we explained to them that this workaround was going to start having to be utilized But still it's an impact because they don't really understand why You are doing this to them And that's that's kind of a bummer When we start thinking about impact of failure, we want to start determining what features the users look at the most What do they touch most often? What happens if that fails? Are they gonna not be able to interact with the system? Are they going to lose data? Are we gonna lose money? Well, someone literally died In case of like a medical thing. It's it's a potentiality In short, what is impactful to the company? What makes an impact on the company on the users on the team on anyone? That could be impact Dante gets it Impact of leaving him for the weekend is everything falls off the table Also last time he dug a hole in one of my plans and got dirt all over the place Clearly I need a Dante sitter Let's talk probability of failure the likelihood that the application use case feature will fail Seems pretty simple, right? It'll fail or it won't so When we start talking about probability of failure, we're making educated guesses. We don't know How likely it is to fail we guess But we have data that can help us tell if we're guessing in the right direction Has it failed before has something similar failed? Do Excuse me. Do we have historical data in the form of defects or tribal knowledge RCA's QCA's anything like that? That weird guy in the corner that's been there forever and knows literally everything look to that guy. That's a great guy I know These things are gonna help us determine. Can this can't we guess if this is going to fail? Again, we want to also ask how often the users interact with this. Is this something they are hitting every single day all the time? So maybe we need to think a little bit more about the likelihood that it's gonna fail If we start if we start with this and if we miscalculate it Then we start to put ourselves in kind of a weird position down the line We'd be like, oh, I didn't think it was gonna fail. Oops and That could be super uncomfortable One of the things I like to do there is talk to as many people as possible if you can see why a Then you're in a way better position if you guess incorrectly and remember your failures Remember if you've guessed incorrectly because that'll help you not guess incorrectly the next time something similar comes up Again, what use what features to users interact with the most? How do they interact with them? What's inherently fragile? Are there external changes to consider? How do you feel? Are you proud of your features? Those are two questions that I like to ask developers and I like to ask product owners And I like to ask technical requirements managers if I've got them on the team I find that there's not a lot of situations where we ask if we're proud of something unless it's failing Are you proud of what you've done? Can be really valuable It's okay. You can laugh. It's cool It can be really valuable to ask somebody if they're proud of a feature You would not believe the number of times I've gone to developers and said are you proud of us? Are you happy to be releasing it? And they're like and you step back and you think hmm Let's run a few extra test cases on that bad boy Someone is proud of something when they're happy about it when their morale is high the quality of that product is generally going to be higher People ask all the time in quality assurance What is a metric we can use to evaluate your performance and someone in the back goes How many bugs and then the rest of the QA people start beating them up Because that is the worst metric to ever use for anything quality assurance Number of bugs is essentially pitting two groups of people against each other against their will and that's not okay That's super not okay When I was a baby QA monkey, I used to Think I was playfully antagonistic with my developers It was me versus them and I always won and as I've gotten older. I'm like Because it's not me versus them it's an us thing and That's why my favorite quality assurance metric is morale If your team is happy if you are generally pleasant with each other if you generally like each other If you generally feel good about your product, it probably has a pretty high amount of quality into it You can say yeah, I'm proud of this It's probably pretty awesome unless you're working with terrible people at which point we're hiring These are very educated guesses about what might fail You may get it wrong You're probably not going to because you're good at your job. You know what you're doing You've done this before and you've got people you can ask about it Unlike Dante was very very He fell off the roof doctors outside your feature use case or application can also Contribute to risk and there also something that need to be talked about I say impact of failure and probability of failure and also Other types of risk so There's a lot of things here. This is not everything because Everything is a huge number These are things I've run into in the past Six months modified timetable more time or less time a lot of times you're like, oh more time. Yeah, we can do stuff It's gonna be great No, your developer is in the back and that you're refactoring something When you give people extra time, they're like, okay, we can do more and if they're doing more That's potentially gonna increase risk because we weren't thinking about that from the start And if you weren't thinking about it from the start, it can't really evaluate it I Used to have a developer when I joined his team the team lead took me inside and it's like He's going to refactor something. Tell him no And that was really fun because he wanted to make a better product But we had to kind of rain that in so that we could make sure the features that we were Contractually delivering were as good as possible. I love that kid Environmental issues Changing anything on production on staging on dev is going to increase the risk a lot of times You don't think about staging as being a risky place But if it doesn't mirror production in exactly and it doesn't it can potentially be useless I saw some tweets coming through about a talk where someone kept saying over and over staging is useless And I need to hunt it down because that sounds really interesting And it also makes the hairs on the back of my neck rise up, which is the sign of a good talk New or inexperienced team members can also be risky. Hi, that's me. I'm a new team member I've only been at my job for a month and a half. I know nothing I don't even know what I don't know and that's really kind of a cool place to be because I get to learn everything But at the same time I also have to learn everything I've started taking to switching where I'm sitting so I can sit next to all the QA people. It's getting super annoying, but I love it Natural disasters. I'm from North Carolina. We have hurricanes. We have terrible drainage There's been more than one time where I've been flooded in or out of the office with and without power If the power goes out in the office for my old job Every staging server went down every team environment went down and parts of production stopped working Don't think about that too much. It hurts Sickness had an entire stroke team out for three weeks because someone didn't get their flu shot get flu shots And that's something you can't actually predict very well. You never quite know when sickness like that is gonna hit and sometimes it does Outside pressure your CEO walks past like that thing do that thing Or a VP or literally anybody that thinks they have a say in your life walks past it tells you to do a thing and Then industry specific risks. My old position was in digital marketing Facebook was generally considered a risk for us because they would randomly update their API They'd be like, okay, so that thing he used to do. Yeah, it's cool You don't need to do that thing. Yes, we do. We do need to do that thing. Uh, so that was that was a really interesting Experience they also didn't have a good sandbox I Know baby. It's a lot to think about. Yes, it's necessary found out the bow jangles I am so sorry for literally everyone else in this room come down to North Carolina. I will buy you a biscuit Don't tweet that I don't need the entire Twitterverse asking me for It's absolutely necessary to talk about risk. It's absolutely necessary to talk about this language We cannot test everything. We have limited time limited bodies limited resources limited attention spans. I Get bored super easily if you ask me to test everything, I'm not going to and if I do I'm gonna do it really terribly Once humans get bored we make mistakes You make all the mistakes and we don't realize we're making them and that's the main reason why testing everything is is Kind of depressing because you know, you're going to fail at it. I'm like, what's a bummer? So we assess risk. We talk about the impact of failure. We talk about the probability of that failure We define these terms so that we can create this language so that we can start saying, okay, we can't test everything But we can test what's risky. We can test what's important. We can test what makes a difference in our lives Well, I did that slide like three minutes ago What we can do is we can communicate clearly and precisely why we test what we test I can say I'm doing this because it's risky and it's not just wavey arm man freaking out about risk It's me having sat down with my team during grooming and said Is this risky? How's this failed before? What happened when it failed? What could happen if it fails? Why are you not as scared about this as I am? What do you know that I don't know? You get so much information by asking that And then the developer made fun of me for saying I was scared. It's like it's just code and I'm like a little scary little letters. I miss that guy And when I say test In my world, I mean test. I mean I do a thing. I make a thing. I test the thing. I get the information back I relay it. However, this can also be giving more attention to one item than another item It could be raising concerns about a feature talking about needing more resources Choosing what stories to play even and asking for more time and then where do you focus your manual and automated efforts? Risk can be used to evaluate all of these things You can use it to say hey, I have a concern about this. I think it's risky Let me define these terms for you Let me talk to you about them and then let's have this conversation between the two of us between the four of us between the eight of us as to what risk is and What we can do to mitigate it on Dante thinks we should have a serious discussion. Oh, no Dante just wants to take maps Spoiler alert. I picked that flooring color because it matched my cat Normally I dive into some risk matrix examples here. I'm not gonna do that because as I guessed Probably out of time But it exists. It'll be in my slides and we can talk about it at some point if you'd like to find me I'm super cool. I promise So but the one thing I want to leave you with on risk matrices a Complex or simple they need to convey the correct information when we start making these We're talking about actually putting a number on the impact of the failure the probability of the failure and using that to determine Where we go how we move forward. I Do want to tell you a story because I love stories This one's true imagine this My team is in a room together. We are not happy creatures We are sitting around a table our product owner sitting across the table from me and My team lead says we can't release this project And the product owner goes why can't we release this product? It was in alpha for like a year and We've had it in beta for like Three months you guys have had so much time. Why can't we release this product? And we all kind of looked around and I said This product Was a good girl who went to college filling with the wrong crowd started drinking needs to go to rehab before we can release her to the public And he looked down and he looked up. He's like, yeah Understand that was We got deep into this project we found that there was a significant amount of bugs a Significant amount of refactoring and some re-architecting that had to happen for it to even freaking run on our production servers and That was insane. It was so much more work than we thought it was going to be and then we demoed it for the users And they told us they wouldn't use it And we're like, um And you guys approve the designs you approve the design. They're like, we haven't seen this Almost a year and no one's talked to you panic attacks. I Was having them other people were having them It was one of those situations where the VP of engineering walked into the room and it's like, so we're doing this, right? We can't do this What we did was we started creating a risk matrix we sat back and we said, okay, what are the things that have gone wrong? What are the bugs? What's the impact of those bugs? What does it look like if we let them out? We decided on these different terms we wanted to say what's the risk to the user of catastrophic failure What's the risk to engineering of significant technical debt? What's the risk to the team's morale of failing sprints having hot fixes anything that would drag us down? And then we also said when can we fix these issues? Is it something that has to be fixed before we hit prod? Is it something we can take care of afterwards if given the time? And I also argued for a pitchfork index, which is how upset I thought the users were gonna be if we didn't fix some bugs It's very important to me that people in my groups and my tell my teams understand that they are not just making things Because they were told to make a thing. They're making a thing because a person needs it And if nobody needs your product, why are you making it? So no one agreed with my pitchfork index, but I kept bringing it up and they started laughing at me, which is fine I'm cool with that So we were able to actually get out in front of our VP of engineering and say Hey, this is why we can't release. This is why this can no longer be a Q2 goal for us We have reasons we have words. We have meanings. We have definition. We built trust with him and said hey This is what we've got. We're not going to put it under the rug. We're not going to lie to you We're going to give you Actual numbers that tell you how bad we feel and he was like Q4 then and that was a huge win for us because we actually got the time to talk to the users Make the design that they would use and fix a lot of the bugs and then I quit my job Supposedly and went well though and of course Dante always discussed risk with everyone involved No birds were harmed in the making of the presentation. Here's your possum. I Apologize the previous slide usually has a picture of Dante and possums. They're super cute I'm running out of time so I'm gonna do this super quick if we talk about risk the more we do it The more cohesive our team is going to be one of the fundamental things of building a team of building a tribe of Building a group of people is to give them a language that is their own To give them something that when they say it to each other, they're like, ah, I know what that means a little in joke a Little out joke a little slightly inappropriate joke some way to describe something that you do is a team that is unique to that team The language of risk can be that for your team It's great to have other funnier things that are quite as serious One of my other teams we look at each other Like you're eating ants And people are like what It's a term that we came up with to describe somebody doing something silly because they're being unattended Like when you're at a family reunion and there's that one three-year-old in the corner that no one's paying attention to And they're eating ants because of course they are So we would say things like that and that was our team's internal language. Don't tell them. I told you about ants But we could look at each other and be like, huh Ants everyone would laugh. No one else would laugh. We were a team Risk does the same thing. We become better. We become more cohesive. We start making better things cooler things We can use it for more thoughtful testing and more thoughtful conversations We build trust by building language. I know baby. He gets overwhelmed by thinking about risk To be fair. He gets overwhelmed. Oh, there it goes That's my presentation my dialings. I hope you enjoyed it. I hope you learned something about communication something about risk Uh, I have put a few conversation starters up here because we are getting ready to go to the party It's gonna be super fun and super excited Think about some of these things ask some random person in the audience one of these questions Or ask me or ask somebody in a blue shirt Start to talk about language start to think about language start to think about emotions and start to think about how adorable my freaking cat is