6 Questions to Ask Before You Begin Testing Workday

June 22, 2017 Appirio

By Anthony Wang

Welcome to Appirio’s Workday blog series. Where we explore how we enable the Worker Experience for more engaged, productive, and agile workers through the implementation and use of cloud technology. Today’s workers are looking for a top-notch, consumer-grade experience — from the moment they onboard until their first performance review and beyond.

You’ve gone going through your Workday design sessions and explained your business to the consultants. You’ve also extracted mountains of data from your legacy systems — all while doing your day job. Now it’s time to sit back and relax, right? Maybe just a little, but then we’ve got to get ready for testing! Testing is one of the most important parts of a Workday deployment. It is an opportunity for you and your team to get into Workday and see if it does what you want. However, this part of a deployment is sometimes overlooked and underestimated in terms of time, people, and the effort it takes to successfully test a Workday deployment.

Below are six questions to ask before your initial Workday deployment:

1. Who is your testing champion?

On Workday deployments, testing phases and activities can take nearly 50 percent of the project timeline, and it is so critical for clients to test. Who wants to be responsible for a wrong paycheck or broken recruiting process when you go live?

The QA/Testing lead is a unique and independent role on Workday deployments. This person will drive the overall testing efforts, from creating a test plan to managing testers and tracking defect metrics. They should be involved from the beginning, and are like a psuedo project manager, collaborating across all the different workstreams, making test schedules, and ensuring everyone’s on track with the test plan. Although it may work on smaller projects, the QA/Testing lead shouldn’t be your HCM lead, nor should it be a project manager taking on additional responsibility — there are too many crucial activities that need priority and attention. Testing is not an add-on; it needs it’s own champion and focus on a Workday deployment.

2. Who should you involve in testing? (What about John Doe from the Indianapolis office?)

It depends on where you are in the project and what their role is. The people you involve in testing is another critical clement on a project’s success. When clients begin testing for the first time, I strongly recommend they keep the group focused to just the core team. This is like inviting friends and family over to a new restaurant opening. You want to work out the kinks, resolve issues, revise design decisions, and learn what does and doesn’t work. The same notion applies to getting into a new system like Workday. You may find that your Hire business process doesn’t need three extra approvals. This is just one of many possible changes that occur when testing Workday for the first time. Having a smaller group allows your super users (the core team) time to learn the system and also make configuration decisions faster. If you bring in too many people too early in the project, it could lead to frustration in learning the new system when everyone — including the core team — is trying to figure out Workday, and slower decision-making on configuration changes, as people may have strong opinions on certain areas. This could result in starting off on the wrong foot and lower adoption of the new system. For subsequent testing phases (e.g., End-to-End) you can include people from outside the project team, such as managers or HR colleagues in the field. The new users will be able to provide another perspective on the configuration and you will have the added benefit of the core team knowing the system and teaching new users.

3. Have we tested this? Where do I log a defect?

At the beginning of the project, the QA/Test Lead should identify tools and processes for tracking testing progress and issues. These metrics will be help you gauge the quality of the Workday system and see if there are areas that need attention because of low testing participation or a high number of defects.

It is also important that users know how to use these tools and understand the processes. For example, at Appirio we offer Cloud Management Center (CMC), which can be used for defect management. We offer training on how to use CMC as well as the defect process. Similar training should occur with other tools and processes. A defect process should be well defined and communicated, so people know how to log, report, escalate and close issues. Below is an example flowchart. You don’t want people asking where to report an issue or who they should ask to escalate.

4. Should we bring the team together for testing?

Testing takes more time than you may think, but many times I see clients not doing enough. It’s integral to test early, often, and together. There are a few proven ways to help facilitate testing:

  • Have a dedicated room or area for Workday project activities like testing. This allows team members to stay focused on Workday and avoid workplace distractions.
  • Block off time on people’s calendars and get them to work together in the same location. This builds accountability and allows people to collaborate cross-functionally on Workday and ask each other questions.
  • Regular check-ins with consultants to get questions answered, defect statuses, and review timeline.

Finding issues early-on in testing is the least expensive way to improve the quality of your Workday deployment. When you’re in the middle of payroll parallel, you want to spend the limited time you have doing comparisons instead of fixing an earning. If the earning had been tested and resolved earlier, then you wouldn’t be spending time and effort fixing it while under the pressure of finishing a parallel payroll in a tight project timeline.

5. What tests do I need?

Although Workday provides test scenarios for the various modules, they are generic and need to be customized to your business requirements. One way to do this is to follow these five steps:

  1. Brainstorm test variables for business processes and configuration.
  2. Review your design decisions and business requirements for additional test variables.
  3. With the test variables you’ve come up, review the Workday generic tests and customize them to your requirements.
  4. Come up with Expected Results. (What should happen from the test?)
  5. Identify test data to use. (Who your testers will use to test.)

6. When should I train my testers?

Sending the core team to training prior to testing has been beneficial to the projects I’ve worked on. They have a better understanding of Workday terminology and navigation. As a result, they can spend more time working out the kinks of the system rather than learning how to navigate Workday. Earlier in my post, I recommended that the first testing phase be limited to the core team. After the first testing phase, the core team should have a good understanding of Workday (and the configuration), and should be able to teach and help new testers who participate in later testing phases. Additionally, the core team can collaborate with a change management and/or training team to develop training materials, sessions, and strategy around adopting Workday company-wide.

At the end of the day, the purpose of testing is to make sure the Worker Experience is optimal. Spending that extra time and attention to testing your Workday deployment will mitigate post production issues with HR processes, people getting paid correctly, taking time off, etc. — things that employees expect to work seamlessly. If someone doesn’t get paid correctly or a new hire can’t get into the system, that distracts them from their daily job and adds more work for everyone. At Appirio, we offer three services: 1) Test Advisory, 2) Test Coordination, and 3) Test Execution to ensure a quality Workday deployment and an optimal Worker Experience. Please feel free to reach out to us if you need help or advice on Workday Quality Assurance and Testing.

Previous Article
Parameterized Reports for Objects and their Related Records from Custom Buttons in Salesforce
Parameterized Reports for Objects and their Related Records from Custom Buttons in Salesforce

By Vikas Menon Here’s the scenario: A user wants to see the open activities of a particular account, and ot...

Next Article
The Best Way To Sort Date And Date/Time Columns in Data Tables
The Best Way To Sort Date And Date/Time Columns in Data Tables