How to Build QA Culture in Your Company - Filip Barszcz

Most people just think about us outside of the community, that we are only testing. It's not true. The truth is that we are feedback givers for all the development teams. Brutally honest guys, that's a perfect roadmap, but we need to put effort here.

We have to think of us as the last line of defense of the company, but the first line of defense of our customers. It's one of my failures in my career that I wasn't able to build a proper way of the communication. Welcome to Software Testing Unleashed, the podcast for testers, developers and test automation engineers and all the people in the software development process who want to create great, amazing quality software. My today's episode was recorded at TestWarez, a great testing conference in Poland.

The days were full packed with great quality content and I had a great time discussing and chatting with the Polish and the international software test community. If you haven't been here you should definitely go to one of the next TestWarriors conferences. You find a link to the conference in the show notes. My guest today is Filip Barszcz.

He is QA, chapter lead and seasoned quality engineering professional in the finance industry with experience across FX, Fintech, mobile and web ecosystems. We talked about how to build a QA culture inside a company and a team, how to convince management and how to get practical quick wins in the process. We talked which strategy can be used and what's the role of a QA today. And now enjoy the episode.

Hi, Filip, great to have you here on the show. Thank you for having me, Richie. It's a pleasure to meet you in person, finally. Yeah, it's so great.

A nice conference here, the TestWarez. I'm so happy to be here. It's such a nice crowd and chatting with all the people here and having good events and good time. Yeah.

This is my first time here as well. So the crowd, the people that talks that are on the corridors are just amazed as lecturers. So there's definitely a good place if you want to learn something new or different perspectives or experience from different people. Yeah, that's true.

Yeah. And now I'm happy that you are here at podcast too, because yesterday we talked a little bit what's your passionate topic and you told me that you're dealing with building a quality culture into a company, into a team. And I said, "Okay, that we have to talk in the podcast." Definitely, that's where I feel like I'm fishing in the water.

Definitely, that's my topic. Mostly I'm picking the companies that have some struggling in QA culture and QA approach. And that's what I pick of my career path, career goal to introduce for the companies that our way of work, our point of view on how we should deliver the products. So what is the typical situation you come when you see when you say that they have no QA culture?

What is their daily business like? So it looks like mostly that is ad hoc testing. It means we have something and we have to deliver this, for example, in three days. And you should use as much resources to do this to achieve this in three days.

So this is like the a lot short sprints of work. over the over workload is so high and intense that it can cause a burnout for the QA specialists, especially in that short period of time when you have hyper focus for that. So mostly I'm going to the companies which have this kind of the culture and this kind of the attitude to QA work of way of work. And in this companies, how is it on the developer side?

Are they doing a good QA stuff like unit testing and all this stuff or is it also very... It depends because there were for example, I was in one company who had perfect unit tests and integration tests, but they are struggling with E2E and the discovery tests from a manual perspective. And I was in the company that they have only unit tests. There was no integration tests, E2E tests, and most of the weight of the quality was moved to manual testers.

So it really depends because anytime I pick the company, I'm trying to find something unique where I can introduce good practice for specific products. I see. It's often the topic that a culture is not falling down from the sky and it's there. So where do you start to build such a QA culture in a team?

Oh, the most interesting part here is that when you talk to the people on the different positions, they understand QA in different ways. For example, stakeholders, they have a totally different view than component owners, for example. And when you gather all this information step by step, they make some table, for example, that okay, so developers think about the quality that way, product owners differently, stakeholders, technical leaders, totally different point of view. And then you just translate their hopes to our QA language.

And then you have a roadmap, what they expect, what they want to do to achieve. And after that, there is the meeting and brutally honest, guys, that's a perfect roadmap, but we need to put effort here. Are we ready to just start introducing the changes that will be in the beginning, they will be difficult in the beginning. For example, our productivity will drop down, but in the long term it will be a fine investment.

For example, in one company I made a research and diagram of the QA efficiency after my probation period and I showed them that during my four months of the probation period, their productivity, the quality of the product dropped down a little bit. But in the fifth and sixth month, the skyrocketed to the high. and people adjust to the new way of work. That was the first introduction, that was introduction to QA policy and QA strategy for to anybody.

I just prepared all the requirement things, requirement actions for specific people, introduce them and try to show them that this is small amount of the work and it will be impactful in the longer period. I was really proud, especially from the DevOps team in this one company, because they just adjust smoothly I saw results after one month. That was perfect. And these small baby steps gives us that, that's just opened the door because we have to present that the QA matters on every step.

This is the problem. In most of the companies, huge companies, there is the approach, the mindset that QA is only for testers. They don't even recognize the tester is very often not the QA engineer. They have problems with understanding.

So my job is I have to speak a lot. So during my first four months, as you ask, I meet mostly people. I discuss, I write down the tables. I just make a lot of confluence pages to just share, to discuss, and when we are on the same page, we can move to the step two.

So the leadership, approval leadership, feedback about my ideas. And later on, this is what the QAs do. we start with the processes because from my perspective, from my expertise, when the process is correct one and is resistant for the changes and resistant for the failures, it elevate products on totally new level. We can just spot the differences, not only from our technical part, but from the business view as well.

That's why we have to understand the values, what the business understand under QA terms. You mentioned that the stakeholders have different view on QA and different needs for quality. What are typical, when we take especially a technical and the business look, what are typical views on the quality they had in your... For example, in one company, stakeholders, they were interested in how much time our systems are working.

So how long we have an open window for earning the money. And they didn't, for example, just look on the specific issues that for one client have some problems. They just look at the window of the opportunity for the company and for the business, for example, level below that, for example, for business owners, it was mostly like the experience of the client, that it should be smooth, it should be just user friendly, customer friendly. But they didn't, for example, mention, they mentioned sometimes performance, sometimes that it should have the very intuitive.

They focus on that experience of our customers. So it's a very good answer for us for when we design the process. It's like we have to think as us as a last line of defense of the company, but the first line of defense of our customers. That's why we use personas.

That's why we testing in some approaches like our customers trying to look like we have some research about our customers and we can just design specific personas and we try to simulate that. And another important thing for both this group, stakeholders and business part, they love tables. They love tables and the color for tables. And when you just send to them in monthly to weekly report with the tables with colors, how it's going on their perspective, they are more than happy.

They are eager and willing to invest in the QAs. In my current company, after this, a lot of different reports after this seven months right now, and they are eager to invest in the quality because they see the purpose, we see the value, they see our point of view. We have visibility. This is very, this is phenomenal for me because mostly when there is the lack of QA culture, they don't understand our work as a QAs.

They don't see our work. And this is, for my opinion, this is one of the things that we should introduce in the culture. Visibility, not for our work, but for the effort from the developer side, develop side, artists site to just make the rewards praise for them that they are working at the same team as we. This is the building of the team spirit inside for the tribe, the unit, what kind of organization you have.

I think it's when I can imagine that when I see it, my clients is that they are also not aware of the quality perspective of the others. So they just talk about quality and QA, but everything have their own view in mind. And so there is no real communication about that. Yeah, it is.

And you just scratched a very important topic, communication, because sometimes I have a situation where there was a huge problem of communication with the technical owners. And it didn't go well, unfortunately. That is one of my failures in my career that I wasn't able to build a proper way of the communication. And mostly I struggled because I didn't have a proper knowledge about the kind and styles of the communication in that way.

That was in the early stage of my career as a QA lead. And one of my grave mistakes that I made. Right now, after this year, I will just make different decisions and different presentations of the data made to just achieve what I wanted to do. So mostly, definitely, we should listen.

Listen and if we are listening, then write down the things to then read and write down to try to just put the shoes of the different people to understand if I really understand what they need from me. I see. And so the first step you said is you put all the information together and to make clear what is quality company-wide and everybody sees that. And then you said you get the okay from the management and the leadership to do something else.

So how do you argue that to the management that there is some change needed? Because they said, "Okay, why should we spend money into your effort?" Oh, I just compared to the competitors hours because very often they just promote themselves that they have the quality culture. They have, for example, TMMI on the level four or even five and they just don't hide it.

And then I just compare, for example, where we are, what are our earnings, what our competitors do when they are and compare our products to just present to just by comparison. It works. Mostly it works from the business perspective. And a different thing I saw, I was present how much money we lose on the back fixing, for example, in the last stage of the development and then make calculation.

I just always say, this is the estimated calculation from the, for example, portals with the salary. And then, for example, I present this issue cost us 15,000 euros to fix it. And business just, how? Why?

And they start asking the questions and when you can present for example the savings that they can do by for example switching the all things of the test from the for example tree to the environment before, they just start counting money. If they have some money they can make some investments and in the beginnings it's difficult because you have to do this with your current resources. But it's when you discuss with the devs, with BAs, with component owners, very often they are eager to help.

This is an important thing. We have to be on the same page, on the same side to do. And thanks to that, I could achieve that in my current company with help with the developers, component owners, to make some POC for one team. And then I presented the results.

Results were very promising. And right now we introduce this solution for all teams and we have more than well results. And that's why the current management decide that they can invest more money because they see the opportunity to elevate our product on the higher level. That's for example, impact that our product receives some prices.

So we want some competitions regarding in our area. And that's an additional factor for them that this is a good way to do. And besides that, just imagine that they have less rollbacks, less problems with the customers. So they have more time for focusing on the real work.

So that's why most of the things that I discuss present to them after the POC to just make decisions from their side. Great approach, I think. So you mentioned that you start with when you have to okay with some baby steps to let the change begin. What are typical steps you mentioned there?

So how big are they when they are small? So I started from the clinics of our own yard. So it means that I just observe, analyze our QA. And for example, I narrow the number of the priorities to be more clear.

I just make the information what means specific priority from the business part. I just start, for example, communication additional that I announce that we are on this stage of the testing. Right now, this environment is very fragile, important for us. Please don't deploy new things, so don't sabotage our work.

For example, the different thing is that to the release notes, I add additional things. For example, regression status current, the checklist, what the current scope, I share the information because very often we just forget about important things in the QAs. This is mostly about sharing the information. So when we have some blocks with the information and we just unlock the stream of that, it gives the opportunity not only for us, but the beneficials are from the different departments as well.

So that's the baby steps. I just start the communication where there was lacking of that. And it helps and it's just, this is just quick win for the QAs because that's how much time you spend. Two hours per week, four hours additionally to just make, move the information from one place to another one, to just make maybe additional 15 minute call to explain the current state.

You save a lot of effort for different people. And thanks to that, different people can just focus on the different works. And during the time, you can just involve different people. For example, one of the testers is responsible for the regression status, different one is responsible for the checklist.

And the developers, for example, are responsible for part of the checklist, because we can just extend the list on the environment. And then just engage to show just the way from the small improvements, like in the Kaizen, if we can, or in the academic habits, if we can improve by 1% per day, the end of the year, it will be that massive change. Yeah, yeah, that's so true. And I hear that there are really small steps and small changes.

So when we look at the company or a team, change can be overwhelming, because if you change everything in the first day. It's not possible. People sit there and say, "I don't do that. It's what the crap.

I'm doing my work as I've done before." So how do you deal with that? To not make every change in one day, but to split it off and delay it a little bit. How do you deal with that?

Right now, this is the perfect topic because right now I'm doing the huge change in my current company and I decided to just have three months of adaptation for that. And I make the consultancy with different people who will be impacted by this change. So they could read it, learn it, know my approach, what we want to gain, and I'm listening to their feedback. I just adjust some things that everybody feels that I'm the partial owner of that.

For example, product owners at additional meeting about just extend the back triage, DevOps just added additional step in the checklist. Product component owners just said that we should have additional environments, so DevOps team will call it if we are able to do this. And the general idea was exactly the same, but I engage all the people who will be impacted by that during this whole process. And for example, I ask which team voluntarily can just test it.

And there was the one team, I have one of the teams who is very proactive. They started to use it. And this month I presented the outcome of that and is more than satisfied for that. And I already received the feedback from the different team that the deadline is we started from the 2026.

But second team just give me information that they are willing to try it even before, because they see that the team that they are competitive with another one, they want to not be behind them. So this is kind of the consultancy here to be on the same page and share the same information because very often we are resistant for something because something is unknown. We know we don't know something, we lack with something. That's why I had to present this whole new change.

This is the workflow change mostly. And just introduce it step by step. First of all, the whole flow was accepted by my superior technical tribe leader. And then I went level below and then I will go level below to just share this information with everybody.

And then of course, sign in that everybody just know that this is a new flow and we are working by this new flow. It's time consuming because for my character, I want to do this in one week. Just introduce it, shock therapy for everybody and go on. But after I talked with business analytics components owners, I realized that it can be just, this can be a huge revolution.

Too much to handle it right now in that part of the year. So that just forced me to change my attitude to a smaller one, but they agree for a bigger even change for that. So that's my recipe for the bigger change. For small changes, it's easier to ask for forgiveness than the permission.

So that's my recipe here. Definitely, if you have small changes, you can just do it by yourself and test it. And as you said, to engage the people, to include them into the communication, be transparent, I think that's crucial for the success of some such change, not just to put it in and you do it. So to talk to the people, what's the impact for them.

In my opinion, we as QAs, we have to be proactive because just look at us, we are the people who share the feedback. Not always the good one, we have to just deliver the bad news as well, but this is our approach. And most people just think about us out of the community, that we are only testing. It's not true.

The truth is that we are feedback givers for all the development teams. That's so true, because I saw that yesterday in my speech too, We have much more responsibility than we think of about that. Not just testing around. Yeah, I totally agree that that's changed in the last 10 years, because when I started as a QA, I was responsible only for the manual tests and reporting issues.

And that was all. Right now, there is more different requirements, duties on us. And to be honest, I like it because we have a bigger, more meaningful impact for that. And thanks to that, we can improve not only our work and not only our processes, but processes for different people.

This is really enjoyable when you just can see that you change, just decrease number of stress inside the team, just increase the quality and customers are more than happy after your changes. So this is the thing that we should have in our heads. Yeah, yeah, so true. When you do your change process and do the steps, how do you decide when it's enough?

When you say, "Okay, now it's working, now we don't put more effort in that." How do you deal with that? When do you decide we are done? It depends on the type of the customer.

Because for example, in one team, there was approach CICD, okay, but in different company, I just realized that they have so many legal obligations that they wanted to achieve CICD. But I thought that from our perspective, it's a waste of resources. So it depends on the niche specification of the current customer companies. In our current company, we have huge aspirations, but in my opinion, in next two years, we will just go to the level of the quality that I think is achievable for this tribe.

I mostly look at cost effort metrics, how much time we have to spend and what we can gain for that. And that's why I spent a lot of time on the analysis and discussion with business and technical leaders to understand their point of view. Because you know, we have our metrics, we have our approaches, we have our techniques. But very often we have to, not very often, always we have to think about it.

If this is applicable from the dev side, devop side, and what's the business outcome? Because in the end, the business is paying us for delivering the product and it has to just gain some value for them. Okay, so it's a very individual, context sensitive look. what is needed and when it's enough.

But to be honest, it should be our approach for every company because we cannot compare a company A who work for example in one part of the market and with company B who, for example, work in the financials. So it's a totally different approach, different outcomes and different ideas there. Different weight of works, mentality of the people. For example, we have to think always about if the people are ready for another change.

Because sometimes if we introduce too many changes, I did this once, you just make a tired team. There was a lack of stability for that. And people just start resisting for the changes. So from my opinion, one huge change per quarter, but also doesn't mean huge change.

One change that should improve and then you just prepare another one. And then just measure what was the impact of the first one. If there was a problem, there is no huge change as long as we don't just prepare properly the first change. There's a stability that there should be after the change.

And that's why I'm just curious how it will go with that huge one that I just started preparing. First feedbacks are pretty good. But you know, on the production, always just something just unexpected can happen. Yeah, yeah, that's so true.

Yeah. So that's a good insight for that. So, Filip, thank you very much for your experiences that you shared this year with our audience here on the podcast. It's, I think, very interesting and very inspirational to hear that change can work this way and how to deal with it.

I think that's a huge benefit for the podcast. So thank you so much that you invited me here and to just share this experience. I hope that the listeners will enjoy it. Yeah.

I think they will and we have your contact details also in the show notes and so and so if somebody has a question, they can just move on to you and ask you and maybe get some help. Definitely. If anybody has any questions, just reach me on the LinkedIn or different social medias. I will be more than happy to answer all the questions.

Great. Thank you very much. Have a nice rest of the conference here and then a safe travel home. Oh, thank you so much.

Enjoy today's day of the conference. It will be, there are some amazing speeches, so let's enjoy it. And thank you so much. Thank you.

Bye. Bye.