When I hear someone use the word "quality" in one context or another, I almost always feel the need to clarify what exactly they mean by "quality." And when I do ask for clarification, I can hear a wide range of answers. Contributing to the complexity is the reality that this term is integral to our job title, implying a comprehensive understanding of quality is expected.

But is this ambiguity a problem?

I'm inclined to think not. If we take such concepts as “theory”, “fact”, or “probability”, then without a philosopher friend, we'd struggle to comprehend. These words have several interpretations, and depending on the context of their application, they can take on entirely different meanings.

Something similar happens with quality. We strive to enhance it, ensure it, evaluate it, but cannot unequivocally formulate what it is. Academic knowledge offers numerous interpretations, making it easy to become entangled and lost in the labyrinth of definitions.

Personally, I've come to the conclusion that it's not about knowing every definition or dry knowledge; it's about constructing your own understanding of the concept of quality. It's about shaping your knowledge and understanding of quality in a way that enhances your ability to excel in your work, rather than viewing it as something unnecessary, yet shameful not to know.

Quality of usual things

Let’s start with thinking about quality of things which are familiar to everyone. What, for example, came to our minds when we are hearing about quality of pants? Yes, usual human pants and that is it. No additional context.

For me personally, assessing the quality of pants boils down to identifying what makes them good for my needs. As someone who doesn't prioritize clothing, I value pants that are comfortable to wear, easy to purchase, provide adequate warmth in cold weather, and are durable enough to last through multiple seasons. Essentially, quality pants are those that fulfill their function effectively and don't require significant resources from me. In summary, they are garments that I can confidently describe as 'great,' 'comfortable,' 'durable,' and 'affordable.'"

Suppose the minimum criteria for what I consider quality pants for myself are defined. Is this enough to evaluate any pants? Perhaps if I lived alone. But I'm married, and my wife helps me with washing my clothes. Also, she gets upset if I look too unkempt when we're together. And since I love and respect her and her efforts, her opinion matters to me. So, in addition to what I consider quality pants for myself, my wife's opinion is added. But her perspective is slightly different. My thoughts in this case change from "Great, comfortable, durable, and affordable pants" to "Great, comfortable, durable, and affordable pants that are also easy to launder."

We can further develop the idea and consider other interested parties. For example, our cat loves to sleep on folded clothes, so it wouldn't mind if I chose pants that are comfortable for it to sleep on. Is its opinion important to me in this case? Probably not. My "Great, comfortable, durable, and affordable pants that are also easy to launder" won't change to "Great, comfortable, durable, affordable, easy-to-launder pants that are also soft when folded." But I can easily imagine that for someone, their cat's opinion will be important when choosing pants.

In summary, my opinion on quality pants is formed from my personal quality criteria and the quality criteria of those whose opinions matter in this matter.

Is this all?

Perhaps, for the pants I buy for myself, this is all. That is, for the pants for which I am the user.

But let's try to look at quality from the perspective of those who make these pants. Every product has an owner (whether it's an individual, a group of people, or even a whole state - it doesn't matter). In most cases, the highest quality product for them will be one that is produced quickly and with minimal investment, yet capable of generating maximum profit (monetary, reputational, or any other type).

Thus, the business perspective is added to the equation of pants quality.

But that's still not all.

We were talking about pants without any specific context. Without a doubt, the situation would change if we were discussing, for example, a mountain hike, or working in the garden, or a business meeting, or even a space flight. Depending on the situation, completely different quality criteria would apply, and different stakeholders would be added, sometimes even conflicting ones.

Thus, the equation of quality for pants would be multiplied by number of different contexts where they are worn.

You might argue that this isn't about quality. Quality is when a product does what it should and doesn't do what it shouldn't. In other words, these are pants that fit their size, whose material fully matches the stated description, pants that are uniformly well-sewn and without holes. So, I invite you to look at the next picture:

I took this picture from the internet while searching for “expensive ripped jeans”. These are “Balenciaga distressed wide-leg jeans” which costs a little bit more than 2000 EUR at the time of writing this article.

Please take another look at the picture and try to imagine the answer to the question: will the pants be of good quality for the following people: a legionary of the late Roman Empire, a wandering artist of early medieval Europe, a farmer from 19th-century USA, or a representative of the punk subculture.

Quality in Software Development

The idea that runs through all academic theory is that a tester should test an application from the perspective of the end user. The tester should delve into the user's psyche, think, and act like them during testing. Consequently, decisions about what is considered quality and what is not should also be made by the tester, speaking on behalf of the user. But is the user the only or primary stakeholder for any given application, for whom everything is happening? In my opinion, this is a misconception, and it's precisely because of this that many novice testers experience cognitive dissonance while working on real projects.

If looked at from a certain angle, both pants and software have a lot in common: they are primarily solutions to specific problems for certain people in a particular cultural and temporal context.

Then let’s try to apply the same logic.

Without delving into too much detail, let's briefly describe different stakeholder types and determine what "quality software" means to them.

Product owners

For them, the most quality product would be one that is developed quickly and with minimal investment, yet capable of generating maximum profit (monetary, reputational, or any other).

Developers

What constitutes a quality product for a developer? There can be a wide range of answers. Some appreciate the opportunity to work with the latest technologies, while others consider it quality to work on a product with a well-known name or with certain people in the team. For many, the main aspect of quality is the ability to solve interesting problems and implement something new, rather than maintaining an old system. For some, the most important thing is a decent salary.

Imagine next situation: development team want to try to implement new approaches or frameworks or whatever. As a tester you confident that this would lead to instability of the system and potential quality problems for the users. However, this could make developers happier, earn their loyalty and probably attract new talented developers. It turns out that the decision in favor of developers can actually be decision in favor for quality in a long-term.

Marketing

I think no one will argue with the statement that selling something is easy, while selling something else is significantly more difficult. Those involved in sales will probably consider products that sell better to be of higher quality than those that are difficult to sell. One aspect of quality that can be highlighted is "Marketability."

Support

Almost always, products exist for some time and require a certain level of attention after they are delivered to the end user. This includes both technical maintenance and resolving potential issues for specific users. Those involved in support undoubtedly have something to say about how well their product is supported. “Supportability” in some context can be very important.

Customers / End Users.

These are the individuals who will use the product, or those who have purchased the product for their subordinates to use (interestingly, their goals may be directly opposed). For them, a high-quality product is one that requires minimal resources for acquisition and installation, and one that performs what it should while avoiding what it shouldn't.

In summary, looking at this incomplete list, we can formulate a product of ideal quality as follows: A product that was developed with zero cost and time investment. A product that brings maximum satisfaction to developers, is easy to sell and support. A product that is given to end users for free, fully meets their expectations, and makes them infinitely happy.

I believe no one would argue with the assumption that such products do not exist. According to the uncertainty principle, we cannot simultaneously have precise measurements of both the position and velocity of a particle; the more accurately we know the velocity, the less precisely we know the coordinates, and vice versa. According to common psychology, we cannot be liked by everyone simultaneously. Similarly, there's something akin to this with quality, as the well-known adage goes, "No pain, no gain." It's obvious that in the final equation fully describing how quality is formed, no matter how it looks, there are associated variables. A product cannot simultaneously maximize profit and be free for the end user. A product is always a compromise among the interests of all stakeholders. A quality product is one where the compromise is reached at the ideal focal point, where the accents on quality aspects are smartly balanced.

And sometimes the balance is achieved in very unpredictable places, such as in the story from my own experience.

I worked as a tester for a project that was a graphical interface for a database. The primary users were developers and other technical-minded individuals. After several successful releases that implemented the core functionality, the project's CEO came up with a brilliant idea: he introduced a dynamic backlog where users could donate towards specific features. Consequently, in the next iteration, we prioritized the features with the highest donations. Often, these were technically complex tasks that few on the project understood. Sometimes, we had to release blindly, hoping we had delivered what was really requested. After the releases, discussions unfolded within our repository regarding what had been done and because many users were developers, they proposed their own implementations of certain features in case our blind shots were not precise.

At some point, we subconsciously realized that our task was to motivate people to write to us and rationally process their feedback. The most interesting thing was that the number of active users and their subjective attitude towards the product did not correlate at all with the number of errors in the new functionality. Sometimes, it was even the opposite: users actively reported problems and discussed solutions. Essentially, our product was not just a program per se for them but also a place where they could fulfill other needs. Accordingly, our testing strategy was built around this: we spent most of our time on regression testing, and the time that could have been spent on testing new functionality was dedicated to processing feedback and communicating with users.

So, quality.

“Quality is value to some person (who matters)” - Jerry Weinberg’s quote adapted by Michael Bolton & James Bach perfectly suits the principle “the broader the concept the more abstract should be definition.” This definition can be considered non-fragile and serves as a solid foundation for its application.

We cannot be good for everyone, but we can be good for those whose opinion matters to us. Our product should be of quality for those whose opinion is meaningful for the project. Quality engineers should gather and provide information on what is considered "quality" for stakeholders.

Quality is …

Quality depends on the context.

Most likely, profanity on the homepage would negatively affect the quality of any product. However, with less obvious things, it's more complicated. For different business models, different technical implementations, the same solutions can affect quality differently. What is good in one situation may be completely unacceptable in another. Consider a program for training testers. The more diverse and interesting bugs there are, the more we can consider this program to be of high quality.

Quality is subjective.

The same product can be perceived differently by different people. Perceiving a product is a process involving both the product and the person using it. Beauty is in the eye of the beholder.

Quality is dynamic.

A joke that might have been considered funny several decades ago may now be completely unacceptable. The presence or absence of something at one moment in time may be considered quality, while at another moment it may not. The same values of a certain KPI system can become less qualitative over time. A product exists within a specific context, and when the context changes, the quality may change even if the product remains the same.

Quality is not just the product itself.

In a certain context, what happens around the product is equally valuable as the product itself. For example, the speed of bug fixes may be more important than the absence of bugs. Every product has errors that will be found by users. Eliminating them is impossible, so devising a strategy to mitigate the consequences of errors is entirely feasible.

Good documentation that describes the specifics of behavior and possible workarounds can be a highly qualitative solution for difficult-to-resolve bugs.

The true nature of quality will remain unknown.

“Answer to the Ultimate Question of Life, The Universe, and Everything” involves many variables. We may not know all the stakeholders. Even if we do, we may not know with absolute precision which aspects of quality and their significance are important to them. Even if we do, we cannot track how expected quality evolves at every moment.

The question of quality can be likened, for example, to the question of raising a child. Calculating the actions needed to ensure a child grows up happy is a non-trivial task. The number of factors that can influence this is enormous: from the cultural epoch and geographical location where the child is raised, to the genotype of the parents and the mood of the medical staff delivering the child. We cannot account for everything in the equation and have a definitive answer for every case. However, we can assume that certain actions, with a certain probability, bring us closer to or further from the goal. For example, physical violence, regardless of the circumstances, is probably a bad idea. Conversely, ensuring the child spends enough time outdoors is likely a good idea.

Something similar applies to quality.

How we use consept of "quality" in krafteq

Developers joke that sometimes discussing how long it will take to implement a task takes more time than implementing it. Task estimation in development is a technique that improves the predictability of the development process, but sometimes the value of predictability for the project is less than the effort spent to achieve it. In other words, sometimes it's more rational not to estimate.

Understanding and structuring the concept of "quality" will not make the project more qualitative. Sometimes it's more rational for the project to spend this time on other activities. However, if more than one person is involved in testing on the project or there is a desire to improve understanding among all participants in the development process, I believe that description of quality should have a separate section in the testing strategy. The level of detail and size of the section may vary depending on the context.

Within the section, there should be answers to questions about what constitutes quality for the project: which functional and non-functional aspects are highlighted for the project and how important they are. Excessive detail can hinder comprehension, while insufficient detail may not be enough to achieve the goal. Therefore, I recommend starting with a simple model and iteratively adding complexity if necessary. For example, you can start by dividing quality aspects into very important, important, and unimportant categories. Classifying quality aspects and hierarchically dividing them is a fluid process that can change depending on the perspective. Therefore, you can refer to sources such as ISO/IEC 25010 or, for example, Wikipedia, to see what is relevant for your project.

Goal - decomposing and visualizing the quality model. The model should not be overly strict; rather, it should serve as a tool to better understand the product. The model should perform the following functions:

Highlighting areas of responsibility

Sometimes what is obvious to one person is not obvious to another. Discussing quality in general and who is responsible for what is another opportunity to discuss expectations and reality. Also, ensuring certain aspects of quality requires special expertise, and if it turns out that the project will need expertise that is not currently available, it's better to find out about it as soon as possible. For the testing team, this is an excellent opportunity to clarify and formulate the testing mission. Determine what is in the scope of testing and what is not.

Highlighting priorities

Understanding what is important and what can be neglected is one of the key skills in software development. For the testing team, a prioritized quality model is an additional tool for prioritizing testing activities.

Being an additional argument in decision-making

Throughout the product lifecycle, various decisions are made, whether they are technical, organizational, marketing-related, and so on. Often, the choice is between options that are roughly equally good or equally bad. Referring to the quality model can serve as an additional argument for or against a particular decision.

The above-described is the simplest model, which can be further complicated as desired and needed. For example, any complex project has subsystems with potentially different quality requirements. For instance, the importance scale could be expanded to include more values. Functional issues could be subdivided into multiple categories, with importance levels defined for each type as well. These are all details that should contribute to improving the understanding of the product and synchronizing the understanding among all stakeholders.