Reduce bugs by making the system easy to use


The trend is that systems grow in complexity and that we’re relying on systems of systems to get the needed value. At the same time, we want to deliver new functions to the users faster. This puts pressure on test. The first response is always, we need to automate more. And yes, that’s one part of the answer, but automation isn’t the only way to work more efficiently. The fastest way of getting rid of bugs is before they are made. Of course, we can’t get rid of them completely, but we can work towards less error-prone systems. In this blog post, I’m going to talk about one way we can do that.

Easy to use correctly

A lot of bugs occur because the users use the system differently than the developers imagined. This may be because the users use the system incorrectly. A system should be easy to use correctly, and hard to use in the wrong way. Unfortunately, a lot of systems are rather hard to use …

To use an easy example, a door can open towards the user or away. It’s really irritating when you try to open a door by pushing on it and it doesn’t budge. An easy way to make sure it’s easy to use correctly is to have a handle if the door opens toward you and a flat area if it should be pushed. With such an easy design consideration, most people will use it correctly. Our systems should be just as self-evident.

Another example, from the book Writing Solid Code by Steve Maguire, is a Candy Machine Interface. When you get a craving and just have to buy some candy (believe me, I’ve been there) and run down to a vending machine, you want to get your chosen candy fast. You look up the number, presses the keypad, and watch with horror as the machine delivers something else entirely. Checking, you’ll discover that you pressed the price instead of the number. The example from the book is of an American machine, but I’ve made the same mistake in Sweden. Some vending machines, however, use an alphabetic keypad to choose the candy and on those, I’ve never made a mistake. So, if we ponder the design and figure out these kinds of easy mistakes, we can change the design to make it easy to use correctly.

This is relevant both in how we design the user interaction and in how we design the programming interfaces that our colleagues use. Those of us familiar with the C standard functions, have probably made several mistakes using the function “getchar”, that of course return an integer and not a character … It’s easy to misname in the first iteration. The bad naming tends to linger but to reduce bugs we need to take the time to refactor to make our part of the code easy to use correctly, both by users and by our fellow developers.

This part of reducing bugs is about understanding how other people think and adjust the system to make it easy to use. But of course, that is only part of the solution …

Efficient testing is most efficient when done before the development. Making our systems easy to use correctly and hard to use in the wrong way is an important step to reduce bugs in our systems. There are a lot of examples of systems that work in the opposite way.

What is your favourite example?

Eva Holmquist


Eva Holmquist has more than thirty-two years of professional IT experience, working as a programmer, project manager and at every level of the testing hierarchy from a tester through test manager. She has also worked with test process improvements and in test education as a teacher and with the development of courses including a Swedish ISTQB Foundation certification course and TMAP - Quality for cross-functional teams. She's also an experienced speaker, for instance she talked about the role of the Test Manager in the new digital landscape at TestForum 2021, and she's the author of the book ”Praktisk mjukvarutestning” (Software Testing in Practice). Eva works as a Senior Test Specialist at Sogeti helping clients improve their testing practices using her broad experience in system development, process improvements, and education.

More on Eva Holmquist.

Related Posts

Your email address will not be published. Required fields are marked *