No matter how experienced your project team, how diligent your developers, how thorough your clients in their own testing, you will never completely test your projects by yourselves.
The problem with testing your own work, or in the case of client testing, stuff they’ve been involved in, is that you will always — always — end up with preconceptions about how something will work.
Testing scripts will declare that you should be able to do action A or not go past page B without entering a valid email address. You’ll test your product to make sure that it does those things, and when you’re happy you tick them off and move on to the next test.
But chances are, you were expecting those things to happen in a certain way simply because you’ve talked about them for months, built clickable prototypes replicating that journey, and have recently make some changes to the project based on earlier testing.
You will have formed preconceptions about how something should work, and that will dictate how things are built, and how they are then tested. Stuff will, inevitably, slip through the net, no matter how thorough your testing, simply because of your prior knowledge of the requirements.
“External teams” are simply people who have no prior exposure to your project — they don’t need to be external to your company.
This is where external testing teams come in. They have no prior knowledge or expectations of your system, meaning they’ll be able to quickly highlight anything that doesn’t work, or simply doesn’t make sense. They’re not going to use the systems you’ve produced in the same ways you have been doing for the last few months; they’re not going to follow the user journeys you’ve been following.
With a bit of technical knowledge, they can test the things you’ve simply become blind to, like making sure authenticated content stays authenticated and that it can only be seen by the right people (you’d be surprised how often a simple ID change in the URL will reveal all manner of ‘private’ information).
The best thing is, “External teams” are simply people who have no prior exposure to your project — they don’t need to be external to your company. If you’re able to draft in people from another part of the business to take to your project with a fine toothed comb, then that will work just as well as bringing in a third party. Just make sure that they have little or no prior knowledge of the project they’re about to test, and that they are given the time and freedom required to be thorough and impartial with their testing.
With the complexity of modern projects, it’s all too easy for bugs to creep through into LIVE systems: pages that shouldn’t be accessible but are; errors when users take an unexpected route to a particular area of the site; buttons that lead no-where. With last minutes changes common, timelines tight and the simple fact that project blindness is unavoidable, you will miss something. Usually it’s small, sometimes it’s big, but it’s almost always solvable and the sooner you can find it and resolve it, the better.
There’s no shame in having a recognised, independent QA process, and your projects will always be better for it.