🎉 Congratulations to Terrence Cheung from the Met Museum, who won a FREE Workday Rising pass as part our testing survey prize draw! Also thanks to everyone else who took part!

Testing

Robust Payroll Testing for Your Workday Build & Beyond

Newsflash: Staff like getting paid. When they don’t, it can lead to an unhappy workforce. So how do you make sure your Workday Payroll will function accurately at launch, and that you've strong practices embedded that will see you through your own changes and Workday's updates in the future? Damien Taylor, our CTO, explains.

When you’re planning your Workday implementation, you want to cover all bases to ensure that your go-live is as smooth as possible. Everything feels important. But payroll is one of those areas of configuration where it’s crucial to be bulletproof. Right after go live, the last thing you need is the headache of inaccurate pay for your employees.

Here’s some advice on how to build solid confidence in your payroll configuration before roll out.

Understand the Impacts of Retro Payments

A retro payment is a payment to an employee that has resulted from a retro-active payroll event—essentially an event that has been back-dated (for example a hire, a compensation change). Workday Payroll provides really nice functionality when it comes to retro payments. However, you need to fully understand your requirements for retro and then ensure that these have been properly applied to your payroll configuration.

The only way to fully verify that your retro-active events will be processed correctly when you go live is to create and execute test scenarios. These tests are beneficial for two reasons: they help you validate that payroll is configured as expected, and they also help your payroll team understand retro better—because you don’t want your payroll team processing retro payments for the first time on a live payroll.

Ensure You Cover All Scenarios

Payroll testing is more than testing for one or two pay periods. Your payroll will span the entire year. So if you fall into the temptation of testing one or two periods, what are you going to miss?

Lots of companies have seasonal payments or earnings and deductions that are more common in some pay periods than others (for example temporary summer staff, annual bonuses, etc.). If you decide to test two specific pay periods and focus your parallel testing only on those pay periods, you need to be sure to have additional test scenarios to capture the less common transactions that happen in the other pay periods. If you don’t, it could be months before you spot issues with those seasonal transactions, and you’ll be spotting them in production instead of in the safety of you pre-live tenants.

So during implementation, we recommend that you review 12 months worth of legacy payroll to identify the pay components that are not common across all months. Then, build test scenarios to prove that these will work as expected. This will mean some of your test scenarios are for pay periods in the future. It’s more effort, but you don’t want to be testing these for the first time on live payroll.

Don’t Tackle Parallel Testing Too Soon

Don’t fool yourself into thinking you’re ready for parallel testing when you’re not.

Parallel testing should be a confirmation that your configuration is correct, not an initial investigation that your configuration is correct. You shouldn’t be uncovering major issues during this testing. The risk with jumping the gun on parallel is if you do find major issues, you’ll have to re-run parallel again and again. It’s important testing. But it’s also one of the most complex and difficult types of testing to do manually. Don’t put your team through it any more than is necessary. Instead:

  • make sure everything is thoroughly tested before you reach this stage; and
  • plan your unit testing to ensure you have good coverage of your pay components, testing eligibility, calculations, taxation, and payslips.

It’s important at this point to understand your pay component coverage. If you have a 100% pass rate but are only testing 10% of your pay components, you’re kidding yourself. So make sure that you comprehensively test all earnings and deductions.

For eligibility testing, it’s important to do both positive and negative testing. This is to make sure that the people who should get certain earnings and deduction do, and that people who shouldn’t don’t. Time and resourcing constraints often lead testing teams to focus only on the happy paths—those scenarios that validate that people they expect to get an earning or deduction actually do. However, negative tests are crucial for ensuring employees aren’t getting anything they shouldn’t.

Next up is end-to-end testing. This covers a range of scenarios including making sure that a new hire ends up on payroll, and that any inbound integrations that impact payroll, (e.g. third party time tracking) all work as expected.

Your organisation will know best what scenarios to run through, but on a high level we recommend testing everything that you know will impact payroll, testing boundaries, or threshold—for example start, middle, and end-of-month hires. For hire, you might want at least three tests to cover each scenario, and depending on the complexity of your business, you may need to extend coverage for different countries, departments etc.

Regression Test

Don’t assume that a test that previously passed will still pass after you’ve made configuration changes. Imagine that:

  • you have a pay component that is working as expected for 80 out of a carefully selected 100 workers; and
  • configuration changes are required to fix this for the remaining 20 workers.

The modifications you make to fix the configuration for the 20 workers could inadvertently impact some of the 80 that were previously fine. Run the full 100 tests again, fix any bugs, and repeat as many times as necessary. It’s time consuming, but it’s also best practice and the only way to gain full confidence in your configuration’s functionality.

Mini-Parallel Test

Even with comprehensive unit testing completed, you don’t need to jump straight into parallel. It‘s time consuming, labour intensive and requires your valuable payroll SMEs’ time. A safer, more efficient approach is to run mini parallel. It’s also easier to validate and much more repeatable should something go wrong.

Mini-parallel involves a carefully selected, small subset of your workforce. A well selelcted subset of workers that represent a cross-section of your workforce will be a really effective proxy for full parallel testing. If the mini-parallel is successful, that’s your green light to proceed with full parallel testing.

If you follow these recommendations, you’ll be able to build a payroll test strategy that’ll give you confidence with your Workday Payroll at go live and beyond. This may seem like a lot of effort, and it will be if you decide to do it manually. But remember that any bugs that you don’t catch pre-launch will undoubtedly be found in live payroll and need to be corrected. The question is, when would your employees want you to find them?

Like what you see?

Leave us your details and we'll send you useful Workday-related content like this straight to your inbox.

Sign me up!