When I am in client meetings, a comment often comes out of a project manager's or product manager's mouth along the lines of, 'I don't know whether it is better not knowing about problems or to find a whole bunch of issues'.
My response to this is always the same and is really the reason for having a QA person around - it is much better to know about issues, large or small, important or trivial. Finding, diagnosing and investigating problems with your website or mobile app allows you to plan what to fix and when to fix it. It allows you to get ahead of any problems there might be.
The alternative, not knowing, means that any problems are going to hit you when you are just about to launch or are going to come via a customer or a stakeholder. This means that the issues straightaway have a much greater impact.
There can be a tendency by some to put their head in the sand when it comes to QA. It is because, for project managers especially, carrying out testing and reporting a lot of issues can cause them a headache, especially if it is late on in the project. There will be budget concerns with additional work needed, the possibility of missing a key launch date or milestone, which could mean disgruntled project stakeholders.
The repercussions for not testing, however, are far greater.
Once the testing has been done, any issues found can be decided upon in terms of their priority and estimated time to fix before being planned in. If a project absolutely has to launch on time then the most imperative issues can be focused on with the remainder put into the backlog.
So whilst everyone can hope there are no issues, it is better to have a dedicated and independent person or team carry out the QA and report back as to what issues are actually present.
