Do You Know the Three P’s of Workday Deployment Testing?

Workday Deployment TestingTesting is a part of any new rollout — whether that’s a software solution, a website, a brand logo redesign or even a recipe for a new dish — that everyone will agree is important but often gets sacrificed at the altar of keeping your timeline. I am a firm believer in “progress, not perfection,” especially in a Workday deployment where the SaaS solution is configurable enough and nimble enough to make adjustments after go-live. The art to this is vetting out the solution well enough to ensure a successful go-live and initial end-user experience, but not turning a six-month project into a nine-month project because testing has taken on a life of its own.

That’s why, when it comes to a Workday deployment, testing is essential. In fact, it’s one of the most important events in the entire deployment process. A successful testing cycle can make you more confident in the overall rollout because it’ll allow you to identify and get ahead of any issues, and will show you first-hand what the user experience will be like for people who haven’t been involved in the core team. It’s also a great training vehicle for your core deployment team, of which some individuals will become Workday system administrators.

Within the Workday methodology, there are distinct testing cycles: There’s unit testing, end-to-end testing, User Acceptance Testing (UAT) and, if you’re deploying Payroll, parallel testing. A good partner will help you craft a testing strategy that crosses all testing cycles and helps you understand your success criteria.

For me, testing comes down to the three P’s: Purpose, Preparation and Performance. No matter what cycle of testing you’re in, you should always follow this framework if you want to ensure a successful Workday deployment.


Every testing cycle has an overall purpose or goal, whether that’s to unit test a particular component of the application or a larger end-to-end process like taking a candidate from offer letter to hire to onboarding to first day on the job. So it’s important for people to know the purpose of each testing cycle: Why are they doing it? What specifically are they looking for? As a part of this stage, it’s important to create a communications plan so all participants are aligned and on the same page.


The first aspect of the Preparation stage is determining your entry and exit criteria and use cases. Entry criteria defines the specific conditions that need to be in place for a successful test. That may be application- and configuration-specific, design-specific, or process-specific, like understanding how a recruiter will interact with a hiring manager. All of those things need to be defined as entry criteria. And then exit criteria, essentially, are the ways you’ll define completion and success for each cycle. For example, we accomplished 80% of our documented use cases, 90% of them have passed, and we only have three or four major issues.

Use cases are the specific instances you’re going to be testing for. This differs from traditional test scripts that you may have experienced in traditional ERP on-premise deployments. A test script tells you step by step what button to click, what employee to use, what screen to choose, etc. It’s an exhaustive and expensive exercise that typically also doesn’t give testers the freedom to test the exceptions. A use case is a scenario where, for example, if you change an employee from full time to part time, they shouldn’t be able to enroll in a benefit plan. It doesn’t tell you who to use or what button to push, but it asks you to make those decisions and validate the use case. This freedom of choice gives testers latitude and will also encourage a higher level of building Workday expertise.

Outside of use cases, data validation plays an important role in testing. Checking your employees and your configuration and setup to ensure the data is complete and accurate. A good deployment partner will bring data validation reports to the table along with a strong discipline around data conversion practices to support this exercise.

Finally, it’s important to nail down your logistics for how you’ll coordinate all the testing. For example, if you’re a global company, your unit testing may be more of a remote exercise with daily touchpoint calls. On the other hand, end-to-end testing may be more of a war room exercise where you fly people into a single location to facilitate testing.

All of this is important from a preparedness standpoint because it will help you understand how to maximize the testing cycle.


Now you get into the execution, or Performance. This comes down to sound issue tracking and resolution. You don’t want 30 people logging issues — especially the same issues — so if you do have numerous people testing, it’s important to identify your point people, and your processes for channeling issues to them. Usually that’s the core team; they’re the ones who are triaging and deciding if something is part of how the system was designed, if it is a training issue or if it’s a legit issue that needs to be logged and fixed.

Internal knowledge or a strong understanding of internal workings and processes is another important aspect of testing. Every organization has native knowledge somewhere, whether that’s regional or functional knowledge. So it’s critical to have the right people involved in this exercise. These people will know intricacies of policies and process that others may not. Of course, one thing we all struggle with is time and resources, because all these people typically have other full-time jobs and responsibilities. That said, getting people to allocate the time to participate in testing is critical.

Negative testing is worth paying attention to during your execution of testing. It is something that usually falls through the cracks because of time constraints. People are always so focused on testing what they can do in the system, but not as much on what they should not be able to do. A good testing cycle will cover both of these scenarios.

Case in point: One of the things that will be tested is making sure the system follows the correct process for giving people raises. But it’s likely that nobody is going in and seeing if they can give a raise to people they shouldn’t have access to, such as the CEO. That’s an example of negative testing.

Taking all this into consideration will ensure a successful testing process and, hopefully, a smooth go-live when it’s time to open up Workday to the entire organization.

Commercial Solutions Leader, IBM Workday Consulting Services

More Deployment stories

Four Things to Remember Before Starting Your Workday Financial Management Deployment

Your organization is growing quickly and you can no longer afford to have so many manual processes. Maybe your CFO needs more insight on the performance of the business. Or perhaps you’ve been on the same systems for 20–25 years, and they’re now outdated. Whatever the reason, it’s clear the time has come: You’ve decided […]

Continue reading

Four Ways Finance Leaders Can Take the Lead in Their Organizations

This is a guest blog post by Naved Qureshi, Associate Partner, Global Business Services, at IBM These days, many companies are facing digital disruption from sometimes nontraditional competitors or unconventional business models. For example, people don’t normally think of farm equipment manufactures as providing a customer experience or a service. However, by curating information through […]

Continue reading

5 Lessons Learned from Moving a Campus Information System to Workday

Colleges and universities are always looking to make the most of their often limited resources. One way to do that is to commit to constant learning and adjusting based on data and other information at your fingertips. In the case of a technology deployment, such as a move to Workday (especially when it’s a conversion […]

Continue reading