Talking with Nalin Parbhu about the software evolution towards more test automation and the creation of Infuse and useMango. We talk a software development and “left shift” where automated tests and quality checks have moved earlier into the software lifecycle.
Transcript for episode 139 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 Today’s episode is a really fun talk with Nolan and Ola from Infused about agile software development and automated testing and shifting quality to every part of the software development cycle.
00:00:25 Welcome to Testing Code.
00:00:36 I’ve got a couple of people today on the podcast from Infused, and it’s a test automation. Actually, I think it’s a test automation company. I’ve just learned a little bit about it, but I’ve got Nolan and Ola. Is that right?
00:00:51 Yes.
00:00:51 We’re going to talk about test automation, but before we get started, I’d like to know a little bit about both of you. So, Nolan, can you introduce yourself?
00:00:59 Yeah, sure. My name is Nalan Harvey. I’m from a town called Leicester, which a few years ago was famous for winning the Premier League soccer title here against all the odds and small provincial club, basically. I’ve been in London 20 years, educated in London, studied the math degree, and I’m the CEO of Infused Consulting. Cool.
00:01:20 And Ola.
00:01:21 Hi. My name is Ola Mihala, and I’m actually a newbie in software testing. Originally, my background is more in social Sciences, but I was employed in interviews, and now I’m a software I sell software, software testing tools. And yeah, I’m just here to learn and hear the new information that’s out there.
00:01:43 Well, that’s awesome. And Nolan is going to help us with learning more about test automation, and it’s something I’m passionate about as well. So I’m really excited to hear somebody else’s perspective.
00:01:54 Well, let’s jump into test automation. So are you the CTO or CEO? What’s your title again?
00:02:00 I kind of have a couple of titles.
00:02:03 I’m what I call the CEO, but I don’t do much executive work. It’s more chief everything officer.
00:02:08 We are there. We are a 20 year old startup. Right. So we’re not a massive company. We’re about 50 people doing here in India. And I still take a very active role in terms of product development, in terms of looking at the market and the strategy and where we need to go as a business.
00:02:28 And then I get involved the other bits, right, to the sales, the marketing, what I call the everything bit. And then from time to time, I do a bit of executive work.
00:02:36 Right.
00:02:36 But really, I would say I’m still in chief everything mode.
00:02:40 Chief executive mode.
00:02:41 Okay.
00:02:43 So have you been with Infused for the whole duration?
00:02:46 I am, yeah. I’m one of the founders and the owner. I started the business in a place called Canada Water in London 18 years ago in my lounge, and I’m actually sitting in our original office as we speak, which is my spare bedroom. We’ve now moved to the more modern climbs of an area called Shoreditch, which is a bit of a hipster town and village, although abandoned at the moment during covered times. But it’s a bit of a fun part of town, a bit like your meatBack district in New York.
00:03:16 Okay, how did you get into test automation in the first place?
00:03:20 It’s a funny journey, I think. I’m 47 year old Brian. So you don’t design part of a testing career when you’re 27, 28, 29. I got into it at a young age, coding and stuff on the BBC Micro model B. I don’t know if you remember these machines, but in the US, but there was coding and basic as a young lad and then got into the maths degree and then still coding in that, and then basically did a Masters and thought, well, I’ll be CTO, I’m a CIO, and I’ll be my career.
00:03:55 And I was working in a town called Coventry, and I apologize to my West Midland friend down the road, but I didn’t like it. Right. Not very nice place. I’ve been in London seven years, and I was desperate to get into London. So I applied for a job for a company based in Northwest, in a town called Preston, which is near Manchester. And they said they were opening a London office. So I went up there and I presented some ideas around componentization of software and APIs and how things will be plug and play. And I said, you can have the job. And I thought, yeah, this is great. They go, you’re going to be a consultant? I go, that sounds great, being a consultant. 26 years old. And then they put me on this course for a product called Test Director. If anyone’s been around testing long enough by Mercury, which became microphone today, I was like, Damn, Esther, right? Not what I wanted to be.
00:04:46 And my father said to me, don’t discount it.
00:04:50 You might find a niche. So give it a go. Right before you quit on day week one, I gave it a few months and found the opportunities offered by tools like Win Runner. Started working with embedded systems and then automated testing of embedded systems and working in automated testing of tickets, machines, ticketing gates, and all sorts of interesting, fun coding, nerdy stuff, really. So I found a niche and it was complicated, it was challenging. And so I thought, it’s really good fun. And then the company I work for, which is a testing company, wanted to put me on manual test projects. I spend a lot of time writing scripts to automate it sales guy, and I would have lots of fights because I’d ruin all the billing, right?
00:05:34 You meant to do it manually.
00:05:36 I’ve automated it.
00:05:38 Well, you’ve ruined the billing. And I’d be like, well, in these projects, that’s how it went on.
00:05:46 This should do it like auto mechanics do and just have a fixed hour per thing, even if it only takes five minutes. It’s billed as an hour or something like that.
00:05:57 Output based testing, right.
00:05:59 Finish the job, whether it’s in a month or a day, $500, right. Or whatever. Right? Yeah. So this happened a few times, so I ended up climbing the testing ladder as a test manager trying to create a revolution, going every company I was doing it to automate all your testing. And then obviously the rest of the program team would go, yeah, you can do that. Right. At the end when we’ve screwed everything up a little bit budget do some automated regression tests. That was my frustration for many years. Right. Brian and I had visions like I can integrate this into old build tools like Ant, if you remember them back in the early two thousands and stuff like that. Those are the kind of things I was going, right, let’s use these build tools. Let’s integrate automated testing. Let’s do load testing within the container and all this stuff. And no one really wants to listen to that. They said, no, just test at the end. Right. And do your performance testing at the end and your regression testing at the end.
00:06:53 Oh, dear. Okay.
00:06:54 And that was kind of the story of testing, really.
00:06:58 I thought now around what time when was this? Or about what year?
00:07:03 So this would have been about 1998 to 2001. Okay. That sounds better. This is all going on, right.
00:07:11 And so I started Infused in February 2002.
00:07:13 Okay.
00:07:14 And the vision was really an automated testing company. It will be performance testing. We’ll hire technical people. We’ll hire these people called solution engineers, and there will be a little bit of their technical testers. They’ll be able to see the life cycle and there’ll be a change and revolutionize the world in small pockets. We were able to do that. Right. But on the large program, the large companies you’re Fortune 500 put to 100 companies yet to toe the line with all the big system integrators. Right.
00:07:45 It takes a long time to change the behavior of a big company. It does.
00:07:48 Yeah.
00:07:50 The timing was interesting, if I remember right. Late 90s ideas like extreme programming and notions from Pragmatic and stuff were coming in and lean programming and stuff like that, we’re helping to legitimize software testing or automated testing. At least there were at least some efforts to do more automation in the development cycles.
00:08:14 Yeah. No, you’re right.
00:08:17 One of the jobs I did do in the late 90s was with a bunch of guys where we were practicing XP, doing pair programming, sitting down and working closely with developers and business people, what I would call early forms of scrum, really. Right. Trying to work collaboratively. That was in a start up environment in what I call the legacy environment, the corporate environment. It was very different.
00:08:42 Yeah, definitely. I know this interview isn’t about me working for large companies, essentially small groups within large companies. Pretty much my entire career started in 96. But the push for automation has been development a developer effort, I think, because it’s just a faster way to develop stuff, to automate your tests.
00:09:04 You’re right, Brian. Yeah, it’s definitely been a push. I think the modern developer. And there’s been a lot of guys around that sort of vintage around between 96 and 2000.
00:09:17 They’re kind of around between 45 and 50 years old today. Right. And there was a big push around trying to do sort of a TDD test driven development back in those days. Right. Which is where we sat down and we would do the pair programming. We look to design the test earlier on, get involved with the business and drive you’re. Right. Without the effort of the developer community, promote automated testing the business. By the time you get testing, you need to automate it’s already too late. Right. Because you’ve already shipped the code. The actual efficiency is early in the lifecycle writing those API tests, those unit tests. So developers really had to get bought into this situation to make it work, make it fly, and it’s through that change in engagement, to be honest, that actually users had some more success because we now engage with a community that speaks similar language. Right. We engage with technical people.
00:10:13 Previously I had a customer, our customer was ahead of testing a program test manager. Now our customer is the head of engineering.
00:10:20 Interesting.
00:10:21 And that helps. And that head of engineering person is a strong believer of, okay, you do automated testing. I want to hear what you can help me with estimates and frameworks and efficiencies in driving quality engineering. And those were stories that you didn’t hear from your traditional test manager. Right. Because he was receiving the waterfall model or the V model of testing would say one thing, but the reality was testers got chip code and the requirements. They had very little input into it, even though they should have been involved. Right. They were like going, but the requirements are rubbish and the code’s rubbish. Well, it doesn’t matter. Just test it, right? It doesn’t go live. It’s going to be your fault.
00:11:00 I was always mused by the V model. So they basically take the waterfall model and then put a bend in it halfway through and call it something different.
00:11:10 It’s the same thing. It’s just got a bend in it.
00:11:16 Thank you PyCharm for sponsoring this episode. I first tried PyCharm when they started supporting pytest many years ago. Their support for pytest is now amazing. I was a longtime Vim user, so next I needed to test the idea Vim plugin so all of my finger muscle memory still worked while editing.
00:11:33 Check.
00:11:33 It works great. There’s lots of reasons to love by PyCharm, but for me it is because they have the absolute best user interface for test automation. Then I learned many more ways PyCharm can save me time. Like really great support for editing Markdown, HTML, CSS and JavaScript remote connections to database and amazing version control support. Really. It’s the best Get diff tool I’ve ever used. And now version 2023 is out and the shift shift, the find anything key sequence, even lets you search, get commit messages. What even that is so awesome. Tons of other cool features have been added in 2023. Check it out and I hope you enjoy it at testandcode.com. Pycharm.
00:12:20 A lot of your career sounds like or at least your early career was fighting against the inertia of relying on manual testing.
00:12:29 Yeah. The thing about is that we were always about automation performance. So naturally in the early start, early part of our company career updates what I call the infused 1.0 days between 2002 and 2009. A lot of the work you pick up is at the end of the project. So you know about a big program at work and it’s going to run for three years but your opportunity was going to come to an years down the line because that’s when they were interested in automation. We never set out to supply what we call two Bob pay Penny testers, right. Or two cent testers you may call them in the US. Right. Which is a bunch of testers, they’re all manual, they’ll follow this process and they’ll execute it and they’ll run it 50 times. Right. Or however and will scale up. My business vision was never to deliver that. It was to drive innovation by shifting left and I just felt at the time that my vision and state of what I call the delivery at the time just wasn’t there and I think now we are in a better line place with where it deliveries going. They want to do a job, they want to devote, they want testers to get involved in the story.
00:13:42 There are ceremonies like three Amigos and they’re really important and the teams aren’t 200 people, they’re like squads of 1012, right. Or even less and that seems to work better.
00:13:55 I’m going to take a quick just because you brought up the phrase shift left and I don’t think we’ve ever defined it on the show so far. What’s your notion of what shift left means to me?
00:14:05 Shift left is about looking at the cause and start of quality. Right. And shift left is all about starting off with quality and often people think that starts off with requirements and it does. Right. But actually my view starts off with architecture, right. That starts off the notion of you can have a tough architecture and great requirements and not going to be very good. Right. Choices like an integration platform whether you go ESP or whether you go or something else. We’ll make big decisions make big impact on your applications. Right. So you could go something like a confluence or you could go for a traditional ESP platform and you could Scop your great program just through choice of architectural choice. Right. And that’s not necessarily a requirement or business requirements based decision to me the shift left starts, that’s where it starts. It’s about implementing quality decisions, choices and requirements throughout the software engineering process.
00:15:07 Right. So we’re shifting that quality behavior left through. If we consider the lifecycle of a product from left to right or shifting the quality ideas as far left as we can and actually throughout the whole thing, just smearing quality all over the place, correct?
00:15:24 Yeah.
00:15:25 Not like Nutella, but yeah, I think the buying for quality is coming at a business level. If you’re going to buy a house, you want to say build it with bridge, even a Minister would say, okay, we would have input into the quality of some of those decisions. In it, an executive, a finance person or CEO will kind of not have an input into that and should be a little bit accountable for those quality decisions. Right.
00:15:58 You’re right. It is smearing quality up the chain and making everyone accountable as a team for that quality output.
00:16:07 I think of it also is being able to utilize starting to build the test automation as soon as you can because then you can use it as regression, you can keep running it. And the other thing is around that is you can discover problems and solve them when you have enough time to solve them, like API decisions. Sometimes if you’ve already got partner companies looking at your product, maybe that’s too late to change an API. So you want to be testing far earlier than that.
00:16:40 One of the other things that you brought up in the conversation was the two titles, developer and tester. And I kind of think of those as merging into one. But there’s a lot of companies that still have those very separate.
00:16:55 Yeah. I used to have a guy when I was first developing, I was writing APIs for a side company, Ballmans. They make a site called Strongbow UK. It’s quite famous. And I was writing these API’s for them, or interfaces as they were at the time in the lab. And every time there was a defect in my code, the test used to come up and he used to always dress like in the Blues Brothers black suit. And when he found a defect, he used to put on the hat, put in the shade, and come over to my desk. Right. And that was kind of a good fun way of kind of doing testing. Come over, you see him coming in the corner of your eye. He was quite a robust chat, right. Big chat.
00:17:35 You see him walking towards you and you’re like going, damn, he’s found something, right.
00:17:43 The aim was always like, I don’t want him to put in the hat, but it was quite good fun to work in that type of environment. There is a melding of the two. You know, people have estab.
00:17:54 I think there still needs to be some separation, though, right? Because they are two different qualities.
00:18:00 Because you’ve got the person that writes the code and you’ve got the person that kind of needs to validate that code is written to requirements, meet the user story, is written in a good way. Unit test is well written and executed and then looks at it from a different point of view, I don’t think this is particularly a mindset issue. It’s more of a focus issue in a mode where you’re creating code and you’re writing functions that you need to go in a certain way.
00:18:28 So I think the line of separation, I think there is what I call this there is a merger of the two, but I still think there’s a separation of roles within the team of the quality engineer and the developer, the software engineer. I advocate myself that people should have the skills to do all the roles and also there’s no harm in people.
00:18:51 Right. In terms of context switching. Yeah, all those roles.
00:18:55 So maybe it does make sense to have the roles still there in some cases, but the skill sets are very similar because with automated testing, the person writing the tests is writing software. They’re just writing software to test other software. Correct.
00:19:13 I’m in agreement.
00:19:14 There are some companies that treat, like you said, like an SDET sort of thing, software developer and test, and that’s thought of in some companies as a superset, like somebody that has all the software skills, but they also have this testing mindset that is good, and they know how to do all of that and talk with people. There’s communication skills as well that go along with that. So it’s a superset. But there are other companies still, I think, or at least there have been that I’ve seen in my past career that still think of the software testing role as a lower thing.
00:19:51 But maybe that’s just a US thing and international it isn’t, Brian.
00:19:56 It’s definitely here and definitely in India.
00:20:02 I think it’s an international thing. I think we have seen some of our estate leave and say, I want to be a developer, you are writing code, but I want to write apps.
00:20:15 I’ve lost talent to inverted commas, the development community. Right.
00:20:20 Yeah.
00:20:21 And I’m like, but you let code infuse, right. Through automated tests, you’re a developer. Right? Like, well, I want to go. Right. And I’m like, I guess it’s just a question of there’s a bit of a mindset issue. But I think also within the challenges for the big companies that have teams of testers or lots of testers, what I call those, not the small companies because they are a bit more adaptable, but what I call the medium and larger companies, they’ve got these reams of testers with lots of business knowledge. They’ve been there lots of years, and they need to repurpose these people into this modern world of smaller teams. And iterative life cycles. So there’s some of that. Right. I think it’s just going to be a natural shift over time where I think these things will move. So in our product team at Use Mango, we don’t have a classic tester role. All developers do.
00:21:14 So we’ve got all six of them. They all do testing. There’s no classic role. Right? Okay. And they all do DevOps, they all do infrastructure as code. They all do development, and they all do testing. I have on occasion going to our principal product architect, I said, do you need a test? And code goes to me, we’re all testers. Okay.
00:21:40 And they’re doing stuff right.
00:21:41 Do I need another person? Yes, I’ll take another person.
00:21:43 I’ll take another person. I’ll take another person. And they’ve got to do all roles. Right.
00:21:49 Sounds great. And actually, I think it’s more fun because there are times I like to jump back and forth. I do both. I think they’re both fun. And some days I’m feeling like being picky and writing a bunch of tests. And sometimes I feel like I need to just focus on C Code and stuff like that.
00:22:07 But one of the things I was curious about is this.
00:22:12 I want to make sure that we cover a couple of things. One of them is really what is automated testing different than manual? And then also, how are we doing in your view of it, the world, as much as you can determine, are we getting better as a whole as a software development community and doing test automation? Let’s start with what it is you said you used to get hired at the end and people would say automate our tests. What does that mean?
00:22:44 So automated testing still is today, which I know will cover a little bit. But automated testing, and I’ve heard the phrase DevOps in North America customers and UK by both nationally, effectively being regression testing, mainly around the UI, what I call the upside down pyramid. Right. Where there’s a low coverage of unit tests, low coverage of API tests and testing validation is done through the black box, which is normally through the UI, typically done by business users or by specific manual testing specialists, using text written scripts, using written procedures, executing the same thing again and again and again. And so whenever her automated testing and automated testing projects that we sold for the first seven or eight years. Right.
00:23:37 I’ve got 400 regression test scripts to automate them. I run them once a quarter, once a month, whatever it is. And I want to get that time down and free up these resources. That’s kind of automated testing has been now it covers the whole classes of testing, not to be confused by English plastic, that one’s better than the other, but different types of testing. Right.
00:24:03 You got unit test covers the smallest increment of code, typically white box written by developer. You’ve got the API testing and then you’ve got still some UI testing, but it’s normally quite basic. And then you’ve got the concept of end to end, which is kind of your traditional black box UI testing. But the premise of that being that you have a larger coverage towards the bottom of that pyramid. Unit and API and system testing and then less coverage from the end perspective depending on things like unit test coverage and also business confidence. Right. And then typically from that point of view, you still get UAT face, especially on large project. Businesses will still want to do their UAT to validate that this process is fit their purpose. Right.
00:24:51 Uat, what’s that?
00:24:52 That’s user acceptance testing normally done by business uses. Right. Okay, so that’s typically still done outside Sprint in large programs anyway. That I see. That’s kind of what I see. The other thing I’ve seen is what we call the Mullet. I don’t know, the Mullet is kind of got short thing in the front and long flowy bits at the back, which is what we call a child at the front and waterfall at the back.
00:25:18 I call that the Mullet methodology. Right. So you do your unit testing, us testing typically within your Agile, Sprint. It then drops out into what I call a system integration testing. And UAT as a horrific word. They call it Sprint, but I want to call it the waterfall bit where you do system integration in UAT and they follow and then if there’s any defects raise it goes back into Sprint as backlog items.
00:25:43 I love that. I’ve also heard water wheel. That might be different. So the water wheel was requirements go in and then a Scrum team pretends that they’re doing Agile and then they spit it out to the tester at the end.
00:25:58 Cio five years ago, talk about we’re not doing a job with A, we’re doing Agile with the small A. It was a very interesting education in the Alphabet of capitalization.
00:26:09 I have no clue what he was talking about. Right. Just, okay, whatever me, he was from one of those large system integrated companies where they have a lot of phrases thrown out of Mike Mullet.
00:26:25 I like the Mullet method. I’m going to use that.
00:26:27 That’s kind of how I’ve seen test automation kind of go. In terms of what we see now in terms of projects, we see a combination of both that we see a demand for estate joint Scrum team to kind of come to help out in testing backlog. We also see people who are transitioning to waterfall, but they’ve got a legacy of end to end test in the UI. So they’re trying to do that sort of regression test, automate that regression test while trying to keep all the new tests automated as well. The other thing I’ve seen is I’ve seen within Scrum team, they’ve changed the sort of approach and change the organization, but the people refuse to change. Right. So I’ve heard developers saying I’m not writing unit tests. So that stops me creating which kind of buggers up things, really. Right.
00:27:14 Because it’s like, okay, well, you still want to create.
00:27:17 That happens as well. So there’s all sorts of funny vagaries that even if you’re doing capital a agile or lowercase a Agile or whatever it is. Right. The people still don’t change. I think a lot of people, as I speak to executives, I always say you can’t change the people. Change the people. Right.
00:27:35 Yeah.
00:27:36 Interesting. I haven’t heard that before. I had heard before, if you can’t change your company, then change your company.
00:27:42 I have a question. What was described as agile team like agile transformation?
00:27:48 I hear about it a lot. I see it a lot. How do you describe it?
00:27:52 Agile manifesto happened. Yeah, I don’t know, 80s, 90s, and there were a lot of people trying to work on lightweight processes like, similar to Scrum was one of them. But there’s many that fall under this category. These are basically reactions to waterfall and reactions to the idea of doing massive design upfront and then developing. So the more notion it’s an Iterative process. So really, a lot of people think of all of the Iterative processes as sort of agile because we can take a little bit of the requirements that we’ve got and fine tune them, implement them and do what. I think of an Agile team as somebody that’s doing testing throughout development and then biting off a little piece of the requirements at a time, making sure these are clean and always having DevOps is kind of part of it is always having a working solution throughout the whole thing. But really what an Agile team is.
00:28:50 Some people say, if I’m using Jira, I’m an Agile team. Naland, do you have a different take on this?
00:28:56 Yeah.
00:28:57 Anyone using Canvan, right? They could be using Trello and they’re like or anyone that uses a post it note. I got post it notes now. So therefore Agile. Right? I have seen it. I have seen it. That ridiculous. I agree with you, Brian.
00:29:12 The point around Agile is set up practices to kind of create small releases of working product rather than spending $5 million in 19 months and the business has changed. Right. So basically the ordering system for the Blockbuster, while Netflix taking over the world is probably not what you want to spend more money on, right. Then it’s about recognizing those changes in need and adapting to it.
00:29:39 For me, being able to adapt is a key part of it because that’s where the name Agile kind of comes from. The agility of being able to change course quickly if any process during the fight like an end to end test or close to end. And if you’re using API and you find that it’s clunky and you want to change the API, if there’s no way to do that because of all the process involved, I don’t think you can consider yourself Agile. That’s a personal litmus test of my own.
00:30:10 Right. And I see a lot of people think there’s a lot of what I call mispronunciation of Agile. And I think the point around it is not to create huge layers of bureaucracy. Right. There’s things like in Agile that do create bureaucracy, like scale. Right. I have been to many a customer where I speak about scale Agile. When I say scale Agile, I mean in a literal way, we only do agile across many teams. But obviously safe people think it means safe. And I’ve had violent reaction for many a customer.
00:30:44 If you’re implementing safety, I’m going.
00:30:48 Yeah, it’s way more red tape than we had before.
00:30:52 And I think people when you’re spending lots and lots of money as a CFO and a CEO, you want to know where it’s going. But I think Agile store has a lean process, just about making those tools come together and report in the right way without having these massive layers of bureaucracy.
00:31:10 Yeah. Do you think we’re winning the battle?
00:31:13 That’s a really good question. I go to some customers and I feel, yes, right. And then I go to customize and feel, I think in terms of where we are, we winning the battle. I think it is. I think it’s slow, it’s happening, but it’s going to take a while. Right. Because there’s a vested interest among people. Right. And I think some of it also comes from our corporate culture as well. There’s not to be a political thing, but if you go in as a CIO CTO, you’re in for an amount of terms. You want to hit a number of metrics, whatever it is, low cost, lower cost, offshore labor, arbitrage or hit this business metric, and then you’re off key. And so inevitably, the lack of long term stability within organization, agile winning in its truest form and reasons why companies like Facebook and Amazon do it is because they’ve got a leader who’s been there 1020 years and driving that process, and they keep their teams together for a long time as well. So inevitably, there’s always going to be limitations. Right. Just by the nature of the economy that we run, it’s not broadcast. It’s just the reality of what we are.
00:32:25 That’s why I think prevents Agile from being really successful, to get it really efficient and keep teams together.
00:32:32 And that’s not just teams developing product, that’s entire teams. Right. Organization.
00:32:38 There’s probably just a bit too much flux sometimes.
00:32:42 I think eventually we’ll get there. I think we need to do better about teaching test processes and stuff like that to people right out of like, right. When they’re learning code and boot camps, we should teach it then. And learning code in school, we should teach them then. And then the entire culture eventually will change.
00:33:00 We have similar thoughts on this, and I think we could be us for hours on this, and especially if we could kick our feet up with a couple of points be awesome. But I do want to kind of wrap things up. I want to give you the opportunity because I really appreciate your time I’d like you to tell us what Infuse offers people where they can find more and just pitch sort of thing.
00:33:22 No worries, Brian. Yeah. So Infuse is a modern software delivery company. As you may have heard in this podcast, we started off automation and performance testing. And one thing about test automation is that it brings you all sorts of interesting challenges. Right. You find out about test environments, you find about test data into DevOps and test data management, test environment management, and then even architecture. So we’re now what I would call a quality engineering company to help businesses transform into modern software practices.
00:33:53 And we’ve implemented a lot of companies going apply these practices, migrating to cloud, moving to function as a service implementing test automation. And then while we’ve been on that journey, we also created a test product. We use Mango, so that enables your non technical tester to enable to get grips with tools like Selenium and work with a ready made framework out the box, be able to drive and build automated web tests or tests on their mobile phones, and essentially enables those people with regression tests to drive to automate that testing because that backlog still does exist in the industry.
00:34:33 That’s what we do. We’re based in UK and in India. We’re headquartered in London and we’ve got office in Buena in Bangalore as well. And we have the new US as well. So I guess we are international probably. I would say US, Europe and Middle East, but I would say that we are I’d like to think of the company as big enough to deliver, but all in care, and that’s what we do.
00:35:01 Okay.
00:35:02 Awesome.
00:35:02 Well, thank you.
00:35:03 Thanks for taking the time to talk with us today.
00:35:06 No worries, Brian. I just thought throwing you infused it is our URL, so if you need more information, feel free to go there.
00:35:14 Yeah. And if somebody’s just curious to talk or somehow contact you, do you have any way that people can ask you a question or anything?
00:35:20 I’m available on LinkedIn, right. Typing in null in probably isn’t very helpful for my non Anglosacton audience. My surname is the differentiator. So I’m only one of two parts on Google in the planet. There’s someone else.
00:35:35 All the spelling of my surname too. But Papa, Alpha, Romeo, Bravo, Hotel uniform. My name is Nalin. You can reach out to me on LinkedIn.
00:35:44 You can contact me on the website as well.
00:35:46 What we do is we’ve got guest BIOS on our website. And so people can check the show notes and click your picture and they can get that link right there. So I will put that right there.
00:35:58 No worries. Brilliant, Brian, thank you very much for having us.
00:36:01 Thank you, both of you. For sure. Thank you for being on the show.
00:36:03 Cool.
00:36:07 Thank you. Nolan and Ola, fun talk. Thank you, PyCharm, for sponsoring the show. Try Pycharmourself at testandcode.com. Pycharm. Thank you, Patreon supporters for your amazing enduring support of the show truly incredible join them at testandcode.com. Support. Thank you to all the great people answering questions in our slack channel. We now have 895 members and many heroes there helping people every day. It’s awesome. Join the conversation@Test And Code.com. Slack show notes for this episode are@Test And Code.com 139. That’s all for now. Now go out and test something.