Salesforce testing best_practices

Testing Approach in Salesforce.com –
Best Practices
Salesforce Testing Beginning:
1. Understanding the business obligation before beginning system test plan
2. Test plan has been created and reviewed before starting system testing.
3. Test Preparation:
A. Test Scenarios
i. Prepare feasible scenarios based on the business surroundings.
ii. Scenarios must be shield all the well-designed practical requirement.
B. Test Case
I. Test case should insurance all slight and huge real-world condition.
C. Test Data
I. Based on the skilled prerequisite we must prepare test data.
D. Test Environment (QA ORG)
I. All the projected requirements should be past in QA ORG
1-Validation rule
2-Profile
3-Permition sets
4-Mail Templates
5-Layout
6-Field visibility (Field level security)
7-Browser (IE, Google Chrome, Firefox, Safari)
E. Tool needed for testing
I. Get ready the wanted testing tools and device for testing.
1-Load testing (Community/Site)
2-Broken link (Sites)
3-Mobile Device (IOS/Android)
F. Time assigned for testing (Use test methods)
1-Boundarty value testing
2-Equalance class partitioning
3-Monkey testing
4. SIT Test environment has been configured based on arrangement
worksheets/Requirements
5. Test environments for outside systems are available to support test.

6. Traceability Matrix has been created with the major objective to verify the test
coverage i.e. whether or not all requirements and test cases are being covered by the
test cases.
7. Test Execution Metrics (planned vs. Actual dates) is defined and reviewed
8. External systems resources are available to support/execute interface testing to all
external test system.(API)
End of Testing:
1. Successful execution of all test cases, with no Crucial/Very High/Great Defects
outstanding, and an agreed Defect resolution plan is set in place for any outstanding
Medium and Low defects.
2. Test Closure Note is created to summarize the results of System Test.
Stages of Salesforce testing life cycle
Levels of Software Testing
Following are the stages of Software Testing:
Functional Testing
1. Unit Testing
2. Integration Testing
3. System Testing
Requirement
Gathering
Test
Execution
QA
Prepare Test
Plan
Understandin
g the
Requirement
Prepare Test
Scenarios
Prepare Test
Case
Test
Execution
UAT
Test
Execution
Production
Test Closure

4. Regression Testing
5. Acceptance Testing
6. Alpha Testing
7. Beta Testing
Non-Functional Testing
1. Performance Testing
2. Load Testing
3. Stress Testing
4. Usability Testing
5. UI Testing
6. Security Testing
TYPES OF TESTING SPECIFIC TO SALESFORCE.COM
1. Unit Testing:
Unit testing happens as part of (Developer +Tester) effort.
2. Component Testing:
 Usability testing
 Scenario clever testing
 Requirements based testing.
3. Integration Testing:
Interface Testing is accepted in SFDC to test integration with any external system.
EX: Salesforce With any other third party system (Facebook, LinkedIn, SAP)
4. System Testing:
 Requirements-based Testing
 Boundary Value Testing
 Test case Testing
 Usability Testing
 Security Testing
 Condition Testing
 Functionality Testing.
5. Regression Testing:
To safeguard smooth functioning of application in existing functional parts after any
improvements, configuration or customization changes to the application OR with
every release to test the continuity of stream for earlier releases.
6. User Acceptance Testing:
Business Route based Testing of functionality by End User/Client.

COLLECTIVE ANALYSIS SCENARIOS IN SALESFORCE.COM
FOLLOWING SCENARIOS SHOULD BE ROOFED IN TEST PLANNING AND
EXECUTION:
1. FUNCTIONAL AREA/ TEST CASE BASED SCENARIOS:
These scenarios should be developed in such a way that they shield an end to end
test case.
Example: lead conversion
This would comprise all cases right from the User first logging in to SFDC, landing
on Lead homepage tab, creating a lead, prospecting a lead and finally converting it to
an Account, Contact and optionally, an opportunity. Thus, the entire functionality or
test case of lead conversion will be covered by one scenario. The scenario will then be
broken down into Multiple Test Scenarios to validate each part, like, access to all
related objects, page layout validations.
2. SECURITY RELATED SCENARIOS (ROLES & PROFILES):
It is expected to perform Security Testing in both the Component & System Testing
levels. Roles and Profile based testing influences the Profile Matrix/Profile design
document. Test cases which cover each functionality are repeated multiple times to
include logging in with every profile and re-iterating the same steps to validate the
Organization wide defaults, object authorizations/field-level security/Page layouts/
record types and other general or administrative permissions given to each profile.
Similarly test cases to login with test users belonging to each role in the role
hierarchy should be built to validate record level access for users.
Example: We have 2 users 1 user has a read access and another user has both read
and writes access for banking application.
For the above prerequisite we must need to authorize user 1 have only read
admission to the system and user 2 have both the read and write admission to the
system
3. ENVIRONMENT BASED SCENARIOS:
Environment based test planning will consist of test scenarios/cases to do a sanity
check on any new environment, whether a sandbox or production, to validate each
deployment. The scenarios should cover all functionality, usability in terms of
configuration and code movement to discover any cracked navigation, and finally
security related scenarios to catch object record level access related issues

4. GOVERNOR LIMIT BASED SCENARIOS:
These scenarios should include multiple iterations wherever custom code is
deployed - on visual force pages – Create/Edit/Save/Delete/Update etc. to identify
any performance where query limit is exceeded, on functionality which leverages
apex triggers or classes and create/update/delete such records to again ensure that
navigation is continuous. Also, test scenarios should call out cases where character or
numeric limits on fields/number of record limits on reports/ maximum number of
addresses to include in mass emails etc. are to be confirmed.
5. CHANGE MANAGEMENT RELATED SCENARIOS:
These scenarios include regression tests to be achieved after every enhancement or
addition of any new functionality to discover issues of broken navigation in the
entire process flow of pre –existing functional areas and ensure the unified
integration of the new configuration or customization with the previous use
cases/requirements. This will unsurprisingly result in multiple iterations to test all
requirements over several releases AND in different environments, especially if the
project is being delivered based on the agile model, which is common in SFDC
projects.
Example:
Sprint1: Attaching document using Content management system
Sprint2: That Attachment functionality hennaed to new version
For the above second sprint enhancement affect the existing sprint in the production
for these kind of scenario we must consider this testing
6. INTEGRATION SCENARIOS:
These scenarios should include Data migration testing, by querying data in database
where middle ware is involved and comparing with extracts taken from
Salesforce.com, testing that all fields on records are correctly mapped between
external system and SFDC with free data types. Integration scenarios take the form of
both Test case based scenarios and also change management related scenarios as they
are essentially used to validate data flow between SFDC and external systems, with
or without middleware in between.
Example: integrate Salesforce with TFS
TFS Salesforce
Vijay
Test
Vijay<br>Test
For the above table clarifies TFS fields are HTML fields but in our Salesforce taking text field
so it’s saving value with HTML commend.

Salesforce Testing Do’s and Don’ts
Software Test plan:
Do’s Don’ts
Develop test plan based on an sanctioned
Project Plan
Do not use draft (unapproved) test plans
for reference
Document test plan with major testing
landmarks
Do not ignore the test approaches identified
in the test plan during testing.
Identify and document all deliverables at
the end of these landmarks
Do not make changes to any approved test
plan without official change request
Identify the resources (Both
Hardware/Software and Human) required
Do not mix the stages of testing (Unit
testing, Integration testing, System testing,
Functional testing etc.) with the types of
testing (Regression testing, Sanity testing,
User Interface testing, Smoke testing etc.) in
the test plan. Identify them uniquely with
their respective input and exit criteria.
Identify all other external systems, which is
going to interact with the application. For
example the application can get the data
from any other Informatica system.
Identification of such systems will help one
plan for integration testing as well
If performance testing is under the scope of
testing then clearly identify the application
performance requirements like number of
hits/second, response time, number of
concurrent user
Include Features to be tested to
communicate to customer what all will be
tested during the testing life cycle
Include Features not tested to communicate
to customer what all will not be tested
during the testing life cycle

Software Test Case:
Do’s Don’ts
Identify and draft test cases for each unit or
component or module
Do not write repetitive UI test cases. This
will lead to high maintenance since UI will
change over time.
Write test cases with all the mandatory
fields such as test case ID, priority,
description, execution steps, expected result
and actual result
Do not think on negative paths for user
acceptance test cases if the business
requirements clearly indicate the
application behaviour and usage by the
business users.
Design more functional test cases Do not fail to get the test cases reviewed by
individual module owners of the
development team. This will enable the
entire team to be in the same line.
Focus on functional as well as UI aspects Do not leave any functionality uncovered in
the test cases until and unless it is specified
in the test plan.
Write execution steps in points so that the
steps are clearly readable
Do not to write test cases on assumptions. If
the requirement is not clear ask business
analyst.
Clearly identify the expected results for
each test case
Do not write test cases on error messages
based on assumptions. Document error
message validation test cases if the exact
error message to be displayed is given in
the requirements.
Design the test cases as per the workflow of
the application
Security is of high priority in Salesforce
testing and hence document test cases
related to the application security.
Create a traceability matrix to understand
the test case coverage with the business
requirement documents.
Conclusion
 Testing in Salesforce.com projects concentrations chiefly on the functional areas to
cover all requirements , usability to determine if the user Interface is easy to use and
understand, environment management ,integration related scenarios and security
related aspects of Salesforce.com.
 All relevant documents, like the Test Plan, Test Case and Requirement Traceability
Matrix, Change control document should be in place at the beginning of the testing
cycle.
 The role of Software testing is very essential to deliver a quality product on the
Salesforce.com platform.

Salesforce testing best_practices

Salesforce testing best_practices

Recommended

More Related Content

What's hot (20)

Similar to Salesforce testing best_practices (20)

Recently uploaded (20)

Salesforce testing best_practices