How to Write Test Cases

Test cases play a vital role in the quality of the system functionalities by verifying that all functionalities are properly incorporated. Let’s explore how to write effective test cases. Join us to learn about how to write test cases in Salesforce.

What is a Test Case?

A test case is a step-by-step process that includes the expected results to verify a specific system functionality. A test scenario is a real-world situation where the system functionality is used. The vast majority of test scenarios that a user might run into when utilizing the system in the actual world are covered by the test cases that are prepared by the developers to improve the system quality.

Test cases are written to ensure that all the functionalities incorporated in the system work seamlessly, to assess the data visibility for different users, to check if permission sets and profiles are assigned aptly to all the system users, and to verify whether the page layout assignments, object and record accessibilities, compact layouts, and other configurations are set correctly. Based on the test cases provided by the developers, the end-users evaluate the system during User Acceptance Testing (UAT).

How to Write Test Cases?

It is advisable to craft the test cases on spreadsheets (Microsoft Excel or Google Sheets) rather than on word processing applications for easy readability. The test case sheet consists of the following:

• Test Case ID
• Test Scenario Description
• User Profile/Role
• Steps
• Expected Result
• Status (Pass/Fail)
• Test Cycle 1: Tester Name
• Test Cycle 1: Tested Date
• Test Cycle 1: Comments and Screenshot Explaining the Issue
• Test Cycle 1: Developer Name and Comments
• Test Cycle 2: Tester Name
• Test Cycle 2: Tested Date
• Test Cycle 2: Comments and Screenshot Explaining the Issue
• Test Cycle 2: Developer Name and Comments

These are not the only things contained in a test case document. Along with these, if any prerequisites are required before evaluating the system or specific functionality, then feel free to include them in the document.

Continuation of the Sample Test Case Table

The test cases can be broken down into phases of the business process flow, with only the relevant scenarios for a specific phase in a sheet. Alternatively, the test cases can be organized based on individual users, with each sheet containing test cases related to a particular user’s actions in the system.

However, the former approach is more suitable for UAT testing because, as the testing will follow the business process, the necessary steps and records will be in place, preventing any potential errors due to missing data. If the latter suggestion is preferred, then there are chances where a user may face errors due to no record in the system, previous steps being incomplete, or any other similar issues as the user is evaluating the system only on his part. On the other hand, if the client and developers prioritize clarity and readability in the test case document, organizing test cases by user can be a viable option.

Sample Test Case

If there are too many steps for a single test scenario, split that into smaller scenarios and write the steps accordingly. For instance,

Original Scenario: “Verify if the user is able to convert a lead to an account.” The above scenario can be split as follows:

• Create a new Lead record with relevant information.
• Qualify the Lead by updating its status and adding more necessary details.
• Convert the Lead to an Account, Contact, and Opportunity.
• Verify that the Account, Contact, and Opportunity records are created with accurate data mappings.
• Confirm that the Lead record is marked as converted and associated with the new records.

The acceptable range for the number of steps per test case is 15 – 20. Having more steps than this may cause users to be overwhelmed and struggle to follow the instructions for evaluating a single functionality. In addition to that, too many steps might reach the maximum limit of the spreadsheet cell for vertical expansion, causing difficulties for users in reading and comprehending the content within the cell.

In test cases, the initial step is always to “Log in to the system” for all users. However, if a single user is evaluating consecutive test cases, it is not necessary to include “Log in to the system” as the first step in every test case. Instead, it should be written only at the beginning of the user’s role (the first test case for that specific user). Additionally, when a new user is introduced and then reintroduced later, the first step should be “Log in to the system” followed by other steps related to the test case. This approach ensures clarity and efficiency in the test case document while avoiding repetition.

Similarly, avoid repeating the steps again and again each time a particular user repeats the same action in the system. For example, a Business Development Team Head creates a new Account. Later in the process, again if the Business Development Team Head creates Account records, then it is not necessary to write all the steps to be followed to create an Account, as the Business Development Team Head already knows how to do it (from the steps written earlier in the test case document).

It is recommended to write the steps short and clear, and in simple English and with less technical terms as the end-user may not be proficient with all the Salesforce and other technical terminologies. Once all the test cases are crafted, it is advisable to do a peer review. This is done to ensure that there is no controversy between the system and the written steps and expected results. Moreover, the majority of the test cases are reusable. So, to avoid mistakes in the future, it is better to make the present document error-free.

So Far, We Learnt

We learned the concept of test cases and how to write them effectively along with a few examples. By following best practices and guidelines for test case writing, one can save time and resources in the long run, reduce the risk of errors, and improve the overall user experience.