You only get so many chances to impress your clients (aka — the importance of Quality Assurance)

When it comes to keeping a client sweet, it’s not vital that you get everything right first time. It’s nice, certainly…but any reasonable person knows that nothing in life can be perfect all the time, that small mistakes are common place, and that what’s really important is how you deal with them.

That isn’t to say that they’ll put up with such service forever, however — there’s a fine line between ‘a few bugs and glitches’ and a poorly tested product that simply doesn’t work as it should. And once you’ve overstepped that line, it can be very hard indeed to get the confidence of your clients back.

The problem is, it’s easy to release something that’s buggy. With the best will in the world, you will simply never use a product of any kind in the same way that people will in the real world: Think of the billions that Apple spend on product design, yet they managed to miss the fact that when you held the iPhone4 in a reasonally normal manner, it would effectively short out the ariels, dramatically reducing signal strength. Ultimately, when you’re building something, you build it until you’re happy it works; but you don’t always think to see if it would work (or more to the point, if it doesn’t work) when you try to do the same thing in another way.

So, testing is vital, but even when you do a lot of it, you might not catch everything — in reality you almost certainly won’t. But that doesn’t matter, as long as what’s left is small and quickly remedied. What’s really important is that the bugs that make it through are few in number, and not demonstrable of a complete lack of attention to detail or process. This is where Quality Assurance comes in to play.

Quality Assurance is the process of ensuring that what you are working on is of a sufficient quality to meet your obligations and the expectations of your client. It’s the sanity check that you’re building the right thing, and that everything works as it should. Typos, missing error messages, unexpected navigation redirections, broken buttons: all things that quality assurance will pick up. A robust enough process will also highlight not just what isn’t working properly, but what is missing from what you agreed to build.

It’s something that should be done constantly by your teams, as they progress through the project towards completion — small problems quickly grow into insurmountable ones if not identified and dealt with early on. But equally, it’s something that is almost impossible to do purely using your internal teams: they have prior knowledge of how things should be working, and as long as it works in that manner, it will ‘pass’ their QA. Almost all bugs reported will be where a user simply tried to do something in a different way, and it didn’t work.

With that in mind, you need to make sure that the team who do your QA have not been working on your project, unless what they are testing is extremely measurable (a design team can test the application of brand guidelines, for example, as it is a very binary compliance — it either adheres to the guidelines or it does not, with no real middle ground to overlook).

That’s hard to resource, however: QA, as important is it is, is rarely given the budget it needs to do it properly — clients don’t always appreciate you charging to test the work you’ve recently built for them, on the (mistaken) belief that it should be of a high quality anyway, and thus not need such thorough testing. Given that even a small project will require a few days of testing, it can be something that ends up being rushed, overlooked or falling on the teams that built it in the first place.

This is where external Quality Assurance can help — you get the benefits of a dedicated QA resource, without the need to pay people when you’re not using them, and without the prior knowledge of your project that can so often lead to easily identified and fixed bugs being overlooked.

It will always seem like an unneeded cost in your project, regardless of if you resource it internally, where the cost is simply un-billable time, or you bring someone in to help you specifically, in which case you’ll have some outcosts associated with the job. But you only have to have one project where the client is unhappy, or you end up in a huge redevelopment mess caused by bugs introduced early in the project that are now much bigger to deal with than if they’d been remedied at the time before the time or money you should have spent on Quality Assurance seems tiny by comparison.

The worst part of a project going wrong is that it can almost always be mitigated by a robust quality assurance process, and whilst a lot of projects might have managed to get through the door without it — even if it does bring a few headaches along the way — the reality is, virtually everything you do would benefit from someone double-checking everything for you and making sure you only build things once, and that you only build what you’re supposed to build in the first place.