It's fun being a facilitator, in that you get to actively participate in the discussion, and it also gets you up and moving. today I'll be spending most of my time facilitating the webCAST room, so if you see a bald guy in a white AST polo running around, yep, that is me :).
Jess Ingrasselino (@jess_ingrass) works with Bit.ly and worked as a music teacher prior to her tech career. I think that having that background is probably awesome for her being involved in programming and testing. She explained how she went from being a music teacher to quality assurance engineer, and that the processes are actually very similar. When a violinist or violist wants to start playing the Brandenburg Concerto, they don't start with the full piece. They start with the first note, or the first theme, and then they grow from there. There is a focus on building the knowledge and experience with performance and practice. Software testing does much the same thing; we start small with basic concepts, and we practice and apply them.
Testers ask questions, but not just any questions. They need to be targeted and specific, such that they may better understand and learn the product, and focus on other aspects of the product. I'm fond of the definition of testing that I use, which is "Ask the product a question, and based on the answer you receive, ask additional and more interesting questions."
Jess makes a case that borrowing from social science, and understanding the methods used in "qualitative research" makes it possible for us to ask compelling questions The methods Jess will use for this come from Robert Stakes. One of the areas to focus on is "multiple interpretation". What happens when different people with different permissions logged into the system? What is shared? What is unique to certain permissions?
One of the things that is vexing about asking questions is that we can fall into the trap of asking questions that are self-serving. We can easily craft questions that will provide answers that support our own beliefs or biases. We need to be aware of the unintentional ways that we word things or couch questions. Instead of asking "what issues are you having with development?", ask "can you describe for me your interactions with the functional teams in the organization?". Yeah, that seems like a squishy way of asking questions, but it allows the person being questioned to provide an answer free of initial or expected negativity. Instead of asking them to tell us what is wrong, we ask them what they do. In the process, they may more freely describe what is going wrong.
Another compelling answer to questions is silence. Yep. I've seen this many times, and silence means many things. It can mean "I'm thinking" or it can mean "I'm waiting to see if you will walk back that answer before I open my mouth." gauge the silence and don't be afraid to meet the silence with silence. It can often be used as a negotiating tactics. The marks are usually people who cannot get through the quiet and will start saying something, anything, to break the silence. Often, people who negotiate find that they settle for far less than they would if they were more focused on maintaining the silence.
Testers are, or should be, fundamentally curious. Even with that, asking questions is a skill, and it's one that can be developed. I see that studying up on qualitative research is in my future :).