Better Software - December 2008 - (Page 37)

middle of an inquisition, so, in order to build rapport, we often began by asking questions about the local community— what to see in town, interesting cultural activities, sporting events, entertainment, and, of course, fishing. We asked where we could find good catfish dinners and Indian cuisine. We also asked where test consultants could do their laundry—always a great ice breaker. These questions were good natured and never scripted. We sincerely wanted to learn. Note that it is generally not a good idea to ask personal questions of interviewees. While acceptable to some, others might be offended, and starting an interview this way is sure disaster. Task Analysis An informative survey of task analysis and associated interview techniques can be found in the book Task Analysis Methods for Instructional Designers by Jonassen, Tessmer, and Hannum. Their description of the critical incident method is a particularly useful questioning strategy and has been used to learn critical elements of many important domains such as how to fly a fighter jet and how to implement exploratory testing. The interviewee is asked to relate a critical incident which illustrates how their expertise was used to resolve an important problem. The following questions frame the interview: • What led up to the incident? • What did you do? • Why was this incident important? • When did it occur? • What was your role at the time? • What was your level of experience and expertise at the time of the incident? These questions guide a narrative that then can be reviewed with the interviewee to identify important tasks, skills, deliverables, and priorities in accomplishing the task at hand. Once the story has been told, a timeline is made and the tasks are reviewed in chronological order. Many gaps can be identified and deeper elaboration of parts of the story comes out during the chronological review. telling stories We encouraged interviewees to share specific, recent experiences to help us learn what they do. There was always a risk that interviewees would start quoting process manuals even though the documents may rarely be followed. Our goal was to learn what really happens. Our questions were designed to elicit a narrative. Many testers have stories of heroic initiatives or terrifying failures, and relating such tales can help expose important evidence. We let the interviewee tell his story with minimal interruption, but occasionally redirection was needed to get back on topic. We were interested in the facts and avoided jumping to conclusions. Interviewers must avoid interrupting the story with suggestions or recommendations; patience is in order. Once the narrative was told, we used non-judgmental, clarifying questions to fill gaps or explore new ideas. We used these tactics to learn about interviewees experiences: • Tell us what you do. (State facts, not theories.) • Tell me a story about when worked. (Describe a positive experience.) • Tell me a story about when failed. (Describe a negative experience.) • What happened the last time? (Describe a recent experience.) • How do you know it’s time to start? (Define the beginning and entrance criteria.) • How do you know when you are finished? That testing is complete? (Define the end and exit conditions.) • Can you give me an example of ? (Relate actions or activities.) • Can you paint a picture for me? (Create a metaphor encouraging an expanded or more complete story.) • How do you do ? (Elaborate on methods, techniques, approaches, and any means of selecting them.) • A solution is What is the problem that it solves? (This question exposes an interviewee’s knowledge of the relationship between actions or objects and his purpose in the project.) • Can you quantify that? (Help the interviewee describe things in objective, measurable terms to allow comparison of elements of the narrative.) • Have you seen any evidence of that? (Encourage the interviewee to point out a specific instance or event that illustrates a stated generalization.) www.StickyMinds.com • You do ; do others do ? (This allows us to learn about other people or roles covering similar actions. We may identify a new source of information or an insight into a widespread practice.) • How did it get this way? (Probe for the root cause of a situation or condition.) • We were talking about Are there other ? (Is the object a member of a set, are there related objects or actions we should be studying?) • When someone says “I don’t know” reply “I think you do know,” then listen. (In some cases the interviewee may state possible reasons or speculations given time to reflect.) • And what are the benefits of that? (Does the interviewee know the value of an action?) • And what difficulties does that cause? (Does the interviewee know the consequence of an action?) Probing Further Some candidates omitted relevant DECEMBER 2008 BETTER SOFTWARE 37 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2008

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.