I have spent my entire career helping enterprise companies solve complex challenges to scale and root cause analysis. The number one takeaway I have learned? Everyone carries their fair share of weight regarding software delivery from the top to the crop.
This resource will cover how your support teams are essential to delivering world-class software. In addition, we walk through a real-case scenario to provide scalable strategies for your delivery and support teams and, finally, how Provar can help you become defect-free.
We all know that your first line of defense is your help desk support team. The technology firefighters are triaging problems for people who demand solutions right now.
We have a surprise for those leveraging Provar to scale test automation for your Salesforce projects. The next time you do root cause analysis on a reported potential production defect, consider rerunning the feature test script in production without leaving a footprint to get the whole impact story.
You can isolate your purview to see the exact impact on users, roles, and profiles through Provar’s polymorphic design by simply testing them with a single click. Equipped with built-in screenshot capabilities, you can identify the problem faster and more efficiently, saving you, your users, and your team valuable, irreplaceable time. Are you looking for a defect? Just replay the script!
Now that we have covered the importance of help desk teams as an essential part of your software delivery and how Provar can help, let’s walk through a real-case scenario with some insights to bring back to your delivery teams.
Meet Dewey: a Real-Case Scenario for Help Desk Teams
How many times have you leaders at the help desk received a similar late-night Slack message?
Let’s meet Dewey Done Right, a new help desk team member; the above image is his first ticket. “Okay, Dewey, don’t panic. A department manager with significant influence in the organization raised the ticket. You know you must be fast and effective here.”
Dewey recalls rule number one from their training – it’s not a defect until you can replicate the reported problem and screenshot it. But Dewey can’t. The manager didn’t tell them who could and could not access the account. They didn’t tell Dewey that this issue could impact the entire North American (NA) Sales group, which should have 500 users.
Given Dewey’s role as a help desk team member, it is unreasonable to expect him to individually review all 500 user assignments to the profile group and log in as 500 different individuals to verify. But being the problem solver that Dewey is, they know there must be an easier way.
The delivery team uses that new Provar testing automation tool to test dozens of profiles at once with just one script. Dewey decides to go into the testing project, locate the script they used for profile assignment and permissions for the new Account record type, and run the test again.
Dewey tells himself, “That way, I can find out without creating any net-new records in the production environment. Perfect!” So, Dewey sets off to accomplish his goal but soon learns he cannot access the Provar testing tool. Dewey contacts his new work friend and teammate, Marty, on the warranty team to explain the problem. Dewey shares his approach to identifying the potential issue with root cause analysis.
Marty admires Dewey’s thoughtful approach. Conducts the test, confirming the addition of 12 individuals in NA Sales after the production deployment. These individuals were not assigned to the NA Sales group, so they cannot access the new Account record type. Marty attaches the screenshots of the reported defect. Dewey thanks Marty and rushes off to his daily team standup.
Dewey Faces His First Standup: Based on a True Story
Scrum Master: “Thanks for joining us, Dewey. What have you done? What are you doing? What are your roadblocks?”
Dewey: “I received a critical severity defect impacting the NA Sales group this morning. Tyler, the VP, has reported that many of their sales users could not access and edit the new account record type “Commercial.”
“They have 500 users in their group. Since I only had 24 hours to resolve the issue, I felt like there was an easier approach to reviewing all 500 users and their profile assignments. Logging in as each one to confirm access wasn’t the best use of time, so I thought outside the box while staying in it.”
“I don’t have access to the tool I wanted to use, so I reached out to Marty on the delivery team and explained the situation and my suggested idea of rerunning the test scripts in production to check the user profile assignment of the NA Sales User Group. After the production deployment, the tool identified 12 users who had been added but were never assigned. So it was a miss.”
“But before standup, I updated the 12 users to the correct profile assignment, and they now have expected read/write access to the new Account record type. I have updated the ticket and notified the reporter that the problem has been identified and resolved. I have also briefed our DevOps team on the situation. The team is updating the miss in their repositories so that all lower environments will be in sync.”
Scrum Master: “Great work, Dewey Done right! Let’s talk more offline about this testing tool you mentioned. Sounds like something that we could use to help save us time in the future.”
As a leader, thanks to the polymorphic capabilities of Provar. Our E2E solutions support all delivery team members, saving their most valuable asset – time. Although humans create software defects, it also takes a human to use an intuitive tool to improve your delivery. Thanks, help desk team, for keeping things running smoothly.
At Provar, we believe testing Salesforce should be as easy as using it. Discover how our solutions can boost your Salesforce testing and analysis. Click here.
