QA or Test - does the name really matter?

I've been the manager for many different teams. Some call themselves Test and some call themselves QA. Personally, I've found it easier to just use those terms interchangeably. But for many, there are two very distinct schools of thought about what a Test team is and what a QA team is. Maybe at some point testers will just all be thinking about this the same way and use the two terms synonymously, but we aren't there yet.

In the most basic definition of testing, it is to measure and report on the quality of a product. This describes the "Test" part. But most Test teams I've managed are more than that, they are QA teams. Their goal isn't to just take features from developers, find defects, and report back their findings. They go way beyond this to assure quality. So even if they are called a Test team, they act and think like a QA team.

So what makes a team a QA team? Well, many things do and I doubt I can come up with an exhaustive list. But here are a few that are at the top of the list for me. If your team is going to truly assure quality, they need to be doing the following:

1. Get involved early in the process. Give input on requirements, designs, etc. Testers need to learn to test the requirements and design and not wait for code or features to find defects. They also have to approach this part of a product cycle as a time when their input is crucial. This isn't about the testers gathering information and learning about requirements and designs. Although they need to first learn, they then need to go further by having opinions and giving feedback.
2. Hold others accountable. Each person on a project team has a responsibility. Since testing happens at the end of most product cycles, testers naturally try to jump in where needed or compromise when needed to help keep the project on schedule and to allow them to have enough time to get through all their testing. But this actually confuses things. For example, if the build quality is poor, testers need to hold their developers accountable for doing more unit testing and proving out their check-ins before dropping builds to the QA team. If the specs are poorly written or don't contain clear user scenarios, QA needs to hold the right people accountable for taking action. Many times, testers will write their own scenarios. This may help them move forward, but doesn't solve the overall problem. When this happens, the testers need to call these "test scenarios" to distinguish them from scenarios written by PMs or used to derive use cases.
3. Innovate on ways to improve quality. Don't just be a team that writes test cases and executes them. There is so much more that can be done. There are tools and automation that can be written to make this work go faster, to find other defects you couldn't find manually, or to help unblock your testing by emulating dependencies. The list goes on. This is where innovation can be used to truly assure quality by aiming to get more done with less by using code to help you. And if your team members aren't programmers, there are innovations needed in process improvement, root cause analysis, etc.
4. Compromise carefully when it is justified. Yet, you need to stand your ground while collaborating. This is difficult, but in order to have a successful project team, testers need to collaborate and make compromises. But they need to balance this with enforcing the correct course of action that will result in a high quality product. For example, typically my teams will have a date for test signoff and then send out a report of what was covered and an affirmation that the quality is there and has been proven. But at times, this signoff can show compromises such as statements that the tester signs off but with conditions. It's ok to make smart tradeoffs, but you must communicate the risks broadly and clearly. In this one example, people didn't read the details of the sign-off email and assumed since they got the email, everything was good and the code was released to production. Tradeoffs were made, but not communicated well. Tradeoffs cause risks and everyone benefits from those risks being communicated.

So no matter what you call yourself, "Test", "QA", or even "Dev", approaching your project work with quality in mind and always looking for how to improve the quality while moving the project forward is what testers do and what makes this work so important.