Upload
blezard-crm-consulting-ltd
View
11.402
Download
1
Embed Size (px)
DESCRIPTION
Citation preview
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