Salesforce QA or Salesforce Testing is still a niche in the Salesforce eco-system with many companies and partners opting to have their Salesforce Developers testing their own work. However, this will always lead to biased testing and therefore there is now a growing trend to implement a Salesforce QA function to ensure that quality control is applied to solutions being built.
There are many ways to implement quality within the lifecycle of a project, but ultimately this will at very least involve some if not all of the following testing phases (we will look at others in a future post). Remember, testing is not the only quality control that you should have in place, otherwise all you have done is implement a Test Team. There is a difference between having a Test Team and truly apply QA to your projects/solutions. Also remember, QUALITY is owned by EVERYONE not just the Test Team.
Salesforce Unit Testing
Generally speaking it is the Salesforce Developer that actually owns the responsibility of performing Unit Testing. When new code/functionality is created, prior to deployment Unit tests must cover at least 75% of your Apex code, and all of those tests must complete successfully. However although Salesforce states that only 75% of the Apex code must be covered by tests, it is a best practice to not actually focus on the 75 % of code that is covered but actually take the approach of ensuring that every user case of the application is covered, including positive and negative cases, as well as bulk and single records.
This should result in more that 75% of Apex code being coverage. Remember, every trigger must have some test coverage and that all classes and triggers must compile successfully.
Some Customers may request from the Salesforce Tester that Unit Testing are reported within Testing Updates and/or Test Documentation so it is always beneficially to highlight any issues with the lack of coverage that may be identified.
What is Apex?
Apex is a strongly typed, object-oriented programming language that allows developers to execute flow and transaction control statements on the Lightning platform server in conjunction with calls to the Lightning Platform API. Using syntax that looks like Java and acts like database stored procedures, Apex enables developers to add business logic to most system events, including button clicks, related record updates, and Visualforce pages. Apex code can be initiated by Web service requests and from triggers on objects.
Salesforce Integration Testing
The Salesforce Integration Testing phase is where individual units are combined and tested together in order to identify any issues with the interaction between these units. There are various approaches to integration testing and depending on various factors, such as development approach, number of integrations and time, you may need to create your own hybrid approach.
As a Salesforce QA Tester, it is imperative that you receive a well documented design document that details how each unit interacts with other – this will be the basis of your test cases and you should immediately highlight this as a risk if not available.
Salesforce Exploratory Testing
The main advantage of an exploratory testing phase is that less preparation is required, bugs are found quickly, and you can cover the system under test quicker to enable a level of initial confidence in the system. Salesforce Exploratory Testing can be approached the same way standard exploratory testing is conducted. However, the quality of exploratory testing will always be related to the ability of the tester themselves and their understanding of the system / solutions that has been developed. It would be advisable to consider Session Based Testing if more control and accountability is required and if a customer is wanting an understanding of what has actually been executed during the phase. This type of testing can be used during the early Build phase of a project and will assist in identifying any potential bugs very early on.
Salesforce Functional Testing
Salesforce Functional Testing is when the Salesforce solution is tested against the functional requirements/specifications. This type of testing is more effective when the the Salesforce QA has created their test cases/coverage directly from baselined User Requirements. However, sometimes only the High Level Design and other system documents are available and have to be used instead. This can ultimately mean that any defects found, although assisting with the overall quality of the solution, are not going to follow the End-Users usage of the solution and could miss fundamental issues that could have been resolved earlier.
Salesforce System Testing
The ISTQB definition of System Testing is that System Testing is a level of software testing where a complete and integrated software is tested. The purpose of this test is to evaluate the system’s compliance with the specified requirements
During this phase, which should be after integration testing but before acceptance testing, the Salesforce QA should be testing to see if the solution that has been developed meets all of its requirements (Technical, Business and Functional).
A Requirement Traceability Matrix (RTM) is an extremely useful document that you should make sure that is part of your standard QA process. This document essentially maps User Requirements to Test Cases to ensure that no functionality/requirement is missed from the testing coverage (in a future post we will explore RTM’s in further detail).
A Test Management Tool will also be of great benefit to create, manage and execute test cases and also to report on progress being made so it is advisable to make use of one.
The process of System Testing can vary dependent on project but should include the following steps:
- Creation of a Test Plan.
- Creation of Test Cases (with traceability to User Requirements).
- Creation of Test Data.
- Execution of Test Cases
- Defect Reporting and management, as well as re-work.
The System Testing phase is to ensure that a full end to end process does not result in a system failure and also helps to deliver a quality assured product to the End Customer.
Salesforce Performance Testing
Although Performance Testing is still a very important phase of the testing lifecycle, Salesforce Performance Testing requires a fair amount of thought and scheduling with Salesforce themselves.
Performance tests must be submitted to Salesforce for approval at least two weeks in advance of the testing date and cannot be run unless approval has been granted. Salesforce will only take a monitoring role to ensure that any performance testing that is executed causes no issues with the Salesforce services.
Part of the approval submission must include:
– A description of the nature of the test and the specific volumes involved
– The test plan and test cases.
– TPS (Transactions Per Second) Methodology
– The number of data rows in each of the tables
– The method used for loading the data and the tool used (such as LoadRunner)
– A description of the test script you will be using to test.
– The date and timeframe for the test including expected duration. Salesforce requests at least two weeks in advance to obtain the proper approvals and resources.
So as you can see from above, Salesforce takes any performance testing very seriously and it is advised that you ensure that your testing team is experienced in performance testing before carrying out this task.
Salesforce Test Automation
Test Automation involves controlling the execution of repetitive but necessary tasks within an existing testing process (eg. in addition to identified manual testing), or to perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing.
Salesforce Testing has become easier to create and maintain with Test Automation tools being more widely available that are capable of handling dynamic pages – in the past allowing for dynamic identifiers on a page was a challenge in itself and could prove extremely costly in maintenance hours. Tools like Provar and Machine Learning driven automation testing services like Mabl can increase adoption of automation due to easy implementation although a Test Automation Framework/adoption plan should always be documented to ensure that quality is included within any build.
Remember, to this day there are a large number of people within the Software Development industry that believe that every test should be automated and fail to fully understand that you should be aiming to get a high ROI on Test Automation and that put simply, somethings are just quicker and more cost affective to do manually.
A Certified Salesforce Administrator, Salesforce Einstein Analytics and Discovery Consultant, ISTQB® Certified Tester Advanced Level, Jitterbit Foundations and Jitterbit Core Certified QA Test Automation Manager who is also an experienced creative all-rounder with enthusiasm and the proven ability to understand client needs and deliver satisfying solutions. A thirst for new technology and modern Quality Assurance and Testing techniques keeps me aspiring to learn at every opportunity. My current role is at Publicis Sapient who are an official Salesforce Platinum Partner. Publicis Sapient provide Salesforce expertise and strategic thinking that enables organisations to transform their business to Cloud-based technology.