Moving to a More Mature Testing Process

Date posted
23 August 2017
Reading time
7 Minutes
Shelly Wilson

Moving to a More Mature Testing Process

We recently posted this useful 5-tier scale for gauging how mature your company 's Workday testing capability and approach currently is. Here, we elaborate a little on what Level 2 of the maturity progression looks, especially during a Workday update. At first glance it might seem like a less ambitious target on the scale, but for those of you currently sitting at Level 1, achieving Level 2 will be a massive improvement and will give you confidence that you 're testing in a more organised and effective manner. To get there, you need a few keys components:

  • A test strategy
  • A new feature update test plan
  • A regression test plan
  • Clearly defined roles and responsibilities
  • A schedule
  • Tools.

A Test Strategy

This defines exactly what you plan to do when it comes to testing your configuration. Take a look at our article on testing strategy for specific pointers. It 's also important to include entry and exit criteria in your strategy. (In other words, how do you know when to start testing, and how will you know when you 're finished testing?).

A New Feature Update Testing Plan

Everybody 's use of Workday is unique. Some of you are using every Workday module, others only a few. The only way to understand the benefits of the new functionality is to explore the changes in detail and then test. So look at what 's changing in the Workday update, look at what you need to test, and decide what you must test in more detail than other areas. Then prioritise the latter in case you run out of time or resources. This way you 'll have covered the highest priorities effectively.

Regression Testing Plan

These tests focus on a prioritised cross-section of the most critical Workday components that you currently use and leverage. They're essential to provide you with confidence that changes introduced as part of the new Workday release don 't have any unexpected side effects.

Roles & Responsibilities

Which staff will be involved in testing, and exactly who will be responsible for what? For example:

  • Who 's going to be doing the feature update testing?
  • Who 's responsible for the regression testing? Is that one team, or are you creating sub-teams to focus on security testing, integrations testing, and BP testing in each functional area?
  • Who 's responsible for fixing problems and breaks you encounter and testing the fixes?
Identify which staff are leading each plan and the supporting resources that are required. Whenever possible, make sure the people who did testing last time can be involved again. If that 's not possible because they 're on holiday or no longer with company, find suitable replacements for them.

Test schedule

When are you going to test what? For example in the 5-week Workday update preview window, you may want different test events to take place at different times. Timing might be based on priorities, staff availability, or the needs of sequential tests. However, we suggest starting Week 1 with Security, Reporting & Integrations testing.(Read this post to find out why)

Test tools

Are you going to have scripted test cases? How are you going to manage those? If you find any issues, how are you going to report on those? If you want to use automation to test your tenants, how are you going to use that to work most efficiently during the Workday update window? Moving up to Level 2 takes planning, effort and organisation, but the benefits are worth it: confidence that the quality of your testing is more thorough and consistent, peace of mind in the integrity of your Workday system, and happy end-users who get to work with a system they can count on.

About the author

Shelly Wilson