SQA project leaders. People who can make sure that SQA does the right things, and if it has to cut corners, does so with intelligence and approval. Someone that can react to the ever-changing state of affairs, and keep everyone in mangement informed.Writes test plans, SQA project plans, SQA test strategies. Large overlap with what some call SQA Analyst. Directs the day-to-day activities of the entire SQA team. Deals with development project leaders and managers, tech writers and sometimes support and marketing. Doesn't have to be a coder, but it helps.
SQA Architect. The techie half of an SQA manager. This is rarely a defined role per so, but is handled by the SQA Manager, project leader or one of the automation experts. Reviews tools, defines interfaces between tools, designs and builds the glue that makes a fully automated test system fly.
SQA Analyst. Review requirements documents, functional specs, design specs, architectures, unit test plans, SQA test specs, development and SQA project plans, etc. for both content and process. For instance, if a design spec does not reference both the architecture and the functional spec, you can be pretty sure there will be some problems integrating that component. This role is often performed by the SQA manager or SQA project leader. Does not need to be a coder, but should understand the implications of highly complex code, high code volatility, etc.
SQA Managers. People who can manager project leaders and protect them from 90% of the seat of the pants, knee-jerk, gut reactions that some development managers and upper managers get when the first little thing goes wrong. Someone who will sit down with them and tell them that if they want it tested, SQA needs people, specs and tools up front, etc. Needs to know a little about what everyone does. Deals with development VPs and managers.
Automation experts. These are the people that can spend 6 weeks or 6 months building an infrastructure that enables the rest of the SQA team to build 12 to 20 tests a day. They also maintain the infrastructure so that when the GUI changes, or the product gets ported to a new platform, the tests don't have to change. A good automator also specs out the stuff ahead of time so that most of the tests can be written before the automation (or the product) is done.Writes test architecture, test code, users guide. Deals with other SQA folk, for the most part. Must be coders.
Test engineers. These write test specs, build the tests on top of the automation infrastructure, run and evaluate them, run manual tests. There is also a class of test engineers that are domain experts. These will do less test building/running and more test specs. Helps to be coders. Deals with developers.
Lab assistants & jr engineers/testers. These run some automated tests, execute manual tests per test specs, set up machines, etc. Deals with other SQA folk, mostly test engineers, and maybe some developers.
Attention to detail. Many times a good SQA person will find a bug because something looked a little off. Maybe a filename is built from the date and doesn't include the year. Maybe one dialog showed the whole pathname and the next only showed the filename.
Note taking and/or memory. I have a good memory, yet I will take down 6 or pages of notes per hour while testing. Later, when I go to repro a bug, I'll know exactly what I did.
Patience. Arguing with developers will never get them to see things your way. Often you can just point them at a problem, andlet them talk themselves into deciding it's a bug.
Thoroughness. When you log a bug, don't just say what broke. Try variations on the test until you find some that work. Document all of the cases you tried and the result. Sometimes a developer will look at what you did and knwo whatis wrong by what worked and what didn't.
Flexibility. Each developer has a different way of working. Some want to pump you for info first and then go and investigate on their own. Others will want to see the bug and work with you from there.