Why is it some people find testing software so difficult and stressful? In this article, I will look at not only some areas of best practice but also the pitfalls.
Testing software implementations is a big thing! It’s important to get that out of the way. Too many times companies implementing new software treat it with a rather flippant and nonchalant attitude. It’s a big thing and deserves a great deal of focus and attention if you want to make your new software a success.
For now, let’s start at the beginning.
At some point, you have bought a system and you will have a contract and set of project documentation that states what you have bought and what its intentions are. Contracts, solution design documents and project initiation documents should all form the base of what you will eventually test. When you look at testing, you should always reference back to these. You are accepting what it is you have bought and agreed to. This is acceptance testing and is critical to the end-users accepting the system. However, it isn’t the only form of testing.
When you contracted with the supplier, you are expecting the software to carry out a purpose. If you sign-off a testing programme and have not referenced this, then you may have little recourse to say it doesn’t work after go-live. The supplier can easily say ‘but you signed off the testing’. Use the contract and the project documentation as a reference point and after testing, it can not only be your testing that is focused but it can also be used as a measurement of success. This is functional testing.
So, what is testing in reality? A common thought is that it’s all about user acceptance testing. It’s not.
One of the most basic forms of testing is unit testing. In a nutshell, it is functional testing at the software level and is typically done by developers. You may touch on this if you are building a system yourself but let’s hope you are not, and you trust the supplier to have done this.
I mentioned functional testing above, and this is very important to get right. Functions are tested by feeding them inputs or data and checking that the output is what you expect. As I said, it is where you reference design documents and the likes of specifications or more importantly contracts. Have you ever heard of the phrase “but that’s not what we wanted”? Exactly, so that’s why functional testing is one area to get absolutely right.
Integration testing… we certainly know that one of the most important areas in housing management systems is how they integrate and work with finance, repairs, asset management and many more systems. Integration testing is an aspect of testing in which individual standalone modules or other systems are tested as a group. The important thing about integration testing is that it leads naturally into systems testing.
Systems testing is another area that causes some stress in organisations. There is a good reason for this. It is usually done before thinking about the above integration testing. System testing naturally takes as a starting point all of the integrated components that have just been tested in relation to the integrations. System testing is performed on the entire system in the context of your specifications. See, it all comes back to the beginning.
A final concept in relation to systems testing is that, in my opinion, it’s the area that binds it all together.
The areas above certainly contain some jargon, but it’s really important to understand how it all fits together. If your project is deemed as mission critical to the business (and why would you do it if it wasn’t?), then it deserves a good understanding of the areas above. Consider the following:
- Does the system grind to a halt when you run a massive report or print job?
- Does it crash when you stretch its resources?
- Does it work effectively on the infrastructure you have provided it with?
- When you input something, do you get the expected outputs?
- Is it sluggish and/or will it frustrate end-users?
All of this brings me back to what most of you will be more used to and that’s user acceptance testing. UAT is what gets all the attention, and rightly so. In fact, if done properly, UAT can actually part-educate users on the depths of the system that you don’t perhaps see in training.
UAT is simply the last stage in your software testing process. During UAT, actual users who will end up using the software will have to look at real-life scenarios, according to not only what the software is expected to do from a specification perspective but also how they would go about their jobs. And let’s face it, if your users aren’t happy then it won’t be adopted by them and that leads to all sorts of woes.
Here’s a handy hint – well before you get to UAT, get users to do something like record everything they do on a daily, weekly or monthly basis on post-it notes as they go along. If you suddenly surprise users by asking them to all develop a testing script of their typical activities and actions, they will panic and you won’t capture everything, so do it as you go.
And before I forget, give yourself lots and lots of time to do all of your testing.
Now, what shouldn’t you do? I have listed five classic mistakes:
- Don’t underestimate the importance of testing. Lack of planning is a classic mistake and so is not providing enough resources. Think of testing from the start of your project; a mistake some people make is to leave testing too late, so plan early.
- Never assume that the supplier will test. That’s akin to buying a television and then getting the manufacturer to come into your house and tell you which programmes to watch to see if the television works – madness!
- Involve as many users as you need to during UAT; in general, the more the merrier.
- This might seem silly, but plan for rooms, plan for PCs, plan for mobile devices to be tested, plan for the infrastructure to be ready.
- Be creative: have events, hype it up and make it big!
David Loudon is the owner and managing director of DtL Creative. He is also the head of IT for Alliance Homes.
