Salesforce Development Testing- Friend or Foe
As a developer, the most terrifying part of the process is telling the end user that their request is ready to be tested. Even though, you have run through the scenarios and tested your code, there is still the chance you missed something. Not every user does it the same way. We all know those users that can find unique ways around the process. And then it happens, the dreaded email from the user who just tested your changes, but it gets worst. All the email says is that they tested your changes and it did not work. So many questions fill your head, but you are not sure how to answer them because the user left out some details like how they came to the conclusion that the changes did not work. Taken a step back, one part of the process that is overlooked many times is coming up with test cases. Test cases can help the user know what your thoughts were when you coded the process. Giving your users a template to follow can be very effective. A good test case template should cover such areas as:
Pre-condition: Any prerequisite that must be fulfilled before execution of this test case. List all pre-conditions in order to successfully execute this test case.
Dependencies: Mention any dependencies on other test cases or test requirement.
Test Steps: List all test execution steps in detail. Write test steps in the order in which these should be executed. Make sure to provide as much details as you can.
Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input.
Expected Result: What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on screen.
Actual result: Actual test result should be filled after test execution. Describe system behavior after test execution.
But many times, these test cases do not cover every scenario. Sometimes the test case scenarios can be your enemy. If you tell the user to do it one way, that is how they are going to test the process. This will leave out the unexpected scenarios. Trying to fix the unknown can lead to many hours of banging your head against the wall. One way to avoid the black hole of fixing problems is letting your users know that they need provide the following information:
Who: Who were you logged in as? Was it a sales rep?
How: How did you get the error?
What: What were the changes you made to the record before you got the error?
When: When did the error occur? Was it after you changed a picklist value and clicked saved?
Where: What Account, Contact, Opportunity, etc. were you on?
Answering these questions can save a developer hours of trying to figure out how the error occurred. Remember the developer is coding to the requirements given to them by business unit which may not be the user who is testing or using the final product. Even seasoned developers have trouble figuring out the common error. The developers at CRM Manager have years of experience and follow a process that is very effective to providing their clients with the end results that are expected. Let CRM Manager customize your Salesforce org the way you want to do your business.