Test Drive is a Salesforce-native app that I built to solve many of the struggles that come from organizing and performing large-scale User Acceptance Testing exercises on the platform. It was designed with the tester’s user experience in mind, geared towards encouraging them to actually complete their tests, while also providing a single-pane experience to do so. It was also designed to leverage as much standard functionality as possible to avoid unnecessary technical debt. It’s also important that the UAT feedback from the testers only reaches the dev team radar when necessary. Lots of the UAT feedback becomes unnecessarily prioritized by the dev team which causes confusion and delays. This app addresses all of that, along with comprehensive analytics and real-time automations for rapid bug resolution.

 User Acceptance Testing is when the rubber meets the road. It’s when the client stakeholders either confirm their biggest fears, or validate that they picked the right partner. Test Drive empowers the project and testing teams with the tools to execute bug-free Salesforce UAT sessions globally.

If you wait until UAT to start laying this foundation, though, it’s too late. Use these indicators to identify whether UAT is going well or not…

Test Driven Development

Test Driven Development (TDD) follows the framework of capturing and approving test scripts before development even begins. I am a strong proponent of this approach, as it boosts the usefulness of the user story and creates a common thread from design through roll-out. This approach has several benefits, including leveraging TestDrive when it comes time to assign testers.

 Install Test Drive in the same environment where testers will be testing and assign test script packages to test users. There are a few steps for the Testing Lead in between, but after just a few hours of setup, installation and import, Test Drive is ready to supercharge your UAT.

So What is it, Already?

TestDrive is a custom data model that leverages Salesforce tasks to assign test scripts to users. The solution is applauded because it centralizes what many testing leads are already doing across several systems, folders, and even spreadsheets. This pain flows downstream to the testers, as well, often having to juggle between multiple systems to complete and notify the testing team. God forbid there’s a bug! TestDrive centralizes all of this in one spot so that UAT can be managed solely from the environment where testing happens.

Some will then say: How will the bug information get back to the dev team to make updates and get ready to retest?

Good question. Here’s my answer: If the testers are chosen strategically, there should be some that are not familiar with the system yet and are seeing the solution for the first time. Because of that, we can anticipate that some of the feedback will include things that don’t actually indicate any development issues. With this system, all UAT feedback is collected and the testing lead reviews the feedback before determining if it’s a real bug or just a clarification or human error. This keeps the dev radar clear to focus on actual development fixes that jeopardize go-live.

Today, your testing leads are probably sharing all feedback with the devs and letting them decide, which actually contributes more to the problem. With test driven development, though, those test scripts would have been approved months before UAT, allowing that testing lead to grow very familiar with what will constitute a bug and what won’t, further empowering them to quickly identify bugs and correct human error when they see it.

Tester’s User Experience

Test Team Win Themes