One of the biggest challenges for Salesforce testing is that it’s a constantly evolving platform. They continue to bring out new products through innovation or acquisition; Slack is a great example. While customers love this constantly improving environment, it becomes a major headache for dev teams responsible for testing as they can’t keep up with it. It becomes very expensive to maintain and it also means that customers might not be doing enough testing. That’s where Provar comes to the rescue.

“Our unique approach is that we actually use something that Salesforce provides. It’s called metadata that allows us to be very smart and deliver unbreakable test cases for large Salesforce implementations,” says Geraint Waters, CEO and Co-Founder, Provar.

Provar’s approach is quite smart as they used polymorphing that allows them to take a single test case that covers many different scenarios such as multiple users, different browsers, and even different languages.

To make it even simpler for users, Provar has embraced a no-code approach so both technical and non-technical teams at companies can easily create and execute tests without compromising results.

Given the growing shortage of cloud skills as well as the growing adoption of cloud-native technologies, this no-code approach becomes even more critical to new businesses that can’t hire the technical expertise they need.

“I think it’s really interesting actually from the skills perspective as environments such as Salesforce are bringing in new people who don’t know the technology, but they’re upskilling them really quickly with great online training and a great ecosystem,” adds Waters. “We recently sponsored Supermums, which is trying to encourage mothers back into the workplace.”

Another realistic aspect of these new businesses is that they will have a mix of teams – highly technical teams driving core development and operations and non-technical teams. Provar helps bridge the gap between these two teams so they can continue to work together.

Check out the interview on YouTube to learn more about how Provar is helping teams in the Salesforce environment.

Guest: Geraint Waters (LinkedIn, Twitter)
Company: Provar (Twitter)
Keywords: Test Automation, Salesforce Ecosystem, Low Code/No Code
Show: Let’s Talk

About Geraint Waters: Geraint Waters began his career in technology and innovation as an IT Consultant for PWC in 1999. After advancing his leadership at UBS Investment Bank and Barclays, Geraint and his co-founders saw a high market need for a no-code Salesforce test automation and founded Provar in 2014. For nearly a decade, he has scaled his global teams as CEO/Co-Founder, while continuing to bring new solutions to enterprise customers. When not at work, Geraint enjoys rooting for Liverpool and spending time with his two children and wife in Beckenham, Southeast London.

About Provar: Provar pairs intuitive testing solutions with world-class service to help teams capitalize on their Salesforce investment with a robust and scalable solution designed to improve release agility, drive down system errors and advance innovation.

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi, this is Swapnil Bhartiya and welcome to TFiR Let’s talk. Today we have with us Geraint Waters, CEO and co-founder at Provar. It’s great to have you on the show.

Geraint Waters: Good, pleased to meet you Swapnil.

Swapnil Bhartiya: Tell us a bit about the company, what does the company do and what problem you saw in this space that you wanted to solve that you created the company?

Geraint Waters: I mean, we were a leading test automation company for Salesforce. So we’ve been around for about nine years and we have offices in the UK, India, US. Realistically, I mean the biggest issue that we saw nine years ago with Salesforce testing is it’s a constantly evolving platform. They’re always bringing out new products. I mean recently acquired Slack. I mean, it is a very changeable environment and realistically customers love that. It’s rapidly bringing on new services, third party packages. Actually from a testing perspective, it just makes traditional coded frameworks very expensive to maintain. So customers don’t test enough and they’re employing developers to do it. So our unique approach is that we actually use something that Salesforce provides. Something called metadata that allows us to be very smart and deliver unbreakable test cases for large Salesforce implementations. We also have features to support sort of non Salesforce so we can do like end to end testing.

Realistically we’re quite smart. We call something called polymorphic and that allows us to take a single test case that covers many scenarios, such as multiple users, data driven, different browsers, different languages even. I’d say the last thing we’re particularly good at is just being very intuitive. So a lot of our users and we get into this in the chat, I hope is that essentially that they’re not always technical. So we have a no code approach where our users can create tests the same way as they use Salesforce and they can edit and execute test in that fashion. So it works very well for our space.

Swapnil Bhartiya: Today every company is going through digital transformation and cloud adoption, which is creating a unique challenge, first not every company is not a tech company so they don’t have in-house tech expertise for these technologies and 2 there is already a huge shortage of cloud skills.  So can you talk about the role no code and low code is playing in helping folks embrace these latest new technologies without having to worry about getting the technical skillset that is needed.

Geraint Waters: And I think it’s really interesting actually from the skills perspective and resourcing is that these environments such as Salesforce are massively bringing in new people and enabling new people who don’t know the technology, but they’re up skilling them really quickly with great online training and great ecosystem, encouraging people. I mean, we are sponsored supermoms recently, which is trying to encourage mothers back into the workplace and Salesforce and a great job encouraging that. So I think you’ve got this situation where you have business users, you have less technical users who are able to declaratively make changes to Salesforce and really add value to projects. But then I think you also have lots of other scenarios which are required for any project where you need more technical people. So do you want to do integrations? Do I want to join third party applications?

So that isn’t something that you would want to trust someone who hasn’t got an It background. So I do believe those two worlds are combining and it’s a skill to make sure that we get the best of both worlds. I would say a lot of enterprise customers are realistically getting on the road of having things like center of excellences. That allows them to really pull the architecture type of resource in a place where companies can allow their business users to develop applications declaratively, then rely on the sense of excellence to be a fallback, to be a, we will not let you go wrong type of situation. Because ultimately what I’m seeing in Salesforce space is we start small and it gets bigger. Then we get regression. Then we get emails flying out. Then we really have a lot of danger.

Because the problem with Salesforce is you genuinely can make these changes that can torpedo a large part of the system you didn’t know you were touching. It’s got this no code elements, it’s got the non-technical parts to it, where you got the expertise in what you want to do, but you also need to have these safety nets. You need to understand how you’re deploying. You need to know how you’re testing and that you can’t expect people who are coming in with the business knowledge to think about those things in the same way.

Swapnil Bhartiya: When I was listening to you I wondered if there is even further gap within the  Salesforce environment – where some teams are highly technical and others are not technical, depending on their department. What are you folks doing to bridge this gap between these kinds of teams?

Geraint Waters: I mean, what we’ve got to do is look at what companies are trying to achieve firstly. I think that’s. We’re bored of traditional IT development. I mean, I go back to my days prior to Provar I would work on these client server apps. It was all custom. We were deploying databases with something above on top of that. I mean, the no code, low code solutions are coming out there are phenomenal with regards to enterprises not having to invest in really technical stuff, such as data centers and monitoring the data centers and failovers. No one would quite understand how difficult and painful pushing data around globally for end space, really quite hard stuff. So we get that for free. It’s absolute phenomenal. And again, to my mind, I think the key thing is we want this agile quick to deliver approach, but new problems are presented I feel because of that approach.

So you get lots of stuff for free, but you stay in time, the fundamental issue of testing, making sure that you don’t break things between releases. It’s dead easy to make a small change. Fantastic. The business are over the moon that you’ve delivered something in a day and it went live in a day. However, they’re not over the moon if that change ultimately took down some very important end to end flow that was the payment system. So we want both. We want the security that it’s working. We want to have the less skilled people doing it, but the skill is that we need to put those pieces together. I think what are we doing in particular? I think is part of the question. Is we bring the tool that can rapidly build that test and keep them maintainable.

But in order to implement it, we bring a service that allows us to up skill. Again, the less technical people, the business users, how to develop these safety net. So they can go at speed, they can deploy regularly, but each time release days being the night that people don’t sleep because they’re so panicky that something will break because last week it did, when we did a deployment. I genuinely feel, important things that we do is preventing the information to people so they understand how things are changing and how things are tested with scenarios that are covered, but also evidence so that the production teams can have faith that these guys can be trusted.

Swapnil Bhartiya: I am curious how most enterprises manage the testing for low code and no code applications and how are you folks helping them so they don’t end up wasting too much time on such tasks?

Geraint Waters: I mean, it’s a good question. I mean, I’m going to give you my opinion here. I mean, there’s a large number of customers. Again, I’m using Salesforce usually as my example, that are adopting Salesforce, but the reality is, I think it’s a bit of a journey. Again, I feel Salesforce is adopted in pockets across a big company by many teams and it’s not always coordinated. So typically what happen is you make your changes, you put it live, it’s phenomenal. You put it live within a week. The problem then is those teams are probably the guy who configured it is the person who’s then testing it. Now that works for a while. Then what happens is you put a bit more on, you put a bit more on, then the users love it and you change it, then there’s more and then regression builds.

So that model of just the same people testing it, who configured it is going to break down, especially when they realize they’re spending more time testing than not or they’re not testing at all, which is even scarier. So I then feel there’s an evolution where they go, “No, we need to test.” And they bring in professional testers and they end up being manual. Then the problem evolves into a new problem, which is this thing that was really quick to deploy now has this really time consuming, manual testing element, where we can’t make our changes quickly because we’ve got this weak worth of regression. So I think that then involves into, “We need to sort that out.” The sorting it out involves usually looking at something like a coded solution first. I mean, people like the open source approach to this and I think that’s a great solution.

It’s just not a great solution for Salesforce. The reason for that is because Salesforce is a really tricky app to test. It’s got this sort of technical nature to the way it renders its pages that in between releases of Salesforce releases, it looks completely different. So a lot of those tests just are unmaintainable. That’s the reason where products like Provar come along. Now, what we are doing is of course having that product that can, that deliver a regular maintainable solution to this. But we’re also a QA company able to go out and advise and help and assist to really make sure these projects are successful in what they’re trying to achieve.

Not just develop 1,000 test cases and guess what, you’ve got 1,000 test cases to maintain. We want the fewest number to reduce the risk, to make sure that we can execute timely fashion, to understand that we’re. And we frequently advise on just Salesforce changes. We do webinars about what Salesforce are doing in their next release. They do three releases a year that could fundamentally break customer solutions. Again, they need, a lot of our customers need that service to make sure they fully understand what platform they’re on and how to make the most of it.

Swapnil Bhartiya: Can you talk about the evolution of testing how it’s different in the cloud native landscape vs traditional IT environments? There are still IT shops there. On prem is still there, but what is the disconnect between how testing and done for like Cloud Native application development versus local and no code?

Geraint Waters: I mean, I think if you put in apps on AWS is all Google. I mean, you’re very likely to follow similar mechanism, traditional software developments. Obviously you’ve got a benefit to massive scale and scripted environments, but I mean, many of our customers still use Provar test these applications too. I mean, we see that as standard testing. But what I think interesting about Salesforce is, I mean, firstly Salesforce performs its own functional, nonfunctional testing for components they ship and which customers rely upon. Which in reality means that there should be fewer scenarios for the end customer to have to test. Equally, when you’re developing your own apps on Salesforce, you don’t have control over the Dom, the rendering, the resource, the execution. So there’s limitations about what the app can do. So again, you are more bounded. So I think the advantage for no code implementation is that you can prioritize the functional integration testing for what you have delivered.

So it’s like a bit more reducing the scope of what you need to do. Now there’s a big danger with that in my opinion, because actually then the enterprise then just thinks, “Well, I don’t have to do all that testing. It’s not my problem.” But it is their problem because if it goes wrong, it’s their business, their customers that are affected. So when Salesforce bring out their three releases a year, their weekly patches, the reality is the end customer does need to be conscious of yes, you get certain things for free. Yes, they’re bundled with your subscription. Yes, Salesforce are working extremely hard to forever make that testing better. They’ve got load of programs that we’re involved with as well.

But the reality is the overall responsibility has to be in ensuring that works. Again, that is a very good argument for having a regression pack that’s meaningful, that has business scenarios, that ultimately you run all the time and is very visible to the whole project and stakeholders because they get that fundamental belief that yes, we’re making changes, but the core things that we do are continuing to work the same ways they always did.

Swapnil Bhartiya: Do you have a playbook to share for teams, irrespective of how technical they are, in terms of how they should approach low-code and no code testing?

Geraint Waters: I mean, I think to my mind, they’re not massively different. I mean, my tips for any testing is to really understand the full end to end risk based profile of what is in front of you, in my opinion. If I was going to start a fresh, I would sit down and look at, if anything went wrong in this area, would I lose my job? Would my team be under severe pressure? I would start there. I would be looking at where you send outbound emails. So there’s this risk that those emails could get into the wrong hands or be sent from the wrong environments and those type of things. If there’s any financial flows of data, if there’s any PDF documents and quote flows and those type of things. So I’d be really analyzing before I do anything what are the business flows that mean something to me?

If there’s something cosmetic and it ends up being on a screen, that’s more for the internal users and the boxes in the wrong place. You’d fix that in an afternoon. No one needs to know. If there’s business flows and you are really implementing something that goes from a retail website to a Salesforce backend, to an automate API that’s sent to a different system. I would come up with a strategy that combines API testing of those interfaces, along with the making sure that the critical flows of data and permentations of data, if there’s any currency or date logic, which can go wrong and trip things up, I’d be planning that. So to my mind, the tips really are a case of. And this is something we do specialize with customers is `try to understand what we’re trying to achieve because there’s nothing I detest more than just creating tests for the sake of it or because they’ve read a functional spec and I need to be clever enough to find something.

And you end up that into your regression pack, because your regression pack over time bloats and gets bigger and bigger and that’s not actually useful to people. What we want to move quickly and to have agile projects is the right tests running all the time and giving us that immediate feedback. So when I do change things I can get after it. So it’s really important right from the beginning we test the right things in my opinion and I love end to end testing. I just think that’s the way forward. Don’t get rat holing down one app, test it to death. When realistically the one next year you can just do the smallest of things and everything falls over.

Swapnil Bhartiya: Geraint, thank you so much for your time today and sharing these insights. I really appreciate that and I look forward to talking to you again soon. Thank you.

Geraint Waters: No, Thank you for your time. I thought your questions were excellent. I appreciate it. Like you promised it was fun.

[/expander_maker]