Historically, quality assurance has come at the very end of the SDLC. When development and other phases run long, QA gets shortened. But the QA team is still expected to meet deadlines, find all the bugs and, as some people seem to think, assure absolute quality.
Naturally, the QA department gets blamed when things don’t go smoothly and on time. Even in newer development methodologies, QA professionals are often blamed for the bugs they find and the subsequent delays those reports create. This understandably leaves many QA professionals feeling undervalued, misunderstood and frustrated.
Meanwhile, decision makers at the company might not know what the QA department even does, what they’re responsible for and why they’re important. This is the core of the problem. If QA wants to be valued as a full member of the team, key stakeholders need to fully understand the process and purpose of quality assurance.
If it was that easy, though, this wouldn’t be a problem to begin with. The key to communicating the full value of quality assurance is explaining QA in a way executives understand and can relate to the rest of the business. It also requires dedication on the part of you and your team.
Explain What QA Is (and Is Not)
As a quality assurance professional, you think from the company’s point of view, the customer’s point of view and the point of view of a fringe user. You ask yourself if the product works as designed. You also ask if the customer will be happy with this product and if they’ll find it easy to use or frustrating. Then you take it a step further and ask “what happens if I do this?” because someone, somewhere most likely will do it and it might cause a nasty bug – or worse, a security vulnerability.
This multiple personality drive is part of your DNA. But executives aren’t QA professionals and don’t innately think the same way you do. So explain it to them. Explain that for a product to succeed, it has to work on all these levels, and that while a product might work exactly as designed, that doesn’t mean it is a high-quality product. Software doesn’t exist solely as a set of requirements, it has to function well in the hands of users and that is part of what QA is looking for.
Also define how QA fits in with the rest of the company. You are essentially the last line of defense between the company and the customer – if you don’t feel the product is ready for release, then there is likely a big issue. (Remember to be reasonable — not every bug or less-than-stellar UI feature will be fixed before launch and that’s OK, but you shouldn’t have any major reservations.)
Ideally, a product won’t be released until it meets a minimum level of quality as determined by a QA manager or team. But that might not always be the case – launching could be up to a product owner or executive. If that’s the situation at your company, the best you can do is strongly make the case for QA to influence the decision. Make an argument to have QA be part of the overall product planning process. Provide metrics that show the contributions your team has made in the past (showstopper bugs, quick turnarounds, recommendations that have become features). The key is to make the case that quality assurance is just as valuable as development itself.
What QA is not (and what many execs might fail to realize) is a 100% stamp of approval. Software will never be perfect and it’s unrealistic to think it will be. Be sure all decision makers and executives know this. If they don’t have unrealistic expectations for your department, it will be easier to succeed.
Cost
There aren’t many executives that aren’t concerned about the bottom line. If you can put QA in terms of cost savings, you’re likely to get their attention. Executives are used to digesting facts, figures, numbers and outside analysis. If you make your case in these terms, it will be much easier for them to see the “real” value.
“It is estimated that fixing flaws after a software release can be five times as expensive as fixing them during design—” Frank Huerta co-founder and CEO of Curtail, Inc writes in an article from DevOps.com, “and it can lead to even costlier development delays.”
Track any costs that result from bugs found post-launch. If presented correctly, this can help you make the case for more time or resources for the quality assurance department. Though it can be difficult to attach an ROI to your QA efforts, track what you can, especially when you adopt new tools or practices or make any noticeable changes to the QA process.
A third-party study from Hobson & Company found that Applause customers see:
- 150-200% increase in testing capacity
- 25-30% increase in planned revenue
- 50-75% decrease in unplanned downtime
Brand Reputation
Quality has a direct impact on a brand’s reputation. In a recent survey, 88% of consumers said they would leave an ecommerce platform if it was difficult to use, with 56% saying they would never return after a difficult experience. If your company puts out a sub-par product, users will lose faith, complain and potentially take their money or membership to the competition. This is one of the Chief Marketing Officer’s worst nightmares.
Because QA professionals look at products in part from a user perspective, you have a keen sense of how customers might react. Use this understanding to lay out potential pitfalls and their possible consequences in terms of brand reputation.
Releasing software updates and patches is easy these days. This can lull companies into a false sense of security and lead them to downplaying the need for in-depth QA. Remind product owners that this practice can also damage a brand’s reputation. If a company is continuously releasing software or updates that need almost immediate patching, the public will quickly lose patience for the near-constant notifications and lose faith in the company’s dedication to quality. It’s worth the extra time to make sure a product is high quality before release.
,
Efficiency
It may be necessary to remind executives of the saying “measure twice, cut once.” It is rarely a company’s plan to push bad software out the door and fix it later. (If that’s your company’s philosophy, there are bigger problems than just communicating the importance of QA.)
Releasing software without proper QA means you will have to go back and fix it later, and that can have a bigger effect on company efficiency than executives might realize. Extra man-hours and resources will have to be dedicated to this “done” project. This, in turn, will delay future plans. If your company is constantly releasing software that needs a considerable amount of post-launch fixing, the company is not being very efficient.
“The truth is that proper testing takes time and costs money,” Vu Lam, CEO and founder of QASymphony, told SD Times. “What many companies are missing is the fact that proper quality assurance before release is far better than disgruntled customers and repeated post-release patching. The true cost of bypassing QA or hobbling them is tough to calculate, but it could be a lot higher than you think.”
Make Sure You Understand
If you want QA to get the respect it deserves, you need to be a team player. Understand the company’s dreams for this product and overall corporate goals. Just as customers won’t be using the software in a bubble, you’re not testing in a bubble.
Figure out how QA can help make not just a better product, but a better product in terms of what executives want. If you suggest changes and raise issues that have already been dismissed or that are wildly out of line with the company’s goals, you run the risk of alienating yourself, overstepping your bounds and devaluing your opinions in the eyes of the stakeholders.
Know the Expectations
Draft a mission statement that outlines the goals of QA for each project and share it with management. While putting together this mission statement, consider who you are presenting to, what their chief concerns are likely to be and what they care most about. Let these factors influence your goals.
Presenting this mission statement before testing will help you determine if your understanding of the project is in-line with what executives want. If your goals for testing and the desires of executives are miles apart, it’s better to figure that out before you spend time testing. It also opens the door for discussion.
If you need to re-craft the mission statement, discuss what the exec wants from QA and why you chose these goals – it could be that the true goal needs to be a combination of both inputs. Remember, the common goal is to make the best product possible.
Take Responsibility
Even with careful planning and even more careful testing, things might not always go according to plan. Maybe you missed the mark with your testing goals, maybe the management’s requests changed midway through testing and you didn’t get the memo, maybe your team missed a major bug. Take a deep breath and take responsibility – no one respects a blame shifter.
Take responsibility for mistakes that were truly your fault. Form a plan to keep the mistake from happening again and discuss it with your team so everyone is on board. Then bring your acknowledgment that something went wrong and plan of action directly to your immediate supervisor and to any executives you have a working relationship with.
If it wasn’t your fault, don’t just point the finger at someone else. Acknowledge that the ball was dropped, explain why you think that happened and suggest a way to keep it from happening again. If you want the QA department to be an equal member of the team, you need to show the powers that be that you’re a team player.
Stick Up For Your Team
You, just like every other department leader, know your team best. You know how they work, the methods and practices that work best and what really annoys people. Be polite, but don’t be afraid to voice your needs, opinions and concerns when dealing with management.
Don’t whine or rush off to the CEO when there’s an issue, but don’t be afraid to address it with the appropriate person. Nothing will change unless you draw attention to a problem.
If management doesn’t feel production is going as smoothly as possible, they may try to make blind changes. Everyone has heard horror stories about companies implementing “Agile” simply because they heard it produces faster results. If you disagree when a major change gets passed down, ask to discuss the change and the reasons behind it. Bring a list of reasons you think it is the wrong direction for your team. If management is seeking a change, don’t expect them to backpedal simply because you say it’s a bad idea. Instead, listen to the source of their grievances and you may be able to address them in a less disruptive way that will result in real benefits.
,
Conclusion
In the end, you’re still just talking to a boss. It doesn’t matter that you’re in quality assurance, it all boils down to a boss-employee or executive department relationship. Don’t get so caught up in what you’re doing that you forget the fundamentals of communication altogether. No one likes to be talked down to and no one likes feeling dumb. If you go in acting condescending, demanding and spouting tech jargon, you’re going to put management on the defensive. Follow common-sense communication guidelines, such as using the boss’ preferred method of communication (i.e., emails, weekly in-person meetings, phone, etc.).
Don’t just point out problems — offer solutions. Even if the developers are complaining about QA, don’t rise to the bait. You’re adults, so act like it and take the high road (it will make you look better). Be honest and as accurate as possible when giving your analysis and opinions.
If you’re not happy with how QA is treated at your company, it’s up to you to change it. The best way to do that is to start a good rapport with management and prove to them that QA is an indispensable part of the business (in ways that make sense to them).
11 min