Angela Riggs is describing the misconception that quality seems to happen somewhere between software development and software release, that magically a bunch of testers come in and somehow swing “quality sticks” and lo and behold, quality magically appears. Yeah, no!
For quality to exist in an organization, the entire team has to consider it important and part of the core DNA of the organization. Short, there needs to be a “Quality Culture” that all of the organization aspires to.
What does a Quality Culture look like? If you are struggling with this, you are not alone. It’s like trying to define “Blue” (yes, smarty pants, I know that blue can be defined as hex #0000ff or RGB (0,0,255), but try to do it without using those numbers. "If someone tells you “Make it more blue” what’s your response? If you can make a clear and coherent one, maybe defining a quality culture will be easy after all ).
One of the ways that we can focus on this is the idea of onboarding new people to the culture. It’s much easier to bring someone into an existing culture and norms as compared to trying to make a new culture to fit an existing team. Imagine what you would like to see people in the organization embrace. Perhaps start with something small, such as “we want to encourage everyone to develop a common way to handle installing the product” and then add items as they become common use.
I live by the mantra that “Documentation may not get read but it will certainly not get read if it doesn’t exist”. If there’s something I do in my job, regardless of how trivial or challenging, I try to have documentation describing what it is, why I use it and what the benefits are. Will the team read it? maybe they will, maybe they won’t. I will guarantee no one else will write it unless mandated to and to reiterate, you can’t read what’s not been written. Some may consider the idea that arcane knowledge makes a person indispensable. It’s a bad bet. Don’t believe it. What it will likely do is make people lose sight of what you do and why they should care about it. In my experience, documenting what you do increases the visibility of efforts and activities, as well as helping to safeguard against the Lottery/City Bus problem (as in, if a key member of the team wins the lottery or gets hit by a bus, what will happen to your team if they suddenly disappear?).
It may seem unfair that I’m emphasizing the role of the tester here. How about the developers? What is their responsibility? The answer is “every bit as much as the testers”. Quality needs to exist in the code being developed. Testers don’ bat quality in. It has to be there from the start. Ways to encourage that is with techniques like Test Driven Development, pair development, code reviews, and allowing them to grow and iterate over time (this won’t happen overnight, at least not if the desire is to watch it stick).
Additionally, this culture needs to be championed by everyone, not just the engineering team. Having the C-class execs championing quality is every bit as important as having the developers and testers care about it. By getting everyone on board with this and being consistent with what that looks like, the chances of a Quality Culture becoming a reality goes way up :).