The Money Files

I have lost count of the number of times my project testing phase has been squeezed. When you are up against a deadline, your carefully planned 3-rounds of testing with time for bug fixes and validation suddenly slide out the door.

And yet, no one wants to put out a product that hasn’t been robustly tested. That’s just asking for trouble from the customer. I know iterative methods allow for rounds of improvements, but they should be functional, incremental improvements, not fixing bugs you let slip through because the testing wasn’t good, or long, enough. That’s my view, anyway.

It is tricky to schedule time for testing, because you don’t know what you’ll find. Perhaps the solution is so brilliantly coded that nothing buggy will be found. (Ha!) I think this is where some of the pressure comes from: sometimes managers disconnected from the process of creating something new feel that as each component of the software works fine, together the whole will work just perfectly. “If the build has been good enough, there won’t be much to fix.” If only.

Testing goes beyond simply making sure the code is good enough. We test the processes, integration, training materials, communication approach and more. Here are 5 quick tips that I’ve picked up over the years for testing. Perhaps they will be helpful to you too.

1. Keep notes

I know, keeping a note of exactly what you pressed and what happened is boring. Users don’t always understand the rationale of following the script and noting down what happened. Detailed notes help other people replicate the error so they can see it, understand it and fix it.

Get into the habit of documenting everything. You’ll be grateful later.

2. Try to break it

This is the part of testing I enjoy the most! And it kind of contradicts with following the script – except you should have test scripts for trying to break the product too.

Encourage testers to do things in the wrong order, use the product incorrectly and see what happens. You need to make sure it is adequately developed to deal with those use cases ‘in the wild’ as well as for the users who have read the instruction manual!

3. Test with real users

Talking of users reading the instruction manual, ideally testing should be done with the involvement of users. I have been on projects where testing has been done by a professional test team, in our test lab. That was great. The level of detail and accuracy and information provided was awesome and elevated our confidence in the product. Testers are brilliant.

But you should also involve some end users. They may find the test process regimented and a bit difficult to get on with, but a little training should help with that. That community will provide a different insight into how the product works and can give you feedback on usability and process that a testing professional might not know, not being an expert in their job function with the wider business context around that.

4. Test what you can’t see

A lot of testing in my experience has been around what buttons do on the screen, functionality, do you get the data you expect. But when working with professional testers (as opposed to subject matter experts and team members we’ve drafted in to help check the software meets their requirements) they have always focused on what you can’t see as well.

Those are the non-functional requirements. Does it meet the company security guidelines? Is it fast? Can we back it up and do those back ups work? You should have non-functional requirements in the product spec or as use cases, so make sure the testing doesn’t overlook those.

5. Plan the testing

Finally, and I know it sounds obvious, but all of those things above should be in a test plan. Sometimes the test team has written this on my projects, sometimes I’ve had to write it (and probably didn’t do that great a job). But whatever you do, to whatever level of quality, the important thing is that a test plan exists so you have some idea of what is expected, who is going to do it, what you are looking for and how the test results will be fed back to the people who can make the improvements.

Make sure a test plan is included in your overall project plan, and if you aren’t sure how to put one together, get some support from people who have done it before.

I’m not a tester, so I’m sure there is more to it than what I’ve written above from the point of view of a project manager. What would you add? Leave a comment below to tell me!

The testing phase of a project is the time, in my experience, that the schedule gets squeezed. I’ve been on projects with an ‘official’ testing team made up of experienced, trained testers, and also worked on projects where the testing has been done by me. Yep. Not great. In most cases, it’s been somewhere in between, and often I’ve ended up training users in how to test so they can join the ranks of project team members helping squash bugs.

The infographic below shows 5 things to think about when preparing the testing part of a project:

Use a test plan (sounds obvious, but it’s extra – often unwelcome – documentation that is resisted)

Include non-functional tests – because it’s not all about the stuff your users will be doing with the product, but also about security, scalability, data protection and more

Test to the point of breaking – just because you use the product in the way it has been designed doesn’t mean users will. Test the ‘wrong’ way to use it and see what happens

Get users involved – obviously

Keep records – because trying to remember exactly what steps you took to get a bug, so you can replicate what you did and see if the bug is now fixed… that’s no fun, trust me!