Gemma Blezard

1

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

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

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

Unit Testing (code developers)

System Testing

User Acceptance Testing (aka Functional Testing)

Production Testing

Regression Testing

5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“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