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.

As you add key variables and apply those across the worker type combinations that you need to test, your quantity of test cases will of course scale upwards. For example, if you tested all combinations of:

• 3 dominant worker types
• 3 dominate sub-types
• 2 supervisory orgs
• 3 management levels

you 'd end up with 54 separate test cases to run. This would give you a robust, risk-based test pack with quality depth of coverage, which is what you want. So, as you can see, achieving a cursory breadth of coverage of every worker type isn't difficult. But strategically building and then repeatedly executing a risk-based test pack takes a bit more thought, time, and effort. However, the payoff is worth it.

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.

For Workday's optional additions, unless it's a critical item or brings you immediate business benefit that you need to take advantage of on day one, we'd suggest that you put those on your Change Management Plan to action after the Workday update.

For the security testing, is this something that you'd test immediately after a new update is released into Sandbox Preview as part of a Sandbox Preview and Sandbox comparison. Or would you suggest having individual test cases?

Trevor: Both. In week 1 you want to run your individual security test cases in both Sandbox and Sandbox Preview and compare the outcomes. This is because to parallel test your tenants, you need the data in both tenants to be identical in order to get an accurate comparison. The only difference between the two environments should be the version of Workday they're running. Any tests that fail in Sandbox Preview but passes in Sandbox can then be attributed to a configuration issue in Preview, at which point you explore, update the configuration in Preview, and retest those cases until they come out clean. Then in the remaining weeks of the Update Preview period, you re-execute those individual test cases for subsequent testing. I should note that security can be a tough one to test pervasively on a regular basis if you're relying solely on a manual testing approach as there can be so many objects to consider. If you aren't currently benefitting from automated testing of your Workday configuration, here are a few suggestions on how to focus your effort during the update window.

Check individual security groups

As mentioned in the webinar, this can be challenging. If workers within your tenant having multiple security groups assigned to their record, that can make it difficult to get a clear view. I suggest assigning a single critical security group to a test worker (and repeat this for all critical security groups) to assess the impact of the Workday release. If possible, test these critical security groups on a weekly basis during the preview period. Also, look at the power security groups (for example, Benefits Partner, Payroll Partner) or those where you have carried out significant customisation to achieve a security profile that meets your configuration needs.

Key workers

It's also worthwhile to take a worker-based view of security (for example, HRIS Team, Finance Team) for those workers with multiple 'power' security groups assigned to their record. This can provide some certainty that any changes made to the tenant don't impact things like segregation of duties. Take your sample of core security groups and power users and test these weekly. If that's not feasible for you given your resources, then test them, at minimum, in week 2 and 5 of the update window. If you're just getting to grips with Workday Security, you might also like our post Viewers & Doers: An Intro to Workday Security.