Tester vs. Quality Assurance

I prefer to use the team Quality Assurance Engineer over Tester.  You'll meet software QA professionals of all shapes and sizes out there.  Some will be  as hands-off, minds-off as possible.  I tenderly call these testers "Monkey Testers" - relative to the role they usually take on of just being hands on a keyboard.

I expect those with whom I work to assert themselves - to engage their minds, to ask questions, to probe, to query, to ponder, to meditate.  Quality assurance doesn't begin when the code falls onto our plate with a sickening thud as the developer sneaks back to his desk.  Quality assurance begins at conception of an idea - a motive.  Quality assurance doesn't end when the code launches into production.  Quality assurance ends when the product is removed from production to never be used again.

Quality assurance is such an interconnected fiber in the strands of software that without it, the fabric falls apart.  We are responsible - with the rest of the development team - for the success or failure of the product.

"Some testers feel that their mission is simply to find variances between the product and the specifications. Anything beyond that—such as usability problems, requirements problems, data quality, and supportability concerns—are "not my job." We urge you to take a more expansive view. All other things being equal, your mission should be to inform the team, to the best of your ability, about any problems that could adversely impact the value of the product. For this reason, excellent test teams include a diverse group of people who collectively understand the whole equation of the product: how it will be designed, manufactured, marketed, sold, used, serviced, and upgraded." -- Lessons Learned in Software Testing - Lesson 13