 So we're doing something right I guess Okay, no one's no one's moderating, so I'm just gonna get get started. Thanks everyone for coming. I know it's Early and apparently the attendance shows that my name is Micah Abbott. I'm a senior quality engineer at Red Hat I work on the Red Hat atomic host product and the Red Hat Coro s product I'm here to talk about white quality is everyone's job I'll give a quick disclaimer though when I proposed my abstract I had a idea of what I wanted to talk about in terms of quality is everyone's job But when I just developed the slides it transformed more into building How to build a culture around that how to build a team that that respects that So I will still touch upon what quality is everyone's job, but there might not be as much focus as I Planned so first some bad news. I'm not an expert in this. There's probably people who can speak to this more intelligently and profoundly None of the advice I'm gonna give is particularly novel if you were to Google some Software development practices and quality practices. You could probably come up a lot of the stuff I'm gonna tell you about I'm also really bad at following my own advice So there's lots of things I haven't put into practice in my own day-to-day job my own organization And there's no guarantee that any advice I'm gonna give you is gonna work for your team software development, especially quality is really complicated and It really you really have to know your own team to figure out what's gonna work. What's not gonna work But I do have good news. I've been doing this for almost 20 years So I have what I think is a good amount of experience to make some observations Give some opinions on the matter I am IST QB certified for those of you who don't know what IST QB is It's the international software testing qualification board. They're trying to promote Standardized QE practices and best values. I went through their foundation level course Pass their test got the certification I've been participating in agile and agile team for almost four years now This talk will be pretty heavy on the agile methodology down the line I'm a big fan of it having lived both sides of agile and other ways of doing development and I've got a psychology degree and the only reason I mentioned that is because Well, a lot of what I'm going to talk about is building teams how to form relations within teams I think the background of psychology really is helpful in navigating those waters So first I want to talk about how we did QE in the past. I'm sure most of you are familiar with the waterfall model. It looks like this you've got Requirements that are made that fall down in design implementation verification, etc There's a lot of problems with this model in my opinion and I'm gonna start going through them Number one you end up with multiple silos of responsibility Like product management development quality assurance Everyone tends to own that their little piece of work and doesn't necessarily pay attention to what other people are doing in the whole chain And sometimes that generates silos when silos for example You sometimes end up in a quality organization where one team is doing test automation development And then the other team is doing the execution and they might not even be communicating very well or communicating outside of that that larger silo Like I said before everyone tends to stay in their own land They own their piece of work until I get to the end and then they pitch it off to the next Group and then the next group has to deal with whatever output was given was generated And it doesn't really encourage communication between the groups you like I said when you are so Singularly focused on your output you aren't really Going back up the chain to talk about how they did something what they did or getting involved in that process earlier on And the one thing I noticed in these models explicitly missing from there are groups like support and documentation There's no box on that that chain that says you know supports should be providing input here Unless you have a really good product manager or program manager might be pulling people in like that Typically support and documentation are those and those types of organizations are left out of the discussion When we're owning the only work when each stage is when the output of each stage is owned by a certain group Any mistakes are then just passed on to the next group and this encourages things like throwing code over the wall Which you end up like I'm sure you maybe you've seen Monty Python where the code comes over the wall QE has to take it and Oftentimes you end up in a situation like this where the code doesn't compile It doesn't build or you end up a kernel panic and QE is just frustrated because clearly the developers didn't test their code And I touched on before it isn't really conducive to having teams work together When you're just throwing code over the wall, you're not really in a good relationship to to collaborate on on the product itself and I found in my experience. It's a poor model for providing feedback to other teams and engineers in my experience when Working with other development teams in this model you rarely get the hey, thanks for testing this feature Hey, thanks for finding that bug. It's just sort of like everyone's doing their job and focused on the next The next bit of output they have to generate and There's really little to no effort to improve this process You everyone just keeps doing the same thing over and over again And the same mistakes are made often and no little to no improvement is made I Additionally these interactions that you do have with other groups is when something is typically when something's on fire like There's a deadline that's been missed There's a bug that's been found and you have to release the product and it tends up to be ends up being like a high stakes loss of emotion Environment where everyone's trying to place blame on the other person Or the other group I should say So moving to the present We're starting to see waterfall models get phased out and agile's getting phased in at Red Hat in particular where we have a strong Commitment to doing agile in as many places as possible. We have an agile architect actually who helps drive that message across all the group all the teams And this you know, we end up with in this model. We end up with QE and development under the same umbrella in the same team So we end up succeeding or failing together. So everyone's intrinsically linked to the outcome of the product If QE does a bad job or if Dev does a bad job net There is no QE and Dev anymore. It's just one team that team either succeeded succeeds or fails And in this model, I think it promotes professional growth because you're allowed to Work on things that wouldn't typically fall under your purview like QE can work on Dev tasks Dev can work on QE tasks and in some cases, you know, you might own some of the relinch process You get to work on some of the relinch stuff as well And also agile allows you to constantly improve the process So you can look at what happened in the past make an analysis suggest changes try those changes and then Go forward. Hopefully for the better Now when you start practicing agile, you usually end up practicing DevOps as well And that's when, you know, a team the team owns all the phases of development or multiple phases of the development Like for example the actual development test release and monitoring There could be other phases of development in your model But these are the ones that kind of stick out to me and this and this Model of owning all the phases you need to have excellent communication in your team And you got to work well together in team and this becomes your This is like the key point like you have to have great teamwork in order to see it in this model So going in the future looking to the future We're probably going to see more agile adoption more DevOps adoption. We're going to see more automation Obviously things like continuing to get integration delivery can become really important Even more important than they are now because we want to be able to move faster And produce software that's a higher quality at the same same time and I threw in this because Everyone's talking about artificial intelligence machine learning I haven't seen this in practice yet in the QE space, but It's probably going to happen. I can imagine Someone writing something that would analyze test results and Can figure out commonly Commonly found bugs or errors or whatnot And obviously When I'm here to emphasize it's going to be a lot more teamwork. You got to have good teamwork to be successful going forward Much like they did in increment So I'm going to talk about what I think what what I describe as a highly functional team Uh, I don't know if I read this or I made it up myself, but it's a team that works well together It's able to solve problems together and achieve your goals together consistently You're not going to do that every week or every day or whatever, but overall You have a really highly functional unit of of A people And one of the the cornerstones of this I think is open communication Uh, you need to be able to talk to your team members completely honestly And let them know what's happening in inside the team and with the product itself And to do that You should really everyone in the team should feel respected and show respect to the other people on the team and this breeds a an environment where no one's afraid to Uh, share an opinion or share some feedback that might be controversial because they know they're not going to get judged When they make that that uh that statement I also think everyone on the team should have a confidant because you're not always going to want to just go to your team of Eight or ten people and say hey, this is what I think we should do because maybe you're a little Where how it's going to sound you should be able to go to somebody on your team whether it's a architect or a senior team lead or Um, a scrum master for example and say here's the idea I have How do you think I should phrase it? How do you think I should? Present it to the team and that just having that person to bounce ideas off of like can really Help boost your confidence and like get over the hump of feeling scared to talk to your team with What might be controversial opinion Another cornerstone I think is appreciation I think overall in this industry we do a really bad job of showing appreciation for each other We should be able to Tell people that hey, you what you did is important What you did has value and again that breeds that environment where everyone's starting to feel like they're part of the overall team And they're they're they're part of the overall success of the product of the software development process Even a simple thing like thanks for finding that bug or thanks for you know updating the jury ticket like That's just like common courtesy, but we seem to to forget to do that In our day-to-day jobs And when you get that kind of feedback especially from someone In a senior position like an architect or someone that's above you or someone you have more respect for Like that can really improve your day and improve your whole experience on the team And this kind of goes into this uh This picture which if you haven't seen before it's called uh mazlo's hierarchy of needs It was proposed by a psychologist named abraham mazlo in 1943 in a book he wrote And it it shows that we can to reach self actualization and in software development terms this means like being able to take uh Be creative with your solutions be creative with your problem solving and taking risks, etc So in software development, we probably mostly have our Basic needs covered food water security safety Hopefully those are covered when you're working like if not then reevaluate what you're doing Oh, well, you know if the food courts closed there's uber eats or something, you know But when I talk about when I talked about everyone feeling valued and being Respectful and whatnot that really keys it calls it falls into the psychological needs so Like it says here steam needs prestige and feeling accomplishment like when you get that feedback from your team saying you're doing a great job Thank you for doing that like that That helps you fill that that hierarchy and then the relationships That you build on your team fills that piece of the hierarchy. So then you can go once you have those those Those needs addressed in your team. Then you can go and take those risks offer those controversial opinions take some creative Chances with the software that you're working with So how do we get there? How do we get to this highly functional team? Where everyone's owning the process everyone's concerned with software quality Number one, you have to nurture the creation relationships within your team You don't have to be best friends with everyone, but you should be friendly with them You should Feel like they're up here that you can talk to that you can interact with And treat them with the respect and value that I mentioned earlier I think it's also important to meet in person at least once a year Especially here at red hat one here, but at red hat we have We have a lot of teams that have remote workers on the team. I have for example, I work on for example There's people in Westford, Massachusetts in Raleigh in San Francisco, Toronto And then some folks even in Europe. So it's really difficult to get everyone in place Once a year, but if you can it allows you to build those relationships. I talk about In such a much more deeper and more Meaningful way Because you just just the value of human interaction is like I mean, I can't I can't put more emphasis on it And that's just in the workplace itself Like once you're done with the work, then you go out to dinner Then you go and have drinks and you get to figure out More about the persons that you're working with and I think that is going to help you in the long term Have a more successful team If you're practicing agile, I think you should utilize those agile activities like in-person stand-ups or video stand-ups I find that Just seeing the faces of the people I work with on video conference because we are all remote is Reinforces like hey, there's another person on the other side of the world that Is depending on me to do my job correctly and vice versa. They're depending on me to do my job as well If you can do in-person stand-ups like that's even better because you do get that immediate face-to-face feedback And in agile, we have the concept of retrospectives where we Talk about what we did in the last sprint the last Period of time and we talked about what went well What didn't go well and we figure out how we can improve the process To get closer to like a real the the best we can be And the closer we get to the best we can be Clearly we're going to get better quality software out of it And like I said before give feedback to your team Celebrate your achievements that your team has made, you know, whether it's on social media or on email or whatever say Talk about how what this person did in their in their job in the sprint or whatnot Suggest your improvements when things don't work out. Don't don't hold back. I mean do it respectfully clearly, but You need to keep giving that feedback to improve the team as a whole And show gratitude. I mentioned before like just saying thank you for things that happen every day Really go the different go the distance. I think especially if you do it consistently And finally remember we're all human. We all have the same Not the same but we all have similar dreams hopes feelings desires Treat other people like they're human. They're not just another face on the screen or whatnot or a You know email address on you in your inbox So once you have let's say you have your highly functional team and it's finished running well Now you need to start putting your feelers out beyond your team To again to spread the word of how software quality is important to everybody and how it's all there their responsibility So this is when you need to get the non-development non QE people involved Bring in people like tech writers program managers support engineers community managers get them to participate in your development process Let them provide feedback to you and let and let and provide feedback to them as well Like maybe the support engineers aren't As timely with contacting you with critical information or the need for critical information So we can talk to them about that. How can we improve that process or For example program managers, we can talk about how maybe they're not generating requirements that are specific enough or Or whatnot, but get everyone participating on the process And again use the same guidelines. I've talked about before in terms of respect and gratitude and whatnot So now you've got a highly functional team core team You've started to build relationships with external teams now We can start to leverage the strength that we've built with the core team and the external teams This is when you can really start to talk about making quality Everyone's job So you get involved in the development process as soon as possible In the waterfall model You saw how the the requirements planning happens at the very beginning How many people have participated in requirements planning as a q engineer for some piece of software? I mean, I know I haven't honestly I don't know if you have then you're doing the good you're doing a good job Well done adam But I think that that we're missing that a lot from the from the industry And this kind of goes into the this v model So the v model shows on the left hand side We've got the software development process starting with the requirements planning down to architecture design the implementation and on the right side we have the testing and validation portion of the model and you can notice that each for each piece of Development whether to requirements architecture design. We have a test Uh, corollary. So each one of these testing pieces has the ability to validate what was generated on the other side Um, and again, like I said, I don't follow my advice. I'm very bad at following my own advice So I'm not even close to being this this good if you're if you're operating at this level My hat's off to you because it does require a lot of work. It does require a lot of teamwork and But this should be the goal we're striving for you should be striving to Have tests that are able to validate each piece of the left-hand side of the model Ah, that didn't work. Okay. So I wanted all those to come out sequentially, but I guess my edit was wrong. So Yeah Well, I guess I'm doing a bad job so like I said So in terms of getting involved attend these decision-making meetings if you can if they'll allow you to get in there And even if you can just get in there and listen you can get a feel for You know where the direction of the product's going and then Alter your your how you figure out how you're going to test this product down the line Understand the businesses that are being met understand the use cases and start asking questions about how this software is going to be tested If you can do that at these early stages at the planning stages the requirements stages Then you can maybe uncover problems in the requirements that will be impossible to test I don't have a good example of it, but you can imagine what our requirement that would be Come down from product management And then when QE gets it finally at the end of the you know at the bottom of the model if they're not involved They're like I I don't know how to test this like there's no possible way I don't have a million man hours to do this um And start to plan your development test tests together and this is one is another Uh Point where I'm I'm not doing as good a job as I should in our on our team. Um, but if you can Plan that that development piece of work and then Side by side plan how you're going to test that and develop them in parallel Then you're going to be able to pick out the bugs in the software a lot earlier Then if the development finishes first and then three weeks later QE picks it up and says oh, I'm going to write some tests for it You're going to miss bugs and then when you get involved with Development to fix these bugs. They're going to say well, why didn't you catch this earlier? That sort of thing And if you do that you'll have success kid to show for it so to wrap up Waterfall model is bad agile is better if you're doing it properly You got to live or die together a team like That's the whole I think that's one of the key points of the agile model Practice that open communication be be open with your feedback. Be honest with your feedback Oh, that goes right into my next point honest feedback Uh and strive to include those external teams Get their feedback because they have a different perspective on the software development process They then you might and that's gonna ultimately grow your team as a To be more successful And like I said getting involved early on often ask questions And try to catch the problems that we're going to face as QE as early as possible And that's it so Does anybody have any questions comments? No, great go Go do good Thank you everybody All right So my situation I work on fedora, right? Yep, it's it's interesting because it's not a product It doesn't have a developer process, right? So yeah, people think about hey, how do we make fedora do agile? I was Thinking about situations like operating systems fedora rel, whichever you're working on very complex interlocking products Which don't have a single development team a single development model. How do you apply these practices to those? Do you think? Yeah, that's so in case I'll repeat just for the recording case the one caught but adam's asking In the fedora ecosystem, you know, there's many different development teams many different developers How do you apply these tactics to that model? You know, I think It kind of goes hand in hand with how fedora operates now like you just gotta I mean I know you adam you reach out to everybody, right? You try to be respectful Yeah, you try you try you're trying to do the right thing You're trying to talk to them and get them involved You're obviously not going to be able to deploy agile across the entire fedora Yeah system, but I think just Trying to get to that that personal side of things like being honest And respectful and showing gratitude towards these these developers They're going to start to come around And start to interact with you more and then you can have a better dialogue of like, well, you know your code sucks Well, not that you shouldn't say that but you know Your code has some issues. Let's say Maybe we can talk about how to improve that or we can talk about what kind of test we can write to catch the regression We've seen or the problems we've seen um, I don't think there's a really good answer to that because it's Number one. I'm not an expert. I said that earlier But I think I bet you if you talk to One of the agile practitioners in red hat they might have some ideas for you Um, yeah, since you work for red hat you could talk to uh, jen kreger. She's the architect. She might have an idea So Yeah, yeah, I I would just start with being like Start at the bit at the bottom like just Be nice Be be a good person, you know and encourage that sort of that that sort of behavior. I think you know as humans when we see We tend to mirror the behavior we see. I mean, I have two kids and I know that They're basically a mirror of every mistake. I've made and every good thing I've done. So It's sort of a human nature thing even as adults where we mirror what we see So if you're being nice to somebody they're more likely to be nice to you and then you can start to have those dialogues Yep I have a question. So I guess yes, so I mean I agree with everything that you said and I Agree with I agree with everything that you said But I noticed that a lot of times It seems that the success rate is much higher when you have qe and development together But the other teams, especially p.m. For example, it's really hard to get them on board. Yeah So do you have any advice for improving that? Yeah, I mean you need I think in those types of in that sort of scenario where you have those external teams that haven't bought in You need to get I would suggest probably getting your management involved and having them reach out to the other side and say You know, this is what we're driving towards. This is what we wanted. We want everyone on board with ensuring software quality And outside of that, like I said, maybe you can drop in on our meetings, you know, reach out to them I know for example in my team my program manager is ben briard And I've got a pretty decent relationship with him Like I can reach out to him and ask questions And the only reason I in the only way we did that is that you know, he dropped in the office. I was in the same place We said hello, we introduced each other and we just started talking like people, you know And then now I've got this open line of communication to him where I can say like What does this product require me me and like, what are you intending for this? You know, or do you think we're going in the right direction with the development choices we made that kind of thing um So like I said, it really starts with just those personal relationships And if you can't establish that personal relationship, then I think you have to involve your management and get your management To bridge that gap Uh ahead of time Easier said than done. I know but that that's the best the best advice I can give you Thank you. You're welcome Anything else? No, all right. Well, thank you all for coming. I know it's early and uh Have a good rest of the conference you