Chapter 36 -- Learn How to Play QA Gefahren

Chapter 36

Perhaps the most important and challenging part of the QA process is dealing with the feedback you receive. That feedback will come from all sorts of people with all sorts of backgrounds, and some of it will be helpful and some of it won't. In this chapter, I'll focus on dealing with feedback that appears not to be good. Of course, handling good feedback is easy. The suggestion makes sense and will improve the program; you say, "What a great idea," and then act on that feedback. But a lot of feedback isn't so good. In fact, some of it borders on the bizarre, and sometimes the person making the suggestion is very insistent. Worse yet, the person might be your customer or manager, so they aren't going to go away.

I've noticed that most bad feedback has something in common. The tester, QA person, customer, user, or manager—for simplicity, from now on I'll generally refer only to testers—is not reporting a problem, per se, but a change that the person would like to see made to the program. For example, instead of reporting that it's difficult to accomplish a particular task, the tester might suggest adding various menu items and dialog boxes without clearly stating what he wants to accomplish. I like to call this phenomenon QA Gefahren. (Gefahren is German for dangers, perils, hazards, risks, or jeopardy.) When you're playing QA Gefahren, instead of being given an answer and trying to figure out the question, you're given a solution to a problem (and often a bad solution) and you need to figure out what the problem is.

Once I discovered this phenomenon, my next major discovery was how often it happens, which is fairly frequently. In fact, with some testers, it happens the majority of the time. The first reason for this is that testers know what they like and don't like, but they are not software engineers or designers. They come up with a solution to a problem (perhaps without even realizing exactly what the problem is), but they aren't fully aware of the solution's drawbacks or implications for the system as a whole. The second reason is that testers want to be helpful, and they feel that providing feedback in the form of a solution is more helpful. Although this might be true in other fields, in software it is not. The saying "bring me solutions, not problems" is counter-productive in software testing.