Rethinking the Role of QA Profile

The full transcript

Kavya (Director of Product Marketing, LambdaTest) - Hi, everyone. Welcome to another exciting session of the LambdaTest Experience (XP) Series. Through XP Series, we dive into a world of insights and innovations featuring renowned industry experts and business leaders in the testing and QA ecosystem.

I'm your host, Kavya, Director of Product Marketing at LambdaTest, and it is a pleasure to have you all with us today. Today's webinar is Rethinking the Role of QA Profile, and it promises to be a thought-provoking session, to say the least.

We'll talk about how you can explore innovative approaches to integrating quality assurance deeply within the development process. Let me also introduce you to our guest on the show, Christoph Eicke, Engineering Manager at Statista.

Christoph is a seasoned professional with a background as a Ruby on Rails full-stack engineer specializing in backend technologies and Linux-based cloud infrastructure. Over the past eight years, he has led diverse products and architecture teams, guiding them through complex challenges and fostering innovative solutions.

Christoph's approach to quality assurance is revolutionary. He believes that QA should not be a separate phase but an integral part of the development process. So before we jump into the conversation, Christoph, why don't you share a bit about yourself and your journey so far with the audience?

Christoph Eicke (Engineering Manager, Statista) - Sure, yeah. First of all, Kavya, thanks for having me. Yeah, I think you already shared pretty well my background. But I think one important thing is that I come from the Ruby on Rails world, and there, like testing or QAing and writing the code was always very tightly coupled.

So when I came into my first, I would say, more corporate setting with a more corporate team, I was a little bit surprised that actually, QA was a separate role because, for me, it was always an integral part of what I did when writing software. For me it was clear that I'm also responsible for writing the automated tests for it.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much for adding that, Christoph. So let's jump straight into the questions that we have for you. So to start with, what were the biggest challenges that you faced when implementing this developer-driven QA approach in your teams, and how did you overcome them?

Christoph Eicke (Engineering Manager, Statista) - Yeah, so the biggest challenge was really that the software engineers were still having this divide in their heads between development and QA. And the mindset was really that, you know, QAing the code that they have written was really not their responsibility.

I think this came from year-long experience working with dedicated QAs in the team who also lived this kind of divide. But also maybe because it wasn't an agile world back then, there were really schedules where you were released, like, I don't know, once a week or once a month or whatever, maybe you would even send out software CDs where the release cycles are really long.

So there was always a separate phase at this time when you would really QA the software that you wanted to bring to the customer. But I think this has changed also because I mean, software engineers also want to see their code in production fairly quickly.

And continuous deployment was the way to do this. But I mean, continuous deployment only works if you have the safety net of a lot of automated tests, which is really good test coverage. And yeah, I think this is really the key to showing the software engineers how the software coverage with automated tests really enables the team to ship their code quicker to production.

Kavya (Director of Product Marketing, LambdaTest) - So, you know, in a way, it was a mindset-driven issue, I would say. Is that correct in a way?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I think so too. It's really a shift in mindset that was happening or at some organizations still needs to happen depending on where you look and how, I would say modern the approach of QA in the company is really.

Kavya (Director of Product Marketing, LambdaTest) - Right, and as you were mentioning, it was important for the teens to sort of understand the benefits of continuous testing, for instance, right, or a more agile system, yes. Very interesting.

Christoph Eicke (Engineering Manager, Statista) - Exactly, yeah. Yeah, yeah. And I mean, to add on that, I mean, the usual development teams that I saw had like, I don't know, something like maybe five software engineers and then one QA.

And so, I mean, it was always like, yeah, QA is the bottleneck where you also had a distinct QA lane in your JIRA projects where tickets were queuing up. And I think this was really not good for creating a flow in releasing tickets to the customers.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Christoph. Very interesting point, of course, moving on to the next question that we have, right, in fostering a developer-centric QA approach, what specific testing skills and methodologies do you find most beneficial for developers to acquire?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I think it's difficult, but I think the most important thing that helped in my career was really learning TDD. I mean, the concept is fairly straightforward, but the implementation is really hard to really get yourself to think about what the output of your software should be first and then write an assertion for that.

And then actually going back to implement the code, it's a complete shift in mindset again, where you kind of tackle the problem from the back. And I mean, at the beginning, of course, when you start out with that, I would always recommend that you do it really, really strictly.

Of course, software engineers are going to be really slow because it's a total rethinking of the development process. But I mean, with everything, when you learn something, and you practice it for a while, you get better at it, and it kind of becomes second nature.

And this is also then when I think you can kind of weaken the approach again a little bit to not be so strict that every test has to be written upfront, but you can kind of like go back and forth. But still, you know, keep writing the tests while you're writing the software. So, I think this is the most important skill that software engineers need to acquire.

Kavya (Director of Product Marketing, LambdaTest) - And interestingly, you also mentioned developer teams starting with TDD. Is there any advice when you saw that shift happening within your organization? Based on that, is there any advice that you'd like to share with development teams on how to get started with TDD?

Christoph Eicke (Engineering Manager, Statista) - I mean, I'm always a very hands-on person, so my advice is always don't think about a big process upfront, but just try it out. Just start using it and maybe use it for a couple of iterations in your development process and then think about what worked well in this process, what didn't work so well, and then come up with maybe a little bit more of a formal approach so that the whole team uses a similar approach would be my recommendation.

Kavya (Director of Product Marketing, LambdaTest) - Of course, great insights, as usual. Thank you so much for sharing that. Now, moving on to the next question that we have in place. How can what you shared can be applied to larger development teams or complex projects? How do you sort of maintain consistent code quality across teams and projects?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I mean, I think if you find an or if you join an organization where all of this is not really happening yet, my advice would be to start out kind of like a nucleus, like one small team where you have the confidence that this team really wants to get better and is willing to try out new approaches and experiment.

In this team, a little bit with what works best in this type of setup and what works best for the organization. It would be good if you have experienced software engineers in there that know the code that know the organization well so they can really think about what works well.

And after you kind of have this stable team that is kind of your nucleus of this whole thing, then kind of expand this to other teams. An idea would be to pair across teams so that developers from other teams experience a new process and a new way of writing code.

And I mean, simply share your development workflow in larger groups, maybe in all hands, would be a good idea to just present some wins that the team had because of the new approach. Yeah, and something that I would also recommend is always, you know, have these communities of practices inside a company where there are people from various teams sharing their findings in specific communities like the QA community.

For example, where then you have these like-minded people that want to achieve the same goals and where they can come together, learn, share experience, share their knowledge, and also give recommendations from this group of experts to the management on how and what their advice should be implemented across the company.

Kavya (Director of Product Marketing, LambdaTest) - Thank you, Christoph. And the next question related to it was, especially when teams are innovating and experimenting, they might have different approaches when it comes to various projects that they're working on. So the subsequent question was, how do you maintain consistent code quality across teams and projects?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I think it all comes to a common understanding of what quality means. And I think here also the approach that I outlined before about sharing best practices, sharing knowledge, comes into play.

I think you have to start out in one team to define what quality means and what quality of code means, set standards, etc., and then take these standards and what you thought of in that team to the larger organization and kind of infect the other engineers with the idea of taking care of the quality really wanting to deliver the best quality possible.

Kavya (Director of Product Marketing, LambdaTest) - That is a really good explanation and insight. Thank you so much for sharing that. Yeah, of course, I mean, I personally believe that communities, when it's driven by a goal to sort of learn and acquire new skills, right, it definitely helps not just internally, a lot of times, you know, internal projects or internal communities that started off could sort of pivot into a larger scheme of things at times.

Thanks for sharing that. Moving on to the next question, how do you address potential resistance from developers who might be hesitant to take on additional testing responsibilities? I'm sure you must have encountered it.

Christoph Eicke (Engineering Manager, Statista) - Yeah, I mean, yeah, exactly. Yeah, I mean, this it's a really tough one because what you really want, like we outlined before, it's a shift of mindset, and we know that change is hard and there's always resistance. But it's, I mean, this shift of mindset, it's something that everyone will see pay off eventually.

But you kind of have to show the people who are skeptical the way. So my idea of management is not dictating certain processes and saying this is the way to do it now, but my way of management is to help the people realize themselves what the best way to go is.

And I can, as an engineering manager, only show them a potential direction where things are going. And then, you know, I have to kind of find allies, which, who agree with me, who are willing to take the first step and really pull the rest of the team with them.

And, you know, if that really doesn't work, then I would always resort to, you know, having the conversation and then just say, you know, let's just give this a try for a few iterations, then have a retro about it and then see, you know, what, what, again, what worked well, what didn't work so well and, and, and how can we move forward?

And I strongly believe that you know, this idea is so strong that the developers will see the benefits quickly. And that, I mean, in an ideal world, then they become advocates for this as well and really spread this idea around and really live it and are very enthusiastic about it.

Kavya (Director of Product Marketing, LambdaTest) - Thanks, Christoph. I was definitely thinking about how overcoming that initial resistance can be challenging, and I think the way you explained it definitely could be a useful tip for, you know, folks at your level, basically engineering managers, leads who are basically leading teams, right, and are trying to, you know, make their teams adopt new technologies, innovations, tools, whatever it is, right. I think this approach can be sort of implemented across by finding the first few folks who could join in your project, to begin with. Yeah.

Christoph Eicke (Engineering Manager, Statista) - Exactly, yeah.

Kavya (Director of Product Marketing, LambdaTest) - And how do you strike a balance between developers focusing on code development tasks and incorporating thorough testing practices?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I mean, this really comes to the core of what we're talking about. What I always want is for the developers to write the automated tests and get into the habit of doing that all by themselves. But of course, then the question is, what do the QA engineers do?

And here how I see them and how I like to utilize them is kind of as the consultants to the software engineers that ideally already come in at the very, very early stage when I don't know, maybe tickets are defined to already paired with the people who are writing the tickets to think about what's important about this ticket to test.

So I think there, this is where I like to use the knowledge of the QA engineers to really think about this and already add it to the ticket so that afterward, you know, the software engineers are kind of free to go and write the code and the tests at the same time.

But then there's always something in between tickets. It's hard to test automatically. And this is really where I need all the expertise from the QAs to find these really, really strange bugs where, I don't know, you get feedback from production and you can't, I mean, you look at it, and you're like, can't reproduce it, but it still happens every once in a while.

And this is, I mean, I worked with some amazing QAs that found bugs that I was like, okay, I wouldn't even come up with the idea of clicking a website in this certain order and inputting data in this certain order. But then, you know, a bug came out of it, which made the software more resilient in the end.

And so this is, for me, kind of the new role definitions for the QAs on the one hand as the consultants for the engineers and of course also to lay the basic foundation of testing tools and also like the whole CI/CD pipeline really.

But then afterward, if everything works smoothly and the software engineers are on their way and are pretty much independent of the QAs, then I have this awesome resource of the QA engineer freed up to really work on these very, very difficult things which are in between the tickets and really make the software as a whole better because from that experience we find strange bugs which are hard to debug and take a lot of time in the development process to get out.

So, I mean, coming back to the, I didn't really answer your question, I'm realizing. So, yeah, it's, let me say this, this is how I envision like the perfect software development team with the roles like this. And then, you know, everyone kind of has the work cut out for them.

Kavya (Director of Product Marketing, LambdaTest) - I think that is a great answer. Really appreciate your insights because what I am able to understand is that there is a closer collaboration between QA engineers on one hand and software development teams on the other hand, which is really important to ensure that the software that we are turning out at the end of the day is the best in terms of quality emphasizing on how quality is everyone's responsibility per se.

And this truly sort of validates that. An interesting point on how you also mentioned Q engineers can be consultants, how their knowledge can be used not just to lay the foundation, but also to act as consultants for the engineering teams at large.

Christoph Eicke (Engineering Manager, Statista) - Exactly. Yeah. Yeah. And I mean, of course, something I didn't mention is, but it comes with this consulting role is, of course, I mean, defining how and what to test when writing down the ticket is one thing. But then, of course, during the development of the tickets, I expect the QA engineers to be open to questions from the software engineers.

And they also have a very, very close collaboration to work on these things together also a big fan of pairing, and they're also, you know, QA and software engineers pairing together to write, to, you know, really see both sides of the work that needs to be done. And then I think the idea of quality really is in everyone's mind when we do these kinds of pairing across disciplines.

Kavya (Director of Product Marketing, LambdaTest) - I agree with what you said. Moving on to the next question, what metrics or benchmarks can be used to measure the success of this shift in the mindset for the engineering teams?

Christoph Eicke (Engineering Manager, Statista) - Yeah, I'm not a very, very big fan of metrics, but I think if you want to have one, I think the growth of your test coverage is one that you can look at because I really believe that if you really implement this approach, then your test coverage will slowly but surely go up.

So I think this is one thing that you can look at. And the rest, for me, is kind of a gut feeling to see the team interact to kind of get a feeling is it working well. Is everyone on the same page with this different approach to QA?

And then I think one important checkpoint is always or checkmark is always to look in the retros to address these points and ask these questions. How do you feel about the collaboration? How do you feel about the quality of our code?

And they slowly see an improvement; I would say in confidence that the people on the team have in the quality of the code that they deliver and, yeah, the features that they are delivering to go live. So no real metrics besides the test coverage, sorry.

Kavya (Director of Product Marketing, LambdaTest) - No, I think that this definitely helps, to be honest. So, I was just jotting down the points so that I could look at it later on. So asking the right questions and feedback within the team after they have completed the project and looking at this coverage, I think I understand why you mentioned.

You're not per se looking at matrices, but I think even this definitely leads you to the path. So, coming to the last question of the day, Christoph, how does manual testing complement this approach? Is there room for manual testing tools alongside automated testing that the devs wrote the code for, for instance?

Christoph Eicke (Engineering Manager, Statista) - Yeah, so this is what I tried to say earlier about the shifting role of the QA engineers. I think this is exactly where I need the expertise to test these strange things in software and give the QA engineers room to experiment with the software that was written to find these really strange things, outliers, and defects in the software.

And I think this can only be found with manual testing. So I think that's where this comes in. And like I said before, for me, it's always kind of like the black mystery art. I tend to use software only the way it was designed. I never find bugs, and people tell me, you know, with this new release of macOS or whatever there are so many bugs.

I never see them because I think I don't have this QA mindset to try out these things. But I know it's really, really important to have these people try out all kinds of different things and also notice these kinds of things. Maybe I see the bugs but I don't notice them; that could also be possible.

But I think this is you can only find out these things with these manual tests that really where you really need time to do these. I mean, take the full day to just, you know click around and find small inconsistencies that were not addressed in the tickets, but you know, kind of in between the tickets, what I said before. It's like these seams that you need to test that weren't really thought of before.

Kavya (Director of Product Marketing, LambdaTest) - Striking the balance. There was a phrase that we had earlier used in one of the questions. I think that also can be used, I think, here as well. Thank you for giving a comprehensive view. It's interesting how both automated and manual testing can coexist in a very effective manner, of course.

Christoph, thank you so much for all the insights that you have shared. Before we wrap up, I wanted to understand if there is anything more that you might want to share with the audience today.

Christoph Eicke (Engineering Manager, Statista) - I mean, I think especially for the software engineering managers who are listening, this is really, I would really like to tell you that just do a leap of faith and try to change the QA process.

If you are having kind of like this old style with if you look at your Gyra and you have a separate QA lane, get rid of it and really go with your team on this change of mindset because, in the end, everyone will benefit and you will deliver better software faster.

Kavya (Director of Product Marketing, LambdaTest) - Absolutely. Thank you so much, Christoph, for the valuable insights and experiences that you've shared with us. I think your approach to quality assurance has certainly given our audience a lot to think about, and probably they could implement it within their teams as well.

I would also like to thank our audience for joining us, and stay tuned for more such insightful sessions where we continue to bring you cutting-edge ideas and expert insights from the world of testing in QA.

If you have any further questions or need additional information, please feel free to reach out to Christoph on LinkedIn. We would definitely be tagging him in the post. Thanks again, Christoph, for joining us today. It has been a pleasure to host you. Thank you.

Christoph Eicke (Engineering Manager, Statista) - Thank you, Kavya.