 Hello, I'm Mario Hedgman. I'm a quality engineer and product owner in a secret compliance team in REL, Red Hat, here in Czech Republic. And I'm going to talk about how I believe the QE should behave in a cross-functional team or how it should promote the cross-functionality in the team. The agenda is the introduction that happens right now. Then I will present the problem. I will propose mitigations. And hopefully, we will have some nice discussion at the end. As a disclaimer, this is not based on any books or any formal research. It's just my observation over the last three years or two years where we moved continuously from a kind of separated team to cross-functional. And I was the QE in the team. And I've seen what works and what doesn't work for my colleagues. So first part of the problems statement is that let's define what is the team, what are the actors in the team. So first actor is a quality engineer. He is responsible for quality of the product. Usually is just limited resource in the team. Then the most numerous of the team members are the developers. It's the core of the team. And they are responsible for developing new features. They are responsible for fixing bugs. And sometimes it might surprise them. They are also responsible for the quality of the product. The third actor will be a product lead. Prioritizes work is responsible for vision and planning of the work. And again, is responsible for quality of the product. Because quality of the product is everyone's responsibility. And the last one is people manager who cares about performance of the team members and cares about team members doing what they are responsible for. And now, what is the cross-functional team in my view? Is the team that acts as one entity. The prioritization is done by product lead together with team. And the prioritization is done cohesively for all the roles, not just for developers or QE. And the team members share the load. Most of the tasks are defined in such a way that anybody in the team can do it, so there are no silos. I believe there is one talk tomorrow at 15.30 that is called how to transform death and test silos into a team that could be about how to get to this state. I kind of expect that we are already in the state. And what I will be talking about as inefficiencies that we will try to tackle, so first one is over the wall, communication maybe in the team, that QE and developers do not consider themselves. They don't communicate properly. The second one is that QE backlog might be handled separately. Might be because the QE is actually from the different organization part of the company. And is not considered by the product lead. Product lead focuses just on the vision and prioritizes just the development. There might be a capacity bottlenecks quite often because there is less QE than developers and some of the features are actually harder to test than to develop. And it might be that developers are not really quality driven. So there might be a bad quality of low level test coverage. And my proposals are over the wall, how can you, as a QE, because I'm presenting this from the position of the QE. But even it might be useful for developer because then the developer will know what to expect and what to ask the QE to do. So the prerequisite, of course, the developers consider quality to be also their responsibility. Without that, it might not be as useful to abandon your own silo and help them. Because you are doing this. You are abandoning your silo to try their tasks, but you also expect that they will give you back something. And if they don't, it might be inefficient. So you can take development tasks. You can try their development workflows. And you can try contributing code upstream. And you will also benefit from that. By trying development tasks, you will get better overview of the project. You won't see just the later phases, but you will see it whole. If you take development tasks, you are not so ingrained in it. So maybe for you, it will be more, you will need cleaner tickets because you won't have the history of everything that happened in the past. So the developers will have to explain it better for you what actually needs to be done. But that helps everybody because it makes the whole backlog of all the tasks will be cleaner and there will be less misunderstanding. If you try development workflows, you might help optimize the processes. Because you are new to the workflows, but you are not new to the team. You are not new to the company. So you are like newbie. That's actually not new. It's experienced. So you are in a great shape and great position to point out that something that has been done is not really how we can do it better. You can promote better workflows just because you have fresh eyes. And by contributing code to upstream, you will get exposed to the community. So it might promote your market value, but also you will get reviews. And it will make your coding skills, technical skills, better. So these are the benefits of breaking the wall from your site and then you can wait for developers to break their site and come to help you with the tests. The second mitigation proposal to the problem of QE backlog that is handled separately is that you need to talk and you need to explain. Because even if you are cross-functional, this won't happen magically. Sometimes it might be that the quality is not like the top priority for the team. Sometimes it's even deliberate, deliberately not the top quality because first we need to have something to sell or to show at least. Maybe you have some non-product requirements that are coming from above. It might be quality-specific reporting for your managers. It might be a company-wide test environment that needs to be employed. And from the team perspective, this might be worthless. There's no games for developers with this. So you need to be the one who will explain to the team the benefits. And you might actually feel sometimes as you are on your own. So by communicating, you might promote that others will also care about what you are responsible for. So you need to be seen as a good counterpart to the developers. You, first, you need to understand how your work helps successful delivery. It might be by translating the non-product requirements, but also what the product benefits when you find a bug. Because the test coverage should be justifiable and aligned with the goals. It's quite frequent that quality engineers will search for bugs in obscure features that nobody uses. And then they are surprised that developers will reject, will say, no, we won't fix it. This is not important. So you need to understand what is actually important, what are the bugs that everyone cares about. And to this, you should agree with the team on the areas that you will focus on. I wrote here, important bugs are important. It's like if you find bugs in some corner cases, nobody touches, those bugs won't be fixed. So in statistics, yeah, you will have 500 bugs found, but it won't help anybody. So few important bugs are much more useful for even perception of your value in the team than hundreds of non-issues that will be closed as not a bug or won't fix. And finally, strive not to be destructive. Because destructive, it's an inherent part of the QE work. We need to be able to say, we cannot ship this. This just cannot go. We are gatekeepers. But at the same time, we should, by all means, strive to not be needed to do this, to use this power. So from the very beginning, identifying what could possibly be this blocker problem and focus on them first, ideally in a development phase. So there is no pressure, no stress, and no arguing when bugs in these parts are found. That needs to be in your head. That needs to be part of your work to identify these. So you have to talk to others. Don't try to save the world by yourself. Sometimes I see that the QEs are perceiving themselves as the avatars of justice that I need to take care of. I need to watch over everybody. And it's my role to make sure that everyone is doing their job. No, if you talk to others, you are not there on your own. If you get requests that are opposite to each other, just connect the requesters. And let them deal with it. Let them argue. Let them decide which of the requests is actually more important. And highlight misunderstandings and push for finding solutions. It's about highlighting. It's not about solving the misunderstanding. Sometimes you are just not the right person to solve it. But you can definitely raise the red flag that something like that happens. So if you are good in communication, you promote importance of the quality. If you find important bugs that are solved, everyone will be happy. Maybe developers will be even happy that the bugs are found. They will buy you a cake or a coffee or something. Right? And it's a self-enforcing process. By quality being perceived as more important, there will be more focus on it. And more benefit of it will be in the product. The third one, capacity bottlenecks. So maybe here I will ask. So here are some tasks that quality engineer does. So is anybody here who thinks that any of the tasks is not what QE should be primarily doing? Or it's not something QE has to focus on? Do you think is there something that can be outsourced, for example, to developers? Yeah? Running tests? Right. Pardon? Writing tests. Yes. And writing them. I believe these two parts are something that does not have to be done by QE. Because writing tests is just coding exercise. It's about thinking what should be the behavior of the test, what should be tested. That's something that might need more expertise in quality assurance. And running tests and reviewing results, sometimes I hear that developers are not able to review the results of the test. So QE needs to do it. But that's just a symptom of batch tests. If it's not understandable to developer, then something's wrong and they should be redone. So they can be consumed by anybody. And as such, QE should be focusing more on the design, be it designing of the tests or the activities and to do high level plans and strategies. And if you design the test, then you can put it to the ticket that's available to anybody to take. The same, what about test levels that QE should deal with? So we have unit tests, acceptance tests, system integration testing. So do you think there is something that QE should not participate in? That's common perception. And I disagree with this. I believe all of them should be part of the QE view. Mostly because when we establish that the main QE tasks is to design, do the test plans and test strategies, you need to understand what is actually tested in unit test level. Because you want to test it in most efficient way. Of course, unit tests will be probably written along the code, probably by the developers, or by you when you are breaking the wall. But the overview should be there. And I had, in my dry runs, I had some questions so I couldn't hear. So first, or objections. So first, the objection was developers are biased. And they will try to make this pass. And what I can say is that if you can review the poor request with the test, and you should be able to double check with the design, whether it's along the design or not. And the second objection is what about maintenance of the tests? I cannot review every commit in the project. But bug in test is like any other bug. There is nothing special about it. And as such, the project should have means to handle it. And let's just not assume that someone will deliberately game the system and will make test pass just to get done with the feature. Well, and the last mitigation might be not necessary because if all the previous ideas are put in place and you have the voice within the team, you have overview of unit tests. And you put them to the test plans and strategies. And you define tests so anybody in the team can develop them and then review them. I believe the test will be quality driven. Perfectly fine. So with that, that's end of my presentation. And if you have any questions or objections, please. Can you do the first pass? Yeah. Does that change the way the quality engineers behave in the project? So the question is whether in case of extremely automated testing via CICD, whether the quality engineering role changes. I believe that you still need to design it. You need to design what will be tested, how it will be tested. So I don't see it like that. And I believe it's business as usual. And maybe what is the, as I see the quality engineers, they are experts in one field. They are more specialized engineers. And as such, should move the envelope of the whole team, push it, push the envelope further. So that's the main. And it can be even through CICD. Any other questions? Oh, we are out of time, so sorry.