Use the Requirements Already - I am working on a release at work. Initially we were supposed to replicate some bunch of database tables that the customer had in an old system. We did a ...
Now perhaps this quality discussion is just centered around an assessment of the quality of the product. But that is a different discussion altogether. That is more along the lines of asking what the defect rate is looking like. No. That's not what our manager is doing. He is looking for the test team to somehow increase the quality of the product. LOL. No wonder the last test manager quit the position. It was just getting too crazy up in there.
The new guy in charge of test is an up and coming type of guy. He has management written all over him. He is leading a bunch of initiatives. Not all of them are restricted to the test department. A lot of these new initiatives are showing their value. He still will be in the quality hot seat when push comes to shove. Luckily he will probably be promoted out of the test department by then.
The true moral of the story should be that you address quality from the very first day on the project. You got to build in quality safeguards before you even talk to a customer about doing any work. That needs to continue throughout the software development life cycle. That you are testing for the quality level at the end should just be a last thought, not the first thought on the subject.