Guljeet Nagpaul, Chief Product Officer for ACCELQ, explains why automating testing has become a necessity. The video is below followed by a transcript of the conversation.
Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Guljeet Nagpaul, who is chief product officer for ACCELQ, and we’re talking about all things related to testing. Guljeet, welcome to the show.
Guljeet Nagpaul: Thanks, Mike. Thanks for having me.
Mike Vizard: Do you think the whole testing focus has increased somewhat in the last few months with the whole shift to digital transformation, and people are trying to develop more applications than ever? I think it’s kind of critical to get it right the first time these days. I think the tolerance for experimenting on end users, especially in a digital business context, is a lot lower, but is there some sort of fundamental shift going on with testing that you’re seeing?
Guljeet Nagpaul: Yeah, both things you mentioned, Mike, are right on. The digital transformation has clearly been on steroids almost now for the past couple of years, since we’ve seen the world kind of changing around us with remote work. A lot of processes which were even in healthcare and financial space, which were kind of buried with red tape, all of them have been kind of almost on steroids to become more automated, and organizations have had to kind of put their transformation objectives much more on a fast track. That, like you rightly said, automatically leads to having to ship the applications must faster to their customers to run their businesses faster. The need for automated testing for shipping their software faster gets kind of even more critical.
Mike Vizard: Where is that automation taking place? Are we automating tests for the developer as we shift things left, or is the automation more in the CI/CD DevOps platform, and we’re trying to automate it there because that may be the place where the application itself comes together; otherwise, each developer is testing a small piece of something but maybe not the whole thing and then?
Guljeet Nagpaul: That’s exactly right. We live in a world where there is an app for everything. That has been true from a consumer perspective, but now, interestingly, that is more so true on our enterprise application side. Back in the day, if you remember, we had a couple of ERPs and then we had some homegrown systems, and that’s kind of how the IT landscape of organizations looked. But now, with the onset of cloud apps, with packaged applications, with vertical applications, there is an app for everything for enterprises to be able to go more automated. What that translates to is a highly-integrated enterprise application ecosystem. What that means is unit testing or just shifting left in terms of automation is not going to be enough.
You would really need that end-to-end validation, and each app has at least five upstream and five downstream integrations, which means the real automation, and the real customer experience in terms of your end-to-end workflow has to be automated across the board. That DevOps CI/CD pipeline you talked about, that gets even more kind of focused in terms of being able to validate that end-to-end workflow. That is kind of where we are really seeing the need for automation, more than kind of what we would have thought from a shift-left perspective. That’s absolutely necessary because you want to build a stronger product. You don’t want to be reactive in building a strong product, you want to bake quality into the product, but then downstream, you want to make sure your end-to-end workflows work as designed in terms of an integrated end-to-end system.
Mike Vizard: How far down the path are we to achieving that goal, because I think somewhere along the line everybody maybe thinks that testing is somebody else’s job, but what’s the maturity level of testing these days in terms of automation?
Guljeet Nagpaul: Yeah, like with a few different functions within our IT, we kind of see kind of a full circle come back, right? A lot of testing was starting to get perceived as commoditized, and we saw a lot of testing kind of getting shifted from that perspective as a cost function. But, quickly, organizations realized that without continuous testing, there is no continuous delivery, and that’s really the crux of it, that if you can’t have a dependable, reliable, continuous test automation to bridge that gap between your dev and ops, there is no DevOps, because that’s the key bridge between your dev and ops, right? With that notion, the testing maturity level has struggled.
To be honest, a lot of automation approaches, and I spent over a decade with HP, a lot of traditional automation tools and approaches have focused more on silos because our app ecosystem was not that integrated back in the day, right? It used to kind of have integration, but not at the level that you’re seeing today, so the need for an automation approach that can span across these technology stacks is now kind of more new and is now more critical. The testing maturity in terms of what approaches are out there has struggled, but we are now starting to see customers really needing that across-technology-stack approach, and that’s kind of where ACCELQ has a sweet spot.
Mike Vizard: Do you think the rise of micro-services is forcing the automated testing issue because we’re reaching a level of complexity that can’t really manually test all these things?
Guljeet Nagpaul: I would say yes. Just in the last five years, interestingly, Mike, we have seen API testing as part of critical proof-of-concepts to when customers come and try a platform like ACCELQ out in terms of seeing whether it’s fit for their needs or not. Just in the last five years, we have seen at least three times the interest in making sure that APIs can be validated apart from their UI. But, like I said, it’s really more about how that validation can be done across the technology stacks. To give you an example, a healthcare customer of ours, one of the top five companies in the world, they had a use case where a patient walks into a pharmacy to put in their prescription, but now with COVID and everything, the automation is kind of boosted.
Now they can key in their prescriptions directly through their mobile apps connected to their healthcare providers. Once that prescription is keyed in, there are at least 20 downstream processes that are kicked in, including mainframe systems, micro-services, a database that’s maybe sitting on a cloud, but then coming back to a pharmacy system which is still living in an old-school desktop world. The real demand, what we are seeing is kind of this across technology side, because that’s what the user experience is.
Mike Vizard: How smart can testing get? We hear a lot about artificial intelligence these days. Will the whole thing become automated or what will be the role of the tester, per se?
Guljeet Nagpaul: Yeah, that’s a great question. AI unfortunately gets thrown around very loosely these days, especially more so with talking about how AI is the platform. We have looked at it always as a tool in our toolkit. Ever since the inception of our platform, we have always looked at how we can leverage AI to make things more efficient as opposed to saying AI is the platform. We have always looked at it more realistically. If you forget AI for a second, that’s kind of how as people we have embraced technology. In various aspects, technology has enabled us to increase our throughput regardless of which process area are we picking, and that is kind of how we see AI. If it’s leveraged accurately, it’s going to increase the throughput of our test engineers. It is going to increase the throughput of our automation engineers. At various process areas that then test automation life cycle, that’s kind of how we’ve looked to leverage AI.
Mike Vizard: Do you think we’re approaching a point where the number of applications being built is overwhelming the testers that are out there, and the pace of that work is getting to a point where they become a bottleneck?
Guljeet Nagpaul: Yeah, I was having a discussion on the same lines with our Forrester analysts, and one of the interesting discussion points around that was we all as testers within the DevOps space have to almost take a step back and understand what needs to be tested before going about kind of in the traditional manner testing it. Yes, it can be overwhelming with so many apps coming together so quickly in terms of being able to serve our businesses, but a lot of these apps which are getting shipped for our businesses, for these organizations are cloud apps, or maybe packaged apps, vertical apps. All they need is configuration and integration with other apps, and then they can kind of start doing the job in terms of the outcome that the businesses are expecting. It almost needs some level of refactoring, a new mindset when you think about in this new world of facts, how should you be testing and what you should be testing to get the maximum bang for your buck, so it’s easy to get overwhelmed. But, with automation and the right approach to what needs to be tested, you can kind of be more efficient with your efforts.
Mike Vizard: Who writes the tests these days? It seems to me a lot of time and effort has been spent on creating the tests, and, as we automate that process, can we get to the point where the machines can create the tests? I mean, to what degree do I need to create the tests versus run the tests?
Guljeet Nagpaul: Yeah, that’s an interesting point. The way we look at it is, unfortunately, the way testing and automation specifically has evolved, the traditional approaches I talked about, they have lived on two ends of the spectrum, Mike, one end of the spectrum being very record-and-playback oriented. But, we have seen in the past 20 years that automation is not new; it has been around for at least a couple decades. Back when we released Windrunner, and I don’t know if that rings a bell, I was part of the original Windrunner team, at one point we had about 70 percent market share, and record-and-playback was the thing automation. But, in the last ten years, there have been a plethora of tools which have come on the same lines of record-and-playback but we have seen that they just are not scalable enough to deal with the changing technology stack. They are just not real-world enough to work across technology stacks, and a lot of other things in terms of design challenges and so on.
The other end of the spectrum that we live in is open source, and you kind of pointed to how testing had been shipped out as a cost function, and open source made a big kind of wave into the test automation area, but that became a specialist function. The reason this is important, to your point of the question, is when automation has become a specialist function, because we have seen about 60 to 65 percent market share ‒ Gartner did a survey of open source taking over a lot of kind of testing and automation approaches. But, when you see that, basically it becomes a specialized function, and all my testing team is a mixed bag of testers, maybe some automation engineers, but a lot of business subject matter expertise. If you really want a strong test approach, you need to make the subject matter experts people who understand business rules.
That needs to be validated as part of the automation, and that’s kind of where both ends of the spectrum have to meet, where a non-technical, non-specialized tester should also be able to be part of that automation. That can only become if our platforms are smarter, right? Maybe depending on that suite to be adaptable, maybe bridging machine in certain cases, to your point, to be able to write smarter test cases, to basically have your automation more leaner and meaner so that it can do more with kind of less in terms of authoring and design changes and change with so many releases happening, so absolutely. I mean, testing has to get out of the specialized function role.
Mike Vizard: All right. We hear a lot of focus these days on security, of course. Do you think that security ultimately will become part of a quality assurance testing process, because it’s not clear to me that those are two distinct functions anymore. They might be joined at the hip in some fashion.
Guljeet Nagpaul: I sure hope so. The strongest of the software and the organizations just in the past one year, we have seen outages which we would have never imagined, right? AWS went out a few times, Facebook, Meta, went out a few times, and you name it. Security has to become an integral part, and we are seeing this more and more. As part of functional regression tests, customers want to have those security regression tests. Security lived in two worlds until now. One was static code analysis, which is, “Let’s do static code analysis,” which is good, it’s kind of like shifting left to your unit tests. Yes, you’ve got to find your vulnerabilities right when your code is written, but, once the code is in action, what vulnerabilities come can be a different game.
Static code analysis is where security lived, and, like you said, that’s why it was a little bit in the different world. Then, you had dynamic security firewalls, which are kind of more glorified firewalls. But, in the middle, that functional testing, leveraging security validation is a gap in the industry right now, and we are certainly looking to fill that gap. We have already helped a lot of Fortune 100 customers, including certain financial services customers, fill in that gap, leveraging the functional automation approach because they’ve had some solutions around these two things but functional is where it needs to get seated into, right? Like you said, it has to become mainstream into the testing and function automation space.
Mike Vizard: All right. Other than hanging out on your website, what is your best advice to folks about how to get to this continuous testing nirvana, I guess, because, ultimately, time is money, so every time an application has a disjoined experience, somebody is losing money somewhere, right?
Guljeet Nagpaul: Totally. Automation first. Automation first is the key. A lot of traditional mindset still remains at, “Let’s write my manual tests and let’s write the manual tests them into convert them into automation.” The mindset has to change. The organization approach has to change to automation first. For automation first, you can only do automation first if it’s not a specialist function. Don’t get caught up in getting buried into a technical debt. You don’t want a million lines of code to test a million lines of code, right? Figure a more robust solution and go automation first, and that will set you on the right path.
Mike Vizard: All right. Guljeet, thanks for being on the show.
Guljeet Nagpaul: Thanks, Mike. Thanks for having me.
Mike Vizard: All right. Back to you guys in the studio.
