Szilard Szell

Eficode

Welcome to the Eurostar Community Podcast. For over 30 years, we have been bringing the global testing community together to share knowledge, connect, and grow. Check out eurostar conferences.com for our in-person conferences and access to online testing resources. Thank you for listening to this podcast.

In this episode, you will hear from Russell Craxford from the UK Department of Work and Pensions with guest Szilard Szell, recognized tutorial and talk presenter as well as DevOps Transformation Lead and Quality Coach at Eficode. Russell and Szilard talk about keeping your team positive, the keys to quality service, and AI, among other interesting topics.

We hope you enjoy.

Russell Craxford:

Hello, and welcome to another episode of Eurostar podcast. Today, I’m your host, Russell Craxford, and I have a special guest from the conference with me right now.

Szilard Szell: Hello, I’m Szilárd Szell, Hungarian from Finland.

Russell Craxford: That’s a story in itself. Do you want to elaborate the Hungarian from Finland anymore?

Szilard Szell: Yeah. So the longest story is , I’ve been living in Finland for six long winters by now.

Russell Craxford: Okay. Six long winters. I guess. Yes. In Scandinavia, winters are longer, darker.

Szilard Szell: And that’s the only way how you count years, right?

Russell Craxford: Okay. Count years by winters.

Szilard Szell: I survived another one.

Russell Craxford: So thank you for joining us. You’re one of our speakers here at the event this year. So, where do you think testing is going?

The field, the career, the role, the tools, the technology? Where do you think you see sort of testing in years ahead?

Szilard Szell: That’s a good question. And I have some experience and some past in this. So being in the testing for 24 years now,

starting really in a big company, very structured testing, a lot of processes, which sometimes I like dream back that that would be good to bring back.

It’s, it’s like. We had the time and what I think nowadays is all about being fast and faster and even faster. So where testing will go is speed. And it must be extremely fast to catch up with the continuous deployment expectations. With the ability to provide feedback to the developers.

So when we talk about, for example, developer experience, that developers are happy, they produce good code, they produce good quality product services at the end of the day, they need feedback.

Russell Craxford: Yeah, fast feedback, as you say.

Szilard Szell: And what I think is that the future is testing is fulfilling that need, going as fast as you can and using any technology that helps you to be good.

Testing so high coverage and, you know, going all around, but also fast.

Russell Craxford: And I guess, is there kind of any sort of trends and things that you’re seeing? Any sort of ways in which testers can speed up the process, um, speed up the feedback loop? I think it’s really what we’re talking about, isn’t it? Well, speeding

Szilard Szell: up feedback loop is, is happening in multiple dimensions, right?

And, I always love to about shift left and shift right. And when they say shift left, like how testers testing, mindset, testing, thinking could give feedback as early as possible in the whole life cycle. Yeah. I love to say that when anyone asks back for a designer, and I mean service designer or product manager, product owner, like are you sure

Russell Craxford: Yeah, man.

Szilard Szell: That’s already testing.

Russell Craxford: Yes. Asking questions of the idea almost.

Szilard Szell: Or if you ask, and what if not? And they say, this is how it should work. This is , how the end user will use it. Yeah. And what if not? Yeah. So bringing in those questions already there is testing for me and that’s speeding up already testing.

Now the other dimension, the shift right is how can you get, collect feedback from the field? from production as fast as possible. And it might not be testing, because you are having telemetry, you have observability in the field, you want to see what, how the end user is using it. What’s happening there, right?

What’s good, what’s bad, are they happy, are they crying? Yeah. But many times you will need the tester to actually analyze the data or help you understanding what happened. Okay. Helping the architects to design the observability system in a way that it provides useful information. So I see testing is extending a lot and it goes many areas.

For example, designing testability functionality, suggesting to architects how to change the system is still testing for me.

Russell Craxford: Making the system more testable, looking into testability. does that mean you see more testers going into kind of their system design, architectural design, the quality design perhaps area?

I very much

Szilard Szell: believe that testers, some of them will go to service design. Some of them will go more to architecture. Some of them will go more to the business side. Yeah. So there will be really a, I’m not seeing specialization. But good testers, experienced testers will need to understand everything, all of this.

Russell Craxford: Okay, so that begs the question, is that a realistic expectation? Or do you mean know a little bit about everything, not depth and knowledge of everything?

Szilard Szell: Exactly, like we always talk about these full stack developers, right? And then we talk about comp shape, skills in an agile team, in a cross functional product team, as we call that nowadays.

I believe that testers will also grow more of these, these pillars, these legs in the different skills. And I’m taking it from my own experience. I studied service design, lean service creation, actually, to be specific. I’m a facilitator on that. And I love this so much when it said one was the, the, the company’s statement was like, love the problem, not the solution.

Russell Craxford: Yeah.

Szilard Szell: . Validate the problem, go out. And for me that was an amazing learning experience. And I believe more of us should go into that direction and could help service designers.

Russell Craxford: Yeah, I know. , I think problem solving is the one of the areas that isn’t discussed enough within testing at the moment.

Uh, it’s like communication. We are talking about teamwork, collaboration, communication quite a lot in conferences like this. Actually, problem solving is fundamentally and it’s solving the right business problem. Software is built to solve someone’s problem. It’s not built for. Because of a whim, it’s meant to fix something, improve something, make something better, experience, transfer of money, whatever.

It’s just meant to make life easier. And to your point there, there’s, I think there’s a quote attributed to Einstein that I don’t think actually was him, but never mind. Where it’s basically spend, if you have an hour to look at a problem, spend 55 minutes looking at the problem and only five minutes looking at the solution.

Don’t spend as much time on the solution. Make sure you know what you’re solving. That’s the important thing.

Szilard Szell: And I love the representation of that with the design thinking, double diamond, where the first one is diverging on the problem space and finding the one problem that is worth to be solved, then define your product, backlog, not before, there you define your backlog items, and then you again diverge how to solve it, what’s the solution, and then you get back to the one solution Or two, if you have A B testing.

Yeah, you can experiment a little bit, yeah. You can experiment, and again, like, by the testers knowing these concepts, they will also understand, how from testing they can support getting answers on these questions.

Russell Craxford: think you’ve highlighted something, which is, I do think it’s really important that testers start to understand the processes.

Around systems that we’re testing, not just the architecture, the cloud or these other things, but how does the product owners and those sort of roles work? How does the business work? How does operations work? Because at the end of the day, you’re helping to enable our service to go into production to be used by people and maintained to solve a problem.

You can answer questions better on it. If you understand the life cycle, and I don’t just mean the software development life cycle, I mean the actual business life cycle. Absolutely. And it is different in every organization, but similar. And as you said, design thinking patterns, that’s one model that some orgs do.

There’s scale agile kind of models and things and the way that they group things together and separate things out. There’s lots of different models organizations do, and you can help more by understanding some of these concepts. You don’t have to be an expert on them. I know you are a, a man of many certificates,

But, and it does help understanding the basics and doing them, and I think I learned early on in my life that getting some certificates, understanding context helped me give better advice. Yep. Help me challenge things more accurately. Absolutely.

Szilard Szell: Why I do the certifications is to speak the language.

Yeah. And to understand when I talk to. A client, and, they use certain language. I can relate to the framework they are in, and I can utilize the same language to answer the problem in their context. Yeah, that helps. So , that helps a lot. Coming back a bit on this testing , and how testers can grow and help, right?

Yeah. Even more focusing on quality. Not just testing, but quality. And when I say quality, like really thinking of what is the quality of a service. Yeah. I love to use the Lego, example, I love Lego. For me, I love Lego. I collect a lot of Legos, I have a huge amount of them, but I even went to Lego factory.

to see the manufacturing process of them. Sure. Because I do also Lean Six Sigma and I love Lean factories, Toyota production system. Yeah, it makes sense. Mercedes, etc. But Lego has that one. Now, they focus very much on high quality products. But when you think about the product quality, it’s the total lifecycle, right?

And the total value for your end users. Few times, very little few times I found, a piece of Lego that had, molding problem or something.

Russell Craxford: Yeah.

Szilard Szell: Now it means that the whole set is unusable anymore, right? Yeah. So I will be angry. I will shout. I will have emotions and that’s wrong quality, but I just go to the website.

Give , the ID of the box, the set, they show me immediately the whole set of pieces. I pick the one which was broken, click a button, give my address and they send me a replacement part free of charge.

Russell Craxford: Pretty good, resilient sort of service to that. And

Szilard Szell: that’s still part of the product quality. Yeah, right.

It’s the service. Now I’m cooled down. And once I had a bigger item, had a bit of a problem with there and they actually send me even a key ring like, Oh, this is a problematic piece. So now here’s a bit of a, of a gesture. I was so happy and I got happy and I got a new story to tell on podcast. But I mean, like seriously, this is part of quality and many times you don’t think about this.

If we already shipped a fault and there’s an impact, how we can reduce the impact?

Russell Craxford: Yeah, I think that’s a really

Szilard Szell: good and that’s not testing things. And many times that’s like architecture, that’s design, that’s your, really strategy. Yes. Canary release, right. Green, blue releasing. Yeah. All these are reducing the impact.

So improving quality.

Russell Craxford: Yeah, no, I think it’s a very valid point.

Szilard Szell: And that’s why I’m saying, like, shift to the right. Look into that, and testers need to understand and learn these aspects as well. Because this helps improving quality.

Russell Craxford: , It leads on to the conversation, you know, our testers are responsible for quality, are responsible for testing, because they’re not the same things.

Should they be caring about all quality of the system, including how you release it, how you do it? Now, I’m guessing I’m probably similar in mindset to you, which is more quality engineering, quality solution. Testers, in my view, should be contributing to the overall quality of a product. Testing is one of the activities.

Absolutely. One of them. Yes. You mentioned requirements, working with ideas, those sorts of things. The other part, monitoring, release strategies, you know, suggesting experiments, getting involved, helping companies shape pipelines. Yes. Because, again, that faster feedback loop you’re on about is like continuous delivery.

Ideology, really, we’re getting to finding out fast when you make a change, what happens, does it work, does it not work, what do I need to do, it’s launching things behind flags, it’s getting your build out there so that if there’s a problem, it’s small, fast, and you can adapt, you build resilience, and there’s something, I know where I work, resilience is a really important thing, and it’s responding to failure, because you will fail, I’ve worked in software testing, I’m sure you have for a long time, And I’ve seen many releases fail.

I’ve seen many successful, I’ve seen many fail. And it’s about how you deal with those failures that really demonstrates customer satisfaction. Because we all get things go wrong in software. But if your system’s offline for a week, that’s massive. If your system’s offline when you want to do something, let’s say you’re Netflix and you want to watch a film, that annoys people.

If you went offline in the evenings, in the mornings you’ve got kid shows and things like that, so. The impact is really important to building resilient systems, high quality systems that impact the customer, that do the right thing, enabling experiments. A B testing is a great sort of way of helping figure out what matters and what doesn’t matter without betting your house on it, which is what, and then customers give you feedback.

So you impact 10, not 10, 000, 10 million. So there’s lots of things out there. Testers can actually get involved with. It sounds like. Is there any kind of area in particular you think as testers know less about that should probably invest more in?

Szilard Szell: I wouldn’t say it in a generic way that they should do this or that.

I believe testing is a big profession. There’s a lot of dimensions of it. You could go really deep and deep dive in test automation. You can go deep in CICD design. And,, take the pipeline game and learn with that. But I believe also if you want to grow and you are interested in new things, really go into all these aspects of quality.

And for example, yes, taking a look like how can you get feedback from the end users? In your company, who is listening to the customer?

Who runs the help desk? Go there, listen to the recorded talks. Listen to the energy level that there is. I’m sure it’s not high energy. It’s or high negative energy, right?

Yeah. And have the whole company to learn from these to fix those things to get the focus. Bring it back to your risk assessment. Those are the things people get pissed off it. Bring it back to your risk assessment. Bring it back to your regression test set. Design, right? Collecting the regression set, bring it back to your exploratory testing sessions.

The test chapters. And even help. So if you are interested more in the processes, have the company to establish these processes like ITSM, IT service management. Extremely important aspects. I, again, a certificate itil, right? I just got the last year, my ITIL foundation, I. Like that, again, as a new language, as a new aspect, we don’t think in development, we don’t think enough , in the service area, how to manage the service.

Yeah. It’s good to open up and again, helps service to provide service quality.

Russell Craxford: We ultimately are producing a product for use. So understanding the management of its use, is an interesting one. I work in an organization which is large, that has a service management silo, I’ll call it, in some ways.

Separate team, separate functions, separate job roles, and so on. It’s a specialism, like everything else. So it’s all about how we can collaborate, to your point there, how we get feedback loops that aren’t just ourselves to ourselves. Like you mentioned early on, the developer feedback loop. They want to know the code’s good.

We also don’t want to solve the customer problem. Is it maintainable? So it’s making as many of these loops as fast as possible to get the right people input into the solution. Because they all matter. And big organizations, you will have a service management of some form. So making sure that they are involved in it versus the person that gets thrown over a fence to.

Because that never works that well in the end. And so it’s all about integration. Collaboration, communication, and all these things, isn’t it really? And I

Szilard Szell: love to add knowledge management.

Russell Craxford: Knowledge management, okay, yeah.

Szilard Szell: Because when you, for example, again in ITSM, it’s very important that how quickly can you resolve an issue, right?

Do you have the knowledge available? Yeah. Now how much you learn from your exploratory sessions? And you mentioned resiliency. Yeah. I love chaos engineering. Oh, yes. How much you can learn from chaos engineering? How it broke? What you had to do to fix it. Can you bring that knowledge to the ITSM silo?

Russell Craxford: Ideally it’s not, obviously, but yeah. But how do you make sure that you’re working collaboratively? Versus working not. And it’s natural that people, like testers talk to testers. Service management talks to service management. Customer support talks to customer support. It’s all about breaking those down to make sure that they feed into the product.

Because that’s what actually matters. And it’s very easy to create boundaries, but you’ve got to try and figure out the ways that do them and asking the test is a fantastic because you want you care about quality as we mentioned. So it’s the quality from the developers perspective, the quality from the idea and service management perspective, quality from the customer support perspective, quality from the actual person using the software.

So, you know, this we care about all these personas, I guess, and, you know, facilitating the overall good qualities is one of our Strengths. Maybe it’s one of the areas that we need to facilitate more, but yeah.

Szilard Szell: I love you mentioned personas because again, that’s like part of the service design.

Understanding personas and listening to the service desk feedback discussions. You will be able to identify the personas. You will be able to carve out their different problem domains. And then again, from that, you can take those personas into your testing, test design, and even into your exploratory test charters.

Yeah. In person testing and now I’m in persona. Yeah, exactly.

Russell Craxford: You know, think of the, tech savvy user, the non tech savvy user, the, visually impaired, those sorts of different things. Think about the different sort of standards and different ways the Mac user versus the shortcut user versus the mouse user.

All these different ways, mobile,, websites these days, how much do we access on our mobile? The answer is a lot. A lot. So is your site, is your website, if it’s a web based thing, accessible? If it’s an internal agent based system, it won’t matter so much. But if it’s an outside facing system, you’re going to have a massive impact on revenue.

Let’s say Amazon. You could only use on a laptop. They’re gonna make a lot less money than having the app, than having, a website that you can access on your mobile phone. So you’ve got to think all these angles. There’s a lot to think about as a tester, isn’t there?

Szilard Szell: And I’m working now in the telecom sector again, on cloud infrastructure.

Big vendors provide their tooling, and they have a beautiful UI, so you can go around that, you can do your things. And when you think about DevOps, what you end up with is ClickOps, which everybody hates. Give me an API. I’m a developer. I want to run this from a pipeline.

Russell Craxford: Don’t want to use a UI.

GitHub

Szilard Szell: Actions, right? I want to do I don’t care about your beautiful UI. Yeah. You spend time on it? Why didn’t you update your API instead? When the API is not updated, I really don’t care about your, your UI.

Russell Craxford: It’s interesting because they’ve probably thought of the persona of selling it.

So the person I’m selling it to cares about a pretty picture, usually. Or the person who’s learning for the first time, which is more likely to go through a UI than there is an API in, if they’re a starter. So if you can Teach people at the beginning some things. It’s interesting how the psychology I could have a whole new episode on that I think so maybe shouldn’t go down that psychology route.

Is there any sort of, lessons that you want to share? Any sort of advice you want to give to anyone that’s listening? Well

Szilard Szell: I think my lessons went out in my talk. Oh, okay. The dark testing stories. Yeah. I talked about anti patterns and failure stories.

I try to throw light on those, but I think , especially for testers and quality minded people, I would say that thinking about quality assistance is one of the most important for me. I’m an extrovert. I’m like a coach. I love to do this test coaching. I love to work with all the different roles and infect them with quality mindset.

Because quality is a mindset.

Russell Craxford: Yeah.

Szilard Szell: And that’s what I suggest. Learn more. Grow your legs here and there. Be brave to go more to the left. Be brave to go to the right. Yeah. Shift left, shift right. Honestly, I would challenge that for the last 20, whatever, 30, 40 years, we are all focusing on the center on testing, making testing better, but just growing testing will not be fast enough and will not give fast feedback enough.

Yeah, of course we need to do that. We need to have perfect testing. Yeah, but I challenge focusing only there. To go to the left, go to the right and close the loop, have a perfect DevOps there. Yeah,

Russell Craxford: everyone can’t disagree with you if I’m honest, because I think there’s a lot of focus on that middle section, the automation, the sort of continuous testing part of it.

But actually, it’s the how do we build the right thing? How do we know it’s the right thing? How do we release it in a safe way? How do we monitor, maintain, observe? No data in some ways. So I think there is a lot more testers, businesses, not just testers, can get an understanding of there and actually make an impact because you might well know how to test, time might be the thing, but if you can focus on the right thing, you’re going to have more time to do value.

So if you can get the left bit, right, and you can get the right in a better situation. You can make riskier, things. You can make better decisions and you can test what matters probably more accurately because the only time you’ll ever know what a user does is when a user actually hits it.

So, that’s by far the best way of assessing risk. Things like canarying, as you mentioned, is a fantastic way to actually understand the truth, to build the automated tests that matter, not just the ones that you want to do. But again, if you shift left, unit tests, lower tests, things like that. You can have a good quality before you get to the user.

You can consider that the components do what they’re meant to do and all these other elements. So it’s interesting.

Szilard Szell: But on my shift left scale, it’s like a behavior driven development. Yeah. Test driven development. Yeah. Test specification as a a test case, test scenario as a, specification by example, okay, this is the word I was looking for.

Yeah,

Russell Craxford: but it’s, they’re all different variations of that same thing, acceptance, test driven development, etc.

Szilard Szell: And all that is also ShiftWrite. And on, on ShiftWrite, one thing that, I’ve seen amazing, and that was, in a Spotify presentation. When they said that the, and that was many, many years ago, but the App Store comment.

Are on the wall in their development teams. And trust me, when you deploy something bad to Spotify, you will get to know it in a second. People will yell out in the app store, give you a one star and they will comment and you need to filter those out. Look into those one star comments and you will know exactly, you will have the voice of customer.

Yeah. And some of that will be

Russell Craxford: false. Some of it will just be ranters and people, but a lot of it will give you a very valuable feedback. I worked in companies where we put feedback feature into the app itself prominently, give us feedback and so on. And then we fed that directly into our Slack channels.

We didn’t have quite a big screen model, but Slack channels and you had everyone paying attention to it because you got positive feedback. You got the actually, Oh, wow, this is amazing. I love this new feature. I love what you’ve done here. And then you got the, I can’t believe you changed this. I’ve only just learned how it worked.

But it was really interesting because you actually heard the voice of the customer and as engineers, we often don’t get direct unfiltered feedback, and that’s really powerful to help you know what you’re doing is right, wrong. It’s a really good thing to influence others to change because you can say the customer said this.

It’s very much powerful statement than I think this. So yeah, if you can get it into the customer hands, get feedback faster from them. Power is immense. So yeah, that’s a good thing to end on? Well,

Szilard Szell: we didn’t touch AI thing, right? We haven’t gotten too much into AI, yeah. But go on,

Russell Craxford: give us a final note on

Szilard Szell: AI. It’s a must. But yeah, why that is important, as we discussed before the podcast, that as development is using more and more AI generated code and AI supported code.

Testers needs to also grow up to the challenge. Make sure that the safety net what we build as testers are catching even AI generated problems. On the other hand, we should also look and understand how the gen AI generative AI, everything that technology can help us. Of course, any technology. But it’s also good that I’m, , playing around with the different tools.

It helps me a lot to even set my conversations , to, how to say, analyze requirements and et cetera, et cetera. So there’s a lot of ways to use it. Everybody should start understanding. That’s my thinking.

Russell Craxford: That makes sense. It’s like you mentioned something earlier on, which I think. Rings true here too, and I guess I’ll end on this bit, but curiosity.

And I think you mentioned it earlier, it’s really important to be curious, to actually then go and explore, to learn, to get some of that broad knowledge that allows you to become more of an advocate, a coach, a leader. You don’t need to be an expert at everything, but the more that you have awareness of what’s going on, the more you can steer, the more that you know you need to look further, where appropriate, and so on.

You know what you don’t know.

Szilard Szell: And also explore how it fails. Yeah, so you don’t rely on it.

Russell Craxford: Yes. Too much. And that’s the curiosity. , I probably used this analogy before, but I put some models into it to get for a presentation. And I got the model that came out of it. The words were all spelled wrong. It had different images built into it.

It was just wonky, is the best way I can describe it. And it took me a while to notice, because it looked a lot prettier, but I’m dyslexic, so I didn’t notice the spelling was wrong at first glance. And then I looked at it again a day later and went, hang on a minute, the letter’s the wrong way around.

It’s, it looks pretty, but it doesn’t say anything anymore. So you can, if you trust it purely, you’re going to end up with some weird results. So yeah. Use it wisely.

Szilard Szell: You are in charge. Don’t forget that. You are accountable, you need to validate. And it’s your output, not the machine’s output. Yes,

Russell Craxford: you’re still the person being paid to get the job done.

Yeah, hopefully. So use your skill. Hopefully paid. Yes, hopefully paid, not volunteering. Anyway, thank you very much for joining us, Szilard. It’s been a pleasure speaking to you.

Thank you very much. Thank you.