Share via

QA or Test - does the name really matter?

  • Article

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.

Comments

  • Anonymous
    April 06, 2011
    Anita,I'll debate this with you.  I have found that too many times the terms QA & Test have been used interchangebly, and it has been detrimental.  Main reason being that people/groups outside of the Software Testing and Quality Assurance realm have a misunderstanding and misconception of what either term/function really is and what is involved with them.In the software world in my experience (and opinion) is that Quality Assurance is an umbrella term/function for diffrent parts of the process.  Testing is one of the parts under Quality Assurance.  QA comprises functions such as; Software Configuration Management (SCM) & Source Code Version Control, Build Management & Deployment, Metrics, Inspection Verification & Validation (IV&V), Audit, Project Management (yes, it really does need to be here), Standards & Procedures, AND Testing.  The 3 key foundation parts are Testing, SCM & SCVC and Build Managment.  These are core pieces in 'QA' that need to be in place for all projects to have some level of control and accountability for the project.To me if a 'QA' group is only doing Testing (like your list of items) tasks then they are a 'Test' group.  The department/function needs to also be doing and managing the other parts I previously mentioned in order to be called 'QA'.  This is a key thing to get across to managment and other groups so that they do not have the misconception of what your 'Test' group is responsible for.  Really all in all everyone (I mean everyone in the company) is responsible for 'quality'.  But it is management that makes the Go/No Go decision to release, Test does is gather information on the readiness/condition of the product so that an informed decision can be made by management.QA is the mechanism to aid in that, and Test is one of the tools to be used by QA.So yes, get your testers involved early in the project to do the reviews and analysis.  Let them 'test' the requirements / user stories by asking the 'W' questions.  Have them work with development in parallel to get ready for the system level testing, and have them work with development to build more robust Unit & Integration tests.  Empower them to be able to stand their ground on schedule pressures and un-neccessary compromises.  Encourage them to be a communication center and not 'go dark'.  Don't wait for the software to be thrown over the wall.But make sure you clearly delineate and communicate your groups purpose, responsibilities and tasks.  Otherwise you will have people assuming Testing is Quality Assurance.  And then you are heading for a world of hurt in my opinion (and experience over the last 20+ years of testing work).So yes I agree with your final statement that you need to keep quality in mind and do 'quality' work, and that Testing is an important piece of the overall puzzle of producing a software product.  I just have come to believe that in this situation you need to split hairs a little and make the distinction/delineation of the two.Respectfully submitted,Jim HazenVeteran of the Software Testing TrenchesLinkedIn: www.linkedin.com/.../760
  • Anonymous
    April 06, 2011
    I especially like your last sentence! Most teams that call themselves "QA", and most people that call themselves "QA Engineers" or whatever don't have a chance to assure quality. Everyone involved in delivering the software - programmers, testers, BAs, sys admins, DBAs, project managers, UX designers, etc - must take responsibility for quality as a team. They must collaborate to ensure the right testing activities are planned and executed. I think it helps when everyone gets together, decides to what level of quality they want to commit, and make that commitment mean something by not getting stuck when things get in the way.
  • Anonymous
    April 06, 2011
    @Jim - I agree that QA is a large umbrella for a lot of different tasks and responsibilities.  Many that you mention are inherent to a QA team and at times shared with the developers, and therefore wasn't my focus in this blog entry.  What I have found is that if people only focus on those tasks but not on how they are doing them or how they are thinking about the overall way to achieve quality, they will miss something.  Getting involved early, holding others accountable, and innovating addresses how we should do our QA work.  I find that at times people focus too much on what they are labelled as and not on what work they need to do.  So for me, either name "Test" or "QA" works, even calling themselves developers is fine as long as there are clear roles and responsibilities.  But I do recognize that there are other schools-of-thought on this topic.  Thanks for your respond.
  • Anonymous
    April 06, 2011
    The comment has been removed
  • Anonymous
    September 04, 2011
    The comment has been removed