A few months ago I asked people to complete a short survey on quality. Thanks to all who took part.
Quality is often defined using Jerry Weinberg’s definition of “Value to some person who matters”. Although testers tend to use this definition frequently, and comfortably, I’ve found it to have some limitations. The word ‘value” is almost as fuzzy as “quality” and who exactly are those people who matter? It seems that even with a widely accepted definition it’s still hard to translate quality into a tangible concept for developers or customers.
I decided to try turn a definition of quality into a feeling that people could actually relate to, and hopefully use to better their own work. To do this I asked people to rate the quality of LinkedIn. I know many of you will be laughing at the idea that LinkedIn might represent quality but it turns out to be a very divisive topic. People who want to manage a professional network generally rate LinkedIn’s quality highly. Testing professionals usually don’t.
Although heavily leaning towards the “no”, we can see a decent number of people do think LinkedIn is a quality service.
If a service offers value then many people are able to ignore, or maybe don’t even notice shortcomings. I asked people to rate the quality of LinkedIn using just a yes, or a no option. As many respondents pointed out quality is definitely on a scale. What’s interesting to me is that the people who wanted to give a “yes, but no” response tended to say that LinkedIn offers value in managing a professional network (so it is a quality service), but that it it unintuitive to use (so it isn’t a quality service).
The frequency of “intuitiveness” as a measure of quality is of particular interest to the tester side of me. How often do we get caught up testing something against the requirements and ignore the unspecified side of the system? We spend hours hunting down weird and wonderful edge cases, maybe too often choosing to spend our time logging bugs rather than helping to improve the intuitiveness of a system.
We frequently discuss whether testers should learn to code or not. Maybe now is the time to start talking about whether testers should be learning about UX design. At Songkick we see huge benefit in including all team members in testing and quality activities. UI designers are experts at creating usable designs. UX designers understand how users interact with the system. Developers understand how code complexities can cause unexpected behaviour. Ops Engineers know how the system actually runs in production. Product Owners know exactly what they want the system to do. Including all of them in testing discussions brings a wealth of knowledge and skills that, when combined with a testing expert, can have a huge impact on quality.
Quality isn’t the (sole) responsibility of the test team. Everyone involved in developing software should have a good understanding of who the intended users are, their goals, and at least a working understanding of the methods we can use to meet expectations. Facilitate discussions to identify the “people who matter” for your particular system. Help connect team members to users. Even a single session on the customer support desk can have a huge impact on helping people see the real-life impact of a poor design choice. Even just making sure you have a solid approach to managing code maintainability will impact quality as least as much as prioritising features correctly.
Treat quality as a team responsibility. Work together to assist each other in building systems that people actually want to use.
Testing the Mind 
Also, what came to me as I was reading that is also quality is also a related to what currently exists. Someone could build something technically awesome, design and ux of awesomeness and product managed to perfection, but if it is still the best option out there then they will continue to grow/survive. One day (I hope!) something will replace LinkedIn, just like things have replaced things that have died in the past.
I often think about my work. And I see all the flaws. All the things that we are not achieving (yet). The lack of resources. But even with all that, I think we are providing ‘quality’ because we are the best option, for testers, out there.
It’s easy to complain about stuff, it’s much harder to actually do something about it. How does LinkedIn compare to their competitor? How does a life/world to a typical LinkedIn user look if LinkedIn didn’t exist?
Also, you mention designers, UX, developers are experts at x/y/z. What do you think testers are experts at?
Food for thought, perhaps 🙂
Yes, that’s an excellent point. Quality always exists within an environment. Low quality will usually be fine, and accepted, for as long as nothing better exists.
Taking advantage of this low(er) quality approach to move fast is just one way that smaller companies, and startups, can gain so much ground against more established companies. Turning that in to a product or service that scales and has increasing levels of quality is a very interesting challenge.
As for the question of what I think testers are experts at, I think I need to devote an entire post to answering 🙂
Thanks, that’s a good read. Or should I say “a quality read” ? 😉
When having to respond in a nutshell, I usually tend to go with Philip B. Crosby’s definition of quality: “Quality is conformance to requirements”
…or, alternatively, when being asked for a more scientific explanation, with the ISO 9000:2015-11 definition: “Degree to which a set of inherent characteristics fulfills requirements.”
As you see, either way, there is that thing called “requirement” in it. And guess what – from my 20+ years of experience in QA and software testing I can assure you that almost all quality problems don’t come from design, code (and certainly not test) but from these infamous “requirements”.
When we say “beauty lies in the eye of the beholder”, we have to slap our foreheads and think: Heck, the same goes for requirements and expectations. The same single requirement might mean different things to different people. Even if not, it certainly has a different importance to different people. And the only way to get around that is by arriving at a common understanding of what it means and how important it is.
Therefore, on a higher level, quality can only be achieved if all of the people involved into the creation of *something* gather to get a common big picture of WHY WHAT and HOW. (But that is something we should have learned from Crosby too – since the late 70s… *sigh*)