Why We Should Stop Using 'Non-Functional' to Describe Important Aspects of Software
on Blog, Testing
Welcome to another blog post! As usual, these are my opinions. Not facts. Disagree with anything I’ve said? Get in touch, let’s talk. Happy to have my mind changed. Having said that…
First off, describing requirements as ‘non-functional’ is rubbish. Second off, describing testing as ‘non-functional’ is also rubbish. Here’s the dictionary description of that adjective:
1: not having any particular purpose or function.
“in some dolphins and small whales, teeth have become virtually non-functional”
2: not operating or in working order.
“the cooker was non-functional except for the hotplate”
See what I mean?
And what goes into the ‘non-functional’ grab bag? Things like accessibility, performance, security, testability, and usability. These are important parts of well-crafted software! Underestimating, or under-prioritising them, is not going to end well. Yet that’s what happens in a lot of projects.
Also, let’s agree to be careful not to oversell how much information we can give about these topics. I am a tester. I ask questions. My aim is to reduce risk. I can create simulations to give information related to performance testing. I use my past experience to try and find vulnerabilities in whatever is under test. I can run an accessibility scanner. I’m no specialist. I am, in a acceptable way, limited. This is not to say that my input is useless; indeed, my best guess might be adequate for the size and scale of my project. But we should always be aware of those limitations.
But is this a cheerless post? I don’t think so! Testing is all about context. Don’t blindly use acronyms. Be confident. Define what’s going on, how it’s going to happen, what you can contribute, and what the limitations are. Do it pragmatically. It’ll work out, I promise.
