Making Quality Cool Again

1 - > You're listening to the People behind your Favorite Apps. This is a show for 2 - > software professionals looking for uplifting, impactful stories from every stage of the software development 3 - > life cycle. We'll share stories about app development successes and failures, and how 4 - > teens collaborate to develop software that makes tremendous impacts on the world around us. 5 - > Let's dive in.

Hello everybody, and welcome back to another episode of The 6 - > People Behind Your Favorite Apps. My name is Noel Worst. I'm the director 7 - > of storytelling here at smart Bear, and this is the last show we will 8 - > record in the year twenty twenty two. It probably will not air until twenty 9 - > twenty three.

So I am coming to you from the past with a conversation 10 - > that my co host Frank and I are very excited about having. Frank, 11 - > would you like to introduce yourself? Of course, Thanks Noel. My name 12 - > is Frank kil Commons.

I'm an API technical evangelist here at smart Beer, 13 - > and I'm Noel's trusty sidekick for our podcast. Thank you very much, Frank. 14 - > Just a quick reminder of the premise of the show. The show is 15 - > called The People Behind Your Favorite Apps, and it is about just that.

16 - > It is the people who make software great and get it out the door and 17 - > give it high quality and a rich user experience. And those roles we have 18 - > learned to these conversations span all sorts of departments. It's not just developers, 19 - > it's not just testers, it's not just the engineering department. It's ux and 20 - > even marketing and legal and finance and everyone else.

Everyone plays an important role 21 - > in the STLC. And so someone who oversees a number of those roles and 22 - > who Frank and I were very impressed by her experience and all that she oversees 23 - > and has seen, is Raisa Mohammed. Raisa, could you introduce yourself and 24 - > thank you so much for being here today. Thank you so much.

I'm 25 - > Raya Mohammed, technology executive at Bajuan Cybertech. Where a technology company that's headquartered 26 - > out of the Middle East North Africa region with offices globally, US, Asia 27 - > Pacific and so on. Is it out of the Dubai headquarters. And we're 28 - > a technology and services companies, so we build our own products as well as 29 - > implement solutions for end customers.

So, as you mentioned before, I've been 30 - > on both sides of the spectrum when it comes to interacting with customers and delivering 31 - > and producing software as well. In addition to that, we form joint ventures 32 - > with other companies. That's where we delve into the depths of industry, So 33 - > that allows us to understand an industry as well as develop the technology and solutions 34 - > for that three per se, and then we form strategic partnerships with vendors to 35 - > augment and complement the services and solution offerings that we bring to and delivered to 36 - > our customers.

So much work, so much to be responsible for time, 37 - > yeah, I know exactly, like so much to get to observe are you 38 - > and to get to see where things can be made more efficient or can be 39 - > improved. And one of the things that the three of us talked about in 40 - > our initial conversation was around our share interest in software quality and how there has 41 - > just always been a need for more education around software quality for everybody. Not 42 - > no one knows everything, no one has it all wrapped up and doesn't need 43 - > any further education.

It's certainly an area where it's a lifetime of education because 44 - > as software evolves and users and user expectations evolves, and technologies become increasingly more 45 - > increasingly complex, how to keep quality up, you know, as something where 46 - > there is always something new to learn there. So brace is going back to 47 - > what you said as being both a seeing both sides, and you also talked 48 - > about being both a producer and consumer of software. How do you feel about 49 - > the state of software quality today and maybe where some of that increased education is 50 - > needed.

Yeah, so it's it's an interesting question. And coming from being 51 - > a producers so working to meet customer requirements and so on, you understand the 52 - > importance of quality. You understand the importance of delivering excellence. And when you're 53 - > built thing that you also understand the stress of the timelines and deadlines where you 54 - > just have to deliver, deliver, deliver, And it's a double edged sword, 55 - > right.

And ever since we've been through you know, giving away my 56 - > age, or perhaps we've been through the waterfall cycle of you know, software 57 - > development and moving into the agile mode, it's almost as if agile has given 58 - > people a free pass, you know, because we deliver fixes so quickly, 59 - > because the next iteration is coming out. It's it's almost at the expense of 60 - > software quality. So testing is done, but it's done in a limited capacity. 61 - > Or if that breaks and we haven't yet got to that, let's just 62 - > push it out.

If a user pix it up the log a bug or 63 - > our famous Jura bless it, it will come in Jira and we'll fix it 64 - > so that it's as I use a lot of SaaS solutions now to either start 65 - > up new products and you know, to let's say, hasten the build process 66 - > and so on, or to make it more efficient. Rather you realize as 67 - > you're consuming them, wow, how did that one pass QA? You know, 68 - > how did that bug pass QA? So I, again, being on 69 - > both sides, I understand the need and the pressure.

So I'm not you 70 - > know, sitting on any high pedestal saying you know, or there's just slipped 71 - > pass QA and no one focuses on this. So I understand that, but 72 - > I almost I think we need to find a happy medium between the breath of 73 - > testing that's done and the education around what that actually entails across the rules, 74 - > across the software development life cycle, and I think I think we're almost strangled 75 - > by SDLC. The fact that it's called software development life cycle leads people to 76 - > think that, you know, it's it's all around the developers, that's where 77 - > the cool tech is at, and I often say it comes at the cost 78 - > and at the expense of testing.

Okay, So I think in general the 79 - > road is paved with good intention. And as we've seen, we're all kind 80 - > of transitioning maybe from from different flavors of implementation strategies, from like historical wall 81 - > of fall approaches into more agile ones now without turning this into kind of a 82 - > history lesson, you know, of course, there's there's different strategies that you 83 - > can apply. It can be stronger, it can be something else. But 84 - > the intention in any of those flavors of agile is never to introduce lower quality 85 - > software.

In fact, it's the opposite. It's about having closer interaction with 86 - > the in consumers and let's say the business stakeholders with regards to a software component, 87 - > involving them in the process and at the end hopefully getting to where we 88 - > want to be quicker and in a more collaborative manner. And so do you 89 - > think the challenges is an educational one or do you think it's even broader as 90 - > just this industry industry challenge with regards to how agile is is implemented, Because 91 - > what I've seen as well in certain enterprise settings is there will be this concerted 92 - > effort we have to move into agile, and that there will be trainings executed 93 - > and so on and so forth, But perhaps the coaching aspect of how you 94 - > actually practically then implement this outside of the classroom setting is maybe not invested in 95 - > properly, and it's too easy for companies to fall back into old habits and 96 - > start squeezing a waterfall approach into a shorter agile iteration cycle, which does not 97 - > work basically, as you've already pointed out.

So curious as to your thoughts 98 - > on is it an educational challenge, is it a broader industry one, and 99 - > what life is at the end of the tunnel potentially? Well, I think 100 - > there's more than a couple of challenges out there. I think sometimes we can 101 - > be the architects of our own downfall. Right, it's resistance by the people 102 - > we've always been doing it this way.

The moment something new is introduced, 103 - > there's a certain amount of resistance and works great, as with most things, 104 - > works great in theory and in actors. While there's lots to be learned. 105 - > So I think we've come a long way in implementing agile in an agile fashion, 106 - > you know, learning through that as well. Initially, I think you 107 - > hit the nail on the head when you said, you know, we took 108 - > waterfall and we started implementing it using which doesn't work.

And I think there's 109 - > been many lessons learned from that. But education is at the crux of this, 110 - > It's the absolute core of it. And you know, I see I 111 - > see education from from two aspects. One is around the whole importance of testing 112 - > and you know, ensuring the quality of what we deliver and what we develop, 113 - > as well as the education of what testing actually is to the stakeholders and 114 - > the importance of testing because it's often seen as a background task, you know 115 - > that's been done, so development is given because if you don't have something developed, 116 - > there's nothing to test.

So a lot of the focus is given to 117 - > the development. And I come from a development background. I'm a techie, 118 - > hardcore checky, right, so I know the mindset that comes with that as 119 - > well. You know, it's it's we've developed it and then we've thrown it 120 - > over the wall.

And in agile there's essentially no wall. So we're trying 121 - > to, you know, the whole education process firstly, bring everyone around the 122 - > table, not just past the buck. So it's no longer playing Chinese whispers 123 - > with requirements from you know, from business requirements gathering to the end delivery or 124 - > to production. It's more so gathering all the stakeholder holders around the table, 125 - > you know, also socializing the concept of testing and what's involved, you know, 126 - > the elements, the length, the breadth of testing.

You know, 127 - > from from a developer's perspective, if my API worked and it worked on my 128 - > machine, then it's going to work everywhere. It's going to work on every 129 - > browser, it's going to work on every device out there, and so on. 130 - > But very seldom is it actually understood that the vast testing that needs to 131 - > be conducted in order to actually ensure that that one piece of of or screen 132 - > that's developed actually works, or the one API that we've developed actually works many 133 - > times, not many.

Not a lot of the development team, or the 134 - > design team, or the architecture team for that matter, understand that testing, 135 - > the breath of testing, whether it's made up of integration testing, unit testing, 136 - > functional testing, security testing, acceptance testing, stress testing. I mean 137 - > I've even left a couple of that out there, you know. But the 138 - > education of the length and breadth and depth of the testing I think is really 139 - > important as well.

Yeah, I think it's it's such such an interesting kind 140 - > of approach, and I can completely understand for teams and for orcs that are 141 - > not used of, let's say, letting go of certain regimented control with regards 142 - > to transition through various states of a project into this more collaborative delivery process. 143 - > It can feel like things are becoming a little chaotic, but in but in 144 - > fact the opposite is true. You have much more control over your destiny working 145 - > in an agile fashion if there's trust and if people are playing their roles appropriately 146 - > because there is no ambiguity in what's being delivered.

It's like there's this like 147 - > I've worked in so many projects where the requirements have been minted three months in 148 - > advance or even longer in advance, there was no strict expiry data on requirements 149 - > to deliver the stuff, and like nobody actually wanted if there's this quote from 150 - > an unknown author, but I saw it come up again recently on someone's email 151 - > signature that they sent me, and it just came into my head now and 152 - > it was it's and the users exclaimed with a laugh and a taunt, it's 153 - > just what we ask for, but not what we want.

And that's just 154 - > a kind of that just represents, you know, the major risk that's there 155 - > with delivering in a water fall method. Plus, like, what's also really 156 - > good is being able to kind of tease out hypotheses with regards to MVPs and 157 - > then helping that shape the direction regards to where your software will evolve too, 158 - > which is much more suitable to an agile fashion because you don't want to go 159 - > to the end level of effort from a non functional requirement perspective into your quality 160 - > testing.

If you're rolling out an MVP of a certain feature that you're not 161 - > going to make GA or a mainstream or like globally available, you don't want 162 - > to have to go into all of that scalability testing or security testing until you're 163 - > sure that that's where how you want to evolve the software and put that investment 164 - > in the right place. So it gives you that freedom to focus on what's 165 - > important rather than be distracted by the breadth of what you have to cover from 166 - > a historical kind of development approach.

And it reminds me of another point with 167 - > regards to the socializing and the education around testing, it's often perceived as oh, 168 - > they're just there to find bugs, that's I mean, like I said, 169 - > I've been on the other side as well, so you know you understand 170 - > that when it's the proverbial thrown over the world for testing, it's it's a 171 - > matter of because there's no collective accountability across the project. You know, it's 172 - > just like, oh, the testing team is going to come back with a 173 - > bug, Whereas I think we can almost put a spin on that and look 174 - > at you know, king at it from a quality perspective, so understanding.

175 - > For example, if you take I think the famous story is a Starbucks. 176 - > You know, their point of sales system went down and they had lost out 177 - > I think a couple of million dollars in sales. You look at a very 178 - > well known automotive manufacturer who had a recall of I think a couple of million 179 - > cars because there was a software defect on one of their air bag senses. 180 - > That's all a testing on a quality, quality assurance issue.

So I think 181 - > I think there's a there's a little bit of polishing that we can do up 182 - > in terms of when we start a project, and the onus is on us, 183 - > It's on all of us to bring to cultivate a culture of collective accountability 184 - > to be to deliver quality that goes across the team. It's not just if 185 - > my piece of code or my development deliverable worked in dev and UET and production 186 - > at one point in time, then that's quality. You know, quality is 187 - > if we deliver successfully to the customer, Because when we deliver quality, it 188 - > elevates customer satisfaction and it builds trust with your customers.

And that's where the 189 - > objectivity of everyone, even to the development level, should lie. All Right, 190 - > So I know that we already have people listening, well, will this 191 - > is being recorded in the past. I know that we will have people listening 192 - > already at this point who believe all this and feel just as strongly about quality. 193 - > We talked about that reluctance to change a little while ago.

I'd love 194 - > to kind of get both of your opinions on this, but it reminds me 195 - > a couple jobs ago. I got was lucky enough to take part in Michael 196 - > Bolton's three day rapid software testing course and it was just amazing that it was 197 - > just an zing three days of like learning how to be a really great tester. 198 - > And when I first went in, I'm on the marketing team, and 199 - > when I first went in, I thought I was just there to eavesdrop, 200 - > and I was like sitting back in the corner.

And the very first activity, 201 - > he was like, why aren't you in a group And it was like, 202 - > oh, I'm just in marketing, I'm not actually a tester, and 203 - > he was like, half this room is in testers. And it was like 204 - > I didn't even know that. I just assumed, you know, those assumptions 205 - > that caused so many problems. But there was ux people in the room, 206 - > and there were graphic designers in the room and engineers and testers and product people, 207 - > and I just, you know, I was guilty already kind of making 208 - > those assumptions.

And I joined a group and all of my ideas were none 209 - > of the ideas that anyone else had. And then when we would share our 210 - > group's work, other groups would have thought of the ways to test this system 211 - > that no one in your group did, and it was just everyone's input became 212 - > so valuable, and I remember it was being so moving, And when I 213 - > got back to my own marketing team, telling them like, you got to 214 - > take this course, It's the greatest thing ever, and they were just like, 215 - > why would we take that?

And it was that same like I believe 216 - > I know where quality lies and who's responsible for it and it's not me? 217 - > And how I even contribute to something like that. I'm not a technical for 218 - > all that kind of stuff. There's there's reluctance and assumptions everywhere.

So when 219 - > you feel this passionately about it, what are some ways that you've you either 220 - > you yourselves or have seen other people effectively combat that reluctance to change or those 221 - > assumptions of what quality is and whose jab it is and why it's not theirs. 222 - > I'll take the first stab, but that I think, I think it's 223 - > skin in the game. You know, make make your teams, make your 224 - > project teams collectively accountable for the deliverable end to end.

So it's not even 225 - > though yes we say angile, but we have our teams right, we have 226 - > the developers, etc. It's collaboration. Make the developer and test to sit 227 - > together. One of the fundamental things is everyone needs to understand what they're building.

228 - > They need to understand how the user is actually going to consume that, 229 - > how the user is going to use it, interact with it, and also 230 - > understand the business outcomes. So what is my business trying to achieve with this 231 - > particular piece of software? Is it stickiness with the customer and so on. 232 - > Because by then you you were also as a tester as part of the testing 233 - > team, you're also able to identify your use cases to align with the business 234 - > outcomes.

It's not just testing an API regression testing. It's not just making 235 - > sure that it's works across a browser. It needs to be And when I 236 - > say skin in the game, it's it's incentivizing and it's not just from a 237 - > monetary or financial perspective, but it's tying that to the business outcomes that we 238 - > you know that the project has that ties this in and it needs to be 239 - > driven from from the top down as well as from the bottom up. I 240 - > think I've found that to be the best way you know, to bring it, 241 - > to bring it together, so to speak.

But I also have swapped 242 - > rules. Like you said, I've tried that, and I say, you 243 - > know, a day in the life of a tester, and it's only when 244 - > you feel the pain, that's when you realize that or you understand and you're 245 - > able to empathize with what the other person is supposed to do and all of 246 - > a sudden, and it's not that my responsibility is more important than yours, 247 - > because we've always seen, show me a project that's over budget and not on 248 - > time, and where does it lie?

It lies with testing. If I 249 - > had a dime for every time somebody told me this, I wouldn't be doing 250 - > the podcast. I don't know. And that's that's sort of the the the 251 - > mindset that we need to change and the whole the like I said, the 252 - > empathy of what testers do, and then also testers and the testing team understanding 253 - > what development does and the pressure that comes with that, and the technical challenges 254 - > that you face there as well.

And I think once once you craft that 255 - > out nicely, that's when everyone is able to collectively sit around the table, 256 - > collaborate and then deliver quality right brank anything out there. I think it was 257 - > summed up pretty well. I think the focus it has to be on accountability 258 - > and collaboration. Like what I've worked with teams in the past and trying to 259 - > be an advocate for is changing the UZZ and them into a wee because it's 260 - > it's we collectively that that delivered the software.

It's not the development against the 261 - > testers or the business analysts against the developers know they actually don't know what they 262 - > want. This is what we're going to build anyway, it is getting to 263 - > that shared understanding that we're in it together and we have to have that same 264 - > understanding like I think techniques like example mapping whether or not you want to go 265 - > into BDD type of delivery or TDD type of delivery, it's it's irrelevant.

266 - > It's getting a clear statement as to how the software should behave and making sure 267 - > that there's common understanding in that across the across the product side of the house, 268 - > the engineering side, and the testing side, making sure that everyone is 269 - > in it together, working towards delivering that software. Yeah, you just reminded 270 - > me of something, you know, the the the whole shift left movement that's 271 - > that's been born of late I think development deployment, you know, the continuous 272 - > CICD process.

We focused the focus was on, again the development and the 273 - > deployment. The testing was sort of left by the wayside. And now we're 274 - > seeing more and more the adoption of the shifting left for the testing movement and 275 - > that that again has both pros and cons and it's an education as well, 276 - > because when you shift left, all of a sudden, the developer says, 277 - > oh, okay, I've got to test this. Yeah, it just unitest 278 - > and everything is well with the world.

No, it's actually moving the entire 279 - > testing methodology to shift left. So it's all of the testing. You know, 280 - > it's continuous and we have to be slightly careful there in terms of when 281 - > we're testing in an agile fashion, we then test bits and pieces, but 282 - > we also have to remember to come back and test it from a holistic perspective. 283 - > So there is light at the end of the tunnel.

And I think 284 - > as education goes and as people learn from their projects and people aspire, everyone 285 - > aspires to deliver quality as they start to realize that. And also testing is 286 - > socialized in terms of what the concepts of testing are, what it involves, 287 - > and also making it cool again and making it more exciting with these bug bounties 288 - > that you see these days, and the hackathons that now involved testers they call 289 - > test athons and so on.

It's sort of, you know, it's we're 290 - > getting there with education as well as I think a cooler and a more exciting 291 - > approach to it. We're certainly seeing the adoption of the ship left movement from 292 - > a testing perspective as well. So that was a perfect lead in to my 293 - > next question. I'm going to put Frank on the spot.

One of my 294 - > favorite things to do, by the way, is to ask really smart people 295 - > questions and then just kind of like not piggyback off what they said, but 296 - > they always inspire my next answer. So we're going to let Frank take the 297 - > lead on this one because it was Frank in our last call that said that 298 - > we have to make quality cool. And while some people, if you ask 299 - > them what's cool about quality, some people might go accountability and like business outcomes, 300 - > but maybe not many.

So what are some ways to make quality cool 301 - > and not make accountability or business outcomes almost feel like not threatening, but like 302 - > intense, Like you have you better deliver accountability and you better deliver business outcomes. 303 - > What are some ways to just like think of the work that results in 304 - > that as being cool. What are some ways that people can get that mindset 305 - > or or if it's something else that they need to do for me? Well, 306 - > I don't think anyone you know, intentionally wants to put out boogie software, 307 - > Like, I don't think that intentionally happens.

I think I've been lucky 308 - > in working in software for most of my career that is not you know, 309 - > life or death orientated software, because I've let some houlders of bugs slip through 310 - > in my time. But there's a lot of satisfaction and kind of good morale 311 - > boosting use in being proud of what you're doing as a team to I think 312 - > getting getting the bar set in place that hey, this is the bar that 313 - > we're always going to adhere to, and getting that in place from the start 314 - > of the project.

Making sure that you're confident in your in yourself as a 315 - > team. Regards to voicing the importance of quality up the chain in an organization, 316 - > to say no, we're not going to jump just because ELT is shouting 317 - > loud for this particular thing. You know, we're not ready, it's not 318 - > meeting our standards. We're just not going to ship this out there.

And 319 - > that gives you the confidence thing to also understand twin it's okay to let things 320 - > out there because I think it's something we also say no, you know, 321 - > not every bug is worth fixing. You know. It's being able to have 322 - > that insight and understanding regards to how you're analyzing your code from a static perspective 323 - > where you put the focus on automation, where you put the focus still in 324 - > manual t seeing how you deal with security how you deal with performance and then 325 - > how you kind of build upon that in every cycle that you're doing.

I 326 - > think is something that you can be proud of. And when I've worked with 327 - > certain teams in the past, it's then trying to trying to not coerce them, 328 - > but try to kind of give them the confidence that they can take what 329 - > they're doing day and day out as a reference to other parts of the organization, 330 - > and then it actually makes them feel better again about what they're doing because 331 - > they can help educate within their company and they can become advocates for quality as 332 - > across different teams cross functionally as well.

Yeah, I love that, right. 333 - > So I was going to ask you, because we've kind of talked about 334 - > this as well, that people can be really really good at motivating people to 335 - > believe a certain way and getting people on board. We were talking earlier about 336 - > like the Agile Manifesto, Like it's hard to read that and not be like 337 - > ready to take the hill or some motivational speech. But then without those things 338 - > that you can actually put into practice and make those things possible, just the 339 - > motivation and the good intentions and the high morale, they all feel great, 340 - > but sometimes it's like actual things that need to be like built into your structure 341 - > or the way your teams are are are architected.

So what are some of 342 - > those things that people can do to start moving towards this mindset of making quality 343 - > cool and making everyone accountable and shared skin in the game. And what are 344 - > some of those next steps besides just like care enough that too up to do 345 - > that. I think focusing of automation and excellence is something that drives people a 346 - > lot of the times and clients that we see or when when we do things 347 - > and come across projects as well, a lot of a lot of the tasks 348 - > is on the manual side of it, and you know, other groups or 349 - > other departments or other teams get to use the latest software, they get to 350 - > use all of the cool toys, etc.

But when it comes to the 351 - > testing and the QUA, it's a lot of manual or it's just scripting, 352 - > et cetera. So automation needs to be introduced and excellence and when when people 353 - > when you testing can sometimes be perceived as boring and mundane. You know that 354 - > that is what we hear from from members that that's that's the corridor talk. 355 - > And I think when you introduced tools, when you introduce an automation of the 356 - > or sequence of automation that they can implement, and they there's there's this there's 357 - > this level of satisfaction of getting more done and being more productive.

And I 358 - > think then that's also a motive to be able to excel, to be able 359 - > to deliver higher quality, and to be able to be more vested in the 360 - > project and deliver. Now there are other I think maybe programs or like like 361 - > I spoke about Testathon's earlier, or bug bounties and so on. So I 362 - > think that that sort of almost needs to be introduced and can be introduced in 363 - > projects just to make it fun as well. Also, I know sometimes when 364 - > some of the test cases pass without there being a failure, you know, 365 - > the developer is hailed as well.

So you bring just not when something goes 366 - > wrong, but when it goes right, you recognize that. So, I 367 - > mean, we don't have all of the answers, but that's what we see 368 - > and try and and those things and incremental steps. Yeah, keeping it fun 369 - > is part of what makes it cool as well. You know, it can't 370 - > be an afterthought.

It has to be ingrained into the culture of the team 371 - > and those fun tactics or it reminds me of one. This is probably going 372 - > back a decade ago. I'm trying to even think of. Cruise Control was 373 - > the automation tool for buildings, So that tells you how long ago it is.

374 - > But in our team at the time, if you broke the build, 375 - > you had to change your email signature and I am signature to build breaker and 376 - > that was with you up until the next time someone broke. So the stakes 377 - > are wow, But it's part part of the fun. It's you know, 378 - > it's part of having that good, good culture around quality. It's just what 379 - > makes it, what makes it work.

Yeah, it staves Yeah, it 380 - > staves off the stigma, like you say, right when everyone is socialized to 381 - > it, et cetera, and you can go around having such fun email addresses 382 - > or im names because it's no longer associated with the stigma. It's it's part 383 - > of what we do. Yeah, and it's a learning opportunity. I mean 384 - > one of our our own marketing team here.

Every month we have these spot 385 - > awards and just as a like communications cultural like junkie. It's so funny to 386 - > me. One of them is like the failure of like the marketing fail of 387 - > the month, and people are really reluctant to contribute one, and it's the 388 - > intention is to like share one and say, like what you learned from it, 389 - > Like you're not going to do that fail again. It was so like 390 - > striking to you because what you learned and why it didn't work, like you 391 - > would never repeat that.

So by like sharing the failure, you could help 392 - > someone else not then make that failure because they did know that that had already 393 - > been tried. And so whenever there's a month where someone doesn't introduce one, 394 - > I'm just like, part well, number one, I take the blame for 395 - > that, partially because I make failures every month and it's like, well I 396 - > didn't submit one either, And so like eliminating that stigma of like being afraid 397 - > to report, like yeah, this was on me, Like here's how I 398 - > made it, Here's why it was overlooked, or here's what it happened, 399 - > like here's why it won't happen again, Like those are really big learning opportunities, 400 - > and so removing that stigma of like it's okay to have a signature line 401 - > building Like I'm just thinking of my own signature line of like typo introducer or 402 - > something like that of like oh my god, what if I had to do 403 - > that.

But it's like, lighten up, you fixed it, Like I 404 - > love that. I really like that a lot. Very cool. Well, 405 - > we talked about accountability a lot.

That was what I was going to talk 406 - > about next. So I mean we can probably just move on to kind of 407 - > this next section here of like let's again think about those folks who maybe maybe 408 - > they weren't on board earlier when I thought that our ten minutes of brilliance was 409 - > enough to already convince everybody. But for those folks now who are like I 410 - > get it, we need a more shared understanding of quality. We need greater 411 - > participation.

It shouldn't just beyond the debs. It shouldn't just be on the 412 - > testers. It's not just going to get solved with this one step. What 413 - > are some of those kind of like next steps of like, after you listen 414 - > to this, have this conversation, or who's a person maybe you should reach 415 - > out to for more support.

If it can't just be you trying to rally 416 - > the troops, where should you go for more more people to kind of back 417 - > you up on this and try to change the mindset, the culture or whatever 418 - > it is that needs to be changed in someone's org. Yeah wow, and 419 - > it's going to be different in every org. But just as like for someone 420 - > who's like I'm ready, like give me one thing I can do today or 421 - > like make some progress, whether what's an early stage step that either you took 422 - > or that you've seen taken.

Automation that's one of yeah, you know, 423 - > and using tools to automate what we do, apart from just writing scroops, 424 - > getting being able to get things done faster is such a huge boost in terms 425 - > of your morale, in terms of your sense of achievement and so on. 426 - > So automation has been the key when we introduce tools automate testing, whether it's 427 - > and I'm talking about companies and enterprises that still have people testing their websites in 428 - > a non automated fashion, so everything is done manually.

It is absolutely cumbersome. 429 - > So introduce some sense of automation. And it doesn't have to be you 430 - > know, the boll or end or start with one area. That is, 431 - > if if you focus on mobile apps, so if you focus on desktop or 432 - > web testing, etc.

Choose pick your poison, as I like to say, 433 - > and then start there because it is everybody's business and really it needs to 434 - > be the advocates for the delivery need to sort of carry the message up it 435 - > needs to be delivered up as well. They sort of need to I can 436 - > envision them walking around with loudspeakers going. Quality is important because again I'll say 437 - > this again, I probably sound like a stuck tape recorder here, but it 438 - > elevates customer satisfaction.

It increased trust, which then delivers a competitive advantage. 439 - > So quality can be seen as a competitive advantage. And that's that's a CEO 440 - > level priority, right, That is everybody's business in the organization. So that's 441 - > that's where i'd start, you know, as as a first step in terms 442 - > of who you should come to.

Wow, well, i'll take the little 443 - > bit of you right, come to us. There's always a room for shameless 444 - > plus right. But I think what you say is is absolutely so. You 445 - > have to be committed to being able to repeat your process consistently if you want 446 - > to look to try and improve your process, and teams need to be given 447 - > the freedom to invest in automating part of that so that they can prove out 448 - > is it's safe to make this change and framing like the pressures and stresses of 449 - > every will hit every team.

But I think it would be definitely the let's 450 - > say, not the norm to voice the concern upwards to say, well, 451 - > do you want us to do this at the risk of not being able to 452 - > deliver it to the appropriate level of quality. Probably the executive leadership would not 453 - > say yes, do that. So it's about having clear communication. They're not 454 - > taking shortcuts for the sake of shortcuts.

Try to incrementally improve that process, 455 - > and if you want to be very tactile about it, have a good understanding 456 - > of what parts of your code basis changed most frequently and focus on getting automation 457 - > set up in those areas. There's plenty of kind of get up scripts you 458 - > can run to get an overview of that. There's complexity analysis you can do 459 - > to understand the most complex parts of your code, and if it's an intersection 460 - > between frequently changing and complaint, then probably that's an area that's good to start 461 - > on with regards to getting a good baseline for repeatable automated testing.

Another thing 462 - > that we've been doing here lately, like as of like only a couple of 463 - > weeks ago, is thinking of ways to really as a tool vendor, like 464 - > thinking of ways to make testers, developers whoever it is that's using our tools 465 - > or purchasing our tools like the Hero and not the tool itself. Because we're 466 - > big on automation as well, we absolutely could see areas throughout the STLC of 467 - > where automation is a huge benefit, like you were saying, but then making 468 - > sure that like that tester, that developer doesn't isn't already thinking like but that's 469 - > my job, Like that's what I do, and if it's just un by 470 - > a tool, they won't need meet like that kind of thing, Like we 471 - > don't want that mindset to exist out there, and that like by even seeing 472 - > like you just said, right, so the opportunity to make something more efficient, 473 - > able to meet you know, a delivery date at a level of quality.

474 - > You know that it's that individual that recognize that opportunity to improve thing and 475 - > who introduced this thing and who brought this tool and to be evaluated whatever the 476 - > case may be, really making sure they get the credit for caring that much 477 - > as opposed to like everyone go tell the tool that did a good job like 478 - > that kind of thing. It's it's the person who who saw the need for 479 - > the tool. It's not the tool that just came in and did all the 480 - > work and deserves all the credit accordingly.

That's great. I think we covered 481 - > everything. It was really awesome. Thank you so much for Racer for being 482 - > here.

Really appreciated thank you. I absolutely enjoyed it. It was great. 483 - > And then before we go, Frank always likes to ask a fun question 484 - > here at the end, so I will let Frank do that.

Yes, 485 - > of course, So just wondering, yesa, what are some of your favorite 486 - > apps to use? Favorite apps? Personal, professional, can be anything, 487 - > everything's really yeah. Personally, when I just moved to to Google Maps right 488 - > that I kept getting lost to Google Maps was my favorite app, and now 489 - > it has to be Dubai now that it has one hundred and thirty versus you 490 - > know, across government, utilities, et cetera.

So that's an example of 491 - > an app that has created stickiness with the user. So that's that's my favorite 492 - > at the moment. The other's games to de stress, type Shift being the 493 - > latest. So yeah, type shift, yeah, built with type script probably.

494 - > Sorry. Now those superhapps are really taking over. They're they're getting so 495 - > so popular. They're really getting you there, keeping you there, letting you 496 - > do everything from order your groceries to you know, sorry natural personal finances, 497 - > they're they're they're keeping you, there're paying my fines.

Yes, yeah, 498 - > and and you know, it's it's really it's when you look at the evolution 499 - > of these apps. So we've come through platforms and so on. It's really 500 - > about how you create digital stick economy, stickness, right, So they've created 501 - > a digital economy within this application, and there's a sense of sharing, you 502 - > know, across the apps and across the services, etc. So it's it's 503 - > a lot of you know, a thought has gone into it.

So that's 504 - > that's pretty cool. I spend a lot of time on this. I'm not 505 - > a big social user, so it's never going to be one of the social 506 - > apps. But yeah, anything that helps you get your work done with less 507 - > stress and that the game the games are still there because it's never going to 508 - > all go away.

You're always going to need the downtime for sure. Well, 509 - > thank you so much again, this was great. Really appreciate having on 510 - > the show. Again.

That the new year will have already begun by the 511 - > time this episode comes out, so it's still appropriate to wish you a happy 512 - > new year and helpe that twenty twenty three is a good one for you and 513 - > to everyone listening. We hope twenty twenty three is off to a great start 514 - > for you, and we hope that you come back for more episodes of the 515 - > people behind your favorite apps. Smart Beer Solutions streamline the development and testing processes 516 - > for more than sixteen million software professionals around the globe.

Our mission is to 517 - > be the first choice for software teenes of all sizes, providing them with tools 518 - > that enable the development and delivery of world class applications. Learn more at smartbare 519 - > dot com. You've been listening to the people behind your favorite apps. If 520 - > you like what you've heard, please rate the show and share it with a 521 - > friend so we can deliver these memorable software development and testing stories to as many 522 - > people as possible.

Thanks for listening. Until next time.