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