Testing - the first or last line of defence

Have you ever sat back and really thought about why and what you are testing for or when you should test? We are all told constantly how important it is to do testing, especially if you are doing a big change programme. However, many executives deep down disagree. After all, software does not break anymore, it is always just configuration to be done, so why spend time and effort on testing at all? Let us step back a moment to ponder. The question to ask is: Why are you implementing the software? The answer to the above should be the reason you are testing: To ensure you are getting what you need! It is not just about the system(s) working, it's about how they are working for you.

Here’s Problems Solved Top-10 tips on testing

1) Test your target benefits, right at the start of the programme, before moving forward! Getting this right is more important than anything you do later. So, test them!


2) Test your requirements; Are these the right requirements? Do they match with your target benefits? Is this the complete set? Will implementing these requirements break something else? Will they work for all stakeholders? When these questions are answered you are well on your way to success.
  
3) Test the unhappy path; Analysts & designers typically use 80+% of their time designing the happy path so you are unlikely to find much on that path, instead use 80+% of your testing effort on the unhappy path – when things do go wrong, they can easily go really wrong.

4) Go professional. Testing is one of the most underestimated and undervalued disciplines around, having one or more professional testers on your team increases the likelihood of finding the real issues very significantly. He/she will have the ability to think the unthinkable, has the test to break attitude, strong desire to quality and attention to details.
  
5) Ensure you do test your systems inhouse. Do not have the supplier(s) do it all. After all, we all tend to be oblivious to our own flaws, suppliers are no different. We do recommend doing nearly everything with a complete business focus, but technology can still fail. Don’t forget the integrations between systems and between products from different suppliers. Integrations and touchpoints are the most common point of significant failures.
  
6) User Acceptance Testing (UAT) is not about gaining user buy-in! The purpose of UAT is to test that you have achieved all your business side changes and are ready for go-live. Focus this testing on your processes not on the system. Sadly, on many projects, UAT is the first time real users are invited to be involved. Real user requirements and buy-in should be done at the start of the project with requirements gathering, leaving it to UAT is too late and will lead to failure.
  
7) Test your support structure; How is support going to work? Will it be ready when you need it? Test your support structure well ahead of go-live so you have time to remedy!

8) Test your training; Does the training cover everything it needs to? Are your people well enough trained at the end of it? Does the training unlock the benefits you targeted?
  
9) Test your go-live process; Have you thought of it all? Who has the keys to the warehouse when there is a power outage in the middle of the deployment? Do you have the right people awake to test that things really work, on all sites including your team in APAC, immediately after go-live? Test it!
  
10) Test your benefits realisation; do not just trust that you are or will get the benefits. Check by testing them and keep testing them until you reach your goal, sustainably. If you are not getting what you expected or wanted, take action! These are Problems solved tips for testing. Do you disagree? Is there something we should add? We welcome your comments. Let us know, we love to discuss and learn.

Glossary:
“Target benefits”: The benefits you are looking to get from your investment should be measurable

“Happy path”: The path through your systems & processes where everyone and everything does what it is supposed to do.

“Unhappy path”: The path through your systems & processes where people, or systems, does things they are not supposed to do.

“Real users": The people who will use the processes & systems after go-live.

“Support structure”: The tech people, trainers and superusers whose job it is to keep things running smoothly and the systems these people use.