Aiming for (at least minimum) quality software

Posted by Bart Klinge on January 12, 2024

In the summer of 2022, I had a child; a beautiful son who can’t stop trying to get himself hurt, or worse. Luckily, next to us being vigilant all the time, the world tries to help us a bit. A recent, real-life example I saw was a stuffed elephant. Either they put warnings on their product (like 3+), or they make sure that it is a suitable quality for their sweet spot customer. For my kid (3-), this means that his toy is safe and has no small parts that can almost be swallowed. Because he likes to break things, the toy should also be robust, perform well and, last but not least, be accessible. Kids tend to be on the tiny side, so their hands need to be able to grab the toy.  

For TOPdesk this isn’t any different. To have our product suitable for our customers it should adhere to a certain level of quality. It should have no security leaks that put a lump in your throat, no crashing environments, and be accessible for a wide group of users. Next to that, as TOPdesk, we want to build one product that is consistent throughout all the different components. This means we need to have a quality baseline that is shared among all teams.  

Quality can mean a lot of things, from different perspectives. In general, we don’t need to strive for the highest possible quality but aim for a more “in the middle” approach. This means not choosing the ISO 25010 norm, which splits quality up into 8 quality characteristics and up 31 sub-characteristics, each of them with more standards. Instead, we trust the expertise we’ve got within our company in the form of guilds. They have in-depth, practical knowledge and know-how on the different topics and help us define standards and guidelines. Those standards combined form a shared quality baseline from different perspectives.  

One thing’s for sure, there are lots of guilds and expertise groups within our company. To visit every one of them or have a team member be part of those groups is impossible. Having the baseline from each group written down and stored in different ways and places will likewise be a mess. That’s why the Quality Assurance guild collects all the expectations and combines them in one comprehensive format, a shared quality baseline. 

This written-down, shared quality baseline has multiple purposes. A couple of them highlighted: 

  • It forms a baseline for measuring the quality of our product. 
  • It creates a starting point for discussions on the topic of quality. 
  • It gives insight into where we can improve our tooling to accommodate our development. 

From the Quality Assurance guild point of view, non-functional aspects are just as important as the functional aspects. The stuffed elephant needs to be both cuddly and safe. Both aspects need time and consideration. So, before you pick up a user story or task, you want to make sure that you know what criteria to fulfill during development.  

With that baseline written out, it is quite a bit easier to collect your criteria and start working on your story, while being more confident of what needs to happen and when the work can be considered done. And with done, I mean not only working for customers, but making them happy with a good product where they don’t have to think about quality, simply because it is already there. 

For the people outside of TOPdesk development we call this list of written-down, shared quality baseline the Minimum Quality Requirements (MQR).  

About the author: Bart Klinge

More Posts