Best Practices for Testing in salesforce.com
31 likes58,528 views
The document discusses testing best practices for software projects. It covers the purpose and types of testing, including unit testing, system testing, user acceptance testing, production testing, and regression testing. It also describes testing roles and responsibilities and how to manage test scripts and incidents. User acceptance testing is highlighted as important for clients to approve that the system meets business needs before public release.
Best Practices for Testing in salesforce.com
- 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