SAP Knowledge Base Article - Public

2076141 - Testing a New/Updated Performance Form Template in Performance Management

Symptom

  • This KB article provides a testing strategy when adding or updating a Performance Form template.
  • What testing should be conducted when modifying or creating a Performance Form template.
  • Forms should be tested before launching to users, even if they have been used in the past
  • New review forms should be tested
  • Forms with any changes should be tested
  • Forms should be tested after a release to ensure fucntionality is the same

Environment

SAP SuccessFactors Performance Management

Resolution

Note: This is not a comperehensive guide to testing a new form or changes to an existing form. This is general tips to assist in the testing.

  • These are common test scenarios to help ensure the Performance form is configured as expected. For each item, are the results what is intended? If not, adjustments may be needed. While not all of these scenarios may apply to the process, evaluating each item will help ensure users do not have unexpected access or limitations.
  • Please also see reference KB article 2090185 - Guide to Starting A New Process 101 

General Form Testing:

  1. Create a form for a test user via Admin Tools > Performance Management > Launch Form.
  2. Launch the form to a test user with complete hierarchy. This is a user with each role in the route map.
  3. Proxy as the test user who currently has the form.
  4. Fill out the form and then click Save & Close.
  5. Verify the form has performed as expected.
  6. Send the form to the next recipient.
    • If you have required fields defined, send the form to the next step without the requirement being met.
    • If so, try sending the form to the next step without meeting the requirements.
    • Note if the error for the requirement is triggered.
  7. Once the form has been sent to the next recipient, Proxy as that user.
  8. Fill out the form and then click Save & Close.
  9. Verfy the form has performed as expected.
  10. Proxy as the first test user again.
  11. Open the form from the En Route folder.
  12. Review the information on the form in En Route folder and verify the user should or should not see this information.
  13. Proxy again as the second recipient and send the form forward.
  14. Repeat these steps through the planned routing of the form to ensure the form behaves as expected at each step.
  15. Once the form is completed, find the form in the completed folder for each user who receives it.
  16. Verify the user can see all information required and they do not see information that should be hidden.
  17. While sending the form from user to user, take thorough notes on what needs to be changed using this format:
    • on template named _____, in section named ______, _which role(s)_ should/should not be able to __do what?__
  18. If you have any downstream processes that rely on the ratings and information in the form, ensure that this information, particularly ratings, flows to those areas properly.
    • Some areas may incluee: Calibration, Compensation, Employee Profile, and Reports.
    • Verify the accuracy of the information.
  19. If the testing has occurred in a test/staging instance, be sure to test again thoroughly in the Production instance as Form Template Settings, Route Maps, Competency Libraries, and Goal Plans may differ between instances. leading to to different results. 

Specific Elements to Test

  • Competencies - If competencies are populated by job code, make sure different roles have forms that look different. For example, engineer competencies should appear on an engineer's form and administrator competencies should appear on an administrator's form.  If there are any new Job Codes, be sure to map competencies to these roles prior to launching the forms.  If competencies are hard-coded onto the form, ensure none of those competencies have been deleted from the Competency Library.  Invalid competency IDs in the form can cause an error when launching the form.
  • Goals/Objectives - Add goals to the form, whether through the goal plan or directly to the form.  Verify the correct goals are populating the form and the goal information is correct.  If you’ve copied the form template from a previous year, check that the goals on the new form are from the correct goal plan and not an old goal plan.
  • Button and Form Labels - Ensure that the labels are correct for the form fields and buttons as well as the information displayed as the form is routed.
  • Route Maps - If the only changes made are route map changes (reusing a previous form template), ensure that the form’s permissions allow for the desired view and edit access at the new route steps.  The steps outlined above for general testing should identify any issues with permissions. 
  • Languages - If forms are multi-lingual (users with different languages see translated versions of the form), test the forms for each language to ensure the translated view is correct.  This can be especially important if new fields or sections have been added to the form template.
  • Required Fields - Verify the required fields you have set up are working as expected. 

Tips to Ensure Form Launches Go Well:

  • Do not launch forms to real users until you have thoroughly tested.
  • Avoid launching forms with known configuration issues while assuming that you can fix those issues later. It is best to delay the launch until the configuration issues are addressed.
  • Do not add steps to your route map and assume forms will work the same.
  • Do not delete competencies from your Competency Library without reviewing the form template, else your forms may not launch at all.
  • Testing cannot be done in 5 minutes! Proper testing should take a few days and should include more than one tester. Include someone who didn’t participate in the form design, they often catch errors that an administrator might miss.
  • A test template cannot be put into production as the dependencies (competency ids, rating scale names, ...) are typically different from instance to instance.
  • Don't go from your memory regarding last year's forms.
  • Make sure to run your reports that will be created after going live.
  • Route the forms to completion.
  • It is safe to launch test forms in the production instance if forms are launched to test users. The test users may be users that have been specifically added to the system for testing. Or, they might be the SuccessFactors test users. For Example, Alex Anderson (aaaa), Brooke Brown (bbbb), etc. The testing scenarios and test users are different for every customer.  Ensure you have your test users set up to meet your review process.
  • Don't wait until the last minute to create your case.
  • Changing requirements after work has started will lengthen the process.
  • It is best to submit all (thorough) requirements at the start of the case.
  • If there are route step changes, please create a new route map and link it to the template.
  • When copying last year's form to create this year's form, last year's goal plan and/or dev plan will need to be swapped out for this year's goal plan and/or dev plan if there is a goal plan/dev plan section.

Downloadable Guide: How to Test a New Form.

  • Please feel free to download this guide from the Attachments section below.
  • This document describes common elements of a new form template, and how to QA that form using test users before launching it to end users.

See Also

KB article 2090185 - Guide to Starting A New Process 101

Keywords

SF, success factors, PMGM, PM, change , KBA , LOD-SF-PM-FF , Form Features, RTE, Spell Check, Legal Scan, Print , How To

Product

SAP SuccessFactors Performance & Goals all versions

Attachments

How_To_QA_Form_Templates.docx