QA is NOT an afterthought - it should be an essential part of every step of the project
Imagine this purely hypothetical scenario. You're a phone developer... you develop a new handset, you spend millions researching and developing the hardware and software, millions more on marketing and bringing it to market. How embarassing would it be if you then found that the phone you spent so much on bringing to market didn't make phonecalls reliably? No doubt people would laugh at you, your company reputation would be damaged. Fortunately this is hypothetical and has never happened.
If QA is considered from the very start of a project then the dedicated QA team can ensure that what is delivered at the end matches the requirements set out at the start. The requirement "must make phonecalls" will be tested by the QA team all the way through from the initial design (does the phone sit in your hand, is it comfortable for a phonecall?) to technical specification (are we including technology that lets you make phonecalls) to delivery (we've built the phone, does it work - yes it does). If QA is an afterthough then you might have spent millions on design, research, specification, building prototypes, etc to only find that money has been wasted because your phone doesn't make phonecalls... if a QA team was involved from the start then at everystage they can ask - has this phase of work done what it's supposed to, is this a quality bit of kit, has this been done right?
QA is NOT only for big projects.
Why would QA not apply to small projects. QA means you only output quality work - if you skip it for smaller projects, even a tiny banner or minor copy change, then you still risk that those tiny bits of work could be crap (lack quality)... QA EVERYTHING.
QA does NOT mean purely technical testing.
Testing that a website works doesn't just mean do the buttons go to the right place. A proper QA will ask - do the designs match those signed off? Is the architecture of the site fit for the user? Does the copy have any typo's? Is the content in the right place? Can the server handle the expected number of users? Does the code meet standards (e.g. accessibility)? Does it match the functional and technical spec? Have we overspent?
QA can be carried out by anyone... but it shouldn't be you QA'ing your own work
It's true that bigger pieces of work benefit from a dedicated QA team - but smaller bits of work (or agencies without a dedicated QA team) might not need this. The main thing is - make sure someone has understood the brief, reviewed the work and signed it off.
QA is systematic
QA should be thought out - another reason QA should be considered from inception is it is time-consuming and costs money. It takes awhile to understand requirements, write systematic test plans, understand test requirements (do I need automatic scripts, what should I test on, etc).
QA is not money down the drain
Making sure you test everything seems obvious. If something lacks quality then it devalues the end user experience of the product. If something is worth doing then do it right; you'll save a fortune if you take the time to always get things right.
