How often does quality assurance come up in your HR team’s conversations?

The quick answer, from what I’m seeing: Not enough. I think that QA in HR transformation is fundamentally broken. Here’s what happened: Instead of using on-site, home-grown technology and solutions, most HR departments are moving to cloud-based, self-service platforms. While we used to diligently test internal HR systems, more HR departments are struggling to get through the testing phase of an implementation because their “day jobs” take priority. Besides, they think, don’t our HR SaaS vendors have us covered when times get rough?

The reality is that technology providers don’t supplement testing resources during testing for clients and rarely give the right estimates about how much time and effort it truly takes for a client to fully test the new functionality.

I think it’s time for organizations and HR leaders to re-examine how we approach QA in our transformation projects. Here’s what I think is driving the QA disconnect, why it matters and how we’ve worked through it with our clients.

QA Is Trapped in IT

QA historically is an IT function, but with the widespread adoption of cloud-based HR systems, why not consider a move of QA to the HR function? QA being trapped in IT causes a strain and sometimes a slowdown in retaining the necessary resources to complete the testing phase.

What we don’t see these days is HR taking on QA resources as part of a cloud implementation, and this is what I think is fundamentally broken in the process. There’s a disconnect. On one side you have QA sitting in IT, and on the other you have the business without any QA.

Whether you’re building or changing business processes, this side of your organization needs more QA, not less. The problem is that too often HR is unwilling or unable to spend money on QA.

Testing Is Incredibly Important

Don’t underestimate the time it takes to test major HR or payroll implementations. It’s always going to be difficult and take more time and effort than you expect. The reality is that providers don’t actually do the testing for you; they’ll give you a subset of test cases that you’ll have to personalize to test the functionality of your system.

I believe the key to any QA testing of your system is to use functional testers who can look at the process as it was designed by the project team. I suggest bringing them in as early as possible to make sure the system is intuitive and easy to use. When you have to train hundreds or thousands of people on how to use your new system, you can’t have a system that’s too complicated.

For past implementations we’ve brought in what we called “extended stakeholders.” For one retail client we brought in store directors to do some of the testing. They weren’t there to look at the functionality and say “Wouldn’t you want to do this instead?” Rather, they were testing the requirements that were detailed by the business to the provider.

For payroll implementations we do other types of testing as well. First we do functional end-to-end testing in which we move through the entire process in the new system. Then we do parallel testing, which involves running the same processes through both your current and new systems to compare the two and determine whether the new system is set up correctly.

These are vital but complicated, labor-intensive tests that require time and dedicated resources to perform correctly.

QA Needs Buy-In and Budget

I believe it’s really important to include QA in the business case for your implementation from the beginning. Plan to work functionally across multiple departments and pull in IT resources from the get-go. Include testing in your initial budget and timeline. Making plans for QA in the business case for your implementation up front will save you plenty of headaches.

I am looking for insight into how organizations have managed their implementations and testing phases. How have you made QA an integral part of your transformation process? Please comment, because I truly want to help organizations be better prepared for what’s to come with testing.