Looking at design types of “bugs” is a challenge

One of the types of "bugs" I tend to report now and then tend to stretch the definition of "bug" a bit. At first glance, you could say bugs are code defects - any time the code does not perform to the design specification, you are looking at a bug. Fair enough. But there is also the case that testers need to report when the design itself needs to be changed. Sometimes what looked good in the design stage may need to be changed once you see the results on screen. It is also possible to develop a poor testing habit when seeing these types of problems. Lets turn back the clock to look at a design choice from the past.

Windows 3.1 had the idea of color schemes. One of the color schemes was "Hotdog Stand" which was a very (to my eyes) garish blend of red and yellow.

We could debate the need for this scheme. I could imagine it was used as an example scheme of what "not to do" with customizing the scheme, though. If you dig into the dialogs, you can customize each of the colors windows displays and perhaps this was used when Windows 3.1 was being shown about what can happen if you make color changes just because you can. Lets go ahead and say this is implemented exactly the way the specification said to implement it.

I could also imagine that no one ever intended this to be used for any "serious" purpose. After all, the name of the scheme is "Hotdog Stand" and not "Law Office Interior."

The last bit of information about this scheme is that it was not the default. If I remember correctly, you had to open about two windows and two dialogs to get to this selection.

So we have a situation in which the code is doing exactly what the specification calls for. Bear with me, because we are now talking about behavior that is closer to 20 years old than 5, and history has already decided if this was a bug. So to make my point, I want to propose this scenario. The design team decided Windows 3.1 should be a "fun" release and want to make this the default that every one sees, and it did seem fun and whimsical.

Then you actually get to see it in action. You go with the concept for a day or two, then you turn it off and install a more moderate theme. Since you are on the team, this is a relatively trivial task. This is where you start to develop the bad habit - you are actively working around a design feature of your application. As the days go by, you can develop the habit of changing to the scheme with a utility, or muscle memory takes over and the first thing you do after logging is execute the keystrokes to turn this off.

At this point, you can't say there is a bug. You may be the only person who does not like this decision, but there needs to be some default. It could be the case that you simply don't like this design.  Again, the feature works perfectly, causes no problems and does exactly what it is expected to do.  The only “problem” that exists is the color selection. 

You may look around one day and notice others are doing the same thing. If you let the habit of working around the bug remain in place, it could cause you to not see the problem (I created) here: no one is using the feature.  But if you do notice the situation in context, it gets interesting and it’s time to gather some actual data.  You can't rely on anecdotal stories about what people are doing. User studies can be useful, beta feedback and other surveys can help find what percentage of users do not like the design. Then you can file a report (likely a bug) to reconsider the design.

Testers are on the hook for many different deliverables and too many times we can get wrapped up in "code" bugs and overlook the design implications. It's a balancing act that we must complete in order to ship software.

Questions, comments, concerns and criticisms always welcome,

John