Strategy: Test X Quality

Welcome to episode 136 of the Testing Peers podcast.

In this episode, David, Chris, Russell and Tara dig into a question from #PeersCon25 speaker, Stuart Pates: what’s the difference between a test strategy and a quality engineering strategy?

The peers explore:

• Whether strategies are rigid documents, living guides, or something in between
• How context drives whether you need a test strategy, a quality strategy, or both
• Why language and labels (“test” vs “quality”) can help or hinder collaboration
• The role of purpose and value in defining strategies that actually work
• Strategies as empowerment tools versus “one-way to do things” policies
• How to avoid strategies becoming shelfware and instead keep them living and relevant

As always, there’s plenty of banter (including revelations about everyone’s oldest open browser tab!) before diving into the topic.

We’d love to hear your thoughts, what does strategy mean in your organisation, and how do you approach the balance between quality and testing?

#PeersCon26 Tickets for the event are now live too, starting at £15 until December 2025, when they increase to £30.
And as always, we are looking for sponsors to make this event the success it has been for the last 2 years, get in touch if interested

Twitter (https://twitter.com/testingpeers)
LinkedIn (https://www.linkedin.com/company/testing-peers)
Instagram (https://www.instagram.com/testingpeers/)
Facebook (https://www.facebook.com/TestingPeers)

We’re also now on GoodPods, check it out via the mobile app stores

If you like what we do and are able to, please visit our Patreon to explore how you could support us going forwards: https://www.patreon.com/testingpeers

Thanks to our sponsors – NFocus Testing.

nFocus are a UK based software testing company. They’ve been supporting businesses for 24 years by providing services that include burst resource, accelerated test automation, performance testing and fully managed testing services. In 2021, they launched a Test Automation Academy to create amazing testers and they’ve now created jobs for 48 people in our industry in just under three years!

nFocus were a big part of PeersCon in 2024 and 2025, really grateful for all they do to support the Testing Peers.

www.nfocus.co.uk and info@nfocus.co.uk for anyone wanting to get in touch.

Transcript

0:01: Hello and welcome to the latest edition of the Testing of Peers podcast. 
 0:07: Tonight we're gonna look at strategies, both in terms of quality versus test and the differences between them. 
 0:14: And we'll dive into that a little bit later. 
 0:15: But tonight, we have a couple of old guard ready. 
 0:20: We've got Chris. 
 0:23: Ahoy. 
 0:24: Russell, not sure I like being called old. 
 0:27: hello, but you're a guard. 
 0:30: So that that is that better? 
 0:32: I don't know. 
 0:33: And finally what are our semi-regular people, Tara. 
 0:37: Hello. 
 0:39: Thank you for adding guard onto that. 
 0:41: I thought you were just gonna call us old. 
 0:43: , we are very pleased to be sponsored by EFocused. 
 0:48: EnFocused are a UK based software testing company, and they've been supporting the business for over 24 years by providing services that include first resource, accelerated test automation, performance testing, and a fully managed testing service. 
 1:02: In 2021, they launched a test automation academy to create amazing testers, and they've created jobs for over 48 people in that time. 
 1:11: And I think that's really amazing what they do for the industry. 
 1:15: If you'd like to get in contact with them, you can look at the website at enfocus.co.uk or contact them via email at info@nfocus.co.uk. 
 1:27: Right, before we get into the main part of the podcast, we always start with banter and we have King of banter, Chris, to show us the way. 
 1:37: He's even got a crown. 
 1:39: So, yeah, he's been anointed. 
 1:41: Well, this day it was a crown that looked amazing, let's be honest. 
 1:46: Not that you'll ever see it because we're not a video podcasts. 
 1:49: Thank you for that kind introduction, David, such as I am. 
 1:53: I wanted to know, friends, last time I did this, I asked you to get your phone out and tell me the last song that you were listening to. 
 2:03: Now, in that same vein, I would like you to go to your phone, go to your browser. 
 2:11: And tell me the oldest open tab you have in your browser. 
 2:17: By the way, Chrome archives them, so, you know, you might need to go to your archived brands. 
 2:22: Other browsers are available, I don't use Chrome. 
 2:25: True that. 
 2:26: Well, mine's easy. 
 2:27: Do you want me to go? 
 2:28: Yeah. 
 2:29: Mine is a website called Roadcraft, and it's about kit car engines and gearbox. 
 2:34: And I have no idea how old it is, but I was buying the engine probably about 3 years ago. 
 2:40: No. 
 2:41: I My oldest tab, I'm very impressed with me for this, is only 21 days old. 
 2:50: Your phone die? 
 2:53: No, I'm trying to get better about closing everything, cause I'm usually the queen of 8000 tabs open on my desktop. 
 3:00: And on my phone, and it's, it's terrifying way to live. 
 3:06: But I was looking up sewing patterns, so there you go, not as scary as I thought. 
 3:13: David's still scrolling, this is, this is bad. 
 3:16: Yeah, hang on, how far that are we gonna go? 
 3:19: No, we're not going, no, I don't use it very often, that's the whole problem. 
 3:23: Pre-internet. 
 3:24: So, what is this just you trying to figure out how to use your phone? 
 3:28: Probably. 
 3:29: Oh God, it is going quite. 
 3:31: I was looking at my, it was obviously quite a long time ago, I was looking at my Gmail. 
 3:36: Cos I didn't have the app. 
 3:39: You know when that was from. 
 3:41: Mine is from. 
 3:44: The last time I saw a keynote by Alex Schluderbeck, that's October. 
 3:50: So 10 months ago, she mentioned. 
 3:54: A blog post called Ifs Areiffy, and so I'd opened it and I never closed it. 
 4:00: Did you read it though? 
 4:01: I think it's quite an interesting one. 
 4:03: I absolutely, but I kept it open because I figured I'm probably going to want to refer this, reference this, and little did I know the next time I was going to reference it would be 10 months later on a podcast. 
 4:16: Excellent. 
 4:18: That was a nice quick banter today. 
 4:20: The topic today is strategies, quality versus tests, and this comes from a message that we got in earlier today. 
 4:28: Chris, do you want to explain the context behind it? 
 4:31: Yeah, so friend of testing peers, a fellow peer, and, indeed a taker of workshop at Peers Con25, Stuart Pates. 
 4:44: Who indeed got in touch and asked a question to me. 
 4:50: He said, have the peers discussed the difference between quality engineering strategies and test strategies? 
 4:57: He filtered through a lot more context, but that's kind of the opening gambit. 
 5:04: And I thought, well, we have discussed strategies for testing. 
 5:07: We've discussed quality engineering. 
 5:09: Talked about test plans and stuff, but we've never talked about when should you do one or the other, what's appropriate, what contexts are there. 
 5:17: This is a thing that I know a few people have been looking at, both in terms of in their organisations, QE transformations, third parties, other sorts of areas, large and small. 
 5:29: So, what do we think, team? 
 5:32: It's such a contextually driven question, depending on your org and your team and your goals. 
 5:42: I love the question because I think it gets asked a lot. 
 5:45: In fact, I'm working on educational content about this topic right now, which is incredibly hard to do because so much of it is, it depends. 
 5:58: It does. 
 5:58: Maybe we want to just discuss perhaps what do we think a test strategy is and what do we think a quality engineering strategy is. 
 6:08: All right, so I'm gonna pose the question to you. 
 6:11: Do you think of test strategy as a strategy about test or the actual documentation of a test strategy? 
 6:20: They what? 
 6:22: Yeah, I'm not sure what the difference is. 
 6:24: Well, so in my mind, when you talked about the strategy that you're going to take, most of that is just like a mental exercise. 
 6:32: And we can talk about, oh, it might be best to go over here and it might be best to do this. 
 6:37: But when I write an actual test strategy for a client, it is one step shy of being written in stone. 
 6:44: It's solidifying those requirements. 
 6:47: And our goals, what tools we want to use. 
 6:51: And so that way, when somebody goes, Well, I didn't know, you can go, but it was written down over here. 
 6:56: And it wasn't just a thought exercise. 
 6:58: An unchallengeable rule of everything. 
 7:01: It becomes the de facto decision rather than an adaptable thing. 
 7:05: I think I get what you mean a little bit. 
 7:07: It depends on the context, because I've been in worlds, I know it's, it's going to be Ordering that and it's worlds where they are. 
 7:15: I've had to use them as policies. 
 7:17: I think that's what I would call it, as in this is how you have to do things. 
 7:20: You have to do it like this. 
 7:22: This is the high level, but it is the basis of which you have, it's the boundaries in which you have to work under. 
 7:28: And I've also done them as more abstract conceptual ideas where this is what we're trying to achieve, this is the direction we wish to travel in, this is the priorities, these are the focuses of which we want to do. 
 7:37: These are the. 
 7:38: Core techniques we think will help us get there, but there is a culture that is part of that strategy of change and improvement, that's within that same strategy document, if you see what I mean. 
 7:49: The one that you're talking about, I consider more of a kind of a policy we have to follow as people than the strategy. 
 7:55: I have had to write those. 
 7:57: I won't pretend otherwise, and they've still called the same thing at the end of the day, but it's almost the opening sentence of them is. 
 8:04: You must follow this. 
 8:05: the other opening sentence, the other one is we want to work in this direction and work in this style to come to this outcomeing goal in testing. 
 8:12: And I would say that you probably have the same situation for testing as you would for quality engineering, quality space, that you could write something as a de facto guide, rules, how to, if that makes sense. 
 8:25: Or you could do things which I would call more of a true strategy, which is a bit. 
 8:29: About how you're overall going to achieve the overall priorities. 
 8:32: How you're gonna overall do things with resources, how you're gonna split things up, how are you gonna tackle problems? 
 8:38: How are you gonna go about it at a high level rather than nitty gritty, thou shalt use selenium. 
 8:45: Yeah, type level. 
 8:46: Thou shalt do automation, might be in the strategy. 
 8:49: Yes, right. 
 8:50: Unless there is a good reason justifiable not to do it because it's gonna be thrown away, blah blah blah. 
 8:54: But it shouldn't be too specific in most cases. 
 8:58: But again, I've had to provide documentation to a third party to meet their approval that required it to specify tools and resources explicitly rather than implicitly. 
 9:08: So it, it can depend on what the. 
 9:11: Consumer need is. 
 9:12: If I had to choose, it's more abstract and it gives the freedom, certainly in agile context, to do things more adaptable. 
 9:19: But I've not always worked in pure agile. 
 9:21: I've worked in waterfall, crazy worlds, all sorts of different things, and it's not always that clear cut. 
 9:27: I agree with the the context switching and or the context setting. 
 9:30: And putting the level in. 
 9:32: I, I wanted to pick up on the difference, as I understand it, between quality and the test strategy. 
 9:38: And I think the difference is that the quality strategy is much broader than the test strategy, because at the end of the day, it should be everyone in the team's responsibility for quality, and so therefore you can. 
 9:51: Go broader in terms of quality and talk about, almost talk, include the sort of dev cycle as part of that. 
 9:58: Whereas the testing is much more of this sort of slightly lower level of how you're going to then validate or whatever or verify. 
 10:06: Russell, you're looking at me a bit quizzically there. 
 10:09: I'll come in in a second, don't worry. 
 10:13: That's really what I was gonna say. 
 10:14: it depends on interpretation, I guess, because I've seen a lot of test strategies include quality assurance, and that often does include the development side of it, the levels and expectations of the code, not just the thing. 
 10:28: And it often, and it depends on the rigidity, what process you're following, what definitions you're following. 
 10:33: If you're following ISO standards, if you're doing X, Y and Z, if the test strategy for the people called testers, which often becomes a de facto understanding of it, or people providing the role of testing, so the activities that get you a test result, but it depends. 
 10:48: If it is the goal of quality based software. 
 10:50: Which is originally what test strategy canon was trying to get to. 
 10:54: Those sort of original forms do normally incorporate sort of quality assurance, which goes into the CICD type processes and all the other things that you do, the, the sort of three amigos, all that sort of stuff, which wouldn't be our test per se, but actually it's all part of the quality assurance process to make sure you get out with it what you wanted. 
 11:13: So the lines are incredibly blurry, I guess is my point. 
 11:17: But I agree with the, the context of what you're saying that most people will probably see a test strategy is focusing on what the testers are doing, which therefore would exclude the activities that are predominantly dev or BA or somebody else. 
 11:29: But I don't think it had to be that. 
 11:30: I don't think that was originally the goal of it. 
 11:32: The test strategies is the way they were kind of defined. 
 11:35: I think that's what's become the assumed expectation of them. 
 11:39: And when I've been asked for them by delivery managers and the like, they assume it to just focus on the testing. 
 11:45: They're generally surprised when I incorporate how we as a whole team deliver things, cos I, I must admit I, I would call it a test strategy, but right, quality strategy in my head. 
 11:54: It it's an anchoring linguistics. 
 11:56: isn't there? 
 11:56: There is. 
 11:57: People hear a word like test and they go, not my job. 
 12:00: Even where we've discussed here already, the things that are very important across not only the software development life cycle, but the, the product development life cycle. 
 12:10: The way I've tried to encapsulate my envisioning of quality engineering is kind of engineering from. 
 12:20: Design through to release done quality and therefore, my interpretation of a quality engineering strategy would be inclusive of all of those elements, how they intertwine, where there are dependencies, who has responsibilities, how we want to approach things, what good looks like, models and heuristics, all those little tidbits that we've all talked about. 
 12:44: But still, The language, the use of the word quality engineering and it's perhaps broader adoption by testers again, does that once again anchor people against? 
 12:55: We're gonna ask that as well. 
 12:56: And an engineering strategy done good. 
 13:00: If you start calling everyone quality engineers, does that have exactly the same effect? 
 13:03: It's the quality engineer's responsibility. 
 13:05: That's the document for what they do. 
 13:06: It'll be interesting to see, wouldn't it? 
 13:08: I remember in college kicking and screaming. 
 13:10: Against the word engineering, because it sounds so definitive. 
 13:16: I really liked when the idea of quality advocacy and quality coaching came around because that sounded much more strategic to me. 
 13:24: And like it would have an impact than being that last minute test and the last minute step and a strategy where you're, you're just the test. 
 13:34: You know, it's just the testing. 
 13:36: And it felt a lot more encompassing to be able to say, OK, I'm gonna go sit at this table and we're going to talk about the definition of done and what that looks like and who's responsible for what pieces, and including much more of that holistic process when I can be an advocate from Go rather than the gatekeeper at the end. 
 13:56: I'm gonna avoid going into the checking, testing debate. 
 13:59: degree, but is a test in itself not something that's used generally to verify or check something meets an expectation, hypothesis, an expectation, it doesn't matter what you might want to call it. 
 14:12: So, in effect, the test then is quality. 
 14:15: It is something that's determining the quality by default. 
 14:18: So, again, if we go into semantics of language, which, you know, we tested, we love semantics to a degree, we shouldn't. 
 14:24: I, I just, but it's, it's all interpretation. 
 14:26: I think it all comes down to what's in it. 
 14:29: What is it trying to achieve and what's the expectation of the person, because if it is just trying to set the expectation of how you do a test. 
 14:36: And it could be done by a developer, a tester, a BA or anyone under the sun, your customer, even it has a different interpretation to if it's done by the whole team. 
 14:45: And it ultimately comes down to is it a strategy for everyone or just some parts of it? 
 14:49: Is it the whole team, or is it just part of it? 
 14:52: So one thing we haven't talked about is like strategies can be at different levels, organisational. 
 14:57: Project, programme, team, and things like that, and often it's about just trying to think who you're trying to influence. 
 15:03: The bias of the documentation is about trying to get it out there. 
 15:06: Call it just QA strategy, calling someone just a tester, any of those things is biassed, but getting out there and explaining what it means, explaining the content, what is the goal, and it's a strategy. 
 15:17: If you can't do a one liner of its purpose, it's pretty much pointless. 
 15:21: You know, the strategy of the quality strategy surely is about helping the whole team build a higher quality outcomes. 
 15:27: Strategy, test strategy might be the testing, or it may be the improving the quality of testing to provide better quality outcomes. 
 15:34: But it should be able to have a snappy-ish one line that you can explain to other people quickly in an elevator, in a lift, depending where you are in the world, to articulate the. 
 15:44: value it has, because that sentence to impact the whole team, impact this or that, suddenly puts it into a context so people can start to see and understand whether it's for them or has value to them. 
 15:55: And I think that's ultimately what it comes down to. 
 15:57: You hit my two favourite words on there, Russell, value and purpose. 
 16:02: I think a lot of times the teams that I see struggle with whatever you want to call it strategy, it comes down to they've forgotten. 
 16:12: The purpose and what the value of those activities actually are. 
 16:17: And so I am one of those people that's a total glutton for punishment. 
 16:21: I love writing these documents because it is that anchor point to be able to come back and say, well, remember when we started this project, or remember when we decided that we were going off the rails and we wanted to solidify what our actual goals were and what our purpose was and what your team was gonna get out of this and what my team was gonna get out of this. 
 16:40: And we wrote it all down for posterity. 
 16:44: But love those moments because we lose track of that purpose and the value so quickly in the bug hunt or the next release or whatever your stressor at the moment might be. 
 16:57: And being able to come back and say, OK, remember that goal that we had. 
 17:01: It wasn't just find all the bugs. 
 17:03: It was, we wanted to hit these requirements and we wanted our users to be happy and, and all of those things that we wrote down. 
 17:11: I suspect that mission, or whatever we want to call it, is quite resilient. 
 17:14: It doesn't dramatically change, but how you're going to approach it, the more detail of the strategy, the techniques, the approaches, or anything else you want to. 
 17:22: That is more likely to go through change. 
 17:24: But your aspirational goal, your purpose, your point, your, why we're doing this, what we're trying to get out of this, that's less likely to change. 
 17:32: You know, whether you include performance testing or not and which type of testing you do, those should be and I think the one thing that I'm passionate about is all strategies, quality engineering, testing, quality. 
 17:45: What you want. 
 17:46: I think we talked about at the very start here. 
 17:48: Adapt. 
 17:49: A document written 3 years ago is by definition wrong. 
 17:53: It's out of date. 
 17:54: It's not living with the times. 
 17:56: You need to make sure that you can adapt it, you listen, you learn, and change is hard, but that's why it's better not to define that you, it's only one way to rule them all. 
 18:06: And I'm sorry, this takes me on the rant, and I'm, I already was ranting, I know. 
 18:10: On centres of excellence, the definition, and I don't mind them in conceptual ideas, but when they define only one way to do things, I find that quite frustrating. 
 18:18: And the same goes with strategies that define there's only one way to do everything, and the answer is, you could be right, but it might vary between a mobile. 
 18:25: A desktop app, it might vary between something that's a throwaway, that's permanent. 
 18:29: There are so many contextual variants that the strategy at the top level should stay true. 
 18:35: But actually the how you get there will probably adapt a little bit. 
 18:38: Don't forget that. 
 18:39: So many people forget that and often not tested to be here. 
 18:43: I was gonna say that again with the purpose and things like that, it's, and you highlighted a good point there, Russell, is that with documents, whatever we decide to call them. 
 18:53: They need to recognise who the audience are. 
 18:55: Why are you actually writing the document in the first place? 
 18:58: What is the purpose of it? 
 18:59: And that, and as you say, strategy should should outline that top level, and then other things change underneath. 
 19:05: But who is reading that? 
 19:07: The nuances between the quality engineering. 
 19:09: The testing strategy can be, again, that context between who are you actually writing it for? 
 19:15: Are you writing it for the client or the stakeholder that is passionate about quality, or are they more interested in the way that we're going to do it in terms of the test and things. 
 19:24: So. 
 19:25: Making sure that we know, understand who you're actually writing it for is really important in whatever document you actually write. 
 19:32: That's if you call it a document, that's if you call it a document. 
 19:35: Or if you ever write it down. 
 19:37: Well, mind map. 
 19:38: I did a workshop with Cala makerryan at. 
 19:42: Here's Con 24. 
 19:44: 1 of the key things we wanted to try and get across was the strategy, is that something that you do? 
 19:49: It's not something that you publish and get on. 
 19:52: And I get that often that is stuff that's written down, and I was being slightly facetious, as is my want. 
 19:57: In reality, what we want to try and achieve is something that is relevant all the time and is. 
 20:05: It's, what's the word? 
 20:06: People use living. 
 20:07: It's living, it's always aware. 
 20:08: It's it's, it's context aware, it's living. 
 20:12: That's where, you know, I, things like, like notions and, and confluences and things like this, wikis, that are actually kept up to date, that people all have access to and can do those things, can work really nicely if. 
 20:27: They are relevant and people see the value to, to your point before that piece is is quite difficult because you could do something with the greatest of intent that your audience don't buy into, other folks don't buy into. 
 20:44: It doesn't work for them, just cos it worked for you elsewhere, even if you think it's the right thing and you get an agreement from old Chuck over here, if the actual wider group don't see that value. 
 20:56: It doesn't, doesn't take off and we can't just have one person on their hill screaming around saying these things. 
 21:02: And so, you know, you've got to get buy in on these things. 
 21:05: And, and when we're not just talking to testers, I think normally we're quite good at speaking tester-ish because that is our language. 
 21:13: But speaking to other people about it, getting buy-in from other folks who maybe are biassed against something with test or even quality in the name. 
 21:23: can be something that takes more work and bringing other people in the creation, the understanding, the problem statements, the risks, what good looks like, all of those things are so important. 
 21:35: You know, we, we like the words empowering often when we talk about our leadership stance. 
 21:40: And it's true. 
 21:40: I think one of the things that I wrote about them before was that a well structured quality engineering strategy empowers team to Build quality into everything that they do. 
 21:51: It reduces friction. 
 21:52: They'll nod to Stu Crocker again, increasing efficiency, delivering high-value software sustainably, not necessarily in sustainable practises and things like that, but in kind of efficient ways that can be reused and can sort of flourish in nice ways. 
 22:06: And that helps us move from a, maybe something that is a bit smaller. 
 22:10: I always thought of test strategies as, as a part of quality engineering strategies, like for. 
 22:15: For me, if, if I was thinking of something that was, again, we, we're inverted comma a lot here, just test strategies, just how we approach testing. 
 22:24: If we have segmented it as a separate facet within a broader strategy, I always saw it as like a, a, a child within all of that, along with a way of working, along with a design strategy and, and, and those sorts of things. 
 22:37: But it gave everyone the opportunity to actually see, cause I, I guess you get kind of irritated when people say, well, Where's your, where's your coding strategy, and where's your requirement strategy and things like this, and they sort of, I, I understand where it comes from, believe me. 
 22:51: But actually, if we just all have one that we all work by, we all understand, we have traceability, we have visibility of these things. 
 23:01: That's really, really valuable. 
 23:03: There is historical biases to things called test strategies, and it's the tester's job to do it and so. 
 23:09: And there is biases of the whole team is more likely to engage. 
 23:13: It's something they feel they all do. 
 23:15: And currently quality strategy, most people will probably feel like they should be involved in defining the quality. 
 23:22: So you'll find it generally easier to have the conversation with the developer, to have the conversation with the BA, the project manager, and so on about influencing and designing a, a holistic quality strategy that incorporates the whole team. 
 23:36: Whereas if you try and having a conversation about the test strategy as a whole team, you might get meetings with people in, but you'll probably find engagement is weaker. 
 23:44: I'm honest, if a test, someone with an experience of test strategy thinks that's what you're doing but calling it quality, the weakness is probably still there because they've seen a 100 page documents that, to Tara's point earlier, are almost the policies and procedures of how you do testing. 
 23:58: They aren't a strategy, they're not really even a plan. 
 24:00: They are just literally the guide to testing. 
 24:03: And that's not a test strategy in my view. 
 24:05: I'm adamantly against that. 
 24:07: To Chris's point, if you put that in a document like that, you'll never sign it off, you'll never get agreement, you'll never get things cause to get agreement will take forever. 
 24:14: So your strategy should be high level, and if you do need procedures, they should link off it. 
 24:18: Wikis, other things like that are great because they're living. 
 24:20: You can maintain the thing that's relevant rather than try and maintain this high level thing, which is often hard and complicated and just messy. 
 24:27: You're right to say that there's different approaches and there's different ways, but if you want to get engagement. 
 24:32: The traditional test strategy documents that I think we've all been hit with at some point in our lives, for some reason. 
 24:38: I can't explain how many project managers have asked me for a test strategy document. 
 24:42: In a certain format and then sent me a template that they expected in that's got, quite frankly, it's not a test strategy. 
 24:49: It does my head in, and I've had to educate every single one of them, usually not to success because they're anchored. 
 24:54: This is what I've done before, this is what I expect. 
 24:57: I don't know anything else. 
 24:58: I just want this. 
 24:59: If you can shift that conversation was, why not we just do as a whole team a quality strategy? 
 25:04: How are we gonna get the customer what they want, and the consumer what they want. 
 25:08: That has been more successful in changing their. 
 25:10: Mind and making them forget. 
 25:12: I use the word forget because it usually is just forget about wanting a test strategy. 
 25:16: Often I've been asked again for it later. 
 25:18: Letting go of past trauma. 
 25:19: Yeah, yeah, plenty of it on this one consultants and other things. 
 25:23: Well, this is the thing, it becomes one of those standard prints to or one of the other project management things that people expect. 
 25:30: It becomes a kind of a on a project manager, delivery manager's checklist. 
 25:34: And to Chris's point earlier, you often won't see development strategy. 
 25:38: , you might see architecture, but you probably won't see development or coding strategy and things like that in there. 
 25:43: But it's not a bias, but it's all, but to be honest, a quality strategy incorporates all this. 
 25:47: How are we as a team gonna outcome quality solution that's good enough for our purpose? 
 25:52: Who isn't perfect cos and often as a tester I can get caught up in trying to get towards perfect. 
 25:58: That's not the goal. 
 25:58: The goal is good enough without risk or significant risk. 
 26:03: I would say though that, you know, starting my, my career on the development side, that there are very often development strategies and policies in place. 
 26:13: They're usually something that's been baked into your IDE. 
 26:18: I had companies where I was required to use the splinter with this. 
 26:21: Set of rules and, you know, all of those things and reviews where if I didn't follow naming conventions, they'd kick it back and tell you rename it. 
 26:31: But it's more of a culture and accountability system than it is, but we said X, Y, and Z. 
 26:41: You made a good point there, Tara, because I've been hit by this recently actually, by people saying that actually we should automate the whole strategy. 
 26:49: So everything should be automated and checked, and I kind of think some things can be, like automated test quality and all the rest of it can be. 
 26:57: The standards, the coding standards, all that sort of stuff could. 
 27:00: Whether a ticket has got acceptance criteria on it, you can automate some of these things or not. 
 27:04: The quality of it's a bit more arbitrary, but you can automate some of the basics of it. 
 27:09: But you can't automate it all is my honest opinion. 
 27:11: But you should automate what you could, because. 
 27:13: Let's be honest, if we can get a computer to say hang on a minute, you've got no acceptance criteria, then clearly this can't be done because it's got nothing to be done on it, and it throws it back. 
 27:22: That saves humans time and effort and energy. 
 27:25: Same goes, it's it it speeds up the review cycle, the feedback loop, which is all what these things are meant to be doing. 
 27:31: So if we can find automated tools to do all of any of that that we can, great. 
 27:35: But I would like to say out there to the audience. 
 27:37: I may be wrong, but I don't think it can do the entire quality process because a lot of that is to do with humans and interactions. 
 27:45: It's about working together to collaborate and understand things, to improve things, and you can automate a lot of expectations, coding standards, and the like. 
 27:53: Does it meet X, Y, and Z? 
 27:54: Have you done X Y? 
 27:56: But to actually know. 
 27:57: The arbitrary stuff, the abstract stuff, it can't determine, but it can do, if this is good quality code, it can do if the complexity is too complicated if you're in on 10 lines, but 2, it could do things like that, but it can't tell you that test was pointless. 
 28:09: So you're running a test forevermore, that's got no value. 
 28:12: It generally can't do that. 
 28:14: It would be nice though. 
 28:14: I see that a lot. 
 28:17: No, I agree. 
 28:17: I'm always amused when people find failed tests and it's like, but the bills, you've been telling me the bill's been passing. 
 28:23: Oh yes, but the tests failing for 6 months. 
 28:25: But how's the bill been passing? 
 28:26: The testing has been failing for 6 months. 
 28:28: The test has been failing for 6 months. 
 28:29: Oh, it was false. 
 28:30: Why didn't you fix it? 
 28:31: It just gets on my head. 
 28:32: It's like the bill has not been passing. 
 28:34: You've been lying to me. 
 28:35: Builders manually being checked and verified, or you've ignored it and hoped that that wasn't a thing. 
 28:40: But anyway, ran over again. 
 28:42: But it, it comes back to that whole concept of policy versus strategy. 
 28:47: Like, it might be the strategy to just say, we'll tackle that later, ignore it. 
 28:52: but it definitely probably I would want it to be the policy to do that. 
 28:56: I can tell you for certain that in most places I've worked, it is the strategy to fix problems where you find them, not to ignore them for later. 
 29:03: However, it is someone else's strategy to push them down the line. 
 29:07: It's, there's also that thing, isn't there, that Heather talked about minimum shipable risk and identifications of risk and what are we willing to go down. 
 29:16: And I think to your point about things being in your strategy, but not in their strategy, again, this is where a single strategy. 
 29:23: Which has an end to end piece, a single source of truth, if you will, actually helps everybody because we don't have this throwing over into the next column or so and so being measured by different OKRs or whatever, because we all see what good looks like for all of us. 
 29:41: So we all identify pipelines and bottlenecks and, and all these things that would enable us to actually just all benefit from doing a better job. 
 29:50: It doesn't work. 
 29:51: And by the way, people push back all the time on the qualities of everyone's responsibility, because if it's everyone's responsibility, it's no one's responsibility. 
 30:00: It's often the pushback we get. 
 30:02: But I think to really, like, you bring this back in, for me, a quality engineering strategy is more holistic, more involved, and more people. 
 30:09: It takes more work, people, to set these things up. 
 30:13: But most things that provide more value take more time to get right. 
 30:18: It needs more context, it needs more people. 
 30:20: It needs more buying. 
 30:21: But if we do it well and we have something that's relevant to our context that is continually iterating and adapting, everyone on the same page, everyone being focused on what good looks like together, everyone identifying things together, that is great. 
 30:37: You we talk about silos all the damn time. 
 30:39: Break them down. 
 30:40: Let's, let's try and do things together. 
 30:42: Let's find out what quality engineering looks like to us in our context. 
 30:47: Let's not read it from a book. 
 30:49: And if you're gonna go and sort out a strategy, think about what level you want it at. 
 30:54: Do you want it organizationally? 
 30:55: Do you want it for your project programme? 
 30:57: And if you create one for your project, does it conflict with the ones that are above it? 
 31:02: Because we often forget that fact, and it may conflict for good reasons. 
 31:06: But I would encourage you to have the conversation when it conflicts because it can often be a massive problem later. 
 31:11: It is incredibly impossible to retrofit strategies. 
 31:14: It's very, very hard and never ever done. 
 31:16: And the strategy may not be right, and it's often better if you can to challenge the strategy to therefore improve it versus to kind of create conflicting strategies elsewhere and it bites you in the bum. 
 31:27: That's an experience there. 
 31:28: No, no, I couldn't tell at all. 
 31:30: Yeah, they're they're done with the right with the right desire, I guess is the point. 
 31:35: And often because the high level one or the organisational ones out of date irrelevant, but often that's complexity of these things. 
 31:41: But I think strategies are those things. 
 31:43: If you focus on the top things you want rather than everything, to your point, if it has a exactly how you do automation, it's gone away from a strategy really. 
 31:52: It may link off really love. 
 31:55: I really love when I have brand new testers that come in. 
 31:59: And start questioning things in a strategy or noticing those conflicts between the higher level and the project level, because it's that fresh set of eyes that I think, you know, we, we become jaded, we lose that ability to see things with a fresh set of eyes. 
 32:15: And to have somebody brand new come in and go, This doesn't make sense. 
 32:19: Why do these conflict or why are we doing it that way? 
 32:22: Those are my favourite moments. 
 32:23: So I'm like, you're right, that is dumb. 
 32:25: Why are we doing it that way? 
 32:27: Have you ever thought something was in a strategy that wasn't? 
 32:30: I've been a leader in areas and thought like the strategy implied this sort of thing, and then went back to it and my opinions change, but and the information has never been updated. 
 32:40: The conversations have happened, but again, the reference, so these people that come in are seeing things that aren't the culture because you or people like yourself haven't actually have forgotten that the reference documents aren't up to date. 
 32:55: It's fun, isn't it? 
 32:57: We are guilty as everyone else is. 
 32:58: Documentation is a nightmare to update. 
 33:00: We're all terrible at it, I think. 
 33:01: Bring in AI just to read my mind. 
 33:03: Thanks. 
 33:03: Update any documents I might reference ever. 
 33:05: This is why my favourite people at most companies are tech writers, because they keep us honest and up to date. 
 33:12: That's as long as we don't get in their way. 
 33:15: Yeah. 
 33:16: Definitely more use of typewriters. 
 33:18: Anyway, we have talked quality engineering strategies, and we've talked test strategies of the confusion between the two of them, what they are, what they aren't, bits and bobs of our history. 
 33:27: I've shared my scars, but it's probably time to wrap up tonight's little talk. 
 33:32: So thank you for joining us, David, Chris, and Tara. 
 33:35: I've been Russell. 
 33:36: if you want to reach out to us, give us a topic to talk about perhaps, or just to. 
 33:40: Compliment or insult us or to suggest, things that we can do to improve or improve our strategy, you name it, just reach out at contact us at testing peers.com. 
 33:51: If you want to join us at our conference, please feel free to do so. 
 33:55: We'll hopefully be announcing the speakers in early 2026. 
 33:58: Please do come along to our Piers Con conference. 
 34:01: You can find us on the internet interweb at testingpeerscon.com. 
 34:08: It's our 15 pounds upfront to early bird. 
 34:10: Early birds until I think December. 
 34:12: So feel free to come along, it's in Nottingham in the UK. 
 34:15: We would love to see you talk about testing, not just hearing us, you'll hear lots of different people. 
 34:20: So thank you everyone. 
 34:22: Thank you very much. 
 34:22: I hope you've enjoyed listening to us. 
 34:25: Adios. 
 34:27: For now, It's goodbye from the testing peers. 
 34:31: Goodbye.