Welcome to my first blog! In this series, I will answer questions relating to People Tech, a topic which HR professionals may not want to ask about for fear of getting answers that are “too technical”. My role at Phase 3 is very much to bridge the gap between HR and Technology, so if you have any questions regarding your People Tech please do feel free to get in touch and ask away in confidence. For my first blog, I have chosen to think about the subject of System Testing.
What are the different types of System Testing?
If we’re talking about the implementation of a new system, we’d start off with User Acceptance Testing (UAT). When you build a system, you should test that the configuration works against the design document. Within this, you’re going to go through various work scenarios and testing the quality of the build to ensure that it is configured as expected. Then you move on to the next stage where Actual Users test theirs (for example, looking at payroll calculations and seeing if they are working and that the system behaves how you want it to). When errors occur (and they will!) you go to regression testing to go back, fix and re-test.
In my opinion, configuration consultants should check the system but not do the testing as well since that would be a bit like a pupil marking their own homework! The consultant has built the system how they believe to have been asked, so you can ask your consultant to show you how to test but somebody else really needs to actually do the testing. If you have signed up to the Phase 3 – 12 Step Series to Successful HR Tech Projects you can find a test template available for you to use.
Extracting Data from Legacy Systems and transforming into migration templates – how does this work and what do we test here?
So, you need to know if you can extract that data (Data Migration – a job in itself) and what the quality of that data is. You need to understand this first. You must prepare for the extract before you even think of the upload and, if you have an old system, understand if it is actually possible to get that information. If your organisation is small it might be that you can enter the data right into the front end as a manual process (which can help to get users familiar with using your system). If you are a larger business and are likely to have to load a large amount of data in the future (such as TUPEs, company acquisitions etc.) it’s worth spending this time to learn how to load data.
You could also hold the data somewhere in the middle (such as in an Access database or Excel spreadsheet) ready to format into the right template to load into the new system.
Your new supplier will have a standard format for what their system needs in order for you to upload the data to it. This will be in a document such as a spreadsheet. Some suppliers might show you what to put in each of the data fields whilst others require the support of a consultant as they are significantly harder to figure out. A basic example might be D.O.B. format – your current system might hold this as DD/MM/YY but the new one might hold this only as MM/DD/YYYY.
How is best to test? Should we use dummy data or real life data?
If you get a dummy data set, it’s very likely to be perfect!! You might create Disney World as your organisation and your staff are Mickey Mouse and Minnie Mouse but it won’t be a true reflection of what’s happening. If you’re doing a simple test to see if a workflow is firing then dummy data will be okay. However, when testing your configuration work, you need to use Live Data to check your system is working and to make sure your files are formatted in a way the new system will accept.
We recommend that you build your system in a LIVE environment and copy this to a ‘Sandbox Environment’ (Sandbox – i.e. where you can play!) and test there. Iron out issues with data load, take out unnecessary things and then you’re testing in your real build.
We have seen people build in TEST and it works. Then they build again in LIVE, but decide to make a tweak … and discover that it doesn’t work, leaving them without an understanding of what has gone wrong! Keep building and testing until LIVE works as it should do.
What environment should we test in? Sandbox or LIVE?
You can build it in LIVE and not switch on and test it in TEST to see if it works before you switch it on for real.
Phase 3 recommend (if it’s feasible with a large system) that you have LIVE, short term TEST for upgrades and then longer term test (e.g. DEV) for longer term developments. This can seem like a lot of different versions of things. So, each time you upgrade it’s in TEST only. DEV is an environment only switched over when everyone agrees on it. This will stop you from losing work if you have a third party (or are hosted) upgrading your system. You know your DEV is safe and will only be changed when agreed upon.
If you only have the 2 environments, it is common for people to lose development work after upgrades, so you could upgrade straight to LIVE and don’t touch TEST.
Should we check configuration before Data goes in?
Yes! It does depend on the type of implementation. If it’s brand new, you won’t have anyone to test it against, so that’s when you’d use your ‘Micky Mouse’ people. In terms of data, the biggest tests for payroll data would be the parallel run. If much of the data is missing it indicates there is a problem, but you need to identify whether it is a configuration issue or a calculation that’s not working. Therefore, test beforehand and test afterwards.
Who should do the testing?
Think of a full ERP system, even an integrated Payroll and HR system with Payroll, Finance and HR. One person cannot possibly know the whole process. Therefore, if you’re designing processes it wouldn’t be very solid having a System Administrator testing the process using their own system administrator access. You’d have to do it via all the different access roles, e.g. Manager, Department Head and so on. It might be better for the big testing piece to have a conveyer belt of people doing each part of their process to see if it works and pass the information through as you normally would. It’s better to have real data, real life scenarios (e.g. a story) and the real life people doing all of the testing to get the truest view of how things are working.
An important note here is that you should make sure that testing really is testing. Often, you get to the testing stage and people start to ask for things to be configured or processed slightly differently. You need to have strong change control here, otherwise the process gets swamped with multiple change requests (e.g. ‘we don’t like that colour’) not all of which gets actioned.
How can we test multiple modules and how they impact each other?
End-to-end tests come in here. For a go-live you might not have each module implemented yet, so make sure your consultant knows your business and your desired end result – for example, what the payroll considerations are. Don’t be too modular and remember who can feed into this process from your supplier to ensure the build is rounded to meet all needs when working across modules.
How do you write a test script?
We see this bit as some fun! Write a story about a person in your organisation, for example “Joan starts work in a care home and has her probation extended. A few weeks in, Joan gets punched by a patient and goes off sick…”. In these scenarios, you have HR thinking about their roles and payroll thinking about sick payments for that person, so everyone is looking at their own specific areas. A generic script will test all scenarios. Also test here that your users have had sufficient training and know how to use the system.
When do we switch on after all the testing is complete?
This decision should be made by the Board. A subject expert from each area can make the go/no go decision. Never underestimate the importance of testing. When your system goes live, it will be a reflection of the HR function.
