Quick Tips for Testing Workday Updates: Reusing Test Scripts

If you 're not regularly regression testing outside of the Workday preview period (for example regression testing around your own business-as-usual configuration changes or the weekly Workday releases), then chances are that some of your test scripts for Workday and the data they contain have fallen out of step with your tenant since the last time you used them. If so and you use them as is, you 'll waste precious time during the five-week update window with:

• delays getting started;
• managing confusion;
• troubleshooting defects;
• correcting scripts; and
• sourcing new data that meets each test 's conditions.

So, before the preview window arrives, you need to bring your scripts and your test data up-to-date.

Bringing Workday test scripts up to date

In your test plan, you 'll have a prioritised list of exactly which tests you plan to run. Compare each script against the corresponding business process in your Workday tenant, note any differences, and then update each test script to reflect your current business process. For example, the script for your Request One Time Payment process might show only one approval. But you can see in your current Workday configuration that the BP has changed since your script was written and now shows a second approval step whenever the request is over $10,000. Does your test script, as written, still hit the conditions of this BP? Do you need two test cases now to adequately cover this BP: one below $10K and one for above $10K, to verify through your testing that the additional approval kicks in? Reviewing your scripts and configuration side-by-side in this way will ensure that the test packs you give testers are aligned to your current configuration and will reduce confusion during your Workday update test cycles.

Bringing test data up to date

Data prep is one of the most overlooked stages of test preparation. Yet, in your production tenant, data changes constantly. For example, workers get promoted and demoted, they move to different supervisory orgs or locations, salaries and benefits change, and some leave the business. New locations, supervisory orgs, and security groups are added through mergers, acquisitions and restructuringor are removed altogether during downsizing. Clients and suppliers come and go, and their details change. Before the Workday window arrives, scrutinise all of the test data in your test scripts workers, organisations, locations, cost centres, suppliers, customers, etc to make sure your tests are good to go when the Workday preview arrives. Otherwise, not only will your test efficiency be impacted during the Workday preview, but so too will the reliability of your test results:

• You 'll spend the start of the preview window scrambling to refresh your data working out over and over, for example, which workers in your worker population work at a particular location and job level with the specific salary range and eligibility criteria to fulfil each test 's conditions.
• Outdated data will make investigating defects difficult, because you won 't easily be able to know if a test failed due to an issue with your configuration, an issue with the new version of Workday, or because the data in the test script was inadequate.
• You also risk false positives, where your tests appear to pass, but it 's only because the test data used in the test wasn 't fit for purpose. This can lead to defects in your sandbox preview tenant going undetected and later making their way in to your production tenant when the Workday update goes live.

Saving time with synthetic workers

At Kainos, we 've changed our approach to test data and no longer rely heavily on existing workers. As Geoff McMinn, our VP of Product explains, 'Instead, we create synthetic workers a group of made-up workers that mirror our real employees and are used to fulfil the specific needs of our test cases. By using synthetic data, we have the ability to hire in workers in any location, at any job level and with any job type. This removes the maintenance overhead on our test packs as we approach a regression testing event for example when real employees leave the company. 'As an added benefit, it also helps us protect employees ' personal data during the testing process itself,' he continues. 'What you do with employee data is under more scrutiny now, particularly with advent of GDPR. Synthetic workers help us stay compliant with data protection regulations by ensuring that no testers have visibility of more personal information in sandbox or sandbox preview than they would otherwise have in our production tenant. We can now easily ringfence real worker data from synthetic data for testing in our sandbox, so it 's always safe to view.'

Effortless synthetic data generation with Kainos Smart

Through the powerful combination of Kainos Smart 's test automation and test data generator, you can create synthetic workers on the fly that mirror your real worker population and automatically hire them in for use throughout your test packs. All synthetic test data is available in regionally-accurate data formats, be it US zip codes vs European postal codes, Social Security numbers vs National Identification Numbers, or phone number formats from around the globe. Kainos Smart's automation and synthetic data capabilities can create a compliance safe-zone for test activity. Create and populate synthetic orgs with synthetic worker data, then limit test team access to these in sandbox. Using Smart 's automation, you can also set up synthetic supervisory orgs that mirror your production configuration and schedule these to automatically regenerate whenever your sandbox data is refreshed. A sandbox tenant full of synthetic orgs that are populated with synthetic worker data creates a safe zone not only for Workday update testing, but also hands-on Workday training and for screenshotting data-safe job aids. Book a demo to learn more about how Kainos Smart 's synthetic data could speed up your test preparation and support your compliance efforts.