What Is Quality?

For a long time I didn’t put too much thought into definition of quality. I just considered it to be an attribute. Something that is either good or not good. What’s so difficult about it?

Now when I look back – the very definition of quality is one of the main reasons that software development is so challenging.

It’s about value

I don’t know when I first heard Jerry Weinberg’s definition of quality. Maybe it was on BBST Foundations course. Or perhaps on Twitter. Or a blog post. Can’t remember.

Nevertheless, it changed my thinking. It changed how I view the world.

Jerry Weinberg defines quality this way:

Quality is value to some person

When I saw this – it made sense. I realized that we (people) like different things. Whether it’s food, drinks, movies, music, hobbies or books. We have our own preferences. One likes science fiction movies. Other one can’t stand historical or future related movies. Third wants to see only comedy. And the list goes on.

Why wouldn’t we also view software from our own perspective and value the things that are important for us? Sure, there are people who value same things, but there’s as much variety between what people value on software. Or products generally.

Who matters?

While quality is value to some person, that doesn’t mean that we’re trying meet everyone’s needs & requirements. There’s a lot of people on this planet. Only a small proportion is most likely the segment of people you want to impact on. Those are the people who matter (James Bach has added “who matter” to Jerry’s definition: “Quality is value to some person who matters“) And they’re not necessarily only customer or end-users. I think marketing, documentation or perhaps your CEO have their opinion about the quality of your product. If you’re interested of hearing their opinion and act upon it, then they matter also.

When we build software, we would like to meet the needs of the people who matter. Perhaps we have made thoughtful decisions about who we are concentrating on. Rational decisions you might say. But how rational they actually are?

It’s also about emotions & politics

Jerry Weinberg discussed on Agile Impressions (originally in Quality Software Management Volume 1: Systems Thinking – as far as I know) how our decisions about quality are political, but also emotional. 

While we would like to believe that our decisions are political decisions that are based on rational thinking – we can’t ignore our emotions and how they affect to our decisions about quality.

Considering that we all have our personal relationship with software. Meaning that we value things that vary from many people. How unlikely do you think it is that these personal preferences wouldn’t affect to our decisions about quality? That we wouldn’t make decisions that drive the product toward something that we personally would like to use? Or report bugs that are personally bugging us? Or criticize the usability based on what is good usability to ourselves?

I’m not saying that our personal preferences shouldn’t affect to our decisions. I’m saying though that we need to consider the possibility that this is happening. No matter how rational we want to see ourselves.

But – what is value?

I’ve seen Jerry’s definition of quality mentioned countless times. On the other hand, I haven’t seen his definition of value mentioned that often:

What are people willing to pay (do) to have their requirements met

There’s at least two perspectives that you can look this definition from.

1. What are people (developers) willing to pay (do) to have their (e.g. end-users) requirements met
2. What are people (end-users) willing to pay (do) to have their (e.g. end-users) requirements met

I guess you could add more variations to this, but let’s focus these two. In first case developers (i.e. programmers, testers, product owners, business analysts – anyone who is involved with making quality related decisions) put effort on meeting end-users requirements. If you’re building an app like Wedding Make Up on Google Play Store, you’re not probably putting too much effort on meeting my needs. That being because I’m not (probably) part of your people who matter.

On the other hand, as an end-user, app has basically no value for me. So, I’m not willing to pay or do anything to get that app.  Sometimes there’s a product that has value, but I might need to register myself to a webpage or pay X amount of money, and that will turn the value to negative. It depends.

If only our needs were static

While figuring out what people (whose lives our software touches) value is useful, there’s additional challenge. That’s the dynamic nature of our needs. They tend to change while time passes. Reasons vary. It might be that I get used to your product and will be expecting enchantments. It might be that I had one time need for your product (e.g. doing a video from the slides & audio of my talk). Or it might be that competitors add all kinds of features that I’m expecting from your product also. Needs are not static.

This leads us to Weinberg’s definition being extended (‘at some time’ being added by Michael Bolton – as far as I know) to:

Quality is value to some person, at some time, who matters.

What’s the impact of all this to my work as a tester?

This was not probably an easy to follow blog post. Largely because my thinking hasn’t settled related to this topic. I hoped that writing all this would help in it, but not sure it did that.

All this has though affected to my work as a tester. Perhaps the biggest impact is in realizing that I can’t put too much weight on my subjective opinion about the quality of the software. This being because it’s based on what I personally value on software. I’ve realized that it CAN be important, but it CAN also differ a lot from people who use our product. Own feelings & emotions act as a trigger for further investigation, but I need to also approach bugs & findings from other angle than my subjective angle.

 

Testing Quadrants As A Communication Tool

 

 

Here’s a modification of Agile Testing Quadrants by Lisa Crispin & Janet Gregory (originally by Brian Marick). I’ve used this as a communication tool in our current project. As it might raise few eyebrows, let me explain couple things.

(Also want to mention that I’ve modified the Quadrants a bit from how they are actually on the project – i.e. what we are focusing on & what we are not focusing on)

Context & Background

I explained very briefly my current context on my previous blog post: Striving For Early Feedback

Besides that, I’ve had challenges with explaining what we (our test team of 2) is testing, with respect to all others on the overall system. Then I was listening Paul Gerrard’s talk (Agile Test Strategy) a while ago. There he mentioned Agile Testing Quadrants. Of course I knew them and had seen them several times before. I just couldn’t come up with the idea of them being useful in my current context.

I first used Crispin & Gregory Quadrants while describing our approach to one vendor. There was though many things that I didn’t personally see useful (e.g. Automated & Manual or ET being on Q3). Then I had a discussion with Jari Laakso on Twitter. After that discussion I realized – with the help of Jari – that I can modify the Quadrants in any way I want. And that I did.

Things I want to emphasize

With my modified Quadrants I want to emphasize basically 4 things:

1. Our testing being a division between testing the expected vs. unexpected – Or in other words ‘Focusing on Expectations’ vs. ‘Focusing on Risks’
2.  We are intentionally not focusing on testing certain things (e.g. unit testing) – but are aware of how that’s being done by certain people
3. All testing is based on exploration – in other words: Learning. We don’t test for the sake of testing, but to learn more about our product with every test
4. Testing mentioned on the top is about People and not only about Business. It’s about people whose lives our product touches (Marc McNeill – according to Dan North)

What was challenging

Perhaps the biggest challenge with Quadrants is that it’s quite challenging to fit different forms of testing there. For example in performance testing we might be testing the expected (e.g. explicit documented requirements), but also regardless of those. That would mean that performance related testing goes to many places.

In the end I found that that particular challenge was something I can live with. Considering I can emphasize those other things with the model.

What next?

I don’t know yet if I will continue to modify and improve the model to make it more useful while describing our testing approach. Or if I will use this model later on the following projects or companies. I might. Or I might not. What matters now, is that it makes it a bit easier (from my perspective) to explain what our testing looks like.