Revolutionizing Test Automation with DevAssure's AI-Powered Platform

WEBVTT
00:00:00.000 --> 00:00:20.560
Music.
00:00:21.923 --> 00:00:25.003
Welcome to the Automation Hangout. I'm your host, Giorgio Kuru.
00:00:25.263 --> 00:00:28.963
And today, we are joined by someone who's making waves in the test automation space.
00:00:29.863 --> 00:00:34.603
Divya Manohar, the co-founder and CEO of DevAzure. DevAzure is on a mission
00:00:34.603 --> 00:00:39.263
to simplify and accelerate test automation with its powerful platform built around AI.
00:00:39.823 --> 00:00:45.283
In this episode, Divya will talk to us about how DevAzure is helping teams shift
00:00:45.283 --> 00:00:47.063
quality software faster.
00:00:47.863 --> 00:00:51.043
She's also going to tell us about the unique features about the platform,
00:00:51.203 --> 00:00:54.023
as well as what's coming next on the innovation roadmap.
00:00:54.623 --> 00:00:56.863
Welcome to the show, Divya. How are you doing today?
00:00:57.683 --> 00:01:00.363
Hi, George. Thank you for the introduction. I'm doing really well.
00:01:00.463 --> 00:01:04.143
I'm really happy to be part of this podcast. Thank you very much for inviting me.
00:01:04.703 --> 00:01:09.563
Thank you. So, Divya, the first question that I have for you is around your
00:01:09.563 --> 00:01:11.723
journey from a software engineer to an entrepreneur.
00:01:12.223 --> 00:01:18.183
So what inspired you to take the leap into entrepreneurship and then build a company like DevAzure?
00:01:19.783 --> 00:01:24.523
That's a question I keep asking myself as well, right? Because I've never aspired
00:01:24.523 --> 00:01:26.043
to be an entrepreneur, right?
00:01:26.143 --> 00:01:29.403
To be a founder, right? It's not something that, you know, I can say that,
00:01:29.443 --> 00:01:31.663
you know, I started from day one. I always wanted to do this.
00:01:31.783 --> 00:01:35.743
No, but I love solving problems. So that is the root cause of everything, right?
00:01:35.843 --> 00:01:39.823
So when I was a software engineer, one of the most difficult problems that we
00:01:39.823 --> 00:01:41.303
faced was the testing itself.
00:01:41.723 --> 00:01:45.383
Especially across three parameters, which is speed, accuracy, and reliability.
00:01:45.903 --> 00:01:49.343
So this slowed down our release cycles to a great extent. And most of the bugs
00:01:49.343 --> 00:01:50.863
were found only in the beta environment.
00:01:51.363 --> 00:01:54.003
So half the time, you know, we were always in like, you know,
00:01:54.183 --> 00:01:56.963
war room trying to figure out how we can accelerate the release cycles.
00:01:57.143 --> 00:02:00.563
Like I've been part of more, mostly part of different startups itself.
00:02:00.803 --> 00:02:05.023
So release cycle, having a shortened release cycle is very, very important for us.
00:02:05.363 --> 00:02:09.863
So then five years ago, I met my co-founders, Santosh and Badri at Ally. Right.
00:02:10.203 --> 00:02:13.023
And we kept discussing this, having this discussion on a repeated mode.
00:02:13.143 --> 00:02:14.323
Right. And we tried different things.
00:02:14.483 --> 00:02:18.803
We tried different approaches. And then we started to think about how to solve the problem at scale.
00:02:19.023 --> 00:02:23.963
So I think that is what led to me becoming an entrepreneur to try to solve a problem at scale.
00:02:24.263 --> 00:02:27.803
Right. So that's when we started talking about DevShare. We started talking
00:02:27.803 --> 00:02:31.943
about accelerated releases. We started talking about streamlining testing itself. Right.
00:02:32.203 --> 00:02:36.563
And then we started DevShare. So we started DevShare because we had a problem to solve.
00:02:36.823 --> 00:02:40.603
Not to be founders, but we had a problem to solve. And that's where that's how
00:02:40.603 --> 00:02:42.063
we got started with Devassure itself.
00:02:42.503 --> 00:02:45.883
Okay, that's very interesting. So I have a follow up question for you, Devia.
00:02:46.083 --> 00:02:49.943
So one of the basic issues that you're talking about was about the speed of
00:02:49.943 --> 00:02:53.963
releases as well as making sure that the release is having enough quality.
00:02:54.263 --> 00:02:59.563
So how does a platform like Devassure help to bridge the gap between speed and quality?
00:03:00.462 --> 00:03:04.702
That's very rightly said, right? I think when you start, when you want to release
00:03:04.702 --> 00:03:08.402
at speed, right, quality is one thing that gets compromised.
00:03:08.662 --> 00:03:12.722
So when we even started with Devisha, we had these repeated conversations with
00:03:12.722 --> 00:03:16.482
multiple customers as well, right, like potential customers as well,
00:03:16.702 --> 00:03:20.262
trying to understand, you know, how they handle the releases itself.
00:03:20.262 --> 00:03:22.282
So they always told us this, right?
00:03:22.442 --> 00:03:25.902
If they wanted to accelerate the releases, they have to compromise on the quality.
00:03:26.162 --> 00:03:30.582
If they didn't want to compromise on the quality, then it meant longer release cycles as well.
00:03:31.062 --> 00:03:34.942
So then you need to find the right balance itself, right? So then the reason
00:03:34.942 --> 00:03:38.202
why teams struggle is because, you know, as your features grow,
00:03:38.662 --> 00:03:40.022
your team size also grows.
00:03:40.202 --> 00:03:43.882
And then eventually you have more test cases to kind of test out and then manual
00:03:43.882 --> 00:03:46.762
execution is no longer possible. You go in for automation.
00:03:46.922 --> 00:03:49.982
But with automation also, there's one problem with flakiness,
00:03:50.162 --> 00:03:54.122
especially as your test cases grow to over like, say, thousands and two thousands and all that, right?
00:03:54.482 --> 00:03:58.122
Your flakiness also increases. And then you spend most of your time fixing your
00:03:58.122 --> 00:04:00.742
automation rather than, you know, accelerating your release cycles.
00:04:00.742 --> 00:04:03.202
And this cycle just goes on forever, right?
00:04:03.382 --> 00:04:07.702
And we wanted to solve exactly this problem. So our main goal was not to provide
00:04:07.702 --> 00:04:13.822
a platform just for test automation, but it was trying to streamline that entire testing cycle itself.
00:04:14.302 --> 00:04:18.922
So that's why we created DevShare as a test orchestration platform rather than
00:04:18.922 --> 00:04:23.102
just a test automation platform, right? So we have multiple agents performing
00:04:23.102 --> 00:04:24.062
multiple things, right?
00:04:24.182 --> 00:04:29.162
Like if you think about a typical development cycle, your testing starts from writing test cases.
00:04:29.322 --> 00:04:33.382
So we have agents which enable that to happen right from your Figma designs or PRD.
00:04:33.482 --> 00:04:36.982
So right from the design phase, we get the agents involved in the testing and
00:04:36.982 --> 00:04:38.522
then it starts building the context.
00:04:38.682 --> 00:04:41.862
It helps developers identify bugs while we are coding itself.
00:04:42.002 --> 00:04:44.842
And then there is another agent which helps with automation,
00:04:45.042 --> 00:04:45.842
generating the scripts.
00:04:46.022 --> 00:04:48.402
And then there's another agent which helps with CI executions.
00:04:48.402 --> 00:04:52.262
So multiple agents are working across the entire testing cycle.
00:04:52.422 --> 00:04:55.862
And all of this put together is what we offer at Devisher.
00:04:56.122 --> 00:05:00.242
So the primary problem that we are trying to solve here is eliminating that
00:05:00.242 --> 00:05:04.162
struggle of trying to, you know, catch up with your test automation on one side,
00:05:04.282 --> 00:05:07.502
trying to catch up with your release cycles, trying to make sure that all the
00:05:07.502 --> 00:05:08.582
test cases are executed,
00:05:08.762 --> 00:05:11.642
trying to make sure that there are no regressions, there are no visual regressions.
00:05:11.922 --> 00:05:16.702
So all of this across web, mobile and API is what we offer as a single platform.
00:05:17.282 --> 00:05:20.822
Okay. So one of the unique features that I found, like most of the,
00:05:20.902 --> 00:05:24.402
as you rightly said, most of the test automation platforms that are out there
00:05:24.402 --> 00:05:26.882
does not have a lot of ability to generate tests.
00:05:27.222 --> 00:05:30.942
Basically, I would say a record or you basically have to do a bit of scripting.
00:05:31.242 --> 00:05:35.702
So one of the interesting features that I saw in your product is basically converting
00:05:35.702 --> 00:05:39.402
maybe Figma screens into test cases and test automation scripts.
00:05:39.642 --> 00:05:43.442
So can you actually elaborate a bit on that capability or that those agents
00:05:43.442 --> 00:05:48.462
that you have developed which actually helps you to improve the speed at which
00:05:48.462 --> 00:05:51.142
test cases are actually designed. Got it. Yeah.
00:05:51.542 --> 00:05:54.262
So it's pretty much like what every QA engineer does, right?
00:05:54.382 --> 00:05:59.142
So if you look at it, like say every team of like four or five engineers typically have a QA engineer.
00:05:59.967 --> 00:06:04.367
So these QA engineers, their main purpose is to like look at these mockups or
00:06:04.367 --> 00:06:07.327
the PRDs or your Jira stories, user stories, anything, right?
00:06:07.407 --> 00:06:09.627
You look at that and then start writing your test cases.
00:06:09.907 --> 00:06:13.487
And then once your test cases are written, there are discussions which happen with product managers.
00:06:13.707 --> 00:06:17.387
And then there's a back and forth that happens between QA, developers and product
00:06:17.387 --> 00:06:20.847
managers to iron out the test cases. And then the developers use those test cases.
00:06:21.207 --> 00:06:24.467
So while they are writing the test cases, you know, a QA engineer thinks from
00:06:24.467 --> 00:06:26.667
all perspectives, right? OK, what are the regression cases?
00:06:26.807 --> 00:06:29.907
What are the end to end cases? what are the integration cases and what's
00:06:29.907 --> 00:06:33.207
what are the feature specific cases whether it is ui functional non-functional
00:06:33.207 --> 00:06:36.267
performance accessibility whatnot right so the
00:06:36.267 --> 00:06:39.407
way we've developed the agent is like typically with
00:06:39.407 --> 00:06:42.607
all of these constraints in mind right in terms
00:06:42.607 --> 00:06:45.907
of like what it takes to write a good test case so the
00:06:45.907 --> 00:06:48.907
agent will actually you know go through all your mock-ups go
00:06:48.907 --> 00:06:51.807
through prds any supporting document for that matter right
00:06:51.807 --> 00:06:54.747
say even if you supply something like an architecture diagram
00:06:54.747 --> 00:06:57.607
then it understands your entire architecture of your system and tries to
00:06:57.607 --> 00:07:01.107
think about system use cases as well right so it
00:07:01.107 --> 00:07:04.047
tries to think about the test cases from every perspective your
00:07:04.047 --> 00:07:07.827
edge case scenarios and all that and for that the requirement documents provide
00:07:07.827 --> 00:07:11.787
you know this as a source of truth and while it tries to analyze these documents
00:07:11.787 --> 00:07:16.427
one of the major you know issues that we've seen with growing teams and growing
00:07:16.427 --> 00:07:20.727
features is identifying your regression use cases so the agent is able to kind
00:07:20.727 --> 00:07:23.527
of you know bring in all of these things as well So multiple features,
00:07:23.707 --> 00:07:26.047
multiple documents that you integrate the agent with,
00:07:26.267 --> 00:07:29.647
or multiple Jira stories, like you have an entire board of Jira stories,
00:07:29.767 --> 00:07:30.867
you can still integrate with it.
00:07:31.107 --> 00:07:33.627
It will crawl through all your stories, all your bugs, everything,
00:07:33.807 --> 00:07:36.767
and generate a complete regression test case as well.
00:07:36.967 --> 00:07:40.007
Like you have a new feature, it identifies components which are common with
00:07:40.007 --> 00:07:43.267
the new feature as compared to the old features and identifies the regression
00:07:43.267 --> 00:07:46.627
cases. Then if you think about end-to-end scenarios, it identifies,
00:07:46.807 --> 00:07:51.187
stitches multiple features together and identifies those end-to-end scenarios, corner cases.
00:07:51.487 --> 00:07:55.107
Like one of the things that our customers also love is its ability to identify
00:07:55.107 --> 00:07:57.547
things like race conditions and concurrences as well.
00:07:58.365 --> 00:08:01.665
And then beyond that, if you look at it, like one thing that I mentioned is
00:08:01.665 --> 00:08:05.665
that conversation that happens between QAs and devs and product managers, right?
00:08:05.905 --> 00:08:09.965
So this tool is capable of doing that as well. So see, one of the reasons why
00:08:09.965 --> 00:08:14.085
everyone is a little skeptical about using AI, especially for testing,
00:08:14.225 --> 00:08:17.845
is because of the assumptions or hallucinations that happen at times.
00:08:17.985 --> 00:08:21.385
So that is one thing that we've prevented really well, where the assumptions
00:08:21.385 --> 00:08:25.345
and hallucinations are converted into questions. So the agent behaves like a
00:08:25.345 --> 00:08:29.825
typical QA engineer and asks those questions, which the product managers can then provide inputs.
00:08:29.965 --> 00:08:34.225
And then it starts, you know, enhancing the test cases more or kind of generates
00:08:34.225 --> 00:08:35.945
more comprehensive use cases as well.
00:08:36.565 --> 00:08:40.745
So typically what would take like, say, two to three days for a back and forth
00:08:40.745 --> 00:08:44.605
to happen between, you know, the QA engineers, developers and the product managers,
00:08:44.825 --> 00:08:48.505
it would take probably two or three days for bigger features.
00:08:48.705 --> 00:08:51.345
Right. And this would be able to do it within 30 minutes itself.
00:08:51.485 --> 00:08:53.205
The agent would be able to do it within 30 minutes.
00:08:53.885 --> 00:08:56.885
Okay so it basically improves the productivity to
00:08:56.885 --> 00:09:00.285
a great extent among testers right right yeah
00:09:00.285 --> 00:09:03.125
okay so how much time does it take for
00:09:03.125 --> 00:09:06.105
a tester or for an organization to implement the
00:09:06.105 --> 00:09:09.505
tool like diverse or yeah that's
00:09:09.505 --> 00:09:12.425
a fair question right because when you think about build versus buy
00:09:12.425 --> 00:09:15.185
that is one of the things that you keep asking right yourself in terms of
00:09:15.185 --> 00:09:18.285
how about the tool adoption itself so typically we we
00:09:18.285 --> 00:09:21.525
see that it takes around like say two to three days because there's
00:09:21.525 --> 00:09:24.805
a rich feature set there are a lot of things that you need to learn especially because
00:09:24.805 --> 00:09:27.565
the agent builds the context also so you need to know what kind of
00:09:27.565 --> 00:09:31.205
information that you can provide and all of that right so it takes typically
00:09:31.205 --> 00:09:34.585
two to three days for someone to actually get acquainted with a tool like this
00:09:34.585 --> 00:09:38.585
and also we also use natural language processing as well and so we have our
00:09:38.585 --> 00:09:42.185
own set of keywords especially when it comes for test automation scripting itself
00:09:42.185 --> 00:09:45.525
given that it's a no-code platform there are some keywords that we expect to
00:09:45.525 --> 00:09:47.445
be present as well so So with that,
00:09:47.585 --> 00:09:50.905
there is a learning curve involved, but it is not as much as your open source
00:09:50.905 --> 00:09:55.105
tools where you have to learn a new language or you have to learn libraries and all that.
00:09:55.185 --> 00:09:59.645
That is eliminated, but typically takes around two to three days to get acquainted with the tool itself.
00:10:00.385 --> 00:10:04.925
Okay, that's a very minimal time and you don't need a lot of skill sets to work on this tool, right?
00:10:05.545 --> 00:10:09.645
That's right. It's codeless. So the testers, they don't have to write any kind
00:10:09.645 --> 00:10:14.245
of scripts or they don't have to be programming savvy in order to test automation. That's interesting.
00:10:14.725 --> 00:10:18.065
So, Digi, like you came in, again, you came in from an engineering background
00:10:18.065 --> 00:10:20.625
with, I don't think you had any background around sales.
00:10:20.805 --> 00:10:25.465
So, how has been the growth journey? How did you manage to find your first customer for DevEsports?
00:10:26.776 --> 00:10:31.556
Sales is always a big thing, right? I think that's one of the most difficult things, right?
00:10:31.656 --> 00:10:34.676
I think, especially coming from an engineering background, you know,
00:10:34.776 --> 00:10:36.396
it's an evolving process, right?
00:10:36.496 --> 00:10:39.716
So earlier, if you look at it, when I started to do these sales pitches,
00:10:39.976 --> 00:10:43.736
I always used to talk from a product perspective, not from the perspective of
00:10:43.736 --> 00:10:45.756
an ROI or a customer perspective, right?
00:10:45.816 --> 00:10:48.516
What they think, you know, I never used to pay attention to those things.
00:10:48.636 --> 00:10:52.736
I only used to sell the features in the product, which I eventually learned
00:10:52.736 --> 00:10:55.896
is not the right way to do it. But coming back to your earlier question in terms
00:10:55.896 --> 00:10:57.376
of like our first client, right?
00:10:57.556 --> 00:11:00.676
So we GA'd like last year in April, right?
00:11:00.736 --> 00:11:04.536
So that's when, before that, we did a lot of trials with beta customers just
00:11:04.536 --> 00:11:08.316
to iron out, you know, any, like trying to understand if the product made sense
00:11:08.316 --> 00:11:12.416
to them in terms of simplicity of use or does it, is this something that they're
00:11:12.416 --> 00:11:14.716
willing to pay? So we did a lot of that research groundwork.
00:11:14.836 --> 00:11:17.216
And then in April is when we released our first product.
00:11:17.356 --> 00:11:20.196
And the first people that we reached out to was within our network itself.
00:11:20.596 --> 00:11:23.636
Because I think the true validation happens there. Within your network,
00:11:23.756 --> 00:11:26.536
no one is willing to pay. I don't think outside of the network it's going to happen.
00:11:27.256 --> 00:11:31.276
Right. So we kind of released it to our trusted circle and asked them to try
00:11:31.276 --> 00:11:34.876
it out. And we achieved like we got a few customers within our trusted circle.
00:11:35.156 --> 00:11:38.976
So first few customers were from our trusted circle. And then we started expanding
00:11:38.976 --> 00:11:43.016
beyond that. But then none of these customers, you know, the first few people,
00:11:43.196 --> 00:11:47.716
they did not buy the product because, you know, it was us, not because of the
00:11:47.716 --> 00:11:49.036
relationship that we had with them.
00:11:49.316 --> 00:11:53.036
But it was because, you know, the fact that they had a problem to solve,
00:11:53.356 --> 00:11:54.816
right? They wanted to solve the problem.
00:11:55.176 --> 00:11:59.176
So because of that, they were able to, you know, kind of resonate with what
00:11:59.176 --> 00:12:02.196
the tool was solving as well. And they onboarded onto the platform.
00:12:02.496 --> 00:12:05.856
But beyond those first, you know, seven customers that we got,
00:12:05.956 --> 00:12:09.476
when we started to expand beyond that, right? So one thing that we,
00:12:09.736 --> 00:12:12.456
you know, after talking to a lot of people and attending a lot of sessions,
00:12:12.596 --> 00:12:14.676
we learned is that we need to build our content engine.
00:12:15.416 --> 00:12:18.996
Because outbound works really well. But then, you know, the intent is,
00:12:19.136 --> 00:12:24.876
I mean, out of the 200 calls or 200 emails that you send, probably just like one person responds.
00:12:25.196 --> 00:12:28.776
So it's not a very good conversion rate because you don't know the intent at
00:12:28.776 --> 00:12:32.836
that point of time. So content engine is one thing that we started working from day one.
00:12:33.376 --> 00:12:36.896
That's something that I learned on the job. We hired a good set of good resources
00:12:36.896 --> 00:12:39.216
as well who helped us build the content engine.
00:12:39.436 --> 00:12:43.336
And with that, we are able to get a lot of inbound, good amount of inbound sales as well.
00:12:43.556 --> 00:12:46.756
And one thing that I learned is writing blogs like from the founders,
00:12:47.016 --> 00:12:48.596
right? Because you write it from your heart.
00:12:48.716 --> 00:12:51.396
You explain the problems from your heart, right? It made a lot of sense.
00:12:51.516 --> 00:12:53.456
It resonated with a lot of people as well.
00:12:54.071 --> 00:12:58.511
And beyond that, in terms of the sales itself, you know, a lot of things that
00:12:58.511 --> 00:13:04.171
we try to solve is in terms of, you know, the longer sales cycle and then trying to identify our ICPs.
00:13:04.351 --> 00:13:08.291
And once we reach that 20 customer mark, identifying the product market fit
00:13:08.291 --> 00:13:09.531
became a lot more easier.
00:13:09.771 --> 00:13:14.911
And so identifying, you know, that formula that repeatedly works for us became a lot more easier.
00:13:14.911 --> 00:13:19.011
And now we have a formula and we keep refining that formula somewhat to make
00:13:19.011 --> 00:13:21.791
sure that we get more and more trials and more and more customers on board.
00:13:21.791 --> 00:13:24.711
It okay it's very interesting to know that you're focusing
00:13:24.711 --> 00:13:27.411
on inbound leaves normally like what i've seen is
00:13:27.411 --> 00:13:30.311
like there's a lot of focus on email marketing and cold calls
00:13:30.311 --> 00:13:33.071
and you don't really know whether your end user or
00:13:33.071 --> 00:13:35.791
the prospect really needs your product whereas when it comes to
00:13:35.791 --> 00:13:40.531
inbound leaves i've seen better conversions and the cost of conversion is also
00:13:40.531 --> 00:13:44.211
very less because the only effort that you're putting in is on seo as well as
00:13:44.211 --> 00:13:48.171
on creating the content that's very interesting to know this year and moving
00:13:48.171 --> 00:13:52.791
on to your entrepreneurship journey again so as a founder you might have had
00:13:52.791 --> 00:13:54.591
a lot of surprises when you started out.
00:13:54.751 --> 00:13:57.791
So was there one thing that you thought would be very simple to do when you
00:13:57.791 --> 00:14:01.711
started building the company and later you found out that it was unexpected
00:14:01.711 --> 00:14:03.231
but it was extremely tough to solve?
00:14:03.785 --> 00:14:07.265
Oh, definitely. Right. It all goes back to the sales itself again. Right.
00:14:07.565 --> 00:14:11.865
So one of the things is, like I told you, like even before we started with Devashore,
00:14:11.865 --> 00:14:14.725
we did a lot of groundwork, like for around eight to nine months,
00:14:14.745 --> 00:14:18.105
right, while we were in our previous organization itself, just to understand,
00:14:18.245 --> 00:14:20.385
right, because we didn't want to build the product from day one.
00:14:20.605 --> 00:14:23.605
Right. We wanted to first understand the problem really well. so we
00:14:23.605 --> 00:14:26.925
spoke to we conducted a lot of customer interviews right in
00:14:26.925 --> 00:14:29.705
terms of trying to understand if you know a product
00:14:29.705 --> 00:14:32.505
like this makes sense for them we had a lot of mock-ups we showed
00:14:32.505 --> 00:14:35.625
it to them and then we understood the market really well so
00:14:35.625 --> 00:14:38.285
while we were doing that while we were going through
00:14:38.285 --> 00:14:41.145
that experience everyone wanted to solve the problem all
00:14:41.145 --> 00:14:43.965
the leaders right whether it was from the QA leaders or
00:14:43.965 --> 00:14:46.645
director of engineering CTOs everyone wanted to solve the
00:14:46.645 --> 00:14:49.365
problem so that gave us immense confidence and then we
00:14:49.365 --> 00:14:52.145
said okay let's go ahead with this tool right and we started building it
00:14:52.145 --> 00:14:55.065
and then we started to and then we started talking
00:14:55.065 --> 00:14:58.105
to a lot of potential customers right we started
00:14:58.105 --> 00:15:01.225
reaching out to people while we were building the content engine
00:15:01.225 --> 00:15:04.265
we started reaching out to people as well but then started
00:15:04.265 --> 00:15:07.005
the actual problem because they get onboarded and the
00:15:07.005 --> 00:15:10.105
trials were going on for like months together two months
00:15:10.105 --> 00:15:12.945
three months sometimes they just have to deprioritize the
00:15:12.945 --> 00:15:15.805
whole thing and then come back after six months or sometimes they
00:15:15.805 --> 00:15:18.685
don't even come back they say they move to a different tool we lost touch
00:15:18.685 --> 00:15:21.525
with them but things like this happened and this was
00:15:21.525 --> 00:15:24.505
a cause of you know this is something that I didn't expect at all because
00:15:24.505 --> 00:15:27.465
I thought okay the problem is there it's easy to make a sale but actually
00:15:27.465 --> 00:15:30.845
it was very difficult to make a sale because I think quality you
00:15:30.845 --> 00:15:34.625
know is the last thing that happens right because leaders have other priorities
00:15:34.625 --> 00:15:38.465
business critical priorities that they have to prioritize and then this goes
00:15:38.465 --> 00:15:42.745
in the backseat then it has to come back again and most of these products especially
00:15:42.745 --> 00:15:46.785
like test automation tools they work only with a top-down approach that is another
00:15:46.785 --> 00:15:47.725
thing that I learned Right.
00:15:48.025 --> 00:15:51.645
Even if QA engineers themselves find the product really useful,
00:15:51.645 --> 00:15:53.785
they need to get approval from their upper management.
00:15:54.105 --> 00:15:57.945
And even if they don't find it useful or they get set back because of a product
00:15:57.945 --> 00:16:01.045
like this, I mean, because of the general fear that they have. Right.
00:16:01.365 --> 00:16:04.105
Because of that, again, a top down approach is the only way it works.
00:16:05.235 --> 00:16:08.315
When you think about all of these things the sales cycle was really wrong
00:16:08.315 --> 00:16:11.035
along initially and that is one thing that you know
00:16:11.035 --> 00:16:13.875
i really misunderstood and then got into it and there
00:16:13.875 --> 00:16:16.835
were a lot of frustrated nights you know that we spent in
00:16:16.835 --> 00:16:20.715
terms of trying to crack that sales cycle okay and
00:16:20.715 --> 00:16:23.575
did you also have scenarios where customers were actually
00:16:23.575 --> 00:16:27.395
asking you to customize a tool based on their needs definitely
00:16:27.395 --> 00:16:30.175
they do it even today right so and that is something that is
00:16:30.175 --> 00:16:33.075
how we built it as well so developer so devashore was actually
00:16:33.075 --> 00:16:35.775
built for you know customers who want to
00:16:35.775 --> 00:16:38.595
solve it for complex applications not the simpler ones but
00:16:38.595 --> 00:16:41.495
for the complex ones like i'll give you an example right say
00:16:41.495 --> 00:16:44.535
if you have something like maybe a map say swiggy
00:16:44.535 --> 00:16:47.555
or something like that and you want to pinpoint something on the map and then
00:16:47.555 --> 00:16:50.695
you want to measure the distance and then you want to validate those use cases
00:16:50.695 --> 00:16:54.635
you can use devashore for that similarly if you have figma you want to draw
00:16:54.635 --> 00:16:58.075
designs there and validate you know how the designs are rendered and then you
00:16:58.075 --> 00:17:01.795
want to basically do all of this within a canvas, which cannot be done with any automation tool.
00:17:01.975 --> 00:17:05.375
You can use DevShare. Flutter apps, you can use DevShare. So the whole point
00:17:05.375 --> 00:17:07.635
of building DevShare was for complex applications.
00:17:07.835 --> 00:17:11.675
So keeping that in mind, we wanted to provide a customized solution,
00:17:11.895 --> 00:17:18.435
which can be customized by the customers based on their application itself.
00:17:18.755 --> 00:17:22.515
So that's how we designed it itself. And we continue to provide it in that fashion.
00:17:22.775 --> 00:17:27.055
So anyone who needs customizations, we provide a lot. Like to give you one example
00:17:27.055 --> 00:17:28.435
that we did very recently, right?
00:17:28.535 --> 00:17:31.275
One of our customers wanted to have the ability to include their own
00:17:31.275 --> 00:17:34.135
libraries as well and we provided that way that that
00:17:34.135 --> 00:17:36.995
as well that as a solution so it's a no-code platform where you
00:17:36.995 --> 00:17:40.635
can even in like even include libraries from third-party
00:17:40.635 --> 00:17:43.635
tools as well so even that is possible so we provided a
00:17:43.635 --> 00:17:46.515
customized solution only which can be configured based
00:17:46.515 --> 00:17:49.775
on the customer's needs okay that's interesting so
00:17:49.775 --> 00:17:52.995
you might have seen a lot of changes happening in QA as
00:17:52.995 --> 00:17:56.075
well as in the test automation space in the last few years so
00:17:56.075 --> 00:17:58.995
where do you see qa heading over the next few years and
00:17:58.995 --> 00:18:02.355
how is devesture positioning itself for that future so this
00:18:02.355 --> 00:18:05.535
is an evolution right like even without ai you
00:18:05.535 --> 00:18:08.935
can see that you know like qa engineers became
00:18:08.935 --> 00:18:12.835
automation engineers and then s debts as well building frameworks and all that
00:18:12.835 --> 00:18:16.835
right that's how the evolution itself happened but then if you think in terms
00:18:16.835 --> 00:18:21.535
of like what goes i mean what is there beyond that right see the goal of devesture
00:18:21.535 --> 00:18:25.715
is We are trying to provide a platform to streamline the entire QA process itself.
00:18:26.219 --> 00:18:30.179
To streamline the journey of a tester. So what are the roadblocks that a QA
00:18:30.179 --> 00:18:32.879
engineer faces, right? That is exactly what we are trying to reduce.
00:18:33.119 --> 00:18:37.359
So in terms of like how we are seeing the evolution happen for QA engineering
00:18:37.359 --> 00:18:40.179
itself, I think the role changes, right?
00:18:40.359 --> 00:18:44.019
Rather than focusing on manual execution or rather than focusing on scripting,
00:18:44.339 --> 00:18:47.639
the role changes to kind of supervise what the AI agents are doing.
00:18:47.799 --> 00:18:51.319
Because at the end of the day, to rebuild the context, or because of the design
00:18:51.319 --> 00:18:54.519
changes, the product changes, the context rebuilding is definitely required.
00:18:54.639 --> 00:18:58.159
To rebuild the context, to make sure that the AI output is right, right?
00:18:58.259 --> 00:19:00.979
So the QAs, I think, will probably change into something like,
00:19:01.019 --> 00:19:04.699
you know, supervising the entire process itself and making sure that the edge
00:19:04.699 --> 00:19:08.479
cases are covered, focusing on what really matters, more value-driven use cases,
00:19:08.619 --> 00:19:10.639
rather than focusing on the smaller ones, right?
00:19:10.879 --> 00:19:14.099
And I think with this, I think there'll be a lot of, you know,
00:19:14.179 --> 00:19:19.259
well, improve in productivity as well, so that the repeated work that the QA
00:19:19.259 --> 00:19:23.979
engineers or the automation engineers or estates are doing can be potentially reduced.
00:19:23.979 --> 00:19:27.539
So I think with Devashore, with all of these multiple agents,
00:19:27.699 --> 00:19:30.379
that's the direction that we are heading in, where we are trying to streamline
00:19:30.379 --> 00:19:34.899
the entire process, build a workflow so that their productivity is improved.
00:19:35.039 --> 00:19:38.599
And at the same time, you know, there's a lot of reliability in terms of,
00:19:38.719 --> 00:19:40.979
you know, how they want to test the application as well.
00:19:41.459 --> 00:19:45.839
Okay. But with the maturity of AI solutions and products like Devashore,
00:19:46.059 --> 00:19:49.579
one thing that I fear is maybe the next four or five years, there is a high
00:19:49.579 --> 00:19:53.739
possibility that AI might replace some of the testers. The only area where I
00:19:53.739 --> 00:19:56.299
don't see a lot of advancement is around domain.
00:19:56.599 --> 00:20:00.819
For example, there are testers who have very good experience around a domain
00:20:00.819 --> 00:20:02.159
as well as business process.
00:20:02.399 --> 00:20:06.519
That's a gap that I see. But otherwise, I believe with the maturity of AI solutions,
00:20:06.699 --> 00:20:10.739
with all these DeepSeek, OpenAI, and all those, what I would say, technologies in place,
00:20:11.019 --> 00:20:14.399
I think there might be, I would say, the number of testers that you might see
00:20:14.399 --> 00:20:17.159
in an organization might actually come down in the near future.
00:20:17.419 --> 00:20:18.679
So what's your take on this?
00:20:19.432 --> 00:20:24.952
Yeah, I agree. Right. Definitely. Right. So I think operating with leaner teams is the new norm.
00:20:25.132 --> 00:20:28.892
Now, whether it is with testing or with development, teams tend to move to having
00:20:28.892 --> 00:20:30.172
a leaner team rather than having
00:20:30.172 --> 00:20:33.832
bigger teams because of the changes that these agents are bringing in.
00:20:34.192 --> 00:20:38.872
Right. But if you ask me, is there going to be a job displacement or a replacement?
00:20:39.172 --> 00:20:43.892
I don't think so. There is going to be a shift in the kind of work that people are going to do.
00:20:44.032 --> 00:20:48.432
There are going to be leaner teams, smaller teams. But I don't think that testing
00:20:48.432 --> 00:20:52.592
is a job that can be completely displaced, like pretty much like what you called out, right?
00:20:52.672 --> 00:20:56.832
The domain expertise, someone is required to still maintain the domain expertise.
00:20:57.012 --> 00:20:59.692
And I think no one better than testers can actually do that.
00:20:59.792 --> 00:21:01.212
I've been a tester myself, right?
00:21:01.352 --> 00:21:04.972
So I know that I need that domain expertise. I need to build it over a period
00:21:04.972 --> 00:21:07.552
of time. And the same thing the agent can do.
00:21:07.912 --> 00:21:11.232
But to think like, you know, at the end of the day, the users,
00:21:11.392 --> 00:21:14.252
the consumers of your product are still going to be humans only.
00:21:14.252 --> 00:21:17.232
They are not going to be AI engines unless and until you're developing a product
00:21:17.232 --> 00:21:19.332
which, you know, you want the agents to consume.
00:21:19.552 --> 00:21:23.132
So when you have the end users being your humans or your customers,
00:21:23.272 --> 00:21:26.572
you have real-time scenarios which only those testers who have their domain
00:21:26.572 --> 00:21:27.832
expertise can replicate.
00:21:28.272 --> 00:21:33.032
So AI can solve your problem 90% of your time, but 10% is still required.
00:21:33.192 --> 00:21:37.372
So yes, with leaner teams, right, I think number of testers will go down.
00:21:37.672 --> 00:21:42.532
But I don't think testing itself will, I mean, testers itself will be displaced.
00:21:42.532 --> 00:21:45.332
There's going to be a job shift but i don't think there's going to be a displacement.
00:21:46.141 --> 00:21:51.041
Okay, that's a very good point of view. Divya, coming back to the product,
00:21:51.321 --> 00:21:53.741
one of the questions that I have was around visual testing.
00:21:53.981 --> 00:21:57.541
And visual testing is one of the, I would say, there are not many products that
00:21:57.541 --> 00:22:01.801
actually offer visual testing capabilities, and visual bugs are also very hard to catch.
00:22:02.081 --> 00:22:08.241
So how does DevAzure help you with visual testing as well as the testing of
00:22:08.241 --> 00:22:11.861
UI across multiple browsers, mobile devices, and screens?
00:22:12.481 --> 00:22:16.021
Yeah, fair point, right? So I have a small story here as well.
00:22:16.141 --> 00:22:19.021
From personal experience so there was a bug fix that
00:22:19.021 --> 00:22:21.941
we had to do it do for a customer not in devaship but
00:22:21.941 --> 00:22:25.081
prior to that in one of my startups that i worked in so
00:22:25.081 --> 00:22:28.141
a small bug fix was required we made the bug fix and
00:22:28.141 --> 00:22:31.061
i just quickly just tested you know whatever that that fix was
00:22:31.061 --> 00:22:33.821
for and then released it to production but then this was
00:22:33.821 --> 00:22:37.101
on the front end only so then what happened was the release
00:22:37.101 --> 00:22:39.801
was done and everything and the next morning i come back and see that
00:22:39.801 --> 00:22:42.701
there's a major production issue because of one
00:22:42.701 --> 00:22:45.761
a small bug fix that i made there was another issue
00:22:45.761 --> 00:22:48.661
that the component impacted right a css which
00:22:48.661 --> 00:22:51.481
was changed in one component impacted another component and that created
00:22:51.481 --> 00:22:54.221
a bigger issue in the home page itself which was very evident to our
00:22:54.221 --> 00:22:57.281
customers so that was a nightmare for me right
00:22:57.281 --> 00:23:01.841
that's when i realized that you know visually validating right it's not important
00:23:01.841 --> 00:23:06.201
just to validate functionally but you need to visually validate itself and even
00:23:06.201 --> 00:23:09.541
in that same organization as part of a hackathon i did a small project where
00:23:09.541 --> 00:23:13.681
you know we wanted to visually test and make sure that you know it works well
00:23:13.681 --> 00:23:14.761
across multiple browsers.
00:23:14.921 --> 00:23:18.181
So this is almost like 10 years back. So at that point of time,
00:23:18.301 --> 00:23:21.061
we had to make sure that the product worked across multiple browsers,
00:23:21.601 --> 00:23:26.561
multiple devices, browsers within those devices, landscape, portrait, and all of those things.
00:23:26.661 --> 00:23:30.441
So I did a small project there. And that is what eventually translated into
00:23:30.441 --> 00:23:32.801
what we have for visual testing in DevShare as well.
00:23:33.001 --> 00:23:36.401
So if I had this at that point of time, definitely we would have definitely
00:23:36.401 --> 00:23:38.781
avoided that bug itself.
00:23:39.363 --> 00:23:43.543
So what the visual validation tool within DevShare does is, it does this, right?
00:23:43.743 --> 00:23:46.603
So whenever you fix something, whenever you fix something on the UI,
00:23:46.903 --> 00:23:50.723
it kicks in and validates it across multiple release cycles to make sure that
00:23:50.723 --> 00:23:53.023
you've not regressed any of the flows on the UI.
00:23:53.323 --> 00:23:57.283
So it makes sure that even a small button shift is actually calculated across
00:23:57.283 --> 00:23:59.183
a different threshold, different thresholds.
00:23:59.323 --> 00:24:03.023
And then you, and it kind of, you know, reports it across multiple browsers
00:24:03.023 --> 00:24:05.263
and different resolutions as well.
00:24:05.903 --> 00:24:09.943
So that was one of the reasons why we built it. And the other part is in terms
00:24:09.943 --> 00:24:14.163
of data validations as well, especially when you have these data visualizations,
00:24:14.363 --> 00:24:16.923
right, whether it is your dashboard charts, graphs that you have,
00:24:17.023 --> 00:24:20.783
right, if you want to validate that whatever data that you're inputting is actually
00:24:20.783 --> 00:24:23.603
being replicated correctly in those graphs or charts,
00:24:23.963 --> 00:24:26.803
then the visual validation tool can also be used for that.
00:24:26.803 --> 00:24:30.623
So one of our customers, they have a lot of these dashboards and all that.
00:24:30.743 --> 00:24:36.123
So they were able to bring down their testing time from one week to 10 hours
00:24:36.123 --> 00:24:37.483
and then 10 hours to five hours.
00:24:37.583 --> 00:24:40.303
And now they are looking to bring it down to one hour itself.
00:24:40.523 --> 00:24:44.283
So they are one of our customers who have been with us for the longest period
00:24:44.283 --> 00:24:45.783
of time, one of our early customers.
00:24:45.983 --> 00:24:50.223
And now they're looking to, they're actually moving towards bringing down to one hour.
00:24:50.403 --> 00:24:53.563
So that's the kind of impact that a visual validation tool has.
00:24:53.983 --> 00:24:55.623
And DevShare is able to do that really well.
00:24:56.083 --> 00:24:59.703
Okay, that's a very good story as well as an example that you quoted.
00:24:59.983 --> 00:25:03.663
Thank you so much for that, Divya. So before we wrap up, Divya,
00:25:03.783 --> 00:25:05.423
like what's coming next for Devassure?
00:25:05.583 --> 00:25:09.323
Any exciting features, partnerships or expansions plans that you're having?
00:25:10.079 --> 00:25:12.719
Definitely on the features side, I think we are two, I mean,
00:25:12.859 --> 00:25:15.279
partnerships, we have like smaller partnerships going on.
00:25:15.419 --> 00:25:19.939
But in terms of the features itself, yes, we have like a lot of big things coming in.
00:25:20.059 --> 00:25:24.499
So like I told you, we have multiple agents who kind of which shares like multiple
00:25:24.499 --> 00:25:26.259
context about the application itself.
00:25:26.459 --> 00:25:30.019
So the next big thing is to for us to actually train these agents in a better
00:25:30.019 --> 00:25:32.039
way. So we have enough data that we've collected.
00:25:32.219 --> 00:25:35.919
And now we want to start training these agents, trying to rebuild the context
00:25:35.919 --> 00:25:40.059
on its own, and then trying to, you know, work in an autonomous way as well.
00:25:40.079 --> 00:25:45.839
So that majority of the work, it can do it without any manual intervention as much as possible.
00:25:46.199 --> 00:25:49.099
Today, there's some amount of manual intervention which is actually required
00:25:49.099 --> 00:25:53.839
at every stage. But we want it to function autonomously with minimal manual intervention.
00:25:54.059 --> 00:25:57.819
So that's where we are heading towards. And one of the things in that direction
00:25:57.819 --> 00:26:01.259
where we are actually moving, which is like kind of very soon is going to be
00:26:01.259 --> 00:26:04.979
released in terms of, you know, especially in terms of test automation is today.
00:26:05.239 --> 00:26:09.719
It takes around like, say, five minutes for a single test automation script to be generated.
00:26:10.079 --> 00:26:15.659
So we want to move this to say, the agent will then be able to do it in parry
00:26:15.659 --> 00:26:17.759
for 25 cases within those five minutes.
00:26:18.099 --> 00:26:20.779
So that is the kind of performance improvement that we are seeing.
00:26:20.919 --> 00:26:25.799
So that today when our customers are able to say automate like say 10 cases
00:26:25.799 --> 00:26:29.339
in one hour, we want them to be able to do 25 cases in five minutes.
00:26:29.719 --> 00:26:32.539
So that is the shift that we are actually planning to make. And we are trying
00:26:32.539 --> 00:26:38.139
to see how we can actually improve the performance with speed and then bringing
00:26:38.139 --> 00:26:40.919
in the reliability aspect as well. Because if there's no reliability,
00:26:40.919 --> 00:26:43.299
then there's no point in developing a tool like this.
00:26:43.919 --> 00:26:47.579
Yeah, I agree. So Divya, this has been incredibly insightful.
00:26:48.019 --> 00:26:51.779
Thank you for sharing your journey and giving us a behind-the-scenes look at Devashore.
00:26:52.019 --> 00:26:56.859
So wishing you and your team all the best as we continue to reshape the future of test automation.
00:26:57.439 --> 00:27:01.819
Thank you so much. Thank you very much, George. And I always followed you on
00:27:01.819 --> 00:27:04.939
LinkedIn as well. So I always value the content that you keep posting.
00:27:05.079 --> 00:27:07.919
So thank you very much for this opportunity, for providing this opportunity
00:27:07.919 --> 00:27:10.519
to interact with you. Thank you very much. You're welcome. Thank you.
00:27:10.800 --> 00:27:54.757
Music.