What is QA? And why do I need “good” QA?
I hear a lot of people talk about being in QA as an SDET or SEIT and I have to wonder, given how they talk or write, if they really understand what QA is and what it does. QA is not just testing, testing is QC and while that is a small part of QA, that is not all there is for QA. Good QA is about making sure 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 stakeholders 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 puts into place the bumpers in the bowling alley, the means by which we gently keep 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 are the result of two engineering groups not talking. Have you ever had to “redo” a client-requested feature because the engineers misunderstood or misinterpreted what the customer requested? So maybe just testing to see if the software is what the developer said it was isn’t such a great idea. QA is supposed to 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? These are parts of what QA does. QA asks the questions before the development starts.
QA is procedure
Procedure is the human part of process; procedure is how you do the various steps. QA by asking questions and getting everyone on the same page is an active process, not just part of the process. QA also helps keep the development process moving, QA makes sure that as much of the procedure as is possible and needed is followed. Some features do not need three functional acceptance criterion where another feature may need nine acceptance criterion. QA is the group that should be responsible for making sure that there is just enough information in a feature that everyone can read the feature request and understands what the feature are supposed to do and why. QA is the group that gives unbiased feedback on the state of the code, without that unbiased view we really have no idea where we stand.
QA is communication
In the previous two paragraphs communication was part of it but at the end of the day without talking to each other we all fail. Written word is tricky as any emphasis is entirely up to the reader. Written word is also open for misinterpretation; have you ever read something and thought that it said one thing but when you went back and re-read the item you get something else? That is what happens to everything when people are rushed we skip words we insert what we think something should be into what we read. Without actual spoken communication how can we be sure that we are in fact doing what was requested? Talking is key to understanding not just what the code does but 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 because they are the only one doing what they do? Their product is crap but they have no competition. The job of QA is to make sure your company isn’t like those other people. A company’s reputation for putting out a quality product is invaluable. That reputation makes it easier to sell your products, and retain customers. A reputation of quality makes it easier to market your product and services. That quality built-in lowers the call volume to your technical support staff. Good QA is a profit center.
QA is not a guardian at the gate
The thought that QA is somehow the guardian at the gate saying “you shall not pass” is wrong and counterproductive. Yes, QA puts in place the process and procedures by which a lot of what is software development, release and deployment gets done, but QA works with the entire team. QA advises that something should not go out, and QA explains the risks in allowing certain defects out but we should only be a hard stop in extremes. QA as a limiter on production is counterproductive to QA and the team as a whole. Companies that allow adversarial relationships to build are setting their selves 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? Probably not thus a company that allows or fosters adversarial relations is poised for failure because good people will leave and the poisonous people stay.
QA does testing
Yes QA also tests the quality of the product but hopefully, our testing is a formality because we have built in quality from the beginning. QA builds in quality by communicating with everyone to make sure we are all on the same page reading he same notes and getting the same information from those notes. QA builds in quality by asking questions to make sure that the feature that reads “the customer would like to be able to drag and drop widgets” is really about all the widgets or that the customer did, in fact, ask for the ability to move widgets.
Funny side note when I started out in QA we used waterfall development, and I read a feature that says “customer would like to do blurring” so I go odd why would you want to blur the image? So I dig in, ask questions, finally get back to the tech support person who put in the request read there call log notes and the customer wanted radius blurring on text. Moral of the story – never assume the request is correct, find out who put in the request and why they put in the request. QA builds in quality by making sure the process and procedure are guidelines, not crutches, and certainly never a straitjacket. QA helps build quality be enabling good fast development. How? We share our test and we openly communicate functional and non-functional requirements, so we can all agree on what a quality well-crafted product is. Nothing screws a schedule more than the thrashing that comes from testing at the end and the development team having no clue what the tests were going to be or why. If the developers know what I am testing for up front in broad terms and specific then they can account for that up front and the job is easier for everyone, development, Product Management, Project Management, Marketing, Sales, and QA.
So what is QA? Quality assurance is a hidden profit center. Quality assurance is the grease in you development process that helps keep your product on schedule, and on budget. Quality assurance is the true witness to the quality in the product. Quality assurance is your communications facilitator to make sure everyone is on the same page.
Why do I need “good” QA? Well good QA is like good bones it 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. Just because you don’t want the bad news does not mean you don’t need to know about the bad news.
For further reading:
Mastering Software Quality Assurance: Best Practices, Tools and Techniques for Software Developer
By Murali Chemuturi
Is your Quality Department a Cost Center or a Profit Center?
By Tom Quinn
The ASQ Quality Improvement Pocket Guide: Basic History, Concepts, Tools and Relationships.
By Grace L. Duffy