Twice each year Workday releases useful new features and functionality to all of its customers, and the community springs into action. It’s an extremely busy period for testers, QA teams, and the business partners who support them during testing. To help you organise for the update window, use your time efficiently, and successfully test your tenants, our Workday experts have pulled together these helpful testing to-do’s.
Understand Why Update Testing Matters
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 surprises can sometimes arise. Your objective during the Workday update preview window is to test your configuration as thoroughly as you can so that on the first day that the update appears in production, you feel confident that your configuration will continue to perform as expected for all of your end-users.
In the four-to-six week before the preview period begins, your team should be developing its update test strategy and test plans—working out exactly what you need to test, why, and the logistics around testing so that when the preview window arrives, you can hit the ground running.
DEVELOP YOUR UPDATE TEST STRATEGY
Your test strategy defines what you plan to test and why. When deciding what to test, we recommend a risk-based approach that prioritises:
- testing of your high-risk or high impact business-as-usual functionality. Ask yourself what processes 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
- testing of 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.
BUILD YOUR TEST PLAN
A good test plan maps out in detail the what, when, and who. It documents the following and should be agreed by your key stakeholders:
- the risks you hope to mitigate by testing (this will come from your test strategy);
- what, specifically, you will test to mitigate those risks. (For example, you might have identified in your strategy that the benefits eligibility during the hiring is a high-risk area that must work when the update goes live. But what specific processes will you test to mitigate that risk? Create position? Hire? Termination? What about Change Personal Information? Or Change Job?);
- the specific scenarios and number of individual tests you will execute in each area of focus to get the depth of coverage you need;
- which staff you will need for the various tests; and
- your test schedule, specifying which tests are taking place on which dates in which order by which staff.
It’s rare to complete a test cycle with zero test failures. So remember to include time to run the initial tests PLUS additional time to investigate issues, log and resolve these, and to retest those fixes. Build this contingency in to every test cycle in your schedule
WRITE YOUR SCRIPTS & PREP YOUR DATA
For every test, you need a test script. This should specify:
- all prerequisites required to start the test, for example open positions;
- what the test is;
- what test data is required;
- who to initiate the test on behalf of (what role/security is required);
- what the other parties in the test are are (for example other workers or objects such as supervisory organisations);
- a clear list of steps on how to run the test;
- the expected result of the test.
For example, a test of what security permissions team members have on each other might specify the initiator as Logan McNeil, the other party as Alain Dubois and an expected outcome that Logan can not change Alain’s Benefits.
If you are reusing previous tests, make sure the step-by-step instructions from the past are in line with your current configuration and UI. Otherwise, when test execution begins, testers will get confused and valuable time will be lost updating the scripts.
Data prep is one of the most overlooked elements of planning. Don’t underestimate the time it takes to identify workers that fulfil your test criteria. It is substantial. Begin this process well before the preview window opens. If you’re reusing old test scripts that contain real worker data, review that data carefully. Data on real workers changes constantly. They change jobs and supervisory orgs, go on leave or leave the company, their salaries change, their eligibility for benefits change, etc.
Without a careful review to confirm that the test data used in previous regression packs is still suitable, tests during the update may fail not because there is a genuine configuration issue, but because the worker data used in the tests were no longer fit for purpose for the given scenarios.
RALLY THE TROOPS
Once your test plan activities are mapped out, you’ll have a clear view of how testing will impact other areas of your organisation. The testing required throughout the five-week preview window is typically a multi-departmental effort, so it’s essential to make sure everyone involved knows exactly:
- why this testing is so important for safeguarding your Workday configuration;
- what their role and responsibilities in the process are;
- what the testing, reporting, and documentation processes are and key deadlines they must meet; and
- what the lines of communication are.
Test Your Sandbox and Sandbox Preview Tenants Simultaneously
Our clients have experienced the greatest success when they thoroughly test both their sandbox and sandbox preview tenants side by side throughout the five-week period. We highly recommend that you ensure both these environments are refreshed from production at the same time. Workday arranges this by default for Week 1 of the preview window. This gives you a simple A/B comparison that allows you to clearly spot which processes have been impacted by the Workday update and need attention. This is also when the efficiencies of automation are most pronounced. With Kainos Smart, you can execute a set of tests on one tenant and repeat the exact same set of tests on your other tenant with a click of a button. The resulting comparison is reported so you can quickly see any differences between the two tenants and take remedial action.
Request Refreshes of Your Preview Tenant
Workday releases software updates to your sandbox preview tenant every week during the five-week preview period, not just on day one. So it’s a good idea to plan further preview data refreshes from production so that sandbox and sandbox preview are in sync during the update window. Workday will arrange this on request after Week 1.
Start With Security, Reporting and Integrations Testing in Week 1
Always start with security, reporting and integrations testing. Given that these functionalities are business critical, you want to make sure that your reporting is successful and your integrations up and down stream are working as expected. We suggest you start these tests each Monday morning to ensure that no data has been compromised as a result of staff making configuration changes in the week prior. For integration testing, the most important factor is to run your integrations on both your sandbox and sandbox preview tenants before any other changes have been made to the tenants. This will allow you to do an exact comparison of your integrations running on the current version of Workday versus the preview version of Workday and immediately pinpoint any discrepancies. If you have a significant number of integrations, we recommend using test automation.
Add BP Testing and Regression Testing in Weeks 2—5
We find that Workday are still delivering BP functionality through the first
week, so it’s best to conserve your efforts and hold off on BP testing until
Week 2 of the window.
Remember, though, to continue running your security, reporting and integration tests alongside your BPs throughout the five-week window—as each weekly release from Workday will include new functionality.
Track and Document
Take advantage of the tracking and documentation tools out there. Manual test teams often lack traceability around test cases and their results. This leads to uncertainty and risk in the testing process, as there’s no reliable and consistent view on progress or potential blockers. Without a means of tracking progress and defects, you miss out on valuable insights ahead of the next update window. And when auditors arrive, there’s no reliable record of the testing you’ve completed.
Test automation can be a key differentiator when it comes to update window testing. The ability to run comprehensive packs with automatically set results at the click of a button helps you reduce testing effort to mere hours instead of days and weeks, improves accuracy, and frees up your SMEs to spend less time on testing and more time exploring and adopting Workday’s useful new features. Our Kainos Smart automated testing platform can reduce hands-on effort during update testing by 90%, increase test coverage by over 400%, and catch 200% more defects than manual testing. If you’d like to know more about how Kainos Smart can simplify your BP, integrations, security and custom report regression testing, please contact us to request a custom demo.