A Useable Definition of Quality

Straight in, here it is:

Quality is the absence of unnecessary friction.

Why, you might be asking yourself, do I think that this is a useable definition of Quality?

Quality Requires Context

“What does Quality mean to you?” is a question regularly asked in interviews for software testers. The jury is out for me on how useful the question is, but answers can be an indicator of the candidate’s biases.

We all know that everyone has their own definition of Quality. Our experiences, environment and needs inform our opinion of what good looks like. Some attributes transcend time, others are more transient.

I’d long given up trying to find a single definition of Quality until…

Lightbulb

Lightbulb moments, they can come from anywhere. This one started with a tweet from @Maaikees

It resonated with me because the assertion that people rarely have an amazing experience felt valid. When I’m shopping or using a service, achieving my goal is the most important thing. I want to complete that goal without the need to arggh, urggh or grrr. If anything gets in my way: the service being slow or the UX being overly fiddly, then those noises will be played out in my head, if not very loudly in an audible way.

In the case of free-to-play games, any friction felt by the user before they can become invested is likely to cost the creator money. It’s so important that friction is removed. The experience has to be considered slick to keep the user engaged as there’s no upfront cost to justify their time. Once the player is hooked, the monetisation kicks in. As long as that isn’t too ‘in your face’, a player buying something becomes more likely.

My first consideration was:

“Quality is the absence of friction.”

I liked this because

  1. It can be applied to mostly anything. As testers we typically have to consider the customer, the business and the things we do to build and operate our software
  2. You can invert the statement and ask what about the software causes friction when one is trying to achieve something?

If we pick a perspective from (1) and ask the question in (2), we can derive a list of areas/activities that can be explored. When we explore with this frame in mind, our aim is to discover friction we can remove.

Refinement

Something is useful to me if I can put it in to practice and use it over and over. My first iteration didn’t. I soon realised there was a flaw. That flaw was: some friction is important.

How can that be you might ask? I’ll answer with a very crude example.

Touch screen interfaces need some friction in how they operate. Without a time delay between touching the screen and it acting on that touch, buttons will be fired off with the slightest of brushes. This would suck. As the interface is an approximation of the physical using electrical currents, it’s more susceptible to being activated than your average physical keyboard and mouse. Even physical buttons normally need to be de-bounced to stop you accidentally typing tens of letters instead of one. Try it yourself.

Once you start looking for good friction, you’ll find it everywhere. My definition of Quality had to change, there was too much friction in it.

This brought me back to @Maikees initial tweet. If I were to remove all friction, I’d be just as likely to get frustrated, but in different ways.

I knew there was something here and I wasn’t going to give up. I needed something to qualify the friction, to focus the intent of removing friction from a system, but only if it were necessary. As I processed that thought, out it popped.

“Quality is the absence of unnecessary friction.”

Given that some friction will be designed and built in to the system, any additional friction that emerges is by definition unnecessary.

I’ve used this a lot since.

Using the Definition in Practice

This year in particular I’ve been laser focussed on Quality Attributes. These define the necessary properties of the systems I’m helping to build and operate.

In any context, a handful of Quality Attributes will always be more important than the infinite number we could come up with.

Let’s say that for a given product, its Quality Attributes are:

  • Fast to use
  • Available when customers need it
  • Secure with our customers information
  • Accessible so that any customer can do what they need
  • Resilient to localised failure
  • Designed for our core demographic

These are all Quality Attributes. They collectively describe what good looks like for our system. We do care about other Quality Attributes, but these are the most important. As a Software Tester this is like beautiful music. When I’m short for time, which is often, this list helps me prioritise my testing activities. I know that when I find a problem that directly relates to one or more of these, it will get fixed.

I can apply my definition of Quality to these Attributes to generate questions to focus my exploration.

  • What unnecessary friction might create the perception that user’s experience isn’t fast?
  • What unnecessary friction might make it unavailable to our users?
  • What unnecessary friction makes it appear to or actually be, insecure?
  • What unnecessary friction makes it inaccessible for people?
  • etc.

I can then pick one of these and break it down further. When I’ve got a question I feel like I can explore effectively within a reasonable period of time, that’s my charter for a session of testing e.g.

  • what unnecessary friction makes me perceive the “logging in and updating my personal info” journey as being slow?
  • what unnecessary friction is apparent when trying to add items to my bag, using only the keyboard?

You can also apply this to attributes of how we build and operate our software, when looking at it from different perspectives e.g.

  • the builders – what unnecessary friction exists which makes it harder for us to generate value?
    • which is sometimes called Toil when referenced in the context of SRE
  • the business – what unnecessary friction makes building and running our software less cost effective?

Summary

  • In practice I’ve found it a useful tool to start and/or focus conversations on Quality and testing
  • It appears to be easy to remember
  • It can be applied to any context
  • It doesn’t conflict with the idea that Quality requires context
  • There are variations that you could use instead, if you feel they’re more appropriate
    • “Quality is the absence of harmful friction”
    • “Quality is the absence of friction in areas that matter”

I’d be interested to know what you think, please share your feedback!

Thanks

I need to throw out a massive thank you to @Maaikees for the inspiration.

And also to my regular Testers Hangout friends who’ve put up with me going on and on about it for ages, in particular @BruceOnlyBruce, @christovskia, @SheyMouse, @zaphodikus and especially the now infected @TestPappy

One thought on “A Useable Definition of Quality

Leave a comment