Workday Update Q&A
13 February 2018
Workday Update Q&A
For testing business processes (for example with the Hire BP), should we hire ALL different worker types, or is that overkill?Trevor: Yes, you should hire all worker types. That 's relatively easy. Suppose that your configuration includes three of Workday's default workers types (Employee, Contingent Worker, Contractor) and six default sub-types (Regular, Regular (Fixed Term), Temporary (Fixed Term), Intern (Fixed Term), UTemp (Fixed Term), and Variable (Fixed Term)). Even if you 've supplemented these with custom worker types or sub-types, a manual test team could reasonably execute a test for each worker combination using identical subsequent data. What 's more challenging is achieving the depth of coverage that you need to provide for each worker type. This means looking at the worker types you have and identifying which proportion of your organisation each type makes up. You want to hire at least one of each worker type, but more importantly you need to prioritise your most dominate worker types and really stress test those, as any issues with those worker types will affect the largest portions of your worker population. For this, you should identify and include those components that drive eligibility for benefits, compensation and allowances again prioritising those factors representing the largest portions of your worker population, for example:
- supervisory organisation; and
- management level.
- 3 dominant worker types
- 3 dominate sub-types
- 2 supervisory orgs
- 3 management levels
Doesn 't thorough testing of BPs and reports validate security pretty thoroughly as well?Brennan: Not exactly. Yes, security groups and roles factor in to whether a BP test or report test passes or fails. However security isn 't the subject of those tests. As a security group enables actions against a number of Workday objects (Worker, Position, Supervisory Org, Custom Org, etc), you should really test that the ability of each security group to perform an action against these numerous groups remains in line with your expectations through the update window. Security groups also allow visibility of worker data, and you want to make sure that visibility of worker data remains the same through the update window. If you rely solely on BP testing to validate your security configuration, many important checks could slip through the cracks because they're not part of the particular BP workflows you're testing. Additionally, you'll have no explicit record of your security tests for auditing purposes, which could prove problematic in future.
During the Workday update should we test business-as-usual items if considered high enough risk, not just enhancements?Brennan: Definitely. Because Workday is a workflow based-solution and not a transactional one, processes often intersect (as do security groups/settings). This means sometimes a change made in one area can have a knock-on effect elsewhere in your configuration. While Workday thoroughly tests its software before it releases it, every customer has a unique configuration and in the wild surprises can sometimes arise. Your objective during the Workday update preview window is to test your configuration as thoroughly as you can so that you feel confident on the first day that the update appears in production that your configuration will continue to perform as expected for all of your end-users. A risk-based approach to that testing should prioritise:
- your high-risk or high impact business-as-usual functionality that would pose significant issues if they suddenly didn 't work as expected, (often these include highly customised and complex BPs and security configurations, as well as those integrations that are tied to financial risk like third-party payroll);
- updates and enhancements that are likely to affect the functionality you currently have switched on; and
- brand new Workday features or functionality that are switched on automatically prioritising those based on their impact to your business and configuration.