What is QA? Why do you need good QA?

Finger pointing at white rectangles as part of a flow chart

Put our talent to work

What is quality assurance (QA)? It’s a hidden profit center that keeps your product on schedule and on budget. QA is your communications facilitator to make sure everyone is on the same page.

Why do you need good QA? Good QA is the frame upon which everything else hangs. Good QA knows how to talk tech and relay that to non-technical people. Good QA will give you honest feedback, whether you like it or not.

Here are some thoughts that should help you get the most out of your QA practice or what to look for in a QA partner.

QA isn’t just testing

Testing is Quality Control (QC). While that is a small part of QA, that’s not all there is for QA. Good QA ensures everyone is on the same page. QA is about communication, including asking the “stupid” questions. QA does not assume that everyone knows what is being done. We talk to all stake holders to make sure the whole team has the same understanding of what is being done and what we are trying to accomplish with each feature.

QA is process

QA is the group that gently keeps the software development process on track. For those that think that QA is just a testing group, think about the cost of fixing bugs that result from two engineering groups not talking.

QA should be there from beginning to end asking, “What about … ?” What did the customer actually request? How is this going to be used? Who is responsible for the integration piece? QA asks the questions before the development starts.

QA is procedure

Procedure is the human part of process. It’s how you do the various steps. QA asks questions and gets everyone on the same page.

QA also keeps the development process moving. It makes sure that as much of the procedure as possible, and needed, is followed. Some features don’t need three functional acceptance criterion, but another feature may need nine acceptance criterion. QA should be responsible for providing just enough information in a feature that everyone can read the feature request and understand what it’s supposed to do and why. It is the group that gives unbiased feedback on the state of the code. Without that unbiased view, we don’t know where we stand.

QA is communication

We fail if we don’t communicate. Written communications are rife with misinterpretation and changing perceptions. Without verbal communication, how can we be sure that we are doing what was requested? Talking is key to understanding what the code does, what motivates each of us and building a team to build a quality product.

QA is a profit center, not a cost

How many companies do you deal with that have poor product but no competition? The job of QA is to make sure your company isn’t like that. A company’s reputation for putting out a quality product is invaluable. That reputation makes it easier to market and sell your products/services and retain customers. Quality also lowers the call volume to your technical support staff. Good QA is a profit center.

QA is not a guardian at the gate

QA isn’t guarding the gate saying, “You shall not pass.” When QA advises not to release something, it explains the risks in allowing certain defects out. Only in rare cases does it advocate for a hard stop.

Viewing QA as a limiter on production is counterproductive to QA and the team as a whole. Companies that allow adversarial relationships to build are set up for failure. Would you want to work with people that made your life difficult? Would you want to go to work if you knew it was going to be a constant battle to do your job?

QA does testing

In a perfect world, QA testing is a formality because we have built in quality from the beginning. QA builds in quality by:

  • Communicating to get everyone on the same page.
  • Asking questions to make sure that the feature that conveys exactly what the customer wants.
  • Making sure the process and procedure are guidelines, not crutches, and certainly never a strait jacket.
  • Enabling good fast development.

We do this by sharing our test and communicating functional and non-functional requirements, so we can all agree on what a quality well-crafted product is. If developers know what I am testing for up front, it makes the job is easier for everyone.

Related Posts
Scroll to Top