Heathrow’s T5 software testing issues have highlighted the importance of software testing, I hope that lessons have been learnt and that CIO’s across the world will take note in the future.

I believe that in the future will we see changes in 6 key areas of software testing:-

1.Accurate information provision (in the language of the recipient)

Software testing’s role is the provision of data to enable go live decisions to be made. If we get this information wrong, wrong decision will be made. If testing can’t provide the right information it actually adds little value.

Key to this is the understanding of what data is required. So many times I see that Test Managers have just produced what they think is right without asking, or even worse don’t understand the goals of the project so don’t know what data should be collected to indicate whether those goals have been achieved.

Test Management tools can help, but they are only as good as the way they are implemented. In a lot of cases this is straight out of the box, with no configuration or understanding of what is to be reported, with a view that the standard reports will be good enough! Test cases are then loaded and then it’s found that the right data is not available!

I believe the way forward for information provision is actually to learn something from the Agile world and start to work/talk to each other. Everyone’s requirement for information is different and so the closer projects work together and people mix the more we can understand and the closer we will be.

I think a software delivery project is much like an orchestra, if each part works together in harmony it can be beautiful, but if only one element works on its own the result will be disastrous. We need to work together so that the software delivery orchestra works, and delivers beautiful results.

2. Building quality in, rather than testing it out, prevention rather than detection

Traditionally software testing’s objective is seen as finding defects, whereas in reality it is a great way of preventing defects.

It continually amazes me how many clients I see who leave testing until the last possible minute. When will companies understand that the earlier a test team is involved, and of course the better trained they are, the more they will recognise problems early in the lifecycle enabling them to be resolved before they become execution defects?

What do I mean? Well, if you knew your back wall was going to fall down, would you wait until it did or do something to stop it falling. The same can be said for a software tester. If early enough in the lifecycle it is identified that elements of the software may fail would it not be better to stop it failing by some corrective action, rather than to leave it to fail and then checking it has!

What I am referring to hear is a risk based approach to testing, understanding what risks the product has at the earliest possible point and putting in place mitigating actions to lessen or completely remove the risk of failure.