1. Gemma Blezard
1

2.  Purpose of Testing
 Testing Best Practices: What testing should not be used
for
 Types of Testing
 Testing Roles and Responsibilities
 Test Script Management – Tests and Incidents
 UAT Support
2

3.  Check that configuration and code is functional
 Ensure that the system’s initial build meets the agreed requirements
 Help to control the project scope
 Confirm that the finished system can support the client’s business
processes
 Gain client’s approval to release new functionality for general use
3

4.  Making changes to business processes
 Introducing additional requirements outside of scope
 Making significant cosmetic changes to page layouts and user
interface
 Training users
That’s what Build Reviews and Training sessions are for…
4

5.  Unit Testing (code developers)
 System Testing
 User Acceptance Testing (aka Functional Testing)
 Production Testing
 Regression Testing
5

6.  Is conducted by Apex developers – involves writing clauses in their
code that automatically tests its coverage
 Evaluates how many records of data the code would successfully
run on in that environment e.g sandbox / production.
 Is necessary to deploy Apex code into a Production environment –
you must have over 78% coverage
6

7.  Is conducted by salesforce consultants
 Tests the system’s technical processes from start to finish
 Involves following a test script based on specific outputs
 Is useful for troubleshooting a problem with automated
rules in the system
 E.g. workflow / validation / assignment / escalation
7

8.  Is conducted by the people who intend to use the application
 Tests the system’s ability to support the business processes – NO
changes should be made at this stage unless they are fundamental to
their processes
 Involves following a test script based on what happens in the business
 The desired output is that the client confirms that the system is fit for
purpose
8

9.  Is a repeat of system testing in the Production environment
 Is designed to test whether config and code have been
successfully deployed from sandbox to production
 Use the same script that you used for system testing
 If there is time, get the client Project Manager to run through
their UAT scripts again post deployment
9

10.  Designed to test whether code and config releases affect existing user
processes within the system
 Takes place once releases have been made that are not meant for ALL users.
Tests are conducted by system users for whom the new releases are NOT
intended
 After deployment, users test the ability to use salesforce.com the way they
normally would
 Users list any system changes that negatively impact their current process
 We fix them!
10

11.  Project Manager:
• Coordinates script writing
• Schedules testing time around day jobs
• Ensures testers are testing when they are scheduled to
• Co-ordinate testing sign off
 Business Owners:
• Write test scripts in accordance with usual business processes
• Sign off testing
 Testers
• Follow test scripts, adding comments and incidents
• Retest following fixes
• Specify whether each process is a test PASS or FAIL
11

12.  Write and complete system test scripts
 Test code that a developer has written and liaise with client for
changes
 Ensure that any code developed has over 78% coverage
 Supply clients with UAT script templates
 Provide guidance on how to complete the scripts
 Resolve incidents that crop up during UAT – or liaise with
developers to resolve them if needs be
 Get sign off confirmed IN WRITING once all tests have passed
12

13.  The build should be completely signed off in writing
 No further changes should be required (including field and
page layout / cosmetic adjustments to screens)
 UAT scripts should be fully written and ready (by the client!)
 All system tests should be complete and scripted by the
consultant / developer
13

14.  Test scripts have two parts: TESTS and INCIDENTS
 Are best managed in the form of a spreadsheet in Google
Docs
 Tests define what process is being tested, steps to follow,
expected vs actual results, overall test pass/fail and an
incident number if the test step fails
 The level of technicality in steps/descriptions depends on
whether it’s for UAT or system testing.
 This example is a system test script for workflow rules that
are misfiring:
14

15.  If a test step fails, an Incident is created on the Incidents tab
 Incidents include the incident no, step no, description of the
Actual Result from the test, the estimated cause for the test
failure and the fix
 Once the initial estimated cause has been identified and the
problem fixed, you can retest the step
 The step is repeated after the first fix as a Retest – copy and
paste the original step details as a new row in your
spreadsheet
 If it fails again, add a new incident to the Incidents tab and
another retest line in the Tests tab. Keep testing and fixing
until the tests pass
 For test step to pass, all parts of the step should work as
expected (ie Actual Result is the same as Expected Result)
15

16.  In this system test example, step 5 of the test script
failed 3 times.
 We logged 3 incidents (2,3 and 4) then retested, adding
new retest rows to the script after step 5 as follows:
16

17.  UAT is designed to test that the system can support the business
process
 The only changes that should come from the UAT are fixes
 UAT scripts should not be technical – each step is based entirely
on requirements from a signed-off requirements matrix OR spec
 A representative from the business (e.g. a process owner) should
write all UAT scripts while the system is being designed and built
 End users of the system are responsible for following each test
step and logging incidents
 Consultants log in to the spreadsheet, reviewing and fixing
incidents then adding retest steps to the test script as the testing
is happening
17

18.  UAT test scripts look similar to system test scripts but
they are at a much higher level and use less technical
language
 They relate to the process and test the requirement, not
the technology
 Therefore it is usual that UAT will happen before users
have been trained
18

19. Supporting UAT involves
 Guiding users to where they can find things if they get really
stuck
 Providing process owners with example UAT scripts
 Talking clients through how to write and follow UAT scripts
 Acknowledging and fixing incidents as they occur
 Being assertive with clients when they try to push through
changes that are not absolutely necessary to support the
process
 Encouraging clients to formally sign off UAT once all tests
have passed. This is essentially your formal Build sign off
19

20. Clients are often nervous about UAT because not many
people know how to conduct it properly. Here are some
tips on how to handle resistance from clients:
 “I haven’t been trained on using the system”.
Gently remind clients that they are testing their own
processes, NOT the system functionality. Encourage
them to arrange their own 1hr demo of the system
to all testers prior to embarking on UAT
 “We can’t test without all our data being present in the
system”
You only need a few test records to test the
process. If your build involves supporting objects
containing lookup data, load a few records and
provide the test coordinator with a list of records
they can use to look up on
20

21.  “I haven’t got any time to test and do my day job too”
• Client project managers are fundamental when you’re
up against this resistance and having a project plan
with dates is key.
• Keep on top of your PM and make sure they book UAT
into everyone’s diaries as soon as possible after the
project starts.
• Have regular check-in calls through Design and Build
stages so that you can rearrange dates for testing if
needed.
• Make sure your client PM emphasises the importance
of testers’ full attention when they are scheduled to
test and encourages testers’ management teams to
arrange cover for the “day job” while their staff are
testing.
21