How to Play the Game

The first step in playing QA Gefahren is realizing that you are playing it in the first place. A tester presents a bad solution to an unstated problem, and the next thing you know you're in a heated discussion on the pros and cons of a clearly bad idea. Everything you do to talk the tester out of this bad idea seems fruitless. You're even tempted to capitulate just so that you can talk about something else. Sound familiar?

Understanding QA Gefahren is especially important when dealing with customers. The motto "the customer is always right" can be bad advice in software development. A better motto for software development might be "the customer always knows what he wants but doesn't necessarily have a clue how to implement it." After all, if they knew how to do it themselves, they probably wouldn't have hired you. I've seen engineers spend a great deal of time implementing solutions that they knew were bad after doing little to try to talk the customer out of it. "Well, they're the customer, and they're paying for it" is usually the response.

However, once you understand that you're playing QA Gefahren, you will never let yourself get put in this position. How? By always asking the Magic Question.

Asking the Magic Question

To prevent the anguish of wasting time debating the merits of an obviously bad solution, you should try to immediately shift the focus of the discussion away from the solution and to the problem. Once you've done that, a good solution is usually not far away. You make this shift by asking the Magic Question: "What problem in the program would this solution solve?"

TIP
When you receive feedback in the form of a solution that doesn't seem to make sense, always ask: "What problem in the program would this solution solve?"

The phrasing of the Magic Question is important because it allows you to shift the focus in a diplomatic way. Once you've asked the Magic Question, you and the tester should now be focused on the problem in a way that allows the tester to fully express his ideas. You are listening to the tester, and you are not being insulting or patronizing. Note that a response such as "what a stupid idea" doesn't have quite the same effect.

During the QA process, another important step is to make sure that any written feedback is clearly focused on reporting problems. Your problem report form should include specific sections, such as "Describe the Problem." Give instructions on how to report feedback, and clearly indicate that you are more interested in problems than solutions.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net