Peter: Good morning, good afternoon, good evening, wherever you are in this wild world. Welcome to episode 5 of Quality Over Coffee. I'm here with Jeff as usual who's just bet fresh from working in inverted commas in Mauritius. Welcome back Jeff, how have you been?

Geoff: mean, fine, thanks, Peter. Yeah, it's been an interesting couple of weeks for me. It was an ISTQB meeting in Mauritius with over 100 attendees coming from all over the world. So really, really good to talk to people about testing in my retirement and actually get a chance to have a chat, bit of fun and some sunshine. So it was very good. I'd recommend Mauritius to anybody who's thinking of going on holiday and can afford to go that far away.

Peter: It's not bad this retirement like you're in,

Geoff: It's not bad at all. What it means is I can dip in when I want to and dip out when I don't. ⁓ so yeah, it's been and this is encouraging me to dip in a lot more.

Peter: Very good, very good. And dare I ask what people think of the podcast in the world of ISTQB?

Geoff: Generally there seems to very positive feedback, very positive feedback, particularly from the English speaking nations. The international community like it, but we being English and we tend to talk quite fast, they struggle. I think we'll both be slowing down a little bit today to make sure that we can get the message over. But yeah, no, generally in general, most people knew about it. There was very few people who didn't know that I was doing it. So yeah, the word's out already.

Peter: Excellent, that's really good news. This week I thought after our ventures into AI we might go back to the future a little bit and talk about our experiences of Shift Left. Now for the historians among us Shift Left was a concept invented in as much as I don't like to say it but it was invented in IBM in 1973 or the concept of it was was invented in 1973.

Geoff: You

Peter: with the thought that developers should review and maybe test their own code. In the last 40 years, it's been there, come back, gone again, come back again, and it's about to be launched in another iteration, I'm sure. What are your experiences over your many years, Jeff, of working in a shift left environment? And before you even answer that, can you explain what you think shift left means? to you as well.

Geoff: Okay, thanks Peter. Yeah, I think it's a very interesting concept and I can see why it keeps coming back. I didn't realize it was 1972 that it got invented and I think I've probably done it, tried to do it everywhere I've worked, but I didn't know it as shift left initially. To me, shift left is moving or pushing, probably pushing given how you make it happen. Testing activity. ⁓ earlier in the life cycle. The message I have always told people is that I understand that the urban myth is that 85 % of all defects are implemented during the coding stage. They're not design defects, they're not test defects, they're code defects. It's not the developers fault in any way, shape or form, it's just what happens. And ⁓ the principle was let's help the developer lower that number. by actually getting them to test themselves. So I think in general, that's my understanding. What I would say today in the work that I'm doing within ISTQB is showing that the largest increase in people wanting to understand testing today is in the development community, where they're now starting to take testing incredibly seriously. Probably more to defend their jobs against AI, but... they are taking it very seriously now. So it's, can see why it's read its head again.

Peter: Yeah, I can too. And for those of who want opinions on AI, please listen to episodes three and episodes four if you haven't already. I think that you're right, Geoff. I think it's the concept of testing earlier in the life cycle or testing when the time is right. It's kind of the just-in-time testing piece, if you like. is really what shift left means to me. It's how can you test something at its earliest opportunity and therefore the whole defect calculation of it costs one time to fix in development, 10 times in system integration test. I think it's something like 110.32 now. It used to be 110.100 but someone put that myth to bed I think about 20 years ago and of course it's the value.

Geoff: Mm-hmm. Thank

Peter: It's the value as well. Although ⁓ it's a cost avoidance value and I was talking to someone earlier today that when you're trying to explain the value of testing you're always talking about the cost you haven't justifying the cost you are spending and I think Shift Left really helps you play into that. Now the fact that it's been around for 50 plus years is kind of irrelevant and the fact that it it keeps coming back and then no one thinks about it and then get like the DevOps movement starts up and everyone's ⁓ yeah it's it's all about shift left we should be doing that. Actually I think testing itself is is about shift left shift right shift up and shift down you just move to where you need to to to to bring the most value to whatever project or whatever piece of work you're on at the time but kind of the concept of it and I really like what you said there about you're getting more developers thinking about testing because that plays into what we were talking about AI as well. Now my question would be it's all right to talk about it but for years 20 30 years we've talked about a testing mindset so how do you get someone whose mindset has not been wired to test to test

Geoff: Yeah, I think that's possibly one of our largest challenges. I was thinking about this when we talked about doing this particular subject. How did I ever manage to do to push testing back in the life cycle? So effectively to do shift left. And I think my most successful situation was a very, critical project for the companies working for legal in general at the time. an MD who was frightened stiff of not meeting the regulatory dates with it. ⁓ And when she asked me to test it, I said, fine, I need your help. I need you to push as hard as you can. But quality is the most important thing on this project. And if we don't get the quality right, we don't go live. Which with great respect to her, she did. And she pushed it all the time, which made my job, I wouldn't say easier. but more acceptable to the people I was working with in development. They didn't see me as attacking them. They saw me as helping them. ⁓ And what actually happened on that project was the developers asked if they could keep the code for an extra week because they felt that extra week they had the code, they could improve it by 50 % more. ⁓ And it worked. And we finished early. And great thanks from the MD, all those sort of things. But my thoughts were that I'm just doing what to me is common sense. You know, like all these movements, they're great when they're sub that they're given a title and we can all relate to that title. But actually, if you've got a logical brain, it's the most why leave everything to the very end to check it, you know, just an aside, actually. Sorry, I'm I appreciate looking quite on this one, but it's quite interesting because when I started my own company in 2004, our mantra was helping testing to shift left. So so much. that did that happen that people we came in contact with there was a company created called Shift Left Testing out the back of conversations we'd had with the two owners who were thinking of creating a company. it was very, became, would also then driving that into companies talking at a senior level and explaining what is ultimately the cost calculation graph that you referred to that if you find a defect. encode it'll take you milliseconds to fix it and boom if you find it when you're in user acceptance testing it may never get fixed or if it does get fixed it's going to cost you a lot of time and effort to go all the way back through the life cycle and check whatever has been done isn't in impacting something else so yeah it's it's been a bit of a passion ⁓ and and but i'm really pleased that we're getting a few questions coming in via the web at the moment about this again that people are taking it but people do seem to struggle to get authority to do this work. ⁓ I don't know what your experience is in there, I mean you've obviously done like me, but you've done it yourself.

Peter: Yeah, well, I have, but I have a probably a take on what shift left is and probably the question before I rock the world a little bit or rock the boat or whatever is why do we need to shift left?

Geoff: That's very interesting. You're asking me that question.

Peter: Well, maybe I could make it a rhetorical question and answer it myself and really then open up the floor for debate and gosh, if you've got any opinions, anyone please hit us up on LinkedIn as usual. But why do we need to shift left? Your example was a really good example, which was if the developers had the code for another week, then you got better quality. So I interpret that is if they actually finish their unit testing, your system testing would go better. I'm going to put it into a simple world unit test, system test, system integration test, UAT. We'll just use those four forms of testing for my example. But you know, it kind of goes circular and you can do small circles, big circles. We've discussed all that. But that just means to me they didn't deliver on

Geoff: He

Peter: They had a date to which to deliver to, fair play to them, then said, give us another week and the code will be better. Now you could have had an overzealous project manager who went, no, give it to the test team. And then all of a sudden you're finding more defects in system tests. doing this and you're doing that. So if you get a piece of code, a function that's fully unit tested into a system test environment and you system test it, and then you integration test it and then you AT, what do you actually need to shift left if everything is delivered on time?

Geoff: That is an interesting question. Yeah. I think the shift left approach is really for the situations when that doesn't happen. So you're absolutely right. I think if you the life cycle should be you're running testing parallel to your delivery cycle the whole way through. We know that's the logic of the V model. And I was brought up on the V model.

Peter: I'm glad you said it.

Geoff: And the amount of times I've had to explain that to different companies who have no idea what it really means because everybody takes the mickey out of it and laughs about it and it's kind But actually it the principle of that model is exactly that you start testing alongside the relevant delivery stages all the way out And therefore so if you do that, yeah, absolutely. It's shift left is is where you haven't got that and you've got to move activities back and you've got to train your developers if they need training. And invariably they don't. But I think your point about the project manager is over set as project program manager is actually often quite correct in that he wants to show his boss that I met all my targets. So he'll push them to deliver. And invariably the development estimate is wildly out because it's written before anything's written. If that makes sense. And often there's no science to it other than what the project manager knows. So they're bound to have struggles to achieve the date. I work for a large system with a large system integration, was at LNG, and when I actually analyzed their plans, it turned out on day one, they'd already included weekends in the calculation. Well, where have you got to go when things start to slip? If you've used your weekends, you've got nothing left. So I think it's an approach that

Peter: Nice.

Geoff: is there to help people to improve their life cycle. It's not there if you've already got it. don't need to shift left.

Peter: No, I totally agree. again, the example you gave to me is the perfect example, which is what you did is give the development team time to finish their job. And when they finished their job, you don't need to shift anything to left and the quality is better because they've tested it at a ⁓ code, route and branch level, which you can't do in a system space. And therefore when you start uncovering some of the problems that you could have had if you'd started earlier, the defect turnaround times go up and then everyone starts thinking about cost of quality rising and things like that. So it feels to me that the rise and the drive behind shift left and I had the agile kick as well, right? You do all this, you do that and all of those, but the drive is essentially because people want to hold a date and nothing else because if you allow people to finish their jobs,

Geoff: Yeah, yeah.

Peter: and go all the way through. You don't actually need to shift anything to the left. Now I am going to contradict myself a little bit because I think the true shifting left happens in the non-functional space. The ability to prove security and performance, if you can improve performance and test it at a unit level or even a system level without the whole integration there or even just your integration points. at earliest opportunity before you string stuff end to end, then you've got a fair start at a full end to end performance test. So I think that element where you would normally say wait till the system's 90 % correct and then run your performance test. Actually, even if you only got 10 % of it, you can performance test it there. think that element being shifted left is way more powerful than talking about, well, we'll do system test here, we'll do this, we'll do that. Ultimately, if... if you've got flexibility and being able to move stuff around and that's what agile should be. I've got 20 story points but I'm only going to do a 16. What the 16 I should be focusing on. Then I don't think you're ever shifting anything left. You're just picking up uncompleted code and then you have that awkward conversation which is, found this defect and someone says yeah but we haven't built the other side of that function. Yeah so it's never going to work.

Geoff: Mm-hmm.

Peter: So comes back to communication and a whole bunch of stuff like that. But, you know, if I come back to the 1973, the concept was actually developers testing their code, not moving it somewhere and have someone else test it for them. And that was kind of, I get that as the shift left bit, but anything else is if everyone does their job and delivers on time. I don't think there's anything to shift left.

Geoff: I agree and I think based on what you were just saying I think the risk element is where we have to think about these things. There's no point in doing a performance test 10 minutes before you go live. You have no time to fix defects. You just know it's not going to perform. But I think interestingly if we go back to 72 and I wasn't even working then, me just say so. I no IT experience at that time but in principle

Peter: Exactly. Alright.

Geoff: we had, there was a time when the business analysts wrote the user acceptance test before they'd finished their design and the testing was all done by development. And I've always had this concern that, and I don't know who started this movement of independent testing. And I absolutely believe in independent testing. If you get the overzealous test manager who wants to do all the testing and do the, you know,

Peter: Yes. ⁓ 100%.

Geoff: isn't is actually more focused on finding defects than proving it works if that makes sense then actually you start to drive a culture where the development goes it it in anything i do if nobody's going to to to check it i'll be more zealous in my own review of that item but if i'm about to pass it on to somebody who's going to review it i will do it my own review but I'm not going to do it as well as if it was just going straight into a production environment. And I think that hasn't helped the world of software testing and maybe shift left, although it was born out of a different era, over time has become this thing where, you know, in that particular project I was referring to, I actually released three of my testers into the development team to help them test. because a lot of them didn't really even understand the concept of what to do. And actually one of the things that I recognize is most of my testers who called themselves system testers were in the nitty gritty. They were looking at the bits and bytes and I had a problem lifting them out of that. So to actually send them into development was a godsend because it committed development to doing it properly and they had somebody to guide them. I think it, so I think there's lots of reasons why it's happened over the years. And I'm not saying independent testing is not a good thing. I think it's a very good thing. I think, but it's about how you manage it. I did a presentation once, I did it in Denmark of all places and it didn't quite go down as well as I thought. But I bought somebody up onto the stage, an actor, a test manager from this company with me. And I was the program manager. He was the test manager. His job was to refuse to tell me anything about how I could do my job better. because all he wanted to do was find defects. So what he didn't do was tell me I've done this, I've tested this system before, this is where it always goes wrong. And the whole story turns around when he realizes that if he could tell me that, his job would be easier as well. So I think there's kind of, and I'm not suggesting testers are all evil people who go out to destroy the world and take total control.

Peter: Well...

Geoff: But in same way we have Overzealous project manager, have Overzealous test manager.

Peter: Absolutely. If you think of the late 90s, early 2000s, testing was seen as the dark art, right? We were very closed. Not everyone can do this. I still believe not everyone can test. I know that the whole point of some of the new methodologies are about everyone does testing, but not everyone can test. They're two different things and they don't have to be exclusive. So I will take your performance testing after UAT and raise you to actual performance testing in production after going live. One of the most bizarre things and I shan't name the company but if anyone's listening who was working with me back then you'll know exactly who this is, launched their version 2.0 of their online offering.

Geoff: Yeah.

Peter: which was fine. went through fully tested, it got delayed a couple of months, ironed out some of the defects, things like that. Did a performance test on it. Nobody had consulted the marketing team who sent out their brief to say, everyone, the new version of your website is out on Monday morning. Here are your new numbers and your new passwords. Please log in at nine o'clock Monday morning and make sure it can work. So, instead of being a thousand people, which was the usual number that logged in on a Monday morning, 25,000 people hit the service concurrently and it went down. yes, so we marshaled about three troops. We gave people indemnities because they didn't really want to test in production and we ⁓ created a lot of dummy users in production and ran multiple performance testings over the

Geoff: ⁓ dear.

Peter: testing over the course of the week. There was a subsequent issue with that that really is head five years later because the dummy accounts never got deleted and as it was a financial institution of course you have to keep money set aside for every account you own and so 25,000 accounts had money set aside that were you know Mr. A Rogers, Mr. B Rogers, Mr. C Rogers all that kind of stuff so so you can still shift left all you want if you're not in line with your marketing team. You're horribly wrong. I do like your point though about overzealous test managers as well and it still comes back to the fundamental question that we should ask why do we test? And I will say if anyone says we test to find defects, please step to the left. Yes, anyone who says we test to validate a system or verify something, the old VNV model or whatever you want to call it, you can step to the right and we'll...

Geoff: Yeah.

Peter: will have a conversation but we're not here to find defects. And I do remember a company in the early 2000s I worked for, we tried a bit of predictability and we predicted in the latest version of the system we would have perhaps 110 defects based on what we'd had before. When I asked what if we don't find that many the project manager said we'll just keep testing until we do.

Geoff: Yes, yes. have exactly, I'll just sit there forever. It is awful when something like happens. Interestingly, one of the projects I worked on, was about halfway through my career at Legal in general. Oh, I mentioned the name twice now. But anyway, it's a good story.

Peter: Fabulous. Can I get on contract now, please? Yeah. twice now but yeah Hahaha

Geoff: I was initially the test manager and was fighting with the developers and we were screaming at each other in a room that we were creating a quotation system that was going to be one of a kind doing almost automatic underwriting for the first time. We were going to beat the market and get there first, but it had to be fast because it was going on these, know, compare themarket.com and if you're not fast, you don't get up there. So the whole point of that project was not only to build this system and all the different connections, which if you can imagine a large organization with hundreds of years of IT is very hard. It is a lot of connections that have to be responsive to get this happen. I argued that we needed to test each unit of code as it was built for performance. And I didn't know if that was right or wrong. What I was trying to do was encourage the developers to think about it. but the development manager refused to acknowledge that was relevant and felt it was best to leave it to me two weeks when we went live. Now, fortunately, I managed to get the performance test done about a month before we went live and it was awful. I can't remember the numbers now, but it was like a hundred times slower than it should be to get at the bottom of the list, if you know what I mean. So I went back to the development manager and we sat down and this time he was quite calm. He was actually quite nervous because of what had happened. And they actually dismantled the code right back to unit level and then retested every unit. When they put it together, guess what? Performance test just ran and we did it in subsonic. I can't, speak. We were perfect. came second in the queue and yet we were doing 45 times more activity than the man that was number one, if you know what I mean, because they were generic quotes rather than specific quotes. So it, in a way, The world of risk is a fascinating challenge and you say, there a risk? Now I might think there's a risk the development manager didn't see there was a risk at all. When he did see there was a risk, it was when it had actually become an issue. ⁓ A bang, you know, but next time he was the first to come to me and say, right, can we do the performance test early? Can I get the performance testers to help us build? know, there's a lot of unit level performance test tools out there that you can get hold of.

Peter: Yeah. Absolutely in this modern day and age as well and I've always said something because you know you and I have worked on hundreds of projects multiple versions multiple methodologies I doubt whether I could count on one hand the number of times code has been delivered complete in any of those projects and I will say one thing when when the pressure is on people code for functionality not performance

Geoff: Yes.

Peter: And that's why that full circling this to round everything up. That's why the shifting left of performance to me is really the value of shift left itself, because functionality should just be taken as read and fully unit tested and system tested, blah, blah, blah. I don't want to keep repeating myself, right? But that's again, my thoughts. very interested in anyone out there who's got any other thoughts on shift left, because it is. very much up to everybody's interpretation as many things are. But this has been a great deep dive into your past and your experience, Geoff, and my past and my experience. Maybe next week we'll have a guest lined up and they'll come and talk to us about their involvement in this wonderful world of quality and we're up to it. If not, it'll just be us two again thinking about something else.

Geoff: Yeah absolutely.

Peter: Awesome. Thanks for your time, Geoff, and welcome back from Mauritius. And we'll catch all of you guys in a couple of weeks.

Geoff: Thank you. Yeah, I look forward to it. Look forward to hearing from you all as well.

Peter: Beautiful. Thanks, everyone.