Understanding the difference between an unhelpful and vague question, and asking questions that are targeted and specific.
How to Ask Questions the Right Way
I think it’s impossible to ask "what is Software Testing?" without also focusing on "how to ask the right questions". It’s entirely possible to push buttons and "ham fist" our way to problems, but are those problems significant? Do they really matter to the end user or the stakeholders? They may, they may not. The problem is that, if we report a lot of "unimportant bugs", or if we ask "insubstantial questions" regularly, our knowledge and efforts will often be dismissed, or at the least given lower priority.
Because we are asking the wrong questions. More accurately, we are asking questions in an ineffective way.
The recommendations listed below come from a site that is dedicated to helping answer questions on various hacker forums.
Note: Hacker in this case means anyone that works with code and tries to make changes, modifications and enhancements to see what those changes do. This is not to be confused with a "Cracker" who works to disrupt services, steal information or break into systems for fun or dishonest profit. From the site:
"So, while it isn’t necessary to already be technically competent to get attention from us, it is necessary to demonstrate the kind of attitude that leads to competence — alert, thoughtful, observant, willing to be an active partner in developing a solution."
Testers need to approach problems or issues in the same way.
Before You Ask
Let’s approach this from the aspect of "before you start testing". What are some things you might want to make sure that you know?
You may want to make sure you are aware of industry standards or what other organizations who make similar software are doing.
You may want to understand alternative ways of doing things that makes sense in that particular world. Testing a photo editor will be much more focused and understandable if you understand actual photographic techniques. In testing, we refer to this as having "domain knowledge", or at least an understanding of where the area we are going to test exist.
How can we be sure we are asking the right questions?
1. Try to find an answer by searching (internal) the existing documents, specs, issue tracking system, or (external) forums that deal with this kind of application(s).
2. Try to find an answer by searching the Web.
3. Try to find an answer by reading the product manual (if there is one).
4. Try to find an answer by reading a FAQ (if one exists).
5. Try to find an answer by inspection or experimentation.
6. Try to find an answer by asking a skilled friend.
7. Try to find an answer by reading the source code (if you have that skill and have access to it).
When you ask your question (whether it be a product or a person), display the fact that you have done these things first. Better yet, display what you have learned from doing these things. Include things like "I searched google and could not find an answer based on [words used]. . . " This helps set the parameters that others will understand.
Take your time.
Do not expect to be able to solve a complicated problem with a few seconds of searching.
Read and understand. Give the problem some thought before approaching experts (or before testing or reporting bugs). Trust us, they will be able to tell from your questions how much reading and thinking you did, and will be more willing to help if you come prepared.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all.
Beware of asking the wrong question or one based on faulty assumptions. You will earn an answer (from a product under test or from an expert), if you earn it, by asking a substantial, interesting, and thought-provoking question.
When asking individuals for clarification, make it clear you are able and willing to help in the process of developing the solution.
“Would someone provide a pointer?”
“What is my example missing?”
“What should I have checked?”
Are more likely to get answered than
“Please post the exact procedure I should use.”
By doing the former, you are making it clear that you’re truly willing to complete the process if someone can just point you in the right direction.
Examples of Good/Bad Questions (from previous site)
Good and Bad Questions
The following text is almost verbatim from the above referenced site. Let’s discuss if we want to change them or present them as is. I think with proper attribution, we can present them as is, as I think the tone of the questions and responses are good.
These are questions about the same problem, one asked in a stupid way and one in a smart way.
Stupid: Where can I find out stuff about the Foonly Flurbamatic?
This question just begs for a response of "RTFM" or "STFW" as a reply. These stand for "Read the [Expletive Deleted] Manual" or "Search the [Expletive Deleted] Web". For this course, I’ll instead use the much kinder, albeit still slightly sarcastic acronym "LMGT". This stands for "Let Me Google That", which gets the same message across. Developers help those who help themselves, and you will get a variation on these types of responses if you ask a question based on something you could have easily looked up yourself.
Smart: I used Google to try to find “Foonly Flurbamatic 2600” on the Web, but I got no useful hits. Can I get a pointer to programming information on this device?
This one has already done the LMGT step, and has come up empty handed. This simple step alone will change the responses the tester gets, because they have invested some of their time and energy to learn about the product.
Stupid: I can’t get the code from project foo to compile. Why is it broken?
This question is placing the blame on someone else. While that may be the case, it’s bad form to automatically assume that someone else has done something wrong. It also shows a lack of humility, and the developers in question will respond in kind.
Smart: The code from project foo doesn’t compile under Nulix version 6.2. I’ve read the FAQ, but it doesn’t have anything in it about Nulix-related problems. Here’s a transcript of my compilation attempt; is it something I did?
Notice the difference in tone. The first thing to see is that they have specified the steps they have already taken, their experience with looking at the FAQ, and most importantly, not assuming that the problem is external to them (i.e. they are not blaming other people, but asking if they have missed something).
Stupid: I’m having problems with my motherboard. Can anybody help?
The first thing to notice about this question is. . . what? More like a lot of whats. What type of motherboard? How is it installed? What CPU or RAM are you using? What CMOS? And a bunch of other questions that we would have to ask just to get to the point of being able to answer even a small part of the possibilities. Most won’t even bother, and will likely just ignore the question.
Smart: I tried X, Y, and Z on the S2464 motherboard. When that didn’t work, I tried A, B, and C. Note the curious symptom when I tried C. Obviously the florbish is grommicking, but the results aren’t what one might expect. What are the usual causes of grommicking on Athlon MP motherboards? Anybody got ideas for more tests I can run to pin down the problem?
This is good overall protocol whenever dealing with an issue of any kind. In fact, the above question would make for a good bug entry all by itself (more on bug reporting later).
The reason this set of questions will likely get attention is that the tester has applied a problem-solving approach to the issues they are seeing. They have reported what they tried to do to make it work, and has also made a guess as to what the problem might be. They may be wrong, but it shows the programmer that they are working towards isolating the issues and understanding the problem.
Additionally, instead of saying “Give me an answer”, the tester is asking “Please help me figure out what additional diagnostics I can run to understand the problem”
How To Ask Questions The Smart Way
Copyright © 2001, 2006 Eric S. Raymond, Rick Moen