From QA to quality engineering

I would like to know about your. Your leg. Sigh. And also what the heck were you doing up in a high area to fall off?

Yeah. So for the interest of anyone that doesn't realize and don't know me, I fell off the roof for the weekend, which was rather painful. I was trying to clear the gutters because the stormer in the UK after autumn falls with leaves everywhere, blocked our drains. We had leaks in the house. I was like, all right, this should be a simple job. I've done this before, not realizing how slippery the ground was. The ladder was not secure enough. The moment. Normally I wouldn't.

And it's.

I suppose I'm not normally a problem. Yes, Common sense and all that stuff. Anyway, the moment I tried to get my leg off the ladder, the ladder went and I went all the way down, fell onto my leg, I think twisted it in, which is why I'm. I'm not sure if it's broken or completely ripped the, you know, the soft tissue. My back has been hurting as well since which people are going, whoa, careful. I'm like, I know, but doctor said today your back's fine. There's nothing wrong with the hips. There's. It's just a lot of swelling. It's going to take time to come down. Moral of the story, don't do DIY single story house. Well, it's a single story roof, but okay, still, it's like four or five meters. The first hospital I went to went, oh, we're just a local. We can't do anything over one meter. All right, okay, so I'll go to the next big general hospital. And they were like, oh, wait, yeah, we're got a doctor strike and we're going through renovation works. That way, please. Wow.

So I used to be quite flippant with ladders until a very close person, certainly someone I knew, had much more of a serious end to a ladder incident. And yeah, I'm particularly mindful now about making sure someone's at the bottom, having the little bit that can clip on the top. And just be very careful because it's especially on our roof. Looking at it. I've done the gutters up there and that is. Well, that's a good number of meters, like a couple of stories up. So a fall from there is. Yeah, that's. That's gonna hurt.

Big one, mate. Honestly, a little bit traumatic at the start as well. I was like, whoa. That was. But I just carried on. I went and did some kitchen work. It's a bit of a swollen one I was like. But it got worse. And the moment I came out of the shower, wow, my foot has doubled in size.

Leg or a.

It's the ankle heel sort of corner. Okay. So, yeah, I'm booted up now. I am sitting relatively comfortably after a week of relaxing quite a lot. And I thought, I know what I want to do. I want to have a good chat with my friend Neil about.

Nice. I like the segue. Well, today, Si, I thought I'd bring a topic around. Testing, testers, quality, and all the other names that come with it. Some people might argue that we could benefit from that and talk about risk and risks of ladders and heights. Well, that's what I'd like to bring today, partly because it's how I got into to tech. We've talked about that in some of the early podcasts, but I'd. I'd like to expand that to challenge each other and find out what that looks like and just get some thoughts on terms of what we've seen, maybe what we like and what we prefer, and we'll take it from there.

I like that. Yeah. And when you tease me with this topic, I started thinking about it, actually got prepared. Okay, so I've got a few opinions on this I just want to pick up on. One thing you've touched on there, though, was the namings that you. It's evolved, I think, over time, as everything in tech generally does. I was a webmaster when I started, and then I became a web designer, then a web developer, then a software engineer.

Then I like webmaster.

It goes on and on. But for me, when I was first exposed to people that do testing, that's why I'm being very specific in what I say. They were called testers.

Yeah.

And I was like, good, now I know what you do. But then that shifted towards qa. I'm like, well, QA isn't just testing, surely, because engineers do their own version of testing. QA brings a different mindset, surely. And that's how I've seen the role evolve in my experience. And QAs aren't necessarily the people that sign it off at the end either. I like QAs that are involved in the design decisions and the earlier discussions to really bring a completely different perspective to things. This is where we can go off in completely different directions. But the evolution of the role is what I want to get a point here. People are quite specific on what they like to be called as well. I made a very bad as well. Sometimes I was like, there's that test Guy. They took serious offense to it and rightly so. I hate to tell you, I'm not that testing guy. I am a QA manager. I'm like, oh, sorry, I didn't mean to cause offense. It was literally, oh, you're the test guy. It was completely off the cuff comment and I was like, I threw my hands in the air. I'm so sorry for cause offense. It was not intended to. I'm not that guy, trust me.

Oh, let's. You called out a few. I wonder if there's any more that we can, that we can come across in terms of job titles or roles that may do the same thing or may do things differently. You mentioned test or tester. Tester using that term. And you also mentioned quality analyst. I guess I've also heard of quality assurance.

That's the QA I've always considered. Okay, quality assurance, but quality analyst, you're right, because it's an abbreviation, you guess.

Yep. And definitely I think I've seen variants and in different industries how that's applied. And then another one, a rarer one. But I, I've certainly come across QAs who refer to themselves as question asker, which I like. That's nice. Yeah, that's a good one. Right. Officially, I don't know if that was an official job title is certainly how they refer to themselves. Have you come across any more? I've got one or two. I think. One or two more.

No, but I like that. I mean even like the book basher kind of mentality and finding problem solving and I think you can quite get quite silly about it if you want to because there are so many angles to the role. But I think they're the main three. I've always heard it's like testing QA estet, I guess, software developer in test.

Yeah, actually you're right. And of course we could add automation engineer.

Yes.

It's a classic test.

Automation engineer.

Yes. And then so some of the more recent variants are quality coach or quality engineer.

Are we talking?

Yeah, I used to be a quality engineer. So that is a. Certainly a job title. I've had one. So there's quite a few actually now I come to think of it, and why it makes it difficult. Right.

In many ways because I think if you're trying to find the right person for that role as a manager, then how do you know that the CVs are going to be reflecting their role? Well, on the flip side, I'm looking for a new job as a quality person. The job spec does not Align with the job title because that's not what I looked for. So I think it's a generic problem in most of tech actually. We try to find and label the right job with the capabilities and the role actually accurately. Very hard. And we know in tech naming things is hard.

It is. With that in mind, I'll go. I have a. It's because it relates to, to names. There was. I'll dig out for the show notes, assuming that we have them, a link for this. It was at a Ministry of Testing conference. A gentleman came on the stage and he talked about a story where they changed or he changed the name of testers in his company over the course of a year. I think they changed their names deliberately maybe three or four times. And then it went back to. Let's just say back to the original tester. They didn't change their skill set, didn't change how they worked or what they could do. They just changed their name. And what he did is he pushed it out, I think through, through hr, told HR this is the new name now. And everyone got referred to that. And he, he said the change was quite, quite drastic. He. I think there was a change where he called the testers like business analysts and all of a sudden teams that were. Were planning suddenly like we need some of those folks in our. They were testers, they were always testers and they came in and do. Did their thing and you might expect someone, a tester coming in early to ask those types of questions. And teams loved it. Not a different person, a different name and a different perception. And then they did it again and they changed it again. Maybe it was around the earliest stages of experimentation and design and they came in and people loved it. And I think it went through three or four and then they went back to tester and. And they weren't invited into. Into things as much. Same people, same company. Fantastic. Interesting. Right. Just how much a job title and make a difference now, of course, people working with them directly, they didn't suddenly go, oh, you've changed your job title, you're no longer part of what we're doing. That continued. But the wider engagement, people who didn't know. Yeah, it changed quite drastically back. He said it was almost. It's a little sad in a way I guess because maybe it's quicker to do rather than finding out the skills and capabilities of people.

Yeah. And it, I mean it might be a bias in that company or that industry where, oh, testers are just there at the end. Right.

Possibly.

Yeah. But I fear that it's seen as. Are you not real engineers? I'm like, come on, who says that anymore? You know, they've got completely different skill sets. But I wouldn't devalue any testers or QAs as I know them.

I, I've certainly seen the evolution of the role and it's why I enjoyed it for so long, because it hadn't, didn't stand still. It had to change with the times. Like as soon as you went from shipping on a CD to shipping in the cloud every day, every hour, every minute, like your entire approach to something has to change and you have to learn what's new. And that's, it's a, it was a constant evolution of the role. Now we still have and still will have all types of testing from the last 20 or 30 or 40 years still prevalent in our industry. Definitely. But yeah, over time I think certainly that the maturity I think of, of that test community, the group of people who might identify as testers or have a testing role, has certainly improved and changed and adapted.

Absolutely. You mentioned the Ministry of Testing community as well. And I've got a lot of respect for that community. I've been part of that community. It's cool that you've heard included. And so one of the QA engineers I've got in one of my teams, she's got the sticker on a laptop. I'm like, yes, yes, I'm glad you're part of it. I don't know how involved you are, but you know, it's amazing. Yeah. And it's the fact there is a wonderful community around your people, whatever your job title is, that come in with these fresh perspectives. And this is what I like to call out about the people in that role. They're not conventional, traditional, write code, ship code people. They are problem solvers. They are looking for different ways of doing things. Recently we had a project which was quite AI focused. I've done Buzzword for you. And I was like, well, where's the QA in this project at this stage? And I went, oh, we're just doing discovery. I went, exactly. We want to make sure that we're doing this properly. Well, it might be a proof of concept, but are you thinking about all those other non functional requirements that, you know, the engineers that are building it will go, I don't worry about it. Mvp.

I love the practice of testing ideas. It's so cheap. Like if you build something or even start building something and investing time and money and people and then do some testing. Well, sure. That's one an approach. But if you test some of those ideas up front, even before any line of code has been written and you've discovered maybe you shouldn't build it or you should build it differently, which has certainly been in projects that I've been involved in, then the value proposition of having people who can see that, think about risk and explore things quite differently is invaluable, especially to a business. You could potentially be so even in them tens of thousands of pounds.

Oh, and that's the naivety of it, I think sometimes when I've spoken to some people more recently where they got rid of QAs from their team, how you know you're shipping a quality when all our engineers think QA and testing. Oh, yeah, sure. So what you've done, Unit test. Right. And that's it. Well, we think about the troit pyramid and you know, what needs to be done where. And I'm like, well, good luck it.

So I'm gonna. I've just made a little note about QAs in teams because I think I would like to definitely touch on that one and get your thoughts about what that looks like. But I just wanted to reflect on the Ministry of Testing because it is a rarer occasion where I might talk to another engineering manager unless they've had worked with or line managed a tester or someone who is exploring that, or even a developer who is very test focused because I've met some of those and they're amazing folks who are very much into exploring, broadening their horizons and they might tell you about Ministry of Testing, but it is a little rarer to hear from other engineering managers. So that's pretty cool that you're aware of that. I think it'd be fair to say that without Ministry of Test, for me personally, my career would not have gone in the direction it had gone. It was. I was very fortunate that they were one of the only communities and conferences and workshop organisers at the time. When I was developing my career, I went to the very first one in Cambridge. I think Rosie, one of the organisers, the lady who. Who had created Ministry Testing, moved to Brighton and took Ministry of Testing there. So then I went to the next four or five after that and I still love coming back to them when I can. I always recommend that they are so much more than just for testers. If you bring a team to that conference, I think the outcome can be amazing because you're not just having a tester or testers experiencing that. Because I've gone to Ministry of Testing and they talk about just good software development and testing and people and leadership and psychological safety and DevOps and everything that you actually need to know about and product design. And it's so much more than just a test conference.

It's not, I think, I don't know the full history. You probably you were there. But it feels like it's very much a grassroots community that forms around a shared passion and discipline that has evolved. Like say the more recent events have included everything from software delivery and building and everything around it. Going back to one of your earlier points, I got wind of, I think ministry assessing through a fellow QA engineer that became a manager as well like me and he's still a very good friend now and he's such a big advocate for everything qa. He's head of engineering now, which is again wonderful to see that a QA engineer has evolved into a head of engineering role because they've got a different way of thinking about problems. Not necessarily. I'll just build it, ship it, build it, ship it, build it, ship it. Point being, it is a very nice to see a journey where these sort of things keep going. It doesn't have that continued passion. You mentioned Rosie, who arranged it. I don't know if she's still actively.

Involved or she's back to running at the moment.

Amazing. And that's really wonderful to hear because as someone who tries to set up communities and keep them going, it's so hard. I know it's quite draining but you know, if you've got that passion for it, great stuff and you've got enough people around you to keep you accountable, even better.

Yeah, they've. And they've really evolved their approach as well from the conferences to workshops to different day events, but also their online learning material you can sign up for. Their pro membership is vast. Like we talked about learning in I think episode two now and we talked about sites that can offer learning to you and they can be great and other sites are available, they can offer you staff on test but not the range that you would get from industry of testing like because it's just so, so vast and so also so specialist. I whenever if I'm line managing testers and they need help and support, one of the first things I would suggest if I'm able to is buy them a pro license. So it's like here is a wealth of material and a community to support you in this activity.

Nice touch point. We're going back to the learning point because if you have got the budget for Those sort of things, offering it and going, look, I highly recommend this from my personal experience in Korea. It was a game changer and I hope it will do the same for you. But for a negligible amount of money and vast amount of resources, it's a real nice way to get people involved. But to your earlier point, don't limit yourself to people that do testing in qa. Just say, look, any engineer could pick up this.

Oh definitely.

Yeah, I prefer them to rather than the QA sometimes because the QA is probably a bit more familiar anyway.

So I think I recall in one of the early episodes you mentioned that you were a test manager, is that right?

I do have QAs and engineer test engineers.

Okay, right. And you manage okay, right, yeah. Is your approach to managing those individuals any different?

It shouldn't have changed too much because I come from more of a front end engineering background anyway. So when I'm managing backend engineers or other DevOps kind of engineers, it doesn't change too much. It's just that I can't provide the experienced answers. It's more like and I signpost you, but I don't actually line manage QA engineers in my current role. They're just part of the teams that I look after by actively checking with them at least once a month on a one to one basis. Is there anything we could do to help? Anything you want to try differently, Anything you need my support with? I am very close allies with their own managers anyway, so we're all sort of triaging how things work and if there are any big initiatives from a QA perspective that the whole organization are looking to do, then then I get early insights to how that's going to go. I can start supporting those individuals a little bit more and sort of give them that full support in the team where there might be a little bit of pushback or hesitancy or whatever. Hopefully that paints a better picture of how the QAs are integrated in our current environments.

Okay, yeah, nice to hear. I'm assuming then that they are line managed by someone else, maybe in the same discipline.

Yeah, literally a QA manager. And that's their manager's job title. I'm an engineering manager. They're QA managers. We're pretty much the same role, it's just different disciplines.

Okay, okay.

But you mentioned earlier about the idea of QA coaches and I think that is the kind of mindset those people are in. Generally the managers are coming in with all the experience and knowledge and people skills to coach their QAs. And engineers about better ways of working. And I like that analogy better than manage people or coach people.

Yeah, I'm so I've been reflecting a little bit recently on evolution is maybe a little unfair and. But it's maybe the easiest way to describe it thinking or at least I can apply it to my own career and see how that sort of role has evolved certainly as a, as a separate role. So just reflecting on me and not making generalized statements about the industry. So starting off in as a tester and I would be certainly towards the end of a process, it wouldn't be embedded in a team, likely separate from the team that does the work as well. So handoffs, none of the good stuff there. But very. I guess there would be particular things that you would be looking for. There might be requirements that you were testing against maybe that they, that there was a workflow or a release plan that you were working through. So that was certainly a flavor. And then there was the move to have actually people work together to build a thing. So let's have everyone in one space. And then you went to smaller iterations. Now in some of those, I think the first instances of those sometimes you see instead of testers getting involved at the very end, they're still at the end. They're just the end of the sprint. And so you've reduced the time but it's still happening with an end flow because teams get more mature. Oh, we now have this, we have this person who has this capabilities and skills. How do they use? Okay. And you have to get used to what that looks like. And I think over time you find that the testers start becoming involved in the entire design concept idea generation, all the way to delivery and end of life, even sometimes as well for a product. So the entire life cycle and testing, testing early and even instead of waiting for something to test, I think the industry and or certainly referring to myself started shifting to well, I don't have anything right now, so what can I do? Can I plan? Can I test the ideas? Can I start mocking stuff up? Can I just paper based and test something out of a mock up and get feedback? So we started thinking about what we could do at the same time. And I think at that time you then started introducing the pairing and mobbing and ensemble element to, to the role. This is where I think you started the quality. So the coaching aspect started coming in where you weren't the sole person who did the testing. You were now a expert or a specialist in that area, but you were enabling others. So that you weren't a single point of failure to do more of. So I think then that role sort of started evolving. I think there was definitely a point before that where. And I think I could see how this had gone where testers might have test cases or test scripts like do this, this and this and this. And you repeated that over and over again. And someone said, why don't we automate that? And they did. And they wrote playwright tests. And then you had automation engineers, which certainly serve a very useful purpose. My preference is that that type of testing is best done with the developers and directly, directly with them rather than having someone separate write automated tests. For instance, I think Microsoft at one point in their history had testers write the unit test for developers because the developers were too busy doing other more important stuff.

That's more important than tests.

I don't know, but I think it was like, oh well, there was. So we had testers writing unit tests, which is for the. I guess after. After the code was written. I'm not too sure. It must have been afterwards. It wouldn't have been tdd. So that.

That comment reminds me though when of. Of a. Of a team I worked in once as an engineer. We were sitting with the BA and there was. He said, I ain't writing your effing test for you because I asked him to do it in GK or something. Look, I'm not asking you to write the test, just the acceptance criteria and yeah, freaking doing that job for you.

I think there's definitely been some of that in the industry. And then I think the automation engineer was an evolution at one point that probably moved more into maybe DevOps focused engineers, for instance, that sort of pipeline.

Possibly where engineers are more engaged and involved, like the actual people building it, not just the people that are deploying it.

And then we sort of now settling on that sort of. Or at least giving it a name. Because when I was a tester I paired ensembled and I coached others. No one called me a quality coach. But we are now putting a net name towards the. To the action that some people are doing. And I think it helps set an understanding for a team that we are here to help and support. And I think that sometimes a name can help with that direction.

They can help. I think I'm very nervous about giving people labels of what they do on what their outcome is. But I know you. It's very explicit about what they actually do in their day job, not necessarily what you're getting out of them. I think every industry is different in that sense it's not a catch all.

So the you did mention an interesting point at the start si and that was about teams without testers, the formalized like role with a person. And I'm really curious because this, this happened and it happened. There was a Google test conference and there was a really famous infamous talk entitled Test is Dead. If you haven't seen it, let me know, I'll send you a link and maybe we can also put it in the notes.

Yep.

And it's a good watch and it was meant to be a talk to insight debate and it certainly did so and probably did for many, many years afterwards. Now it's fair to say the test isn't dead right now. What the point was that the test is changing and that was the point they're making. I think it may have been maybe 14, 16 years ago when Google did this and their point was we can't test in the way that we used to. We need to change. And I really enjoyed it for a conversation piece it got people quite worked up because they're worried about losing their jobs. Naturally with any evolution people don't lose their jobs, their jobs just change and they adapt. So yes, I think that has. It's not a new theme and it's been a theme for a while but in the evolution of the role one thing I have noticed is less testers I think would be fair in the industry and or a decrease, I don't know because I have a very small lens. So maybe that that's not fair to say. But I think with the evolution of the role needing a body of or a number of test engineers running the same test scripts over and over again has certainly decreased as automation has come in and we've improved.

It becomes like an efficiency thing then, doesn't it?

It does, yeah.

Do we need 10 people doing a lot of manual regression testing when we've already got the automation configured to do most of this anyway? We're when we can get a machine to do that or now even AI which is again an evolution of the role, not just saying a human triggers an event on a pipeline.

And I'm certainly, I'm curious to see what you think around a dedicated role. So I'm all in favor. I'd imagine you might be s that the capability that testing itself as an activity, as a practice is important and we should at some point or maybe should have defined what we mean by that. And for me that could be many things but it's really around the discovery of unknowns because that's where the risk lies and where the value of testing can really shine. That as a skill and capability is great, but do we need dedicated people? Because you highlighted that maybe some of your teams or people that you work with or have worked with don't have that dedicated role on the team.

Yeah, I will put an asterisk to that one. It's generally in smaller startup environments where they didn't realise they needed QA and then eventually go, oh, now I need someone that's dedicated to this role. For the early stages of a tech startup, you could probably get away with some automation and some typical traditional unit regression integration, whatever. Testing biggest takeaway I think was when I, I think I talked about in previous episode when I worked in the experimentation team, the AB MVT testing team. I joined that there was three of us, front end engineers, no QAs, shipping stuff straight to production. What can go wrong? Lot, as you can imagine, it wasn't a mess, but that it was clear to me there were gaps in the way that we built and released things. And I very quickly put a business case together going, we need a QA in the team to help us. We're shipping multiple things, a sprint. And we're, we're shipping our own, we're testing our own thing, we're not sharing it out. I'd rather have someone with that dedicated mindset and capacity and behaviors and disciplines to do it properly with some proper test plans or put some automation in place where we can. So that was the alarm bell for me in the early start of my career and ever since then, I've always encouraged, we have integrated QAs in every team that I work with. Rather than the handoff, which you mentioned earlier, I've seen that rarely work well. It's typically, oh, we found some bugs, fix them, chuck them into the next sprint. Oh, come on. Really? This is not, it's not efficient use of anyone's time. The moment you integrate one of those handoff QAs into a team, it's a quicker lifecycle, like you mentioned earlier. Oh, you just test it. Then if a sprint rather than if a delivery. Yeah, but again you just go, well, hang on, why are we doing that? Can we just say you're part of refinement, you are part of design and discovery, then you just do a little bit of regression because you like it or you're better at that than bots are or the machines are. But where can we get the engineers to write all the automation?

So you would, would that be fair to say that if you were building a team for most situations that you would want to include that test run.

I think that's my maturity over time as well is the naivety of what do QA and engineers and test engineers actually value bring. And it's immediate. When you go, well, you're shipping broken stuff, come on, that's, that's the instant value. But the extra skills, behaviors, mindsets, experiences that traditional software engineers don't necessarily have.

Yeah, I think for me it the same would be true. I'm trying to challenge myself to think what would need to be different for that to be the case. Well, I guess it could depend on the product and how much experimentation is needing to be done. I think a start is probably one context where maybe you can afford two engineers and that's it for your Runway. And at some point you decide to expand the team the capabilities and that's when you might think about it. Definitely.

This is where I think things are evolving again because not all engineers are writing code now. They're writing prompts, they're writing PRDs for AI to generate the code. And I feel like we're getting to a point now where a good engineer could sort of get an agent to write the code well and you've got a QA dedicated person that's doing that part of going, well, hang on, before we build it, what's your case look like? Hang on, before we, we spec it out, how are we going to test this? And you're instantly getting early feedback before an agent tries to write a bit of code. That's probably rubbish by the way. But you at least sort of go in, we're thinking QA from the start, go. And you can have two orchestrators. Let's say I've got a lead engineer that's writing an agent code thing. I've got a lead QA that's writing agents to do some testings for me. And everything that we ship has got human interaction. Not necessarily Devin, but they've got human sign off and written. That's where I can see it going. Not there yet at all by any stretch.

That would be interesting. I think certainly the part, the thinking about what a team might need is when it's quite well defined and it's not going to change. I think maybe there's an argument for, for not needing the role so much or a dedicated role, but I don't think that's true for many products that are being built right now. Like change and uncertainty is just in their nature. Um, yeah, so if I was Building something and it. And I could spec it out 100% and it wasn't going to change from that and we were going to include everything. Maybe. But even then I think I could just build the wrong thing for the. Like I could build a thing, but it. It might. It might function fine but not do anything that would be valuable.

I've been funny, it's not that long ago we'd be specking stuff out to be outsourced and you get it delivered and it's completely wrong. That's a human doing it. How's an agent going to be any better? And you need someone involved in that process to catch it way much sooner than that.

I think the. Yeah, any product, anything that needs discovery. I think it also risk. So if I was building a medical device pacemaker, Right. Would I want to employ people who would ask and explore quite unknown things? Right. Yes, I would definitely. I would certainly heard some great stories about testers being in those spaces who are really, well, frankly, have helped save lives by. By just querying and questioning. There's a great quote.

That's a key word though. It's the querying and questioning that you don't. Machine humans are wired that way to challenge things and go, why? How. Agents won't do that unless you specifically tell them to do that constantly.

I remember, I remember there's a lot of teaching you can do to get better at this as well. Because you can. People can ask questions, but you need like it's actually a very deliberate approach, like from a tester's point of view. And it can. Well, it should be and can often be from certainly from more skilled testers. They all describe how they approach thinking and querying and questioning and should be. Rather than just like, oh, I don't know, I just wondered what would happen when I did this on the keyboard. Like it's. That's helpful in some regard, but it's more helpful you can. If you can actually explain the reason why because then it's repeatable and it's understandable and. And it's not just, well, luck like you definitely want to remove that, I think from the equation. There's a great quote from Martin Fowler. Very developer space. Yeah, exactly. And he has a great article on exploratory testing, for instance, which is a part of testing that I really enjoy. And he said I would consider it a red flag if a team isn't doing exploratory testing at all, even if they're automated testing was excellent. Even the best automated testing is inherently Scripted testing, and that alone is not good enough. And this is someone who knows what they're doing from a developer point of view. Right. And some of the great. Seb Rose. Okay. And I think he did bdd. Yeah, I probably got that wrong. Sorry, Seb, if you're listening, he won't be the. Yeah, he, he did a brilliant talk on a book called Explore it by, I think, Elizabeth. Elizabeth Hendrickson. He was talking about exploratory testing. And this is someone like, when you hear developers, it's. I think it's really powerful for people who really are good at their craft from a developer perspective, talking about the value that they have seen in approaches and like exploratory testing is just really powerful. I remember what. Yeah, I think it was Agile Cambridge that Seb did this a number of years back and a few other conferences. So. And of course Martin has talked about it and so has other people as well. So moving beyond the sort of test community into others is. Yeah. Just really powerful.

Yeah. And actually, I just want to look back to a point you made. In that point you mentioned, you touched on BDD as a framework. Business driven development, isn't it?

Yep, yep.

And then you've got tdd, test driven development, which most engineers are familiar with. Not all, unfortunately, but there are all these frameworks. And the point I want to get across is these frameworks would not come out of AI or tech. These need humans to design and come up with a concept or a framework that others can replicate and reuse, find valuable and useful. We need people to continue doing this because these have always been evolutions on previous versions anyway. I don't know where this is going to go in the future. And this is why I think modern QA is almost exploring how we test rather than what we test. It's always thinking about how can we make our job easier. It's like an engineering manager role in a sense. How can I make my job simpler? I'll become less of a bottleneck. I make sure that I'm empowering others to do things better. I'm bringing my action, my experience, my knowledge, my intrigue. That is where I find a good QA can bring extra value to a team because their mind is not the same as well. No minds are the same, let's be honest. But the discipline comes with a completely different set of tools and skills.

An old colleague of mine wants to subscribe to me. We were talking through, like, what might need to be true for a team and even if they knew a lot of things What a tester or a quality coach or a quality engineer can give a team is it's effectively a gateway to unlocking your unknowns. Right. If a team knows what good might look like, I think a quality coach can come in and add on top of that layer.

Is it even better if coach.

Yeah, it can really widen a group's scope and thinking. And it's around the unknown. You ask an engineer, a developer, around testing, and depending on the developer, they will list a number of things and some will be more than others, but it won't be all the things. And I think a quality coach can really help open that door. And a quality coach or a quality engineer or tester, they won't know all the things as well, but more importantly, they'll know where to look and they'll know where to get the support. And that, I think, could sometimes be the important thing as well.

Again, another very specific example for me at the moment. The QA community we've got internally in our organization are tight. They all know each other so well, they've got high respect for each other, they challenge each other a lot. And what I like to see from that group as well is the fact that they invite each other to their team sessions and conversations because they are going to bring different perspectives, which is again, another quality of a Qwikyua person.

I, when I used to do more into that role, I used to love that as a. As a way of working, pairing, swapping and pairing up with other quality engineers across teams. You learn so much, you learn from other. Another team's context, another team's approach, but you bring in your own. And it's a great way, it's a really great way of leveling teams up. And it shouldn't just be for quality coaches or quality engineers or testers. Right. The more we do it as just team members, the better. Definitely.

It's something I'd like to do more of as an engineering manager as well. I don't need to go into every team and sort of go, look, I'm going to fix the way you work. That's far from what I do, by the way. But it's more like, I'd love to see how you do X. So I might take something back to my other teams and so you should try this, go and speak to this team, they've got this bit nailed. Or actually take what we do to them and show them how we do it and can put up bits together because that'll be even more valuable for all of us.

There's a model that I'm gonna say I invented, but clearly I wouldn't have done and I would have just remembered it from somewhere else. And that was around describing team movements or individual movements as like visitors or travelers. So a visitor might stay in a team for a period of time. They might come in to help them with a body of work. There may be the team is doing more on observability and have no idea or haven't done this before. They have an engineer from another team who really knows what they're doing and they'll come in and they'll work with that team actively on that project to visit and transfer that and to help level them up. So that's the sort of visitor where you stay for a while and then the travelers moving around. So this is short term engagements where you might just be in for half a day, you might just be joining for a workshop, you might be running a workshop. And so you're moving around a bit more or able to move around a bit more and you're traveling around. And I really like those two approaches to describe those type of engagements that I'd love to do it more where I am at the moment. I think sometimes that's a little bit harder. But I'd certainly love to get in a place where more people can move around because I think that's not only where we spread the knowledge around testing. We just spread knowledge full stop.

I like the model and I definitely.

Want to send you, I'll send you an infographic, so.

Oh, and we can put it in the show notes as well. I don't know, have we covered most of the angles you wanted to go with today? Actually into that point, I do have.

One thing I'd like to finish with. That's okay. I was asked to help a company, which I agreed to do and it was around how can they be better at testing? They had experience, the type of testing that I might describe as very good, a sort of quality engineer, very experienced tester, but also very good at coaching and enabling others for great exploratory testing. Great with all parts of what good engineering looks like. A very rounded engineer, but very test focused. And they hadn't experienced this before and they wanted more of it, but they couldn't hire. So this was the problem, like how do we do that thing that we've seen you do but without hiring you? I was like, well, you could just hire me. That's. That would be easy. But it was an evolution for them. What we did. We, we, we Worked out the sort of why, but we, we started with, well, actually you're probably already great at some stuff like don't have to reinvent things if you don't need to like. And it may be that some of your engineers have heard things, maybe they've heard around a particular form of testing or an approach or maybe they've done it in their last company, maybe you're not doing it here. But at least start with things that you know or have heard. Right, because that's, you've already got a wealth of stuff that's going to take you a while to learn. So start with that but also work out what you're good at because there might be an engineer in the team that's done this before and just you don't know. So find out what you're good at and then start from this place because that's a great place to, I think to encourage experimentation. Because then people are like, oh I know this, I've done this before, let me help. Rather than just like here's some brand new stuff and everyone's like, I don't get it, it's hard. So yeah, start with what you know because that helps build patterns, it builds learning, it builds going back to the learning episodes, it builds muscle memory around experiments and improvements. So that's all great. And then you can have these like, I wonder if we can do this. And then they become common patterns and then they, from an experiment come common patterns of working. So that's all good. You start with what you know, you amplify the wins. So people get excited about learning. And then the tricky bit is like, how do you introduce unknowns? Because I'm not going to tell them where they are. They need to know what that is themselves. Right. So there's a couple of heuristics that you could try to think about this and that is one could be the agile testing quadrants. It's a two by two matrix with technology facing on the bottom, business facing on the top, critiquing the product on the right and guiding the development on left. There's different types of testing or approaches that fit in in that. So you might say what am I business facing? Critiquing the product tests. Well, they might be observability testing in production. What's my technology facing guiding development tests? Well, they might be static analysis unit test for instance. So you've already got some heuristics that might expand you into your unknowns. And then of course we'll go to go to a Ministry of Test Conference. Right. That's a great heuristic to learn what you might know and just start with building into those unknowns. So it's about how can we find what we don't know and where might we go and find places to support that learning. So I'll share the 2x2 agile testing quadrant as well after the show for you. Si. So there's certainly a approach, but I think that gets you some way. But I'd still hire a good tester, frankly.

I'm going to fix it for you. It's probably a good exercise or a workshop to do in a team straight away anyway. It's like, what are we doing well already? Or what do we think we're good at already? And how do we improve that part before we start exploring bigger, more complex, scary things that we might not even have the capacity or brain power for? Because again, got to deliver all these things while I'm changing the way I work, which a lot of teams do struggle with, unfortunately.

And if you have a team and everyone like in that team, your company isn't the first company. They've been, they've already worked in other companies. They all have already seen some different approaches. So and just asking that question, you might have an engineer say, yeah, I remember where we would pair up with the, with the tester and we would do this thing that they refer to exploratory testing. And I really enjoyed it. And you're like, okay, well now we have a word to a thing that you enjoyed. Like, let's find out more about that. Like, so there's definitely a way of not exploring what you know, but also what people know that might not be practiced already in the team. And then that's a great building point with what you don't know or more importantly, find ways to discover what you don't know.

Yeah, and look at those sources. You mentioned a few already, but there's so many out there, you know, you don't limit yourself to online. You can go to a meet up, you can go to the Ministry of Testing, you can go on LinkedIn and start scanning groups over there. I think the point of this sort of area, what we're talking about is, yeah, if you are a team without a QA dedicated person, there are ways you can introduce better QA models and frameworks. But I'm never going to say you don't need a qa. I'm just saying there are ways to make your quality better in some shape or form as a collective or as individuals. As well.

There's definitely always more that you can do if you don't have a particular person in your team or a particular capability, you can level up and learn. Yeah, definitely. I 100% agree.

Nice. But yeah, I think we've covered the broad topic of I think we can go.

I was really mindful of not going into a lot of the depths, especially as it's been a body of my career. So I wanted to make sure that we. We covered on just a little bit of the history, a bit of experiences, our own personal thoughts. I think is what this podcast is about. Getting to know what you think and.

Let people go off and think about it a bit more and come and ask us questions and ideally channel maybe we can do it.

Well if we have some more dedicated questions or feedback and people would like an episode in the future where we go into a lot more detail in some of this stuff. Yeah, we can certainly do that. We make sure that we share some notes.

I'm now live. This is my current thinking because we're recording a lot at the moment. We're putting them out occasionally every couple of weeks. I know we're getting going to get some comms later down the line. I'm thinking we just carve out one of our episodes. It's all about Q A mode and we can get make sure that we've got enough to go through. Have we had any feedback recently? Actually I think you mentioned someone had sent us some feedback.

We definitely have some feedback now. It's going to be hard for us to act on that feedback fair episodes pre recorded already before the feedback was received. So episode two which is out and this particular episode will have less interaction with their feedback. So I'd certainly asked around the quality of the sound which was useful. I think the feedback was that certainly we could come with an idea to the audience around what we might be talking about certainly in up in the beginning and I think that certainly lends itself to me being a little bit more prepared and what we might cover in a session. Sometimes we just explore things as they come up and I quite like that. We discover different things and we decide to explore it. Rather a formalized pattern. But I think we could certainly inform people an idea of what to expect for the 45 minutes. That could be done retrospectively as well of course after the sessions.

Yeah. So a few podcasts do that actually rather than doing it oh, this is going to be a learning objective. It's more like ah, before we get into this, this is what we cover yeah.

And the other. Some of the other parts was like, as we. We've been, I think, very open with our thought process and have recorded that and have certainly put that out there where we haven't been sure about what we might do or the cadence. And I think there were certainly some suggestions around. Well, actually, we could take that offline. We don't have to have that. I think certainly for us, we've been. Well, we've just gone into it, we've hit record and what, what, what? Yeah, what we've done is certainly. It's just like we've been, oh, what are we gonna do? What should we call it? Are we gonna do it here? And yes, I think in time that stops because we actually become. Well, we know where it's gonna go, we know what it's going to call, we know our cadence. So I think they. They are certainly early episode learning points, really.

It's wonderful that people are actually sending us feedback.

So I love this. It's really. It's really important. Oh, the other piece of feedback I had was from my mum, who listened to our first and second episode and said it was. I said, did you. Did you get much of it? Did you make sense? You said, it was just nice to hear your voice. And I thought that was a very pointed reminder that maybe I should ring her more often.

Yeah. Before I ask my mum as well, see what she thinks. I think I heard someone say that once and went, I know. I know what you do. I mean, it's taking you that long to work out what I do.

I enjoyed the. Thank you for letting me bring the topic today. It's. It's always an important one for me. Tessa's quality folk remain dear to my heart. It is the most fun I've had as a career, definitely. And I recently put my tester hat back on to test an AI chat model and absolutely loved it. It was. I just forgotten the. The, like. The experience of like. Like thinking about how I might challenge the software, what might I do? What were the vulnerabilities, exposing them, Probing and. Yeah, it was just great to get back into that. And I definitely miss that exploration side and I have a lot of love and respect testers.

That's why I'm glad you bought it. And I could tell from what. The way you got into it. It's like, this is definitely your. Your passion area. Let's push it. But thank you for bringing it and I'm hoping anyone that does listen got something out of it. And going forward, we'll make sure that you know what you've got you're buying into for the next.

Yeah, we'll give you a head. Maybe we'll put this is what you're going to get at the start.

Yeah, we might take turns doing that. Yeah, wicked.

Thank you, sir.

And anyone that does want to send us any more feedback or comments, you can find us on LinkedIn. I will sort an email address out. I think actually going forward, make it a bit easier for people. We can share that inbox, but, yeah, appreciate it and we'll catch you next time.

Thank you, Simon.