My contention is that specialist testers know enough to not use the term “non-functional.” And if they are in environments where this term is used, they seek to shift people from this vocabulary. This is one of the ways that I spot specialist testers. Let’s talk about my rationale for this and why I think it’s important.

I’ve already talked quite a bit about how there is (or should be) no non-functional designation, particularly by testers. Admittedly the technical industry is terrible at naming things but to make this point as simple as possible, consider:

• The word functional means “relating to the way in which something works or operates.”

• The word “non-functional” means “not having any particular purpose or function.”

Now, people have argued with me that the above definition is not how they or their teams use the term non-functional. Okay, fine, but then why use the term if you aren’t going to use it correctly?

In my previous posts on this, while I complained about the problem, I didn’t really offer too many solutions or alternatives. Here I’ll do that. Before that, however, let’s make sure we’re all on the same page about what non-functional tends to mean in our industry.

Non-Functional Means …

What is traditionally called “non-functional” tends to be about aspects like usability, performance, security, etc. But each of those speak very specifically to functionality.

• The delivery team may have caused the overall functionality to work more slowly; thus degrading performance.

• The delivery team may have used a reactive-style library that reduces the ability to see when a change happened; thus degrading usability.

• The delivery team may have used two separate implementations for authenticating users, one of which does not connect to the API; thus degrading security.

It’s those degradations that we are looking for; the subtractions of quality. Those always — and I do mean always — manifest as functionality. The delivery team — business folks, programmers, testers — judge the absence of presence of those qualities by how they interact with something and that interaction is functional, by definition.

So, on that point alone, rather than speaking of non-functional, we should consider that there are various qualities that we are concerned about testing for. These are all functional qualities.

Other qualities that sometimes get lumped under the context of non-functional would be scalability, capacity, availability, reliability, recoverability, maintainability, serviceability, and so on. It’s a lot of “-ilities.” These are lumped under the term “qualities.” And they are qualities. They’re just not non-functional.

Sometimes people will frame these as non-functional because they see the “-ilities” as pressures or constraints on the design of an architecture or system running on that architecture. But the only way to determine the presence, absence, or degradation of any of those “-ilities” is via making sure that something is functioning: that inputs are being accepted, actions are being executed, and outputs are being generated.

Again, these are all functional qualities.

Any Alternatives?

What I would like to do is talk about one thing that often gets lost in our discussions around “functional qualities” and (so-called) “non-functional qualities.” It’s the human.

Think of some human qualities.

This would be “trust” or “irritation” or “boredom” or “excitement” or “engagement.” These are the things that happen to people as a result of using what we provide them. There can be increases or decreases in any of these human qualities, based upon how what we provide them functions.

This is the link — weak or strong — between customer problems and business success. Consider that people do have different tolerances for problems and, as an evolving technology society, we’ve grown to accept (or at least tolerate) some aspects of software systems. But when there are many alternatives — or even any alternatives — people can have lower tolerances.

A key area of study in quality, particularly recently, is tolerance thresholds. For people, that is. The idea of “correctness” broadens into “value” when we bring in the tolerances and sensitivities of both technology and people. Those tolerances and sensitivities influence the perception of quality and the ability to produce it.

The Axes of Tolerance

Consumers broadly have tolerance levels you have to consider along two key axes: the barrier to entry and the barrier to use. Imagine your customers asking these questions of your product or service:

• “How hard is it to start using you?”
• “How painful is it to keep using you?”

This gives a hint of design choices to promote as part of quality: the principles of least surprise and least effort. If users feel too much negative “surprise” at how the app works (cluttered, technical issues, slowness, non-secure) or feel it takes too much cognitive effort to use, they’ll abandon.

Yes, there are other factors here like how much competition there exists for what you are providing and how easy or not it is to move to that competition. But the same questions as above are effectively being asked and the same principles will apply.

I suppose we could call these human qualities non-functional and frame our requirements around them. But keep in mind that definition of non-functional: not having any particular purpose or function.

Yet these human qualities do very much serve a purpose and function: they tell us what we are or are not valuing about an experience with some bit of functionality that someone is trying to get us to use. And they do function as a means to prodding us to continue or discontinue using something based on our quality assessments.

Relevance for Specialist Testing

I started this post off with the possibly charged comment that specialist testers should know all this and that the use of an inaccurate term like non-functional is one way to distinguish.

But why do I say that? Or, reframing a bit, why is this something that specialists have to understand and amplify?

Testing is fundamentally a human discipline. It’s about understanding the intersection between people and the products or services we produce. That intersection leads to understanding how people reason about things, how they engage their emotions when using things, where people have low and high tolerances, etc.

All of these aspects form the sensitivities that exist between people and technology. And those sensitivities — conscious and unconscious — are the means by which people determine what “quality” means for them in any given context.

Testing, if treated as a broad discipline that puts pressure on design, provides a way to reason about not just how things work, but how they should work; what kind of value is being provided; why certain value is desired. These are distinctly human approaches that benefit from engagement with the people who will actually use and decide about the quality they feel they are (or are not!) getting.

Specialist testers will articulate all of this in some way.

Point Made?

I don’t know if I’ve managed to convince anyone else except myself.

I’ll close by saying that, ultimately, my rationale here is to get rid of a term that is often mis-used and start framing our activities around human qualities and functional qualities, the former being much more important and informing the latter. This nomenclature shift also keeps the focus on the term “qualities” — aspects that can be present or absent; aspects that add value but that can also degrade over time.