I got a message from some folks I know who are attending CAST asking about places to stay and places to eat. That got me thinking, and then typing...
Right out the gate - Traffic Warning! I-196 – the interstate highway that runs East-West through Grand Rapids has major construction going on and is CLOSED in fairly vital parts of downtown Grand Rapids. All the regular downtown traffic is being re-routed down Fulton Street and Michigan Street – the original E-W thoroughfares in the city. This will certainly hinder any driving you wish to do to get to downtown GR or anything on the West side of the city.
Having said that – there are some pretty cool things to do when you’re not CASTing…
Sunday, August 1 – Music Session - 7:00 PM to 9:00 PM
The location alternates between two spots within a block of each other in downtown Grand Rapids. I believe that August 1 will be at McFadden’s Restaurant, 58 Ionia SW. If I’m wrong, the session is at Tavern on the Square, located at 100 Ionia SW . Generally the music is Irish Traditional, with a smattering of Scottish, Cape Breton, Bluegrass and Old Timey, depending on who is there. Experience level of players tends to range from beginner to reasonably advanced and is open to anyone to play or listen. Both locations have drink specials – McFadden’s carries the Guinness/Smithwicks/Harp line-up with domestic beers as well. The Tavern has a nice selection of micro- and artisan beers, including some locally produced, along with food specials for Sunday night.
Every Day the week of CAST
The Frederic Meijer Gardens and Sculpture Park is a short drive up the road from the Prince Conference Center. Through September, they are hosting an exhibit of the work of Dale Chihuly, an artist who works in glass. Well, that’s a bit of an understatement. The exhibit is astounding. More information on the Gardens and the show can be had at their website. They are open until 9:00 PM Mondays and Tuesdays and until 5:00 PM other days.
Wednesday night
A local “collection” (chain is such a wrong term for them) of restaurants runs a special called “Wine Down Wednesday” where all wine from their “glass lists” is half off their regular price. Although owned and operated by the same group, each establishment has their own specialties and really, really commendable items. The nearest installment is The Blue Water Grill. They are a very short drive from the Prince Conference Center and is easily accessible from, well, the whole city. The largest establishment is downtown – The B.O.B. (Big Old Building) – that houses several individual eateries (and drinkeries.)
Other Non-Chain Eateries
One of my favorites is a neighborhood place on the West side of the city, a short distance from Michigan Street (which turns into Bridge Street when you cross the Grand River on, well, a bridge.) Salvatore’s has some very respectable pizza (my favorite is the “Taste of G.R.”) and a variety of typical “Italian” offerings based on the family’s recipes from Sicily. Not a fancy place, but reasonable prices and comfortable environment.
Where to stay?
Beats me - I can’t tell you the best places – I live in a house in the city! However! There are a bunch of hotels, some major name brands, some less so, within 15 or 20 minutes from the Prince Conference Center. There is a Country Inn & Suites that is fairly new a short distance from the Conference Center. About the same distance, and close to a couple of shopping malls, is a Residence Inn. Right in the same area is a Ramada Inn, although this is in a renovated, former Holiday Inn, so not a terribly new hotel. There is also a Staybridge Suites and a Fairfield Inn in the same general area. Those are the ones that are pretty much the closest to the conference location.
Friday, May 14, 2010
Thursday, May 6, 2010
Listening Vs. Hearing
Yesterday I wrote about the role of Testers and how Testers should listen. Pretty straight forward, no? Just listen. Simple.
I find the challenge to be actually listening for what is said. Not for what you think is being said or what you want to hear.
Did you ever play "The Telephone Game"? The one where a person whispers a sentence to another person, then they pass the message on to the next person. They tell the next person and it goes on until it gets back to the first person.
Usually, well, pretty much always, there is no resemblance to the original sentence.
Our challenge - Our biggest problem - is making sure that the message that we are hearing is what is really being said.
I recently had the opportunity to play a testing game with some other testers. Not the dice games of Michael Bolton (and others) and not the card game of Lynn McKee and Nancy Kelln. This game was a simple word game.
I gave clues to a puzzle and then had them ask Yes/No questions around those clues to get the solution. These testers did eventually get the correct answer.
The interesting thing was that when they repeated the puzzle, they stated it differently. It wasn't wrong, just, different. Things that were actually answers to questions were integrated into the "original clues." This changed the dynamic of the puzzle slightly, but not terribly.
It struck me that if a simple game like this can go awry, how much easier is it to get requirements or "business purpose" wrong when you may not be terribly familiar with the field or industry? Can we, as testers, test our own suppositions about what is "right" to the point where we can arrive at the same conclusion of the need as those on whose behalf we are working?
I find the challenge to be actually listening for what is said. Not for what you think is being said or what you want to hear.
Did you ever play "The Telephone Game"? The one where a person whispers a sentence to another person, then they pass the message on to the next person. They tell the next person and it goes on until it gets back to the first person.
Usually, well, pretty much always, there is no resemblance to the original sentence.
Our challenge - Our biggest problem - is making sure that the message that we are hearing is what is really being said.
I recently had the opportunity to play a testing game with some other testers. Not the dice games of Michael Bolton (and others) and not the card game of Lynn McKee and Nancy Kelln. This game was a simple word game.
I gave clues to a puzzle and then had them ask Yes/No questions around those clues to get the solution. These testers did eventually get the correct answer.
The interesting thing was that when they repeated the puzzle, they stated it differently. It wasn't wrong, just, different. Things that were actually answers to questions were integrated into the "original clues." This changed the dynamic of the puzzle slightly, but not terribly.
It struck me that if a simple game like this can go awry, how much easier is it to get requirements or "business purpose" wrong when you may not be terribly familiar with the field or industry? Can we, as testers, test our own suppositions about what is "right" to the point where we can arrive at the same conclusion of the need as those on whose behalf we are working?
Wednesday, May 5, 2010
Requirements and Listening
At the QUEST conference in Dallas, there were many presentations, exercises and discussions around testers and requirements. Along with stressing the importance of requirements to project success, a regular theme was getting testers involved early in the project to help get the requirements “right.”
What was not often discussed was how the testers were to actually help get the requirements “right.” The problem, as I see it, is that there is not a clearly defined argument that can explain to me how being a good “tester” automatically makes a person a good “requirements definer.”
There were a couple of points made that people may have missed. One was part of a hall conversation -unfortunately I don’t recall who made it. This fellow's point was that the testers needed to do more than simply insist on “testable” requirements. Without being able to bring something to the discussion – without being able to help define the requirements, what purpose does a tester really serve at the discussion?
Nancy Kelln gave a presentation on testing in an Agile environment. It was interesting watching some of the attendees grappling with some of the basic premises found in a variety of Agile methodologies. While talking about Stand-ups, she answered the above question very succinctly. She said, in essence, the role of the tester in an Agile Stand-up, is to listen.
Simple, no? Its what all of us are supposed to do anyway, but usually find ourselves thinking about other things for at least part of the time.
By listening – by hearing what is being said, the tester can gain insight into some of the reasoning or logic or problems that are being encountered. If a tester is listening critically, and thinking like a tester, they can hear not only what is being said, but can hear what is not being said.
The thing is, most people who do not work in an Agile environment would argue something like "Well, that's Agile. We don't do Agile." You don't need to work in an Agile environment to do this. At Requirements reviews, or better yet, Requirements gathering/discovery meetings - the same technique can work: listen.
Listen critically, then, don't be afraid to ask questions. These questions can sometimes be straightforward. For example “We’ve talked about regulations changing around Y. Are there any regulations we need to consider for X?"
How many times have you been in a conversation and asked a question because you were looking for insight, and the person you asked it of had an "Ah-HA!" moment because of it? They realized that something was missing and there was an unconsidered possibility or gap.
By asking questions of the experts, the tester can clarify their own thoughts and maybe trigger others to also ask questions. Sometimes, the strength of not knowing things is asking questions and listening carefully to the answers.
What was not often discussed was how the testers were to actually help get the requirements “right.” The problem, as I see it, is that there is not a clearly defined argument that can explain to me how being a good “tester” automatically makes a person a good “requirements definer.”
There were a couple of points made that people may have missed. One was part of a hall conversation -unfortunately I don’t recall who made it. This fellow's point was that the testers needed to do more than simply insist on “testable” requirements. Without being able to bring something to the discussion – without being able to help define the requirements, what purpose does a tester really serve at the discussion?
Nancy Kelln gave a presentation on testing in an Agile environment. It was interesting watching some of the attendees grappling with some of the basic premises found in a variety of Agile methodologies. While talking about Stand-ups, she answered the above question very succinctly. She said, in essence, the role of the tester in an Agile Stand-up, is to listen.
Simple, no? Its what all of us are supposed to do anyway, but usually find ourselves thinking about other things for at least part of the time.
By listening – by hearing what is being said, the tester can gain insight into some of the reasoning or logic or problems that are being encountered. If a tester is listening critically, and thinking like a tester, they can hear not only what is being said, but can hear what is not being said.
The thing is, most people who do not work in an Agile environment would argue something like "Well, that's Agile. We don't do Agile." You don't need to work in an Agile environment to do this. At Requirements reviews, or better yet, Requirements gathering/discovery meetings - the same technique can work: listen.
Listen critically, then, don't be afraid to ask questions. These questions can sometimes be straightforward. For example “We’ve talked about regulations changing around Y. Are there any regulations we need to consider for X?"
How many times have you been in a conversation and asked a question because you were looking for insight, and the person you asked it of had an "Ah-HA!" moment because of it? They realized that something was missing and there was an unconsidered possibility or gap.
By asking questions of the experts, the tester can clarify their own thoughts and maybe trigger others to also ask questions. Sometimes, the strength of not knowing things is asking questions and listening carefully to the answers.
Saturday, May 1, 2010
Conference Mode
I recently returned from a week in Dallas for QAI's QUEST (Quality Engineering and Software Testing) conference. The first two days consisted of either tutorials or a "Managers Solutions Workshop." The next three days were track sessions, presentations, keynote addresses, meals, snacks, coffee, tea, juice and all the trimmings that most people associate with "large" conferences. Its natural, I suppose, to compare it to other experiences.
Last October I was at TesTrek in Toronto, also hosted by QAI. There, I had the distinct and exciting opportunity to meet in real-life two people whose articles, books, blogs, etc., I had read and learned a great deal from. When it dawned on my that the "Fiona" sitting next to me at breakfast was Fiona Charles, I was, well, excited. A few minutes later, Michael Bolton sat down at the same table and struck up a lively conversation (as always!) This was 8:00 Monday morning - the first day of the conference! What a way to start the week!
Later in the week, Michael grabbed me for a round of "testing games" - yes, his case of dice came out and we went to it. In the course of the game, conversation touched on many, many topics, as these things tend to do. Soon, there was a table full of people engaged in ideas on metrics, measurement, performance, general testing. The dice were set aside and introductions made round.
That is when I met Lynn McKee and Nancy Kelln, from Calgary. They were also presenting at TesTrek - and struck me as smart, well spoken, up-and-coming testing and agile practitioners and speakers. We had a wonderful conversation then, and touched base the rest of the week. When the opportunity came to attend QUEST came up, I was excited to hear Lynn and Nancy give their presentations.
My boss/immediate supervisor went with me. We met Lynn and Nancy early on in the week and agreed to meet again for dinner and more testing games over the course of the week.
On Thursday morning, as my boss and I were having breakfast, we compared notes on our impressions thus far. I thought it was interesting how similar our own views were.
In short, it bore out my belief that the most important part of conferences is meeting people and building relationships with colleagues, and maybe developing those relationships into friendships. Don't tell conference planners this, but I find some conference presentations to be less about sharing information and experiences, than they are about the "sales pitch" for their product. (I make a habit of not sticking around for those presentations.)
Don't get me wrong - I like the "roundtable" format of the Managers Workshops at TesTrek and Quest. It allows peers to compare notes on problems that are confronting them right then. I like the presentations that describe "real world" problems and experiences.
Mostly though, I like sitting down with people who do what I do and compare notes:
"Conference Mode" absolutely rocks.
Last October I was at TesTrek in Toronto, also hosted by QAI. There, I had the distinct and exciting opportunity to meet in real-life two people whose articles, books, blogs, etc., I had read and learned a great deal from. When it dawned on my that the "Fiona" sitting next to me at breakfast was Fiona Charles, I was, well, excited. A few minutes later, Michael Bolton sat down at the same table and struck up a lively conversation (as always!) This was 8:00 Monday morning - the first day of the conference! What a way to start the week!
Later in the week, Michael grabbed me for a round of "testing games" - yes, his case of dice came out and we went to it. In the course of the game, conversation touched on many, many topics, as these things tend to do. Soon, there was a table full of people engaged in ideas on metrics, measurement, performance, general testing. The dice were set aside and introductions made round.
That is when I met Lynn McKee and Nancy Kelln, from Calgary. They were also presenting at TesTrek - and struck me as smart, well spoken, up-and-coming testing and agile practitioners and speakers. We had a wonderful conversation then, and touched base the rest of the week. When the opportunity came to attend QUEST came up, I was excited to hear Lynn and Nancy give their presentations.
My boss/immediate supervisor went with me. We met Lynn and Nancy early on in the week and agreed to meet again for dinner and more testing games over the course of the week.
On Thursday morning, as my boss and I were having breakfast, we compared notes on our impressions thus far. I thought it was interesting how similar our own views were.
In short, it bore out my belief that the most important part of conferences is meeting people and building relationships with colleagues, and maybe developing those relationships into friendships. Don't tell conference planners this, but I find some conference presentations to be less about sharing information and experiences, than they are about the "sales pitch" for their product. (I make a habit of not sticking around for those presentations.)
Don't get me wrong - I like the "roundtable" format of the Managers Workshops at TesTrek and Quest. It allows peers to compare notes on problems that are confronting them right then. I like the presentations that describe "real world" problems and experiences.
Mostly though, I like sitting down with people who do what I do and compare notes:
- How do you help people break away from this approach and introduce other, alternative ideas to them?
- When you were working on the transition to Scrum what did you encounter with folks whose experience was more rigid and less nimble?
- When you were trying to develop metrics that mean something to developers and testers, how did you implement that in a way them so they saw them as a tool for their improvement and not a threat to them or their position?
"Conference Mode" absolutely rocks.
Good Morning, Tester-Land!
My name is Pete Walen - Welcome to my blog!
I do software testing for my profession. I am not a "world famous testing guru." I'm just a working stiff who is a practitioner and student of software testing.
I am also a drummer. I've been learning, playing, performing and teaching drumming for far longer than I've had anything to do with software.
I started drumming when I was in elementary school. I learned the same basics that most beginners learn. Like many school-trained drummers in the US, I played with the elementary/middle school band program, I also struggled with solos - playing them for judges and the like. I played in high school band programs - concert and marching band. Somehow my parents always were able to find me a teacher for private lessons so I could improve beyond what the school did.
I migrated to drum & bugle corps in high school. And youth symphony. And collegiate music programs led me to other ideas and approaches and techniques. I played in pick-up groups playing blues and jazz and rock and.. who knows what all. I spent a semester studying in Ireland where I learned yet another form of percussion - the Irish bodhran.
Something happened along the way. When I was in college, I was asked if I would consider teaching privately. That seemed perfectly normal at the time and I could use the extra cash. What student couldn't?
What was different for me was that one of my teachers had the wisdom to know that there could be many paths to achieve the same goal. If I was not understanding something, he very patiently went through the topic from scratch - explaining it in a totally different way, following a different path. When I began teaching drumming, I remembered that lesson and applied it with my own students.
After college, shortly after I started my first "real" computer job (programming COBOL for IBM mainframes) I discovered bag pipe bands. I was too old to play in drum and bugle corps. While teaching beginners was rewarding to some extent, with pipe bands I could still drum! It was also something else to learn and master. I joined the local band and have been involved in some form of drumming with pipe bands since the early 1980's.
These many years of drumming have led me to find rhythms in interesting and unusual places. In the more "usual" places, I hear rhythms not everyone else hears. When I'm playing music, I oftentimes bring those rhythms out in my drumming.
What are rhythms? They are patterns - ideas and concepts that can be found in the expression of music. Like any form of pattern, they can be found in other places as well. Typing on a keyboard gives a specific rhythm that can be identified. Seams in the pavement while driving to work gives an audible rhythm that sometimes mixes with the windshield wipers.
I used to see patterns in code when I was writing software applications (lo, those many years ago) and now I see patterns in applications when testing. There are rhythms in the way each person works. They can be unique unto themselves or they can be shared and common rhythms across teams or groups. Muggles refer to this as "group dynamics." They really are a rhythm (don't tell the muggles.)
My intent, therefore, is to use this space to talk about testing and other topics related to software, and the patterns and rhythms I see and hear and participate in around me.
I do software testing for my profession. I am not a "world famous testing guru." I'm just a working stiff who is a practitioner and student of software testing.
I am also a drummer. I've been learning, playing, performing and teaching drumming for far longer than I've had anything to do with software.
I started drumming when I was in elementary school. I learned the same basics that most beginners learn. Like many school-trained drummers in the US, I played with the elementary/middle school band program, I also struggled with solos - playing them for judges and the like. I played in high school band programs - concert and marching band. Somehow my parents always were able to find me a teacher for private lessons so I could improve beyond what the school did.
I migrated to drum & bugle corps in high school. And youth symphony. And collegiate music programs led me to other ideas and approaches and techniques. I played in pick-up groups playing blues and jazz and rock and.. who knows what all. I spent a semester studying in Ireland where I learned yet another form of percussion - the Irish bodhran.
Something happened along the way. When I was in college, I was asked if I would consider teaching privately. That seemed perfectly normal at the time and I could use the extra cash. What student couldn't?
What was different for me was that one of my teachers had the wisdom to know that there could be many paths to achieve the same goal. If I was not understanding something, he very patiently went through the topic from scratch - explaining it in a totally different way, following a different path. When I began teaching drumming, I remembered that lesson and applied it with my own students.
After college, shortly after I started my first "real" computer job (programming COBOL for IBM mainframes) I discovered bag pipe bands. I was too old to play in drum and bugle corps. While teaching beginners was rewarding to some extent, with pipe bands I could still drum! It was also something else to learn and master. I joined the local band and have been involved in some form of drumming with pipe bands since the early 1980's.
These many years of drumming have led me to find rhythms in interesting and unusual places. In the more "usual" places, I hear rhythms not everyone else hears. When I'm playing music, I oftentimes bring those rhythms out in my drumming.
What are rhythms? They are patterns - ideas and concepts that can be found in the expression of music. Like any form of pattern, they can be found in other places as well. Typing on a keyboard gives a specific rhythm that can be identified. Seams in the pavement while driving to work gives an audible rhythm that sometimes mixes with the windshield wipers.
I used to see patterns in code when I was writing software applications (lo, those many years ago) and now I see patterns in applications when testing. There are rhythms in the way each person works. They can be unique unto themselves or they can be shared and common rhythms across teams or groups. Muggles refer to this as "group dynamics." They really are a rhythm (don't tell the muggles.)
My intent, therefore, is to use this space to talk about testing and other topics related to software, and the patterns and rhythms I see and hear and participate in around me.
Subscribe to:
Posts (Atom)
