Congratulations on your Workday investment! You’re truly on the first step of discovering the many benefits that comes with this powerful ERP system. If you’re reading this, you’re in the deployment phase, with an agreed go-live date?
We want you to achieve this planned go-live date. Good deployment testing will help you deliver on time. Find out how to set your team up for success from the very beginning, with the right testing know-how, and tools.
At Kainos, we have been delivering and testing successful Workday deployments since 2011. And that’s given us a really strong testing practice that helps guide customers through that really important phase of the deployment. And we’ve learned some lessons along the way.
Testing Workday is different from testing other legacy systems
Many organizations who are moving from a legacy solution will attempt to approach Workday testing in the same way, by having to test absolutely everything. This could include testing the underlying system, from the server through to the database, to the configuration, and then finally the actual usage.
One of the key benefits of Workday is that the background IT is taken care of for you. This will reduce the test effort required, leaving you to test the configuration of the platform, for example, the business processes and the security and integrations, rather than the underlying systems themselves.
These test phases are generally a customer led activity. Testing throughout your deployment will give your organization the confidence that your configuration is really fit for purpose and ready for live operation.
Define the testing process
It’s important to define what your testing process is going to look like. Here are a few considerations:
Your Workday test strategy will outline the approach your organization is going to use—including the scope, the timeline, the roles, responsibilities, the tools, the processes and the set of standards that you’ll use during each test stage. It’ll act as the point of reference for all members of the project team, and provide information on what’s going to be tested, and how it’s going to be tested during your deployment.
Feature and Scenario Testing
A critical part of any test plan is going to be defining which features will be tested, which security group will be used and how each scenario will be executed.
For initial testing, scenarios in particular should be high level that cover key configuration requirements, and the key processes and activities for each functional area. For example, the scenarios might include an expectation of the test outcome or what to check for.
This is a valuable learning experience for your testing team. It’s going to allow them to familiarize themselves with Workday and the functionality and features available. As you progress through your deployment, your test scenarios will get more detailed.
As with any system, testing will be broken down into different cycles, each with their own specific purpose.
Test cycles include:
For a deeper dive into each of these, our Guide to Testing Workday Deployments will give you the information you need.
Another area to mention which often falls between the cracks when defining your Workday testing strategy, are the bi-annual major releases that Workday push out to clients. The likelihood is that at least one of these update windows is going to happen during your deployment timeline and it is important that you plan for and realise the impact that these releases may have.
Firstly, additional testing resources will likely be required to ensure that your configuration continues to operate as expected under the new software version and secondly, there may be new features becoming available within the release that you wish to take advantage of.
Tenant Build Validations
Finally, it is important to consider your approach to both smoke testing and data validation testing when new environments become available. With smoke testing, the build teams should perform a pre-defined shortlist of tests to ensure the core functionality is working as expected before it’s released for a test cycle. This essentially defines if a new environment is fit for purpose before beginning a new test cycle. Alongside smoke testing a new environment, data validation testing should also take place. This activity will be shaped by the data that is being loaded into Workday.
We hope you found this useful. Be sure to check out the second blog in this series, ‘Testing your Workday deployment, a chat with Wyndham Destinations’, as Michelle Graves (HRIS Manager) uncovers the power of automation for deployment testing.
Need a Workday partner with deployment and testing experience? We’re here to help.
Kainos has been a certified Workday partner since 2011, rolling out Workday’s full suite to organisations of all sizes around the globe. If you’d like to talk to us about working together on your next project, get in touch today.