Geoff: welcome to quality over coffee number two

Peter: ⁓ Yep.

Geoff: is the second ⁓ of series of ⁓ webinars that Geoff Thompson and my very good friend Pete Thompson ⁓ are to be doing around quality and our involvement in it and hopefully passing on our history to you and some lessons learned so that you can ⁓ develop using information. ⁓ But we go any further, I would like Peter to introduce himself and actually tell us why he thinks this is a good idea.

Peter: Yeah, thanks, Jeff. And good morning to you. It's good to see you again. Yeah. Look, it was just something that crossed my mind not long ago. And part of that was thinking about legacy. We talk a lot about legacy in the software world, legacy apps, legacy debt, all of that good stuff that's left behind in many, many an organization because the actual cost and the real costs.

Geoff: It is good morning.

Peter: far outweigh the estimated costs in many major programs and someone was talking to me about that and it just got me thinking about well what's my legacy going to be when I retire or decide that I no longer want to work or no longer do something in this wonderful quality industry what's what are people gonna look back and and and see is my legacy now

Geoff: Yep. Yes.

Peter: I'm quite proud of all the work I've done and the journey I've been on since the mid 80s. So, know, mainframe through to middleware, through to microservices, to AI now. You know, it's something I've always been keen to stay relevant. But, you know, I was kind of looking back and going, well, my legacy can be either what I've delivered or it can be what I give back to the industry, because giving back is not hard. It's about just sharing my time through this medium. through other mediums, through conferences and things like that, just to hopefully teach people, learn from people still, because I don't want to close my mind that, you know, I'm the genius here and everything, there's still a lot to learn, especially from the younger generation coming through, and then just really work on how do I give back and kind of the idea of having a chat over a cup of coffee with like-minded peers.

Geoff: Hmm?

Peter: you know, upcoming talent, know, budding talent, grads, interns, whatever you want to call them to part with some of the knowledge that I have to help them lift themselves up to the next level and beyond is is kind of something I feel that maybe I owe the industry. It's given me a good living. All right. And I think I can't ignore that. But but I also globally see a lot of And this might be quite controversial. if you think this is one of you, then please close your ears right now. I see a lot of people who kind of want to hold onto their spot rather than thinking that it's something that their knowledge is something to give back. And I really want to be more thought of as someone who's not just contributing in terms of delivering big programs, building big COEs, you know, running great offshore models, all of that good stuff. I want to be someone who's shown that people can come to, they can ask for advice and they can move forward. Now, know, some of that may come at a cost as I bend down to retirement and have to get another source of income, but right now I think this is good a medium as any.

Geoff: I kind of live with you on that one in that actually a lot of what I've done outside of my day job has been the giving back principle you being involved in ISTQB and this is just a further addition. I also like the point you say there Peter around you never stop learning really. I retired 18 months ago and I'm still learning I'm still finding things AI is still A little bit of a cloudy world to me. You know, it was just initiating when I started. So when I retired, the last 18 months have seen it, you know, prolificate across the industry. I, ⁓ it's very important that, you know, you do keep listening and keep learning. I think sometimes too many people think they know it already and they just go hell for leather without asking and wanting to share as you say.

Peter: Yeah and I think there's a habit right we all have the habit of well this worked for me here and now I'm here I want to try and kind of bring what I had there to there and to some extent that's okay because there will be elements of what you do in any job that is the standard. I've always worked to a standard I've always been a fan of being able to measure you know a TMMI or STQB whatever way you want look at it being able to measure the way you are delivering.

Geoff: Yeah. Thank

Peter: because if you can do that when the challenge comes and in testing quality more than anything, the challenge comes, you can hold your head up high and say, well, we're meeting the standard. And that's why you're seeing what you're seeing. And I think a lot of that comes back to the growth of the industry. mean, last session you referred to as you of you fell into testing. And I think to be honest,

Geoff: Yes.

Peter: our age ⁓ kind of fall into it. ⁓ personal ⁓ was I was an operator, computer operator, working shifts. ⁓ ⁓ I'm free to say now it was a government job so there was way more than us than there needed to be ⁓ the one thing they did on the night shift to keep us occupied ⁓ they gave us the test programs to run. no test environments or anything like that so we ran them against live we printed everything out no data protection right so data protection just came in 1984 so we're talking 85 86 and we would just you know print a section off and compare them to what we produced earlier in the evening on the production system and you know I found I had a little bit of a knack for being able to spot the errors and it wasn't until you know

Geoff: Mm-hmm.

Peter: that job came to an end that I realized there was an industry out there that would allow me to take that skill and grow on it and because I'd also been a shift leader and shift manager and stuff like that I was quite comfortable not just about doing the do but also about you know pulling stuff together and leading it and driving it forward and things like that so and you know when you find you're good at stuff and you know I'll leave it for the viewers out there and people who follow me on LinkedIn and all of that good stuff but I think I'm pretty good at this and you know when you find it good at stuff it just works a lot more enjoyable.

Geoff: Absolutely, I've loved every moment from the day I went into this trade to even today I'm still spending a lot of my time on testing stuff mainly around I will be very very fair to say many around things like ISTQB and TMMI which I'm chairman in both of those situations so I kind of get involved and it's really interesting to watch and see what the world is doing and learn from that. yeah think it's the whole point of this is that we are here to give back i guess so so i would say one of the things i've learned that i would actually pinpoint now and say here's something is always listen to people who've gone before and the reason i say that is that you know so many times i see people saying oh this went wrong oh nobody told me and it's like well you never asked you know you could have come and said i've got a little bit of a problem here jeff can you help But I think you're right. think a leader leads and gives away information to make that leadership work. A manager doesn't. A manager just tracks activities. And that's when you get into that scenario where the manager doesn't provide information. He just tells people to do things. So it's a really difficult thing. yeah, I agree. Learning from what has gone. Well, history will repeat itself if you don't, you know. just in software testing, anywhere. yeah, absolutely. ⁓ did. ⁓

Peter: Well exactly and I think we touched on that last time as well that some of the lessons you you learned in the 80s are still being learned today by others and some of that is you you dress things up you do them a different way but you get the same outcome you know and we discuss that again don't want to bore people by going over the same thing you know the basis of testing is still the same and that has never changed so

Geoff: day off. Yes. Yeah, it's still in fact, it's quite interesting the other day, if we drift very quickly to AI, I was looking through some of the new syllabi that have been created by ISTQB that have really not rewritten the test process in any way, shape or form. What they've done is provide a testing angle to how AI works. So either using AI to do testing or testing something that has AI in it. the fundamental underlying process hasn't changed. I remember the arguments, and you may have even suffered this as well, when Agile came in, and I said, well, it's just a whole load of little V-models. No, it's not. All right, I'll draw it as a circle if you like, but you're doing the same principle, but in smaller bytes and more manageable bytes than we did when we did all the big system stuff. So yeah, the world doesn't change. I guess that's, ⁓ you've got some perspective on that from your. your vast experience with large groups etc.

Peter: you do, right? And ⁓ interesting. Everything, everybody thinks they've got the new thing coming in. ⁓ I had a really interesting discussion. ⁓ Probably about 10 years ago ⁓ a guy whose father was actually, ⁓ was older than me, but he cut his teeth in operations as well. ⁓ ⁓ said the conversation that they were having, ⁓ was talking to them about how they deliver, ⁓ know, the way they deliver all of this good stuff. ⁓

Geoff: But okay.

Peter: ⁓ right and he was calling it DevOps and he said his father was just looking at him going yeah but that's what we did back then and that's what we did back then. Now that's kind of right I think and sometimes I certainly find in outside the industry we do look back at people and go ⁓ yeah but that was done in 73 and this was done in 76 and all that stuff and it was but I think it's the way that it's done today

Geoff: I'm kidding.

Peter: whilst you can call it a different name, Agile, DevOps, whatever you want to call it, it is done differently because it has added a flavor of automation, especially automation. Now you're getting a flavor of AI. So everything while it's the principles are still the same, there is a little nuance to it that makes it different. The only one I get really hooked up on is Shift Left because

Geoff: Yeah, yeah, yes.

Peter: because and again i hope my controversial theory is if everybody does their job properly what are you shifting left

Geoff: That's a very good point, absolutely.

Peter: And there's a debate to be had there and I'm ⁓ going to say maybe over the course of the next year or so we'll drag a few people in and have that debate on what a shift left mean for them. And what does it mean for you? What does it mean for me? Because more often than not, like you said, you look at the Agile and go, it's five mini waterfalls or mini V models.

Geoff: Yep.

Peter: someone else will look at it and say it's well now we call it agile and but you're agreeing, you're agreeing it's just all the terminology you've got to work through yeah exactly yes yeah yeah

Geoff: I think each generation creates its own vocabulary as well. Often we talk the same subject but we're arguing about the same thing. Discussing with enthusiasm shall we say the whole thing. ⁓ I think it is interesting how that evolution of ⁓ thinking lasts for a generation.

Peter: Yes.

Geoff: And then the next generation says, I can take that. And you're right, every new generation adds some flavor that wasn't there before. And you and I probably don't notice it because we've picked it up bit by bit by bit by bit as you go along. ⁓ I've noticed it by I am one of the authors of the ISTQB Foundation book for the BCS Generate. And ⁓ what I'm finding now is that the new authors of the syllabi are using the same syllabi content. but they're rewriting it in quite a different style. And actually I quite like it. We were quite formal in our day. It's slightly less formal now, which I guess is that is the industry as it stands. It's less formal than it perhaps was, but you know, I don't think that's a very bad thing, but.

Peter: ⁓ No, I agree and I think that's a really great observation as well because I think in the finance world and stuff like that there's always got to be some formality because ultimately you're dealing with people's money and you know so if things go wrong yeah people want to know what you've done but I think outside of that ⁓ in the more kind of the retail side of stuff and things like that you have got a bit more license to creative ⁓ ⁓ think that shows through in ⁓ of the methodologies and like you say some of the the phrasing and the rewording of stuff it's saying the same thing but it's saying it in a language that ⁓ know ⁓ people new people to the industry want to hear I mean if we if we were parroting stuff that we you know we heard about cobalt in the late ⁓ 80s right ⁓ everybody would look at us and and saying we're idiots but but even then you know I've walked into

Geoff: Yes. Thank you.

Peter: companies in the last 10 years where they're trying to decommission applications written in Visual Basic and so you know what sometimes what goes around comes around.

Geoff: Absolutely, absolutely, absolutely. I think that the core thing and the important thing for people to remember is that there is a basis to what we do. I think drifting a little bit again towards AI, I think AI is driving some focus into the capability of the individuals that do the testing now. I if you're using AI, you need to know. that the answer it's giving you is the right answer. If you don't understand how it's making that answer, getting to that answer, how the hell will you ever know whether it's giving you enough testing to know? If you just say to an AI system, go test, what's it gonna do? You don't know, you have no clue what it's gonna do. You might wanna say use boundary value analysis or whatever or decision tables, this is warrant using a decision table. But then that drives back into the quality of the requirements, because if they're not, up to scratch any of those techniques won't work either so it's forcing a level i think it's forcing a level of ⁓ almost back to the well i would have said the 70s and 80s where we were following a dedicated process i like we do today

Peter: Yeah, yeah, and that's, again, another great observation. I actually think contrary to popular belief that we should spend a three or four sessions maybe on AI, but I actually think this is the biggest opportunity in the quality sphere, as opposed to, my God, it's going to take all our jobs. Right. So, so I've sat in meetings where, you know, some

Geoff: Yeah, no we should do more.

Peter: great execs go, ⁓ yeah, we implemented this and you know, the QA team went from 10 people to two people. And then the next thing you see is a article on page three of the news about how their system went down for, you know, overnight and a thousand people couldn't be paid properly and a whole bunch of stuff like that. And you think, well, actually, I mean, they're right. The traditional job, the work should get easier with AI, but the volume of people required to do it.

Geoff: you

Peter: may still be the same and it's really an opportunity for everyone to lean into something as opposed to step back from it and and like you say go well I don't know what it's doing do you trust it or do you trust me well actually should be able to trust you both because you should be teaching it all the all of your knowledge and not be scared of it all right it's it's just something else

Geoff: Thanks, Yeah, I think if you look back to what I would have called the the the WWW boom at the start of the century, you ⁓ We had the same scenario where you know automation came along I was running a test team of 12 people and I was I was literally reduced to zero For the next year in my budget. Why is that? I was just given 50,000 pounds to buy a test tool to replace them. He said he's gonna program is actually it reversed itself, but

Peter: Ha ha. Yeah.

Geoff: At the highest level in an organization, can understand how they make those sort of visualizations and say, actually, yeah, we've got AI now that'll do testing. Why have we got 25 testers? Where the reality is that you might those. The other thing I also found is that when the work when something like that happens, obviously, we all might take on slightly different roles. But ultimately, the work increases to to fill the gap. It's there anyway. And often, you know, I always used to say when we did, I still do say to people today, is that, know, if you can find a quicker way to do testing, it'll give you more chance to do more. You could do more testing. You can get better quality. You know, you're never quite going to get it 100%. We know that. That's the world. Although maybe AI long after you and I have passed away will achieve zero bugs. But who knows? Who knows? It can, it can be faster. We all seen Terminator. We saw how quickly he changed. So, um.

Peter: But you're right, right? And whilst we talk a lot about quality and testing, ultimately, this is the business of risk management, right? And it's how do you reduce that risk? And if you can do testing quicker, you've got two options. You can do more testing or you can do more change. Now, industries will look at that differently. But if you can get more coverage and reduce risk, then everyone's happy.

Geoff: Yes.

Peter: I kind of switched the way I looked at test reporting about 10, 12 years ago to start focusing on what's the level of risk we're carrying. And one of the reasons I did that, it was just a little trick. if you are a budding test director, senior test manager out there, if you can understand your systems and applications under a test well enough to define the value of the risk that

Geoff: You

Peter: it brings if it fails in production more often than not the person who has to sign that off people don't want to put that in front of them and again no names and i won't even tell you the year because people go back on linkedin and guess where it was but but i can remember sitting with someone and saying look i get what you're saying but you're carrying these three defects that's this risk it's worth you know 10 million dollars in production you can't sign that off they looked at me and said well who can and I said well it's probably the CIO so you know happy to go along with you and explain through it all and he just looked at me and said no I'm not going to do that let's let's work on getting these closed and we'll try and push the date back another week. I thought well that's a really sensible conversation to have.

Geoff: Exactly. Yeah, yes, yes. that goes, mean, that's what you've just explained to me is kind of people understanding the impact of quality and or lack of quality. And it's interesting, you know, when I was first taught how to test way back in in 70s and 80s, it was all about, you know, you've got a slot and you've got to fit as much as you can into all that kind of stuff. But we were in isolation. We were like, we weren't even brought in probably till a week before the apps were ready. And then we had to rush some tests together and did it.

Peter: Yes.

Geoff: We didn't understand coverage. We don't say any of that stuff And so you think you're doing a great job and then it goes live and it breaks and it's like ⁓ you're you're to blame Okay, but I think the coverage seems in people still and it's probably worthy of a conversation later on I think even today people don't particularly understand coverage. I still hear people talking about coverage as The volume of tests they've done so i've written 100 tests Therefore i've achieved 100 coverage if i've run 100 tests Well, actually that's irrelevant if 25 of those tests do exactly the same thing, but in a slightly different way

Peter: Yeah, exactly. Yeah.

Geoff: Not it's all the coverage is how much and it's very relevant when you're down at the sort of unit level and the developer level where you're looking at how many times you're going through different parts of the code before you hand it over into system test all those kind of things and and I don't think many people understand that but Excuse me more importantly, I think for when you're you're When you're running your test you need to keep a view on what is enough and risk is important. But the interesting challenge I always found was how you manage to get picked because obviously you have to get the buy in from the business that the risk is what you think it is and how when they start, oh yeah, we'll cut testing down by we can look at the less risky areas. And funny enough, there aren't any they're all priority one. There's not one area of the system that's not a priority one. And I think as a human being, we always have a view. We don't really understand risk. We know when it hits us, we know it becomes an issue. But we don't understand it. the amount of times people say, ⁓ there's no risk of that going wrong. And that's not based on any fact, anything at all. It's just a feeling. And we've struggled over the years as testers to get that concept out of testing and into other people's heads. So they understand why we're saying this is the wrong thing. You shouldn't be moving to life. You should be doing some more tests.

Peter: Yeah, and I have a bit of a theory behind that. think it's because predominantly we're reporting negative things and the old adage, one wants to be told that their baby is ugly. But often when we're reporting, the report starts with, we've run 100 tests, we've got 80 defects or whatever, or we've done this and we've done that.

Geoff: Mm-hmm.

Peter: And it's all about what's not working. And again, maybe 10 years ago, I started to change the flavor of the way I reported to make it more positive, you know, talk about the things that work. It's not the shit sandwich everyone talks about, right? You know, good news, crap news, good news. It was more, let's put, let's put a positive slant on it. I got tired of, you know, going to meetings and I'd hear, ⁓ look, we can deliver the code in time. They just can't test it in time.

Geoff: Thank Yeah,

Peter: then you ⁓ into it and they go, ⁓ so you're delivering the code on Friday night and you're expecting to go live on Monday morning well no wonder we can't test it in time so your statement is ⁓ but I would counter that with saying well okay but if you give me an extra $20,000 and two more people we're going to test it and then it becomes something a bit more no we're not there to block you I'm just telling you how we're going to achieve it or you know we can do

Geoff: Yes. Yeah, yeah.

Peter: days worth of testing over the weekend it's going to cost you x y and z and then monday morning we can look at the outstanding risk what's left and then you can make that call but just constantly not saying no you know what's i think i started a conference talk once and i said what are the what are the testers two favorite words yes but right because you because you'll agree to something and then you'll tell people why they can't you know why they can't have it and so

Geoff: What are they called then?

Peter: just changing it around and just removing them and just positively putting forward something to say, you know, we can do this, but we're going to need this. Or, you know, typically it would be, you work the weekend? Yes. So you walk in first thing and there's no one to support the environment. And it's like, well, hang on a minute. Yeah. You know, if we've got to do this, we've got to do it together. And trying to break down those barriers, right?

Geoff: Yeah. Yeah, exactly. Yes. Exactly. think that's partly that's the other thing, isn't it? that testers doing work outside of working hours means they need a support team around them as well. So it's not just as easy as said, are you three testers? You can you stick around tonight? You need somebody on the machine side. You need all the support around them so that they don't suddenly work for 10 minutes and they can't do anything else because everything stops.

Peter: Yeah, exactly, exactly.

Geoff: It's interesting actually one of my last projects when I worked for the last permanent test management role I had I suppose ⁓ was to implement a quotation system for the mortgage brokers around the country. There's thousands of them and it's interesting because we were given quite a tight deadline. The whole thing was given quite the development and everything was all given a very very tight deadline and ⁓ I was pulled in Mainly because I was leaving I think I had him noticing at that stage and we had about nine months to go Six months to go and the MD pulled me in and said Jeff we need this sorted make this your best the best thing you've ever done I said well actually the one thing I need then is you as the MD to be telling everybody the quality is your responsibility if you say that I think I might be able to do it if I get the right you know, whatever and it was interesting because we we ⁓ We were, we worked very closely with the development team, although they put us in different parts of the building for some very weird reason. think it was just space rather than anything else. But we wrote very closely. And what we'd learned historically with that team was that when they got the code ready and the date came to ship, they'd ship and they'd vanish. Yeah. They got, they, they, they wouldn't even walk around to the test team. They would actually just mail them and run. Yeah. ⁓ and, ⁓ in inevitably that the thing would just. fail. What we did was say to them right well okay let's work together all that let's be friends let's try and if need be I'll give you some of my testers to help you do your component testing and whatever else. But actually what I want you to do is be honest with me and if we get to the date and you're not ready and an extra week would save us thousands I'm not gonna shout I'm not gonna blame you for a late delivery because if I get better quality software I can test quicker yeah my team can test quicker. And blow me, they turned up, the boss came around about a week before they reduced the difference and said, we've got a real problem. We do need that extra week, maybe two, but what we'll do is make sure it absolutely works before it comes to you. Right, fine. And then they turned up actually on the day, rather than sending a run, the whole team came in and we ran our test pack in less than two days with three minor issues was all we found.

Peter: Ha ha.

Geoff: So we did a great job, although everybody said, well, you can't be doing a great job. have any defects. Now, that's the point. We're not supposed to be fighting defects. That's proving the absence of defects. And we were finished about a week early in the end because we weren't doing that terrible cycle of rewrite of them rewriting code on in a panic. Code not being stable enough when it came back to us. And that's still as valid today as it was then. The problem you do have, though, is making that connection all the way up the line. You know?

Peter: Yep.

Geoff: in that everybody has different objectives so actually getting that objective getting that objective embedded into their objectives is very hard. I actually did it for a bank in the UK when I was a consultant I did it for a bank in the UK that the day I presented to their board of directors how to do this the government shut them down. We got hooked in when we had all that major disaster whatever it was.

Peter: Yeah. Yeah.

Geoff: in the early 2000s where lot of the British high street banks all suffered from a lack of money ⁓ for bad decision making. but yeah anyway sorry you were going to say something Peter.

Peter: I was just gonna say what a great way to probably end our cup of coffee today. what I think we should do is give people a flavor of what we want to talk about over the next few weeks. And I think we've probably touched on it throughout this episode and I'll give you what I'm keen to talk about and then perhaps you can chime in. There's two really key points and we're both hopeful that we'll get other people to join us and get a different point of view. ⁓

Geoff: you Yes.

Peter: Just simply because we represent, you know, two halves of the world But there is other areas and so we're to get people from around the globe will come and join us some well-known people in automation a couple of authors who've written books on leadership, but I think for me, you know, we can't duck AI. It's the biggest thing we're In the industry right now. So I think you know next few episodes we should talk about AI and the impact of AI and and the skill behind getting the right prompts And I'd really love, once we've done that, to dissect the really great point you brought up today about the difference between leadership and management and perhaps talk a little bit about our leadership journeys on, you know, kind of when did we know we were a leader versus, you know, we're not just managing schedules anymore. That's kind of, you know, my thought for that could take us five or six episodes. So what about you, Geoff? What are you looking forward to?

Geoff: I think for me a big thing that would be really good to talk about and I think would help a lot of people is managing change the emotional journey they go through when And we're going through at the moment with AI so it'll probably wrap around your AI stuff really well the impact on people because we don't know what the future holds How do you how do people get through that with enthusiasm, you know? How do they feel they're gonna fit all that kind of stuff?

Peter: ⁓

Geoff: I actually, the leadership thing I think is really, really important. Really, really important, I think. You can manage a team for one project and probably get away with it, but you can't simply just keep managing team. We found this with Agile, you you could motivate a team to keep going as if you led them rather than manage them, you know. So yeah, love to do that. I think the automation thing is actually pretty important at the moment because it's kind of, ultimately that's where AI's driving test.

Peter: Yeah. ⁓

Geoff: Yeah, it's going to automate more and more in a simpler way, given it's got the right prompts and stuff. So yeah, absolutely there. And process improvement. I'm on TMI, and TMI is a very bad people. So there are lots of people who don't like the idea of process. So that gets quite a bit of bad press around the fact that forcing process on people. And it's absolutely not. And I'd love to talk to people and maybe bring in one of my colleagues who's actually does assessments to talk to us about what it.

Peter: Yeah, I think there's two episodes in that at least one is on the importance of process. And I get it's not important for everyone, but it actually is. And so getting people to understand that it's a process and it's a template and it's so well designed that you can tie it in a knot and still be compliant to it. And getting people to understand that and then the value of having it and the value of the recognition.

Geoff: Mm-hmm.

Peter: having it I think is incredibly important so I I do think there's a great couple of episodes in there I'd like to get some upcoming people on who might give us a few quiz questions and stuff like that and ⁓ maybe maybe a bit of a panel and also probably the one thing I haven't divulged too much is I have been doing a bit of mentoring a wonderful company in the UK I'll shout out to now Fortitude 17 led by the very very lovely Emma Beckett

Geoff: Yep, yep.

Peter: did a lot of mentoring with them and their staff and I'd really like them to come on and talk about the importance of it and what it's ⁓ to them, not just to say how awesome I was, but to ⁓ about the value of having someone there that they can go to and use as a mentor to support ⁓ business. ⁓ Because they're not a big business, right? They're a small business making their way in the world and doing a really good job at it ⁓ the minute.

Geoff: You got the right idea, I guess by pulling you in as a mentor.

Peter: hopefully be ⁓ getting some feedback on ⁓ from you guys out there. Please hit us up on LinkedIn. are joined with us because that's where we'll be launching So ⁓ thank you very much ⁓ and ⁓ keep listening. it