How is your product quality?

When you hear this question, what is the first thing that comes to mind?

It is difficult to answer.

It seems that most software developers, when creating software, are too focused on “correctness”.
It works perfectly
It works as expected
“It meets all the requirements”
“Everything works fine”, etc…

Is that the first thing you think of as a user of software?

No… it’s not. It is usually the third thing that you think about.

Software users (and those who work in software development) are quick to notice the emotive experience. This is the feeling of joy and satisfaction that comes with using the software. It’s how pleasant or painful it is. It makes you feel:
“It’s great!”,
“Best. Software. Ever!”
Or even “It’s horrible… Sooooo bad!”
“I hate this program, and I’m going to tell all my family …”

Users then think about the benefits they receive from the software. It’s usefulness to them in relation to their reasons for using it. The amount they have spent on the software, in time or money, will determine how much it is worth.

Users tend to see the software from a correct perspective.

It’s worth it.

It is probably easier to grasp if you consider any object that isn’t software. Is it your shoes, your chair or your cup of coffee? Are they useful and valuable? Are they accurate?Alt text: This image shows toilet paper in gold with the title 22-karat-gold toilet paper roll $13 Million.

Funny, eh?

Why do we think differently about software development? What is the point of focusing on quality and not quality? This is a mystery that I believe surrounds the art of software development. While we all will have our own hypotheses, we won’t know the truth.

However, I know that testing can be done in a variety of ways that allow us to evaluate different quality perspectives. I am sure that everyone is familiar with scripted testing and how it allows us to verify the correctness of software based upon our expectations. We are all familiar with Exploratory Testing. It allows us to evaluate quality beyond the correctness of software. This is because it revolves around unexpectations and risks. (I hope so, because I know that ET is still a relatively new testing method in the overall scheme of the software industry.

It is rare to think about how these testing methods can be used to evaluate quality beyond software. This is the outputs of the earlier activities in the Software Development Lifecycle.
Extreme example: What is the quality of conversations about the new feature? Or, even better: what is the quality of this new feature idea? Is it useful? Is it useful? Is it right?

It is possible to follow it through. But what about the quality of the requirements artefacts that we write to describe the idea (Epics and User Stories, Acceptance Criteria etc.)? How are they written? Will they be misinterpreted or make assumptions? What are their value? What are their accuracy and relevance to the specific requests of the clients, users, or businesses?

The UX and UI wireframe designs as well as the architecture designs and code designs can be questioned in the same way. Instead of looking at …” from the perspective “what’s its quality?” instead of trying to look at it from the perspective “shifting testing left”.

This is a last blurb. I want to zoom out again beyond software to emphasize how important it is for us to consider in everyday things in our lives. It could be the quality and quantity of your last conversation with someone, the television programme’s quality, or the quality you have with people.

Recall your instinctive response. It’s time that the software industry is more intuitive with the notion of quality.

So I ask you again What’s your product quality?

How do you evaluate the quality of your product to be able answer this question accurately?