Your guide to testing in IFS projects – and how to get it right

Wouldn’t it be wonderful if you could simply plug in your new IFS ERP system and everything worked perfectly?

Sorry to disappoint, but that’s never likely to happen in the real-world of complex software projects.

And that’s why testing is a key part of any successful IFS implementation or upgrade.

After all, you wouldn’t buy a car without going for a test drive. It’s the same for IFS projects.

In this guide, independent ERP consultant Caroline Capper shares everything she’s learned about testing in IFS projects from 17 years working with the application.

Find out:

• Why testing is critical to IFS project success
• How to do it
• What can happen when you don’t get it right
• What she’s learned about the best way to do testing

Why testing is important in IFS projects

When you buy an ERP system, it isn’t “out of the box”, no matter what a salesperson tells you. Everything must be configured for your business, because every organisation – even those in the same industry – is run in a different way. So, every single ERP system will end up being different. And that bespoke nature is why you need test cycles, to make sure the system works for you.

But there’s more to it than just testing the configuration. Another factor is data, as ERP systems are data hungry. You load them with all kinds of stuff, like suppliers, part numbers and purchase orders. Think of every single transaction your business might do; you must pump that data into your ERP system, often from a legacy system. And you have to test if your data works with your new, configured system.

Respond to changing requirements

ERP systems are often put into companies that are growing, and those businesses can change quickly. They might enter new markets and deal with different kinds of customers, and that all brings about new business processes.

Plus, companies can be quite “green” when they enter an ERP implementation. They’ll tell themselves, “We’ll do it like this because we’ve always done it like that.” But as they go through the implementation journey, they realise the software is actually much more powerful. They can do things in a much smarter way, and so their mindset might change – and that means the system must evolve.

Also, your business might have departmental silos, so when you put an ERP system in, all of sudden you must join those inter-departmental processes together. That always flushes out new ways of working, because in an ERP environment you’re dependent on the processes that happened before you for your part to work.

All of this contributes to the need for extensive testing.

From scraps of paper to digital

Take an installation engineer as an example. Previously, they might have hopped in their van with a bit of paper telling them what they needed to do. They’d write down what they did, any components they’d used and how long it took. Then someone in the office would have done a spreadsheet of this and sent it to the customer, updated their stock records and handed it to finance. And then somebody in finance would have put it in a filing system and book it in the accounts.

Now, that engineer can go on a mobile device and somebody will have dispatched a work order, and they’ve got to record what time they started, what time they finished, what parts they used, etc. That engineer’s job has changed because now they must record all that information on a mobile device.

The human interaction with your ERP system always presents issues, so again this needs to be tested.

You can’t just “plug and play”

Everyone’s data is different, so the information your business captures about a customer is different from what another company would capture.

You might have, say, 20 pieces of data you need. So, when you’re testing, you must make sure those 20 fields are populated – and populated in the correct way. And that will be different for every single business, which is why you can’t just “plug and play”. You must test everything.

What happens when testing gets overlooked?

People can very easily underestimate the effort involved in testing. And while it very rarely gets completely overlooked, its importance is definitely underestimated. That’s probably because the task of testing all those different processes can seem daunting.

But it’s a fact that nothing ever simply works first time. There’s always some little problem or something that needs sorting out. So, you need to test, then fix, and then test again.

You normally end up with a number of iterations. In other words, you must keep repeating the process. You might get to a point where the system is 90% there, so you can go live because you know you can handle the 10% of issues. It’s about making that judgement on how much testing you need to be confident you can run your system without serious problems.

A lot of businesses who implement ERP systems don’t always grasp there are several iterations in the testing.

There’s no such thing as “perfect” in ERP implementations

I don’t think I’ve ever been involved in a project where there have been no test issues at go-live. But if the issue isn’t business critical, you can go live with that problem and then sort it out afterwards. You can only delay going live for so long. There will always be some scenario you hadn’t thought about and therefore hadn’t tested, and if it crops up after go-live, you just have to firefight there and then.

What else can happen if testing isn’t carried out correctly?

If you don’t do adequate testing, you basically switch the system on and enter this complete world of unknown. You could be massively lucky and find everything works perfectly – but the chances of that are slim.

The more likely scenario is the consequences are pretty catastrophic. A user might find every time they sit down to use the shiny new ERP system that something doesn’t work. So, they choose not to use it because they don’t have faith in it, and they go back to their old systems or write things down. What you end up with is an unusable new system.

But that’s the worst-case scenario.

There are shades of grey with this. For example, the system might work perfectly in one area, but not so great in another.

But the more testing you do, the fewer issues you’ll have at go-live.

How to carry out testing in IFS projects

IFS has an approved implementation methodology. It’s a structured approach to ensure the success of projects.

With this, the two test phases are: application solution test and user acceptance testing.

Each of those phases might need to be repeated, depending on how the testing goes, the complexity of the project and how many new problems come up. It’s normal for the testing to be repeated two or three times, but some projects might need more iterations. However, on a smaller project you might not need to repeat the testing. It’s different for every business.

Application solution test (AST)

This is the first phase of testing. It’s where you discover if your configured application does what you expected it to. The testing normally involves running a process from start to finish, for example placing a purchase order through to paying a supplier’s invoice.

User acceptance testing (UAT)

This is the next stage. It’s where we allocate permission sets to people.

User acceptance testing aims to mimic the real-life world, where a particular user only has access to what they’re supposed to have access to. That user will have their training material and the data that’s been loaded from the old systems. You test how they perform their job in the new system on a typical day.

Is testing different in IFS Cloud?

It’s the same methodology as earlier versions of IFS, it’s just the software that is different. But once you’re in Cloud, you don’t have the upgrade scenario you would have had when moving from earlier versions.

For example, when you upgrade from Apps 8 or 10 into Cloud, there’s a huge testing emphasis. That’s because you’re effectively applying mass code changes and data changes and moving to different environments.

Whereas after you’ve moved to Cloud, instead of a “big bang” upgrade approach, you’ll have two annual releases, which means the testing burden is much lower.

Who is responsible for testing?

It’s normally owned by your business and your team.

The project team would normally have a subject matter expert or a superuser from each area of the company. And they’d be responsible for testing the system to make sure it works in line with your requirements.

Consultants can create test plans but the testing itself is really down to your business. That’s because a consultant, with all the will in the world, doesn’t live and breathe the users’ jobs.

How can consultants support in the testing phases?

The testing usually starts with supervised testing sessions, where the consultant and the business are together. Your company will do its processes, maybe with some guidance from the consultant.

And if the testing highlights an issue, the consultant can resolve the problem and your business can then retest. This is also a good opportunity for your people to learn how to operate the system.

Set aside enough time for testing

In my experience, businesses don’t allocate enough time for testing. It’s always underestimated. Testing and training are normally the areas that suffer and get their budgets cut when there’s pressure to get something live. And that’s dangerous.

You’re better off going live with a system you’re confident will work, even if it’s a bit later than you’d planned. You don’t want to just ram something in that you haven’t had time to really test.

And it’s not just about factoring in time for testing. You’ll also need time for the rework and retesting. So, if you test something and find it’s broken, you’ll need to fix it and then test again.

Unstructured testing is also useful

Unstructured testing is when a user dips into the system to try different scenarios – and this type of testing is very valuable.

It’s great if your people can go into the system and do as much as they can, because repetition is where the learning happens. So, the more a process is repeated, the easier and more familiar it becomes for the user.

When should testing happen?

Normally you’d start your first round of testing after the solution sign-off. And the testing usually happens in parallel with other things, like writing reports, deciding which permission sets people need, and creating KPI reports.

The best way to test in IFS implementations

ERP systems are integrated, so each user’s processes relate to someone else’s.

The best way of testing I’ve seen is where people from each different discipline get in a room together and test together by doing all their processes in sequence.

Take purchasing as an example, the steps might be:

1. Someone raises a purchase order

2. Someone else books the stock in

3. Manufacturing makes the product

4. The supplier sends their invoice

5. Someone in finance processes the invoice

The above are all different departments, doing different things – but they’re dependent on each other.

This integrated approach needs a high level of dedication because you need to take several of your users away from BAE to test together. But it’s worth the commitment because it will help you complete your testing faster and more efficiently.

But if your users aren’t in a room together, the testing becomes more disjointed and slower.

What else do you need to know?

You should make records of the issues that come out of testing. You’ll need some kind of tracking tool or a database where you can capture the issues and make sure they’re assigned and prioritised. The problems can then be worked through and resolved.

Help with your IFS project

For a chat about getting your software implementation right, meet with our IFS Business Consulting Manager, Oscar Spence, below.