Testing Cliches

Surfing Google News to see what the latest developments on the testing front were, I found this article about a static analysis tool.

It sounded like an interesting, useful and cool tool but sadly the article said things like

"Klocwork [Insight's] static analysis takes the runtime burden away from engineering and QA,"

and

"However, if engineers are able to see and fix their own code, they are able to
preclude that defect from ever being seen by QA or customers. "

Surely the use of such a tool is part of a QA process and means that defects picked up by the tool wont be seen by QC ?

Yes, the old QA is not QC argument...

One I had many times at my last company, trying to educate people into why saying they were giving the program to QA to be QA'd was wrong and why I wanted directory names on the test server called "FOR_QA" to be renamed as "FOR_QC"

And now that I've blogged about it I can join the list of QA/QC bloggers such as

Google

John McConda and Antony Marcano ( and again ) on testingReflections

The Braidy Tester

Alan Page

Steve Rowe



For my next post I need to think which "testing is like..." analogy I can use as that is also a common theme of a testing blog.

Detectives, surgeons, kung-fu, playing pool, driving a car, introducing a guest in your home, dishwashing,a box of chocolates, flossing teeth, growing turnips, toilet paper, hide and seek, marriage and Magic The Gathering have already been done so I'd better get thinking hard if I'm going to come up with a new one

and finally, I gave this post the title 'testing cliches' which is a good example of the problems of the English language and how it can be ambiguous
Does "testing cliches" mean a list of cliches that apply to testing ?
Or does it mean that cliches are being tested to see if they are true ?