Making Room for Constructive QA
As a developer, what got me interested in testing and quality assurance was the realization that past a certain point, I wouldn't be able to reduce my bug count simply by trying to be a better programmer. While I could improve my skills to a certain degree, inevitably I would still make mistakes.
To continue reducing the number of emitted bugs, I would need some kind of tool or process that could catch the problems that I missed. Figuring out how to make a system that's more reliable than any one of its parts is, in a nutshell, QA.
In the software world, QA is often treated as a synonym for testing, but its scope is far broader than that. I think of QA as figuring out what's interfering with the team's ability to deliver good software, then finding ways to address it. While QA is often derided as "process nerdery" and associated with oppressive bureaucratic control, it doesn't have to be anything of the sort.
Realizing that the last few new features made life difficult for the support team and asking one of them to sit in on future planning meetings is QA. Creating scripts to build test environments so that testers don't have to waste time setting them up manually is QA. If you advocate for the purchase of an office coffee machine because the nearest coffee shop is a twenty-minute walk, I would argue that is also QA. No checklists, ISO9000 standards, or forms filled out in triplicate need be involved.
There have been calls for testers to get out of QA entirely, often backed by the rallying cry of "testers can't assure quality!" I think this objection is based on an overly simplistic reading of "quality assurance" and a history of testers being cast in the role of the quality police. No, we can't assure quality, but neither can security specialists assure security, nor can safety officers assure a completely safe workplace. We merely try to improve things as best we can. We inform; we don't compel.
That being said, positioning testers as "the QA group" is counterproductive. Everyone on the software team should be interested in delivering quality. Indeed, QA work can be done by anyone who's interested in observing the development process and finding the places where it falls down. Testers, however, tend to be uniquely well positioned to do this.
Testers see the software evolve from requirements to deliverables firsthand, and they are in continuous contact with all areas of the system. Too, partly due to their role as "bug investigator," they interact with most everybody in the office and see both the software and the organization from many angles. They get to view not only the whole development process but also how it's working out for every stakeholder.
Chris McMahon has written on using software QA as a force for good and the things you might want to learn to do effective QA work. You might find it rewarding to reflect on how the software development process is going at your workplace and to consider what changes might make it work better for everyone.
Nobody likes to be ordered about or to be told that they are doing something badly. However, if you make it clear that you are genuinely interested in improving things for the whole team instead of admonishing people for their perceived mistakes, you may find considerable support from others who feel the same way.
