Learn About User Acceptance Testing

Cameron: Hello everyone. My name is Cameron Johnson. I'm a lead Content Writer for Trailhead and I am joined today, business analyst expert Dernie. Dernie tell us about yourself and what you do for Salesforce.

Dernie: Yes, hey Cameron. So I'm Dernie Hashemzadeh. I lead an amazing team of professionals here at Salesforce who are skilled in business analysis. And in a nutshell what we do, anybody on the BA team what we do, is we are the liaison between the business and technology teams, in that case it's IT. And our main role as a BA is to bring clarity and bring people and technology together to guide our sales org to implement technology solutions.

Cameron: That's awesome. So you are business analysts for our actual Salesforce? Our own internal BAs, awesome.

Dernie: That is right, yeah.

Cameron: Excellent, so the reason why I am chatting with Dernie today is we are gonna go over the main topic of UAT or User Acceptance Testing. I will probably stick with the acronym because it is a mouthful otherwise, but a couple of objectives of our chat today is what is UAT? How is a BA or business analyst involved with UAT? Why is UAT important in a project success? And then I'm also gonna put Dernie on the spot and ask for some good tips and tricks and best practices. So if everything's okay with you Dernie let's get to the very first question. What is UAT?

Dernie: Yes, it's a long acronym. So it stands for User Acceptance Testing. And quite frankly, it is the last stage before go live. So typically it's in a sandbox after the project or the enhancement has been thoroughly tested by the technology team. So usually there's quality assurance, quality engineering that, and once they pass that stage it goes on to UAT. And really what it is it's a testing conducted for projects by the end users for approval prior to production release. And testing can, involve a variety of stakeholders. It can be business stakeholders, end users. It can involve BAs it can, it can also involve IT teams. And usually testing will involve test cases. And usually the result or outcome will be either a pass or fail. And again, really the overall goal of UAT is to make sure that whatever was originally requested is actually being delivered. And it's also to certify that, the system and tool is now sufficient for business usage.

Cameron: Excellent, so when you say pass or fail that literally means the project goes live or it doesn't go live. It's go, no go.

Dernie: Yes, exactly. So think of it as like the last chance, due diligence all your last chance before it goes live.

Cameron: Excellent so, what's exactly involved. So it sounds like a lot of testing but what's exactly involved of UAT. What gets you to that UAT point?

Dernie: I would say preparation. A lot, a lot of prep. So a lot of, especially from a BA role a lot of what UAT is about is planning for the actual execution of those test cases. Who is doing that? Confirming timelines. What are you gonna test? A lot of UAT is actually officially getting your hands dirty. Up until that point especially from a business perspective, potentially from a Salesforce BA perspective as well. You haven't put, fingers to keyboard to test it out, fingers to your mouse it out. So UAT is really where the BA and the end users and other potential business stakeholders get to test out the new system. And then finally, like a big, big part of UAT is the formality of getting official UAT sign off. Like you mentioned that green pass, we're ready to go.

Cameron: Gotcha. So you mentioned that business analysts are very involved with UAT but what's, I'll say in most cases what is BA's role in UAT?

Dernie: That's a good question. I think at the most simplistic level the Salesforce BA, like I mentioned before is the liaison between the business and the tech teams. And their goals are driving clarity and quality in these technology projects. A key part of driving that quality is this UAT phase of the project. To make sure that the actual product or enhancement that is being delivered actually meets the quality and expectations of what the business is expecting.

Cameron: Interesting, so in your experience is the BA always in charge of a UAT?

Dernie: I think it can really vary, team by team project by project, as well as company by company. But I can tell you what my team does here at Salesforce. A couple of the key things we do as an example in driving that at UAT phase is, the BA will be in charge of identifying who are the UAT testers. And again, it can be various types of people. The BA will typically lead and coordinate the UAT. BA often writes the UAT test scripts, with defined testers, who's gonna approve. And then the BA as a final step also gets the official written sign off from the business stakeholders that test scripts cover all the expectations. BA will often validate that the data is set up ready to go in the system. And then oftentimes our BAs on my team will also test the key functionalities with different, key personas involved in the project. And then finally last step is, obviously they would coordinate the UAT. Final step they would make sure that there is written official sign off prior to deployment for go live.

Cameron: Gotcha. So it's a lot of prep, but it sounds like they still also, as you mentioned before, get their hands dirty if you will.

Dernie: Yes definitely.

Cameron: Great, and then your perspective obviously is in the Salesforce ecosystem, but UAT isn't a uniquely Salesforce thing, because you in theory could be launching a product or a project that has nothing to do with Salesforce but UAT still applies, correct?

Dernie: Yes, that's right.

Cameron: Just making sure.

Dernie: And it's the same, I mean it's the same idea. The reason why you need to do that regardless if it's Salesforce platform or specific or not as a technology is, it's the last step for the business to say, hey, yes this works and we're ready to go.

Cameron: It's a universal thing. It's not just a Salesforce thing by any means. Excellent. And then why should a BA be involved? I know that's kind of a rehashing the question before but it seems like a lot of prep, but, what would go wrong if a BA wasn't involved?

Dernie: Yeah, I think, to answer your question I'll say the reason why the BA role is imperative for UAT is because BAs understand the functionality and the intention of the system that is being developed. If you step, go back earlier in a project process you'll know that the BA plays a critical role early on during business requirements. So if you then go back, further down the phase of the project lifecycle to UAT the BA comes with the project contacts. And BAs by nature also are very detail oriented and they can also help uncover potential problems.

Cameron: So if you had someone just strictly in charge of UATs, they may not see the whole story, they weren't there for all the meetings before to get you to just the UAT. Yeah, that makes perfect.

Dernie: Yeah, exactly. And the ideal state, the BA is there at the start of the project, they do all the requirements and engagement with the project team.

Cameron: That makes perfect sense. What are some additional best practices? I know that you have a lot of experience with UATs and BAS and I'm sure a bunch of other acronyms for that matter. What are some additional best practices that maybe we do here at Salesforce that you think people, BAs that are maybe doing their first UAT or just learning about UAT what you'd recommend?

Dernie: I'll give you a rundown of some of our top tips. I think number one is prep. I think tons of prep and that leads to a successful UAT. And high level when you think about what things to consider in your basic checklist of UAT prep that includes identifying resources, here at Salesforce, on my team we create a UAT Slack channel where we set, we decide and set a cadence of status updates. We usually will create, the BA create a UAT schedule. So think about for this particular project do we need a kickoff? Do we need to plan for daily meetings or, status updates, triage? We establish a process. Process of, for example reporting bugs or asking questions. What are all these processes? Then we create test case. So we'll actually create the test scenarios that we wanna cover as well as then detail the test steps. And then finally there's usually a validation point of the actual sandbox we'll be doing UAT testing in. So looking at is the test data ready? Identifying said sandbox. And then usually we think about scheduling like a Roundup meeting at the end of the UAT do we do we formally close it out? How do we prep for that as well? It's a lot of preparation.

Cameron: Yeah, I was about to say a lot of that backend work that you may not think about but has to be done for sure.

Dernie: Yes, exactly.

Cameron: Excellent. And then let's finish with the good stuff. Let's share a good story. As much as you feel comfortable sharing. Do you have any experience where UAT was not planned well? Obviously you weren't in charge of it because it would've gone successfully. But, have you been around any, heard any stories where a UAT didn't go successfully and what happened?

Dernie: Yes, definitely. It's definitely understandably stressful when things go wrong. But I think the key point to realize is that is the purpose of UAT. And again, it's to make sure that the system works as expected from the end users, and sometimes gaps are discovered. And I've definitely had situations where UAT was not robust enough. For example, key test cases were missing perhaps not the right testers. Maybe they were, we had identified people who didn't really know that role or really too new to that area. So one example of a project was a big project that I was a part of. The test scripts were not a reflection of real life. And the actual UAT testers were not subject matter experts or end users. And then what ended up happening was the business signed off on UAT. But once the system was live on production major gaps were identified. Now in this situation there are other breakdowns in the project process, especially earlier in the phase in the project as a whole. But I would say if the gaps could have been discovered in UAT and then the code wouldn't have been pushed to production, we would've, saved a lot of money and a lot of time. I think key point is when things do go wrong in UAT if it's planned well, that is a good thing.

Cameron: Gotcha, and I see what you're saying like for a project not to go live you think would be a bad thing but you caught it before it went live. So that's actually a good thing. And it sounds like your story wasn't caught before it went live. That one not as successful. So interesting. So it seems like just to kind of wrap up what we talked about, and going back to those objectives we said we were gonna go over. So we, you definitely hit what is UAT, how is a BA involved? Just to recap kind of what you said was most of the time it's being led by a business analyst because they've been there from step one to the last step. Why is a UAT important in a project success? I think we hit that one really well with that last story. And then you gave us a lot of great best practices. So thank you so much for your time Dernie. We appreciate it. And I think we certainly learned a lot about UAT.

Dernie: Thank you, Cameron. Nice chatting with you again.

Cameron: Bye.

Dernie: Bye.