Improving the maturity of the Salesforce DevOps process is essential for increasing work productivity and delivering value to an organization in a timely manner. A key aspect of enhancing DevOps involves prioritizing testing and shifting it to the early stages of development. It is crucial to choose the right functional testing tool, comprehend quality, and optimize release quality in Salesforce implementation projects. In this podcast episode, we have Samuel, a product manager and architect at Provar, a leading Salesforce testing tool, who shares his expertise on various quality and testing topics in the Salesforce ecosystem. He also explains how to integrate quality into all aspects of a Salesforce project.

Samuel is a respected figure in the Salesforce community, serving as a product manager and architect at Provar. He is known for his proficiency in developing apps on the Salesforce platform and his emphasis on quality. Provar is an automation testing tool that is integrated and code-free, tailored particularly for Salesforce. Samuel is also the founder of Yplicity, a Salesforce ISV partner, and has extensive experience in transforming intricate concepts into user-friendly apps for the Salesforce ecosystem. In this podcast, Samuel shares his perspective on what defines quality. The conversation then delves into the challenges of balancing automated testing with small development changes in Salesforce. Samuel also discusses the trend of embedding testing and quality frameworks within DevOps processes to maintain quality in the industry. Additionally, we explore how to handle failed deployments or implementations in production. We also touch on the importance of achieving comprehensive coverage across all systems through end-to-end testing expansion. Samuel offers recommended resources for those interested in unit testing, automated testing, and quality assurance. Lastly, Samuel shares his own experience in the Salesforce ecosystem. This podcast is a must-listen for anyone interested in quality and testing in Salesforce implementation projects.

Resources:

Connect with Samuel:
LinkedIn: linkedin.com/in/samuelarroyo/

Mentioned in the episode:

Ministry of Testing: ministryoftesting.com/

Test Automation University: testautomationu.applitools.com/

University of PROVAR: provar.me/

Salesforce Trailhead Modules on Testing: trailhead.salesforce.com/modules

Podcast Transcript:

Francis Pindar 0:00
Hello, my name is Francis Pender, and you are watching or listening to the Salesforce posse podcast, where I speak to Salesforce industry influencers. So we can get you a better understanding of how to excel in a career path from a Salesforce admin or developer, to an architect. And in this conversation, I’m going to be talking to Samuel Aurora, who is a product manager and architect at PROVAR, a fantastic testing tool for the Salesforce platform. But I wanted to pick his brains about how you build for quality, and how you stop pushing the needle to improve outcomes in Salesforce implementation projects. So interested in maximising release quality, I’ll want to take a look at how you choose a functional testing tool correctly, or even understand what quality is, then we’re gonna, you’re gonna get a lot of value out of this conversation with Samuel. So without further ado, let’s go. So here we have Samuel Arroyo. Arroyo, is that correct? I was getting those wrong. Brilliant. So how did you get into the Salesforce ecosystem?

Samuel Arroyo 1:26
But it’s a bit of a funny story I was studying at university. And I think it was it was a three year degree. It was a third year, and we had some conferences, and a startup from Madrid came, they did a couple of sessions. One was about Google Cloud. And the other was Salesforce. I didn’t care about Salesforce at all. We will was the name I wanted? Yeah, exactly. So I definitely went, went to the Google Cloud conference. And I will say there was they did like some sort of interview, where I tried to explain Oh, yeah, I did that. And this and that. And, and I will say that they never contacted me for a while then. I was on holidays. And they reached out to me. They got at the startup and they call me and like, Would you be interested in working in this startup working in in Salesforce like the Salesforce ecosystem? I don’t have a clue what Salesforce is. I’m calling your holidays. But I mean, it’s been, you’re a young person, you don’t say no to a job fairly. Recently, this 50% You’ll say no to a job. So that’s it, like okay, as I’ll be starting in a couple of weeks. And you also find like, when I started the team, that the few people that also joined the already one week training, were training, they were just following one of the Salesforce resources. And there was a like a big book of Salesforce where they they had everything, and they were going through that. But I figured out there were workbooks, there was a like a visa force workbook. And then I started using those, which were much more practical. And and in a week, I really caught up on surpass them, because they were so yeah,

Francis Pindar  3:25
brilliant. Yeah, I remember that. So when did you get started with how many years ago

Samuel Arroyo 3:29
in the cell now? Must be like 2012.

Francis Pindar  3:33
Okay, yeah. So yeah, it’s kind of like, all you had was like the workbooks, the online manual. And that was it. And the Salesforce courses, you know, which you could spend hideous amounts of money on? And that was it, and maybe some developer forums. I think that was it. We’re here. Yeah, talking about quality. And so I think kind of it’s it’s really important for the old days and architect and new way, making sure that that what’s being envisioned, what the goals of the organisation are, are being delivered, I suppose through my architectural designs and also being kind of implemented in the organisation. But I think, yep, I think maybe the first question to ask is like, what does quality mean to you? I think,

Samuel Arroyo
yeah, that’s a good question. Isn’t gnarling to me, I think quality means different things to different people. When I think about quality, I can think of the whole lifecycle and how different people will think that what they do, there’s an aspect of quality. So I think it’s easier when when we look at something that is not software, sometimes and when you have a watch, and you think this watch is quality, like it has good quality, but do you look in it, is it because it’s robust? You can go on the water? Or is it because it didn’t last very long. So I think For me quality, it is that something is doing what it’s supposed to be doing. By when it comes to software. For some people quality means it never breaks. But for other people that are more interested in the experience of the user, for them good quality means a good user experience sometimes. So as a business is important to define, what do we mean by quality? All the different angles by which you can look at quality with, which I think in the end is, well, why what, what is what does good look like? Then set the benchmark? And then once you know what good looks like, it’s like, okay, that is quality that we’re striving for. And, and then anything below that is room for improvement.

Francis Pindar 5:55
Yeah, I think it’s, I always found, yeah, when done done always is the same kind of thing. I remember working in a film post production company. And it’s like, when, and it’s very design thing, right? Creating CG graphics and stuff for films, and it’s very creative. And it was like, when is it got to that kind of quality bar, that you’re happy with it? And these designers that are constantly tweaking and twisting and making it even more perfect? And it’s like, for them the bar was when they ran out of money and ran out of time? That was it. That was the, that’s when you kind of hit that that quality level, right? Because you had to ship it. And I remember where one film, it was literally, it was releasing in two weeks, and they were still, you know, twiddling with it. But so, obviously, like, world, you know, everybody’s kind of looking at the kind of key kind of ways of improving my DevOps process quality being kind of core to that. And it Okay, so there’s one thing of kind of understanding from your organisation, what quality looks like for them, so you know what to focus on? But how do you then kind of understand what the maturity is, and what the kind of the process is to maintaining that and, and setting that, especially if you’ve come from like, a very manual testing, kind of organisation?

Samuel Arroyo 7:31
Yeah, that does a good a whole area in itself, there are different works that try to help people understand the level of maturity? I think it depends on in, how many parts? Are you looking at quality? How are you measuring it? Sometimes it’s not when measured, sometimes is not tested, so you know what quality looks like. But then once you ship a particular feature, and you tick the box, then that say that you never looked back to see if that’s still the case that there are many changes. You may have to do with automation as well. So without automation, it is very difficult to scale. And I’ve seen, I used to work in a consultancy, and quality was always a difficult topic because they pay you by the hour. And that means Well, the thing is, well, you will spend time making sure that everything looks perfect. That is time and money. So you need to sacrifice something, and sometimes you optimise for speed or for the budget that you have, and you have to sacrifice quality. And then the cases come later when they open a case this is not working as expected. And then you look back to the user story. And he was nowhere there. It wasn’t on the acceptance criteria. And then he’s like, Well, we never said that. This was what quality good quality man so even as a product manager, I find that sometimes that I may not spend too much time on a user story or the acceptance criteria. And then when the team comes back with most of it already done, I realise is not as good as I thought. But it’s not the team’s problem. It’s just I didn’t specify in detail what could look like what

Francis Pindar 9:37
is actually a picture isn’t it is that of that house and you’re kind of building a house and different people’s view the house looks different, you know, product, five storey massive mansion kind of thing. Where’s the developers just looking at as a cottage?

Samuel Arroyo 9:53
Yeah. Yeah. And that happens as well like probably In your case, like if you’re managing people, or you’re training junior developers or junior Salesforce admins, and they do something, and you look at the quality of what they’ve done, it’s not good enough for me. But I cannot just tell you all the time to come to my standards of quality, because that will mean that you are senior, and not Junior, like, you don’t have that much to learn. And also, I don’t want to micromanage you. So you have to sacrifice quality because the other person has to learn.

Francis Pindar 10:35
Yeah, interesting. So yeah, so it’s kind of a levels of quality based on the levels of experience developing in Salesforce, or implementing in Salesforce. So how do you manage that in React? So okay, so obviously, you said like, one of the things for scaling, tech quality and testing is going the kind of automated testing route. So what are the kind of the argument that we see got, because the scalable argument for automated testing, but what are the others because always find that, it’s almost like not dancing with the devil, but you can go down a road where everything is so automated testing. And there’s so much kind of engineering there in the automated testing, that when it comes to making small dev changes, which are small on the development side of Salesforce, the impact on the automation, automated testing is huge. And you kind of you almost ended up doing more work supporting the automated testing than you are actually doing the change. So I suppose it’s what’s the balance? How would you kind of achieve that you’re not kind of gone? So far, the automated testing? And what are the arguments for automated testing in that in those regards?

Samuel Arroyo 11:53
Yeah, I think that, that that may be some sort of implicit assumption, especially from I think, the software industry, where, because it’s so easy to build things, we are not used to having these processes in place where quality is very important. Like you look at the manufacturing of cars, yeah, then quality is much more important than it is for us, even though, because obviously, in that case, you’re risking lives. But some of the software, the more implications it has for human beings, or the economic system, whatever the more quality goes into it and cannot be escaped,

Francis Pindar  12:38
which I always find funny, because in the IT world, because it’s like, yes, you’ve got this risk of a life when manufacturing a car, but with it being so unregulated, essentially. But with AI, and many things kind of coming in that actually, the things you’re doing could impact the lives of people. And actually, yeah, having more focus on quality and testing is something that maybe is a safer way of working, then suddenly being liable for something that you had no idea that your development change, there’s my hate in the real world.

Samuel Arroyo 13:17
Yeah. And obviously, I think that there’s that famous debate where real real engineers say subway engineers are not engineers, that you don’t put into your software, the same amount of effort that somebody building a bridge, or our building is going through the risks, you need to calculate everything, you have to go through several levels of quality, everything’s tested. Whereas we software, we just do it and hope for the best. And

Francis Pindar 13:48
we use common of the

Samuel Arroyo 13:55
that I think that that is to say that maybe it’s because we undertake quality, as serious as other engineering specialties. So I think historically, we’re just not thinking about it. We think about speed, train the edge technologies, something that is new, we like to tinker with things. And when it comes to quality, even in the Salesforce world, I wonder how many people even do like test driven development, which I think is an effort on the part of engineers to start with testing and having already done from the beginning, instead of writing the unit test at the end, where it’s really a white box, like you implemented it, your destiny, you know, all the workarounds and all the backdoors and everything and you know how to make it pass like what’s what’s even the point? Some people say, Well, don’t do your own unit tests, have somebody else do them, which means there’s also some knowledge transfer and you cannot see it As you might bring up a box of doughnuts, and then the other person who does, like we tried to do, we tried to get around, improve quality. And I think the automation just makes you stay on top of your game. Because if you know you’re constantly being monitored, and whatever you produce is going to be tested. Like it’s not, it’s not, it’s not going to go into production ignored. If if the automated testing is realised in, for example, because of your changes, the code coverage is going down. What do you do? Or because of your changes, these are the code, these are the flowers, this this thing is breaking. It’s only you’re accountable. So the thing is, if you do that manually, again, you are at the risk of just missing testing a specific user journey, or? Yeah, I think automation allows you to scale, which I think is the main issue.

Francis Pindar 16:08
Do you are you seeing in the industry more because I’m seeing it from my side where, you know, augers are just getting more complex, more troublesome? And actually, people are thinking a lot more around actually, how do we maintain the quality but still kind of keep this feed through the orc and just kind of interesting, you see it like your side, actually more people wanting to kind of embed testing and quality frameworks within their kind of DevOps processes or within the way they’re working? Is that changing?

Samuel Arroyo 16:40
You know? Yeah, I think that there’s still picking up I think that’s why, for example, the likes of Kobato bought some testing software. And we see more Salesforce ISVs focused on on testing. But last month is DevOps is not as big as that, but I think it’s definitely something that people that have been burned with implementations are realising well, what’s the point on just wasting millions on implementing Salesforce? And not getting something in the end that we thought we were gonna get? He’s like, Oh, well, maybe the problem is not Salesforce. Maybe you then the fire what good looks like and how do you test the quality and

Francis Pindar 17:29
where the source of truth is, have been built? Yeah. Yeah.

Samuel Arroyo 17:33
And even the, the main didn’t maintainability of all of that. I think many businesses just use consultancies to implement Salesforce or changes to their Salesforce org. But when they’re gone, where’s that documentation? Where are the tests? How do I know if I can make a change? Will it break what the other company built for me? Am I going to lose all that investment? Because I like how do you now. So unless you have tests that allow you to feel safe to make improvements to your Salesforce org, you’re just in the unknown, you don’t feel confident to make any change?

Francis Pindar 18:16
is one of those problems isn’t the way the ecosystem has grown? Yeah, it’s it’s kind of very consultant driven implementations. And I think again, this is I think this is where again, where people have got to where the maturity the old you had, like, all kinds of different consultancies and people working in the same thing, and you’ve kind of got away with it. Yeah, it’s kind of Oh, issue small issues. Okay, resolve them, they are happening. But now it’s the well, actually, it’s a bit of a quagmire, you know, we change this things are hidden limits over here. And we didn’t realise, and you’re kind of, I’m not, it’s almost not quite the end of that kind of code thrashing. scenario, where literally, it’s just quicker to start, again, is to actually try and fix everything. So how, what would your approach be, then if you are in a scenario where you aren’t doing manual testing, or you your quality, you know, is suffering, you’re getting a lot of failed deployments or failed implementations going into production that just bugs appearing a lot more. And you know, your testing is kind of manual at the moment. What, what are your first steps you said, like you’re defining what quality is, and what good looks like, but then what’s the next step after that?

Samuel Arroyo 19:40
So Well, if you’ve had problems already, with your implementation, you can probably track back what the issue was. I’ve seen this many people working around the established process where it’s like, well, you want to make a change in production. You have to go through the different sandboxes somebody has to prove it. We need to run tests and then you we can deploy that, do you then just do changes in production? Yeah. So somebody may have done that without you knowing to make a validation rule. And then suddenly you want to deploy and you cannot do it anymore. So if you can prevent people from working around your process, that’s one thing. Then I think one of the barriers is something that you mentioned, which is not getting, it’s not bored, it’s just getting angry about how much time is consuming to just keep the quality up. And and the more changes that you do, the more you have to keep track of. So okay, how are you going to define what your business should be doing, like what the system should be doing? You’re going to rely on your you already know what user stories is. So I’m actually updating those once you finish with to reflect what the actual is in the system, because from the original idea until implementation, things may have changed. Some people might say, Well, why don’t you use the test cases? To tell you what the business is doing? It makes sense. Because, okay, let’s not think about test cases as something I need to do to do to, to make sure things I work in is like, these are the source of truth, the same way that you may argue, well, I don’t know what the code should be doing. But I, if I look at my unit tests, they should be telling me this is what they should be doing. If you don’t update your tests, suddenly you the now, but what the business should be doing what the system should be doing. So if you’re starting with manual testing, because it’s better than nothing, to be honest. And then it gets to the point where things break because Julian test them. And you may be the only person who cares about it, or the only person in the team that can do quality. And that’s something I’ve seen more recently, with all these layoffs, unfortunately, the people working in quality are laid off, because it’s one of those things that they sacrifice, like, Well, yeah, we need them. So we just lay them off, or

Francis Pindar 22:27
whoever wants to go, Yeah, you’re squeezed on time, what goes quality testing? It’s

Samuel Arroyo 22:34
and and then you see the result? companies try to release software after laying off. And then for some reason, there’s more quality issues than before. You never know.

Francis Pindar 22:48
You’re not implying something here that happened recently.

Samuel Arroyo 22:54
But I wonder, obviously, I’m thinking about it almost every day. And yeah, I wonder, well, who got laid off? And how do you fill the gap? If if the person was doing manual testing, and you lay that person off? That’s it, no one is doing quality. If at least you have some automated testing, while you can keep running those tests up to the point where you will need to update them eventually with with all the changes coming. So the thing with Salesforce developers are they have to do unit testing is inevitable for them. They can cheat the system because the only thing that is known as

Francis Pindar 23:33
just code. Yeah, get your code coverage. And away we go. Yeah.

Samuel Arroyo 23:37
Yeah. And it goes garbage is? Doesn’t really Yeah. Yeah, ideally, would be. And if it goes down, it’s telling you something is happening. But then you realise, well, that’s a problem for developers to figure out to make sure that they’re following their own best practices. But the thing is, I think in the Salesforce ecosystem, there is less and less push to code and more teachers built with flows and declarative tools. And I think the issue is, how do you test that because as a developer, you have unit tests, and the admins don’t have those tools. And it’s only been recently that Salesforce added a bit of testing or declarative testing on flogs. And from what I’ve heard, I haven’t used it myself. And what I’ve heard is, it’s not great. And

Francis Pindar 24:35
shall we say, yeah, yeah.

Samuel Arroyo 24:37
But it opens the conversation is like, Well, what about all these declarative processes that we’re building? How do we test them? While it’s flowers, you can still use unit tests, but then you need to rely on a developer.

Francis Pindar 24:52
And I think it’s also it’s like the the actual if you’re kind of thinking of the end to end testing, you could be including other systems. in that as well, so actually, it’s wider than Salesforce. Because you’re wanting to test that entire process through to an invoicing system or whatever it may be. And yeah, it’s more than just one piece of the puzzle, I suppose. And how would you kind of get that coverage across?

Samuel Arroyo 25:21
Yeah. And that’s where tools that allow you to automate through the UI. So from the perspective of a user that is interacting with the application, those are the ones that can help you to test your screen flows, your different user journeys. And obviously, there’s a number of tools in the market that allows you to test it there, you have tools that are more generic, even open source, anything like Selenium. They’re open source, but the definitely free. And those are generically you can test every website. The whole idea is, you locate something on the page. And then you just say how you want to interact, you want to click it the owner, put a text on the input, read the text, what do you want to do? And then you have different technologies as well, like, you have like the robot framework, which is a different way of writing your test scripts. And then you go, Okay, do I need to know development? Like, do I need to be a developer to try to automate my test cases? In some cases? Yes, like, if you’re using selenium, or you’re using the robot framework, is you may not look like COVID code. But still, you need to write

Francis Pindar  26:42
that code like way, yeah.

Samuel Arroyo 26:45
And you’re writing a file, it doesn’t feel intuitive, like just drag and drop, click lick lick. You have different tools in the market. And they have different approaches. As well, you have certain things with Salesforce because you may write your test script or read your test case with one of these tools. And then things may change. Even Salesforce may release a change that for some reason, it breaks your test case. And we’ve seen that as they were moving from aura into lightning web components, they were changing the UI back in they were in the way they were rendering things. And depending on your locators, then they could break or still work. And then okay, who do I need? What do I do every time Salesforce releases? Three times a year? Like, do I need to go through all my test cases and fix them? Or does it do allow me to work around that? Do they take care of that or not? So the effort that takes to maintain your test case is definitely something to consider.

Francis Pindar  27:55
So what else do you look for when you’re kind of looking for a functional testing tool?

Samuel Arroyo 28:02
So I think is how easy it is to build a test case. So what’s the learning curve? Is it easy to is it for developers, Kenyan citizen tester, like somebody with no experience whatsoever of writing any code? Start doing it? Or is it for people like admins who want to just automate their manual testing and get rid of all those hours spent to manual testing and do something else? So how easy is it to create a test case? And then how easy is it to maintain? I think those are the two main points. Forget about exporting your task is like, I think once you’re locked in with one tool, the pain of moving to another one is like, I might as well not do it. Yeah, I think that’s why it’s important to choose the right one at the beginning. Sometimes you don’t realise those two things, how easy it is to build and maintain until you’ve started using it. And sometimes there’s just not enough time during the trial period to figure out, is it something I can pick up? Is the name of months? Gonna take me? How do I test fictitious changes that may break? And so what I see with companies, they they tried to do a bit of due diligence. They compare different tools to see at a financial level. Yeah, and yeah, try to test them break them away. But yeah, also thinking of their arm people, like, well, if we need to rely on developers, then good luck trying to go like hiring them, and keeping them and then otherwise, we may have many more non technical people who could who could pick these up and make automated tests much more easily.

Francis Pindar 29:59
All right, cool. That’s fine. I think we get anything else you want to talk about quality? What are your best resources for finding out? How if if you want to learn more about unit testing automated testing quality?

Samuel Arroyo 30:18
Well, obviously there’s a lot out there. I did a course on Coursera. About software testing, I wouldn’t recommend it because it’s just too lengthy for people. But there’s many groups of people the same way we have our like Salesforce Developer Groups and user groups. They’re much more about testing because it’s everywhere. So you go to like Ministry of testing. There are testing conferences all the time going on. There’s test automation University. We have University of PROVAR. So there is a lot of courses information out there. Okay. Salesforce, I think that they have a few Trailhead modules for it. I know that the folks are probably if done two modules. Okay. Maybe going for a third? Yeah.

Francis Pindar 31:21
Okay. I’ll put those in the show notes if I can think about. Cool. Okay, so it’s probably a question I asked everybody at the end, or if I remember, at the end of the podcast, if you could wind back the clock to a point in time in the past and give yourself some advice would it be and when would that time be?

Samuel Arroyo 31:46
The I would probably go the five years ago. So yeah, since the beginning, I always wanted to work on products will product. done that since I started my career in, in Salesforce. But for some reason I was wanted to do that within the company I was at. And he actually never happened. Like, I didn’t get the support or things like that. So few years ago, I just thought, well, I could have just as bill as well build these apps myself. So I set up my own company. I created some epic things apps. And I use my free time to do that. And actually, that’s that’s how I sort of got the job. As a product manager, I switched from more technical tech, CTO to senior product manager, yeah, moved to product management, things to focus in on my free time to do products and just shifting. So I think it’s don’t expect other people or your company to fulfil your dreams. And just try and use even that. Yeah, whatever time you have free time after work hours to pursue those things. And you may be able to switch careers or to get something out of it.

Francis Pindar 33:16
Yeah, definitely. Great advice. Yeah. And to be. Yeah, it’s been the same and similar kind of journey, I suppose. And, and also, just that kind of realising that actually, I could ask my boss and the company to actually work four days a week rather than five. And they were actually up for it. And for me, that was quite a way of actually going well, I want to try something new. But I don’t want to risk everything. I’m just going to reduce my days down. And actually, I can start working on something else on the side. But yeah, fab. So these apps still on AppExchange?

Samuel Arroyo 33:50
Yeah, a couple of them. Going for us. They’re still going through security review, however. But yeah, sort of like a hobby of mine to just build interesting things in there.

Francis Pindar 34:04
So you know, are you the product owner of prover, or one of the products within prover?

Samuel Arroyo 34:11
So when I joined Pro was the company name, and the only product they had was PROVAR. Yeah, that was that was it. But then, a few months after I started working on a new AppExchange product so that the main product that does the test automation, is not on the epic scenes is a desktop app, where you build like a studio like an IDE. And you can run it on your laptop. You can write on the cloud wherever you want. I started working on an epic since product that Richard Clarke had worked previously. So yeah, yeah. And it was about test management. And my background is not quite yet. Oh, like I know what quality but I’m a tester. So I had to dive into what do testers Do what is the quality lifecycle? How does this even work? And, yeah, I’ve, I’ve been the product manager for what used to be test manager, and then they renamed it that to product manager. We launched it back in August last year. Okay. 2022. And it’s grown massively in terms of the scope of what he does. Because well, first is our first application on the App Exchange. But there there isn’t that much about quality on the App Exchange. And there’s even a handful of applications that focus on that. So we wanted to cover all the bases, we allow people to manage their testing lifecycle. So during the test products with test plans, many people don’t do planning at all, like they don’t think and write things down. Before they implement, they just go to straight to implementation. So we tried to train people and raise awareness like, first you plan your design, then you implement

Francis Pindar 36:04
agile, we just push it live.

Samuel Arroyo 36:12
The cool thing is that we wanted to make it sort of a hub to connect to all the different tools that do quality or have to do with quality. So I started, the thing is, obviously, with my developer background, is like, well, I’m going to build this thing, I’m not just going to manage it, I’m going to build the whole thing. And in a way, because it was so like a side project within the company, the main product was the automation baits. They left me like free rein, like do you want. So that’s what I did. I started growing and plugins, so like think extension packages to the main core baggage, and integrate. So you cannot do quality on its own. Like, you cannot just have test cases on its own, that you relate them to user stories, where two people have user stories, DERA Okay, I need to connect the JIRA, I need to bring those into the tool. And then as your DevOps people, at least our customers use that. So those two plugins, then quality is also part of DevOps. So the easiest thing is to integrate it with the native there was players. And the cool thing is good timing, because Salesforce even was getting into the game. So yeah, we have a plugin for Caballo plugin for for awesome, and a plugin for self was ever present. And we were working with, with Salesforce from the beginning, since they were on a pilot to see okay, what are you guys doing? And how can we plug into there, it’s not easy because of using how it is they have a separate interface, but we just worked around it. Like when I created our own app. It’s a nine and experience and just work that way. But that’s how we connect it to DevOps. And it brings something interesting to the table. Because sometimes when you are deploying a number of metadata changes, you’ll know what to test. Like, well, if you know, the test classes that I’ve been deployed, why do I need to tell you what you need test to run? Well, you know, you should know because the first time you don’t know but you should know. So, bro money are automatically tells you, okay, these are the test classes you should be running, or these are the test cases you should be writing because we know the coverage of the metadata, we know what metadata you’re changing, so we bring it out to the table. And then finally, something that personally I feel like is ignored sometimes or if it hasn’t picked up a smart is called quality. And there’s maybe a handful of players that that do that. So we integrated with Clayton we integrated with quality clouds with you, we want to be the central hub where people go to understand the quality of their Salesforce orgs. And of their efforts. technical depth Go code quality is part of the picture. So we should be bringing some of that data from those platforms into the hub. So we have a core package that allows you to do a lot but then we have a lot of integrations that allow you to plug in all that information and to integrate your testing ways your DevOps, bring in information from different places. And then even recently with you know, all the fuss about AI and and I was I was I mean I thought of just quitting LinkedIn for a while and Twitter because it’s just these are the 10 different ways that you should do your prompts. And this is like it’s just annoying up to a point and but then I started thinking well, what’s the point? I know for these AI views and actually putting in inaction. So I started thinking, well, I want AI to take away the most boring things. Especially if I think about citizen testers or admins wanting testing. What are the barriers to start doing it? Sometimes is, well, I’m looking at a user story. Give me suggestions on how to test this. So I quickly integrated with open AI. And he’s no good. He’s just story. Can you give me five test cases?

Francis Pindar 40:36
Is it good? Is it coming up with results?

Samuel Arroyo 40:39
Well, it is. It is good. Sometimes you like you get the results. But sometimes, the answers are more clever than others. Right? Like, let’s try again. It okay, I prefer this ones because obviously, there’s not it’s not perfect. But yeah, it generates five test cases. And then somebody who may not be very used to testing say, well, at least is some inspiration.

Francis Pindar 41:06
Yeah. Lisa, where to start or understand some approach. It’s just I think it’s a challenge of like, it’s still cloud sourced content. Right. So it’s still Yeah, the maturity of what it’s found. Turn out it serves it up. But yeah, it’s interesting, though, is the other shit as I’m assuming. I’m just thinking maybe that actually the test cases that kind of, were actually more accurate or not more accurate, but give you more ideas for juniors than some some other kinds of types of I want this code written like this. And it just comes out with it workable, but just doesn’t scale. type code. But yeah, okay, interesting.

Samuel Arroyo 41:48
So yeah, that’s why I do, I’m only working on that, seeing how we can expand. And I think the main vision is to raise awareness about quality, to have a tool that anyone in the Salesforce ecosystem can say, if I get that tool, it will help me to get more serious about quality, provide a sort of framework that I can follow, it will allow me to connect to the tools I already have in my tech stack. And to make sure that I’m embedding quality into the other things I do however there

Francis Pindar 42:21
Yeah. And in like Provo has always been like that kind of gold standard of testing within the Salesforce ecosystem anyway, but yeah, I love it’s yeah, it’s a good approach. Good, good app, I think, to really kind of glue everything together. And yeah, kind of go a kind of quality first approach to everything. Cool. Well, thank you so much for being on the toss, the pot itself sort of quasi podcast talking about quality and testing. Hope you enjoyed it. It was good, fun. Cool. I look forward to seeing you soon. Thank you. Thanks for watching, or listening to the Salesforce posse podcast. Now please, please, please, if you like, or what you see or hear then please rate this podcast in your podcast player, as it tells me that there are people out there that actually are listening to this and that it’s useful to them. Also, it helps the podcast algorithms to kind of elevate the podcast in the different podcast directories which will be really helpful for me, as well. And finally, if you do have a question that you want to ask on the podcast, then head to Salesforce posse.com/message. And maybe you will appear in the next podcast, but apart from that, thanks for listening, and until next time,