And Now We Test!

Whether or not you consider testing to be exciting (“HEY EVERYONE! COME SEE WHAT I BROKE!!!!!”) or dulling to the senses, it is utterly necessary. And when we are talking specifically about User Acceptance Testing (UAT) done by our clients, it always improves the overall quality of the system being built. And isn’t improving your systems why you are doing this project in the first place?

What is UAT?

Well, User Acceptance Testing is pretty much what it sounds like.

There’s a piece of functionality that is supposed to work a certain way. We at Bigger Boat will run our tests to make sure it is working, but then we pass it to you to test IN THE REAL WORLD. You, as the Real User using Real Data, will be able to find issues or simply overlooked functionality that us non-end-user-types couldn’t possibly track down. The point of UAT is to find out if it works for your organization.

Wow. That sounds great. How do I do it?

We’ll help you get started during implementation but it will follow the same pattern outlined below.
1) We, as a project team, will take a feature or a piece of functionality and write down exactly how it’s supposed to work.
“When I create a relationship between two contacts of any contact record type, I will see the Relationship on each contact record.”

2) Next, we will work with you to write UAT test cases.
“Test: Create a relationship between a Client and a Service Provider.
Expected Test Outcome: When viewing the Relationships list from either the Client or the Service Provider Contact record, you should see an accurate Relationship record that shows each person’s name and their relationship to each other.”

3) You will go through every test case and let us know how it worked! We are looking for how it works with your process and in your organization. So all information that you find during testing is incredibly important.
“Passed. But it occurred to us that turnover with Service Providers is really high so updating this information might be cumbersome for Julie and Matt. Can we talk about this in tomorrow’s meeting?”

Below is an example of how we track this with our clients.

Some UAT tips

  • It’s about your process, not just the data! The importance of UAT is that the User is figuring out if there is real value or a real problem with what we’ve just built. So it could be a bug that you find (“The wrong value is showing up”) or it may be a difficult process that you uncover (“It works as expected but our staff only have 15 minutes to do this daily and this is taking too long. Can we simplify this?”). Both are incredibly important.
  • Use real data whenever possible. If you’re testing fund development functionality, pull out some of your most heavily involved donors and use their data for testing. Using real data compels you to think through real situations.
  • Put your test cases in a spreadsheet, project task-list, Trello board, or issue tracking software. You will want to be able to pull them out and use them again because you are going to be testing repeatedly.
  • Block off time to do it. Once you have your test cases created, it’s simply putting your headphones on and doing the work.
  • Enlist help if necessary.
  • Do not skimp on testing. The path to successful Salesforce implementations is littered with organizations who did not fully test their system. Think Oregon Trail.

There are many types of testing and this is just one summarized approach for clients testing out functionality in a custom-built Salesforce system.

I cannot emphasize enough the importance of testing early and often during implementation. It’s critical to closing out a sprint or cycle (more about our agile approach here). Whether you are testing something you’ve implemented or testing something a consultant has implemented, the overall process is the same. UAT is the time to figure out if it does indeed work “in the wild”!


Know what you are testing.
Write out your test cases.
Put on your headphones and do it!

Interested in upping your mad testing skills? Here are a few resources.

What is a test case
Test case fundamentals