First, I want to make sure everyone is aware... I'm OK.
The short story is that I have a broken leg. The slightly longer story is that I have a tib-fib fracture near my right ankle, and it resulted in my needing to have surgery to repair it. So am I really going to tell a testing story out of my accident? Absolutely :).
So how did this all happen? It happened while I was riding my skateboard from work to the CalTrain station. the stretch of roads from Folsom street to Townsend street in the south of market area is mostly flat. I decided that it would be kind of fun to break up the walk by skating to an from work. Of course, when a person skates on a sidewalk there are the cracks, and the separation points, and other irregularities that we try to navigate around or go over. To better allow for the transitions, I invested in bigger and softer skateboard wheels, and for the most part, they were doing fabulous.
Yesterday, as I was skating down the street, my board hit something. It may have been a crack, it may have been a pebble, but whatever it was, it stopped my board cold. My board stopped, but I didn't. As I found myself off balance, my natural reaction was to try to stand up and walk it out, a move I've done hundreds of times before. Well, this time, I came down at roughly a 45 degree angle onto my ankle, and the resulting velocity and pressure broke the tibia near my ankle and then broke the fibula higher up about half way between my ankle and knee.
As I tried to stand I saw the position of my leg, the tell tale angle... it's a break all right. With that, I just scooted myself back to the curb, sat down on my board, put my broken leg in the least painful position I could, and started chatting with the person who stopped to see if I was OK and who dialed 911 on my behalf. As we talked, the said that I looked remarkably calm. Was I in shock? Was I not absorbing the situation? I smiled and said "well, I'm a Scoutmaster, and as a Scoutmaster, I've taught my boys over the years how to deal with these situations. Rule #1 is remain calm. Rule number 2 is assess the damage, and do a little movement as possible so that "the professionals" can deal with the situation. In this case, the professionals were the emergency response team from a fire station South of Market. They evaluated the situation, made a quick splint to help deal with the blunt force trauma to my leg, and then away we went to the hospital.
As radiology looked at the situation, I marveled at the different techniques and methods they used. Because I couldn't keep my leg still, they had to find various ways to immobilize my foot while maneuvering the machine to get a shot (I was on a gurney and I was not moving if they had anything to say about it). The radiologist took it in stride and exemplified some of the best exploratory testing techniques I have ever seen. His charter, get the shot of my leg without me erupting into painful spasms. Radiology team for the win :).
I was brought back to the emergency waiting area, where the orthopedic surgeon had a look at my X-rays... and then told me the real severity. I'll admit it, my heart sank. they were going to have to operate and insert a plate and pins/screws. this meant general anesthetic, which outside of wisdom teeth when I was 24, I'd never dealt with before. I didn't remember much from this time as i came into the room, they introduced the anesthesia and the next thing I knew I was awake with what looked like a beach ball wrapped around my foot.
So right now, I'm dealing with the aftermath of all of this, and I'm in a thoughtful mood, so I couldn't help but explore this situation from the viewpoint of a software tester. In so many ways, this situation resembles my real work life step for step. How so? It it common to be hyper focused when it comes to the big things. Were I to be skating a bowl or a vert ramp, the odds of my getting a break like this is actually a lot less. The reason? Hyper focus keeps us safe. It keeps us conditioned and tuned up. Even though we may miss a hit or we may fall, we are primed for that fall, and so the damage is not as bad, if there is any. No, the real catastrophic situations, where the walls come tumbling down, are often from a piece of neglect, or from not paying attention, from complacency. Additionally, we tend to take the easy stuff for granted. Thus we let down our guards. We don't give those areas much though, and sure enough, they are the ones that can come back and bite you.
So in my testing world, I'm taking a closer look at the areas that I've less laser focus; the common, pedestrian areas that I feel I know so well. How well do I know them, really? Is there a piece of concrete waiting to break loose (metaphorically speaking)? Will I recognize it if I see it, or will i have to "hit" it to become aware?
I had a talk with my sister from the hospital room... this is the sister that's the professional dancer and television/movie stunt-person. As I talked about the different reactions from people (even split from "oh, what a bummer to "dude, why are you riding a skateboard at your age?!"), she said something that helped put it into perspective... this is the price we pay for an active lifestyle. We could remain perfectly safe, but then we would miss out on many of the really cool things that life has to offer. As in testing, we could also play it safe, and follow the script, and look that the features in the scripted manner that is expected and that many are accustomed to. It's safe, but it's a bit boring. Exploration and taking risks is fun, and we often learn way more in that process. While I'm certainly smarting from this recent situation, and will be for some time to come. I'd like to believe my skateboarding days are not over. They are as far as a commute option, that's for sure, but the joy of riding and getting a good velocity, carving turns on the street or a black top well away from cars and pavement cracks, there's a place that I can open up, be focused, and feel the love again. One day at at time, though, of course :).
Tuesday, August 30, 2011
Monday, August 29, 2011
Next Weekend Testing Session? That Depends on "Who’s Driving"
So I’ve been thinking about this for a while now. Weekend Testing Americas has been active and running now for 9 months. We’ve had a range of sessions running from very good to mediocre and everything in between. Some have asked me when the sessions take place, and why aren’t they more frequent (August being a notable exception; we did three sessions in August, and that’s definitely a spike that will be hard to duplicate).
Sessions truthfully happen about every three weeks, and they happen every three weeks for a very simple reason… it’s about the amount of time I can guarantee a Saturday with enough time before, during and after the event to put everything together as a facilitator. In short, the sessions happen on the days that I can actually drive the bus.
Often I get asked “so when’s the next session?” It’s obvious people enjoy the structure, they enjoy the events and they enjoy the way that the process works, even when we bicker a bit here and there about the way that the events get put together. Over the past several meetings, we’ve addressed methods for how to conduct sessions and the things that people need to know if they want to conduct them. So now it’s time to do the next thing… when’s the next Weekend Testing Session? That depends on who’s going to drive it… and for WTA-19, it will not be me.
WHAT?!! Heresy!!!
Nope, it’s a little bit of tough love and a realization that I’m trying to close the loop on a dangerous loose end. It’s soccer season. My daughter plays on Saturdays. I want to watch her play. My son’s a Boy Scout and I’m his leader, we’re heading into the peak time of scouting events before winter comes. There are several testing activities and conferences coming up that I will be participating in. In short, I can’t guarantee that regular availability I’ve had over the past several months. It would be a shame to shutter something that’s working so well for so many people, and truth be told, I don’t want to. I care enough about this program that I want to give a little EDGE love to others, so I plan to do that, and will help any and all who want the experience, but our next session will have another driver. I could pick about half a dozen people who I think would do a great job, but I’d prefer hearing from those people directly, of course.
What do I mean by “driving”? I mean that you would:
• Develop a testing mission and charter(s). Note: you need not do this alone; many WTA participants are more than happy to help develop these with you, as am I.
• Announce the session.
• Create the permanent link to the session.
• Email and Tweet session details periodically leading up to the event.
• Set up the group so that participants could chat via Skype and add users to the session.
• Announce the mission and test charter(s)
• Watch the clock and make sure that we keep on time.
• Encourage questions, and reach out to participants who may not be actively participating.
• Mentor new testers, those who may not have any clue how a Weekend Testing session actually works.
• Lead the debrief/discussion about the current session, and explore the ideas and challenges seen.
• Publish the chat session and an experience report, and then alert any and all interested parties in the existence of the final report.
And that’s it, really :).
It sounds daunting, but in reality, it’s fairly straightforward and it’s actually quite fun to do once you get the hang of it. I’ll be happy to be co-pilot, and to help negotiate the sessions (note: I wasn’t given the green light to fly these solo until I did a few of them under the watchful eyes of Ajay Balamurugadas and Markus Gaertner, so of course I would give the same guidance to anyone else who would step up).
As we say in Scouting… “see one, do one teach one” is a powerful concept, and it really is that simple. If you’ve participated, you know how it works. If you have helped anyone in a session before, you’ve facilitated. If you’ve facilitated, you have the skills to lead. Is Weekend Testing Americas worth something to you? Is it worth enough to ensure its health and longevity? If so, I’d really like to talk to you and arrange for our next session, but be sure, there will not be a next session unless someone else climbs into the pilot’s seat.
Gang, really and seriously… it’s your move :).
Sessions truthfully happen about every three weeks, and they happen every three weeks for a very simple reason… it’s about the amount of time I can guarantee a Saturday with enough time before, during and after the event to put everything together as a facilitator. In short, the sessions happen on the days that I can actually drive the bus.
Often I get asked “so when’s the next session?” It’s obvious people enjoy the structure, they enjoy the events and they enjoy the way that the process works, even when we bicker a bit here and there about the way that the events get put together. Over the past several meetings, we’ve addressed methods for how to conduct sessions and the things that people need to know if they want to conduct them. So now it’s time to do the next thing… when’s the next Weekend Testing Session? That depends on who’s going to drive it… and for WTA-19, it will not be me.
WHAT?!! Heresy!!!
Nope, it’s a little bit of tough love and a realization that I’m trying to close the loop on a dangerous loose end. It’s soccer season. My daughter plays on Saturdays. I want to watch her play. My son’s a Boy Scout and I’m his leader, we’re heading into the peak time of scouting events before winter comes. There are several testing activities and conferences coming up that I will be participating in. In short, I can’t guarantee that regular availability I’ve had over the past several months. It would be a shame to shutter something that’s working so well for so many people, and truth be told, I don’t want to. I care enough about this program that I want to give a little EDGE love to others, so I plan to do that, and will help any and all who want the experience, but our next session will have another driver. I could pick about half a dozen people who I think would do a great job, but I’d prefer hearing from those people directly, of course.
What do I mean by “driving”? I mean that you would:
• Develop a testing mission and charter(s). Note: you need not do this alone; many WTA participants are more than happy to help develop these with you, as am I.
• Announce the session.
• Create the permanent link to the session.
• Email and Tweet session details periodically leading up to the event.
• Set up the group so that participants could chat via Skype and add users to the session.
• Announce the mission and test charter(s)
• Watch the clock and make sure that we keep on time.
• Encourage questions, and reach out to participants who may not be actively participating.
• Mentor new testers, those who may not have any clue how a Weekend Testing session actually works.
• Lead the debrief/discussion about the current session, and explore the ideas and challenges seen.
• Publish the chat session and an experience report, and then alert any and all interested parties in the existence of the final report.
And that’s it, really :).
It sounds daunting, but in reality, it’s fairly straightforward and it’s actually quite fun to do once you get the hang of it. I’ll be happy to be co-pilot, and to help negotiate the sessions (note: I wasn’t given the green light to fly these solo until I did a few of them under the watchful eyes of Ajay Balamurugadas and Markus Gaertner, so of course I would give the same guidance to anyone else who would step up).
As we say in Scouting… “see one, do one teach one” is a powerful concept, and it really is that simple. If you’ve participated, you know how it works. If you have helped anyone in a session before, you’ve facilitated. If you’ve facilitated, you have the skills to lead. Is Weekend Testing Americas worth something to you? Is it worth enough to ensure its health and longevity? If so, I’d really like to talk to you and arrange for our next session, but be sure, there will not be a next session unless someone else climbs into the pilot’s seat.
Gang, really and seriously… it’s your move :).
Saturday, August 27, 2011
How Fragile is Your System?
My kids had a somewhat sad, but I think important, lesson taught to them this week. We have been involved in a process since March with our main fish tank in our house; we have a 65 gallon tank that has a colony of convict cichlids (Archocentrus Nigrofasciatus). In March, a large clutch of babies was spawned, and we've been actively working to raise them. The tank is well maintained, it has a lot of filtration, and it has a large capacity air pump feeding air stones (read: a lot of bubbles in the tank background).
Recently the kids were playing upstairs, and as they are oft to do, roughhousing and jumping around. Unbeknownst to them, they knocked the air line from the air pump to the air stones. Earlier in the week, they helped me clean out the tank and do a water change, too. They didn't realize it, but these events conspired to make a fatal flaw in our system apparent.
I came home from work Thursday night and the kids said "hey dad, you should go up and feed the fish, they look really hungry!" I thought this was an odd statement, so I went up and inspected the tank. What I saw was all of the fish hovering at the surface of the water, some on their sides, their gills pumping rapidly. As I looked and saw the tank, I heard the air pump running louder than normal. I looked down and saw that the air hose was no longer attached. I quickly reattached it, which allowed the bubbles (and air) to flow back into the tank. However, this was only part of the problem. I also noticed a tell tale sign of what also wasn't normal; there was no splashing water from the filter return. The water was just running under the surface because the hose had slipped down below the water line. Add to that the fact that we also have about 70 juvenile fish, each now averaging an inch in length or a little more, along with the older denizens in the tank. Individually, any of these would not be a problem. Taken together, though, what resulted was a massive failure to the system.
We had to act quickly, so I hooked up the water siphon to the bathroom sink and drained out about 20 gallons of the tank water. this served two purposes. first, it allowed for agitation of the surface by the filter return, thus creating an oxygen exchange again. This mixed with the bubbles from the air filter would allow the oxygen to return to the water. Second, I turned on the hose and briskly sprayed water all around the tank (the motion of which would help oxygenate the fishes gills and help them to breathe more naturally. Finally, I surveyed the damage after I saw the fish were moving on their own accord and had perked up considerably. The result was 15 dead juveniles. They had suffocated from lack of oxygen.
When all was calmed down, I gathered my kids together and taught them a bit more about the aquarium ecosystem and how it worked, about oxygen exchange, about water column movement and also overcrowding and overpopulation for a small environment. They had asked me why no fish had died when we had power outages. Then not only did the air pump stop working but the water pump and heater had, too. Why didn't the fish die then? I explained that the fish population was smaller then, that there weren't so many babies, and those babies hadn't grown to a size to make a major difference to the resources of the tank. Now however, they were large enough to make such an impact.
With that, we had to make a game plan, and part of that plan is to find a new home for about 70% of the fish, as soon as they are big enough "to let go". To let go means I plan to donate them to various fish stores in the county. The remaining 30% I will let grow as long and as big as they want to get.
Our software ecosystems are similar. Lots of new features may seem innocent by themselves and in isolation, but all it takes is an environmental change to have something catastrophic appear. we may have little to no idea what will cause that to happen, but one day all of our tests pass and everything looks great, and then one seemingly small change takes place, and suddenly everything has gone horribly wrong. I've had that experience with my own tests, and sometimes it's just a little nudge that sends everything over the edge. So what can we do? Just like I needed to educate my kids about oxygen in the water and surface agitation, I also have to be aware of the unique aspects of what makes my software environment "breathe". I may not be able to know every contingency, but knowing the big and important ones will help to stave off disasters.
Recently the kids were playing upstairs, and as they are oft to do, roughhousing and jumping around. Unbeknownst to them, they knocked the air line from the air pump to the air stones. Earlier in the week, they helped me clean out the tank and do a water change, too. They didn't realize it, but these events conspired to make a fatal flaw in our system apparent.
I came home from work Thursday night and the kids said "hey dad, you should go up and feed the fish, they look really hungry!" I thought this was an odd statement, so I went up and inspected the tank. What I saw was all of the fish hovering at the surface of the water, some on their sides, their gills pumping rapidly. As I looked and saw the tank, I heard the air pump running louder than normal. I looked down and saw that the air hose was no longer attached. I quickly reattached it, which allowed the bubbles (and air) to flow back into the tank. However, this was only part of the problem. I also noticed a tell tale sign of what also wasn't normal; there was no splashing water from the filter return. The water was just running under the surface because the hose had slipped down below the water line. Add to that the fact that we also have about 70 juvenile fish, each now averaging an inch in length or a little more, along with the older denizens in the tank. Individually, any of these would not be a problem. Taken together, though, what resulted was a massive failure to the system.
We had to act quickly, so I hooked up the water siphon to the bathroom sink and drained out about 20 gallons of the tank water. this served two purposes. first, it allowed for agitation of the surface by the filter return, thus creating an oxygen exchange again. This mixed with the bubbles from the air filter would allow the oxygen to return to the water. Second, I turned on the hose and briskly sprayed water all around the tank (the motion of which would help oxygenate the fishes gills and help them to breathe more naturally. Finally, I surveyed the damage after I saw the fish were moving on their own accord and had perked up considerably. The result was 15 dead juveniles. They had suffocated from lack of oxygen.
When all was calmed down, I gathered my kids together and taught them a bit more about the aquarium ecosystem and how it worked, about oxygen exchange, about water column movement and also overcrowding and overpopulation for a small environment. They had asked me why no fish had died when we had power outages. Then not only did the air pump stop working but the water pump and heater had, too. Why didn't the fish die then? I explained that the fish population was smaller then, that there weren't so many babies, and those babies hadn't grown to a size to make a major difference to the resources of the tank. Now however, they were large enough to make such an impact.
With that, we had to make a game plan, and part of that plan is to find a new home for about 70% of the fish, as soon as they are big enough "to let go". To let go means I plan to donate them to various fish stores in the county. The remaining 30% I will let grow as long and as big as they want to get.
Our software ecosystems are similar. Lots of new features may seem innocent by themselves and in isolation, but all it takes is an environmental change to have something catastrophic appear. we may have little to no idea what will cause that to happen, but one day all of our tests pass and everything looks great, and then one seemingly small change takes place, and suddenly everything has gone horribly wrong. I've had that experience with my own tests, and sometimes it's just a little nudge that sends everything over the edge. So what can we do? Just like I needed to educate my kids about oxygen in the water and surface agitation, I also have to be aware of the unique aspects of what makes my software environment "breathe". I may not be able to know every contingency, but knowing the big and important ones will help to stave off disasters.
Friday, August 26, 2011
Podcast Friday: Three Quick Hits
Hello everyone! It's Friday and that means it's time for another batch of my personal weekly "Podcast Favorites" :).
First, of course, is the podcast I actually produce. This time around, This Week in Software Testing interviews Timothy Western (aka @Veretax on Twitter). Matt and Timothy talk a bit about video game beta testing, ho to leverage automated testing, and dealing with finicky customers and project managers. It's a good interview, I think you'll enjoy it :).
Second, Bruce and Trish are back with another installment of TestCast. This features the 2nd installment of their interview with James Bach and this time around James discusses all things pairwise.
Finally, Back to Work is a special treat for me this week. Dan Benjamin is away on vacation, and Merlin decided to take the show in an interesting direction by interviewing Jonathan Coulton (the independent musician who is deservedly referred to as "the geeks Muse"). It's a fun interview and it is surprisingly "on pointe" for Merlin, but then I've heard that Jonathan has that effect on people.
Looking forward to seeing what next week has in store for us all. Happy listening :).
First, of course, is the podcast I actually produce. This time around, This Week in Software Testing interviews Timothy Western (aka @Veretax on Twitter). Matt and Timothy talk a bit about video game beta testing, ho to leverage automated testing, and dealing with finicky customers and project managers. It's a good interview, I think you'll enjoy it :).
Second, Bruce and Trish are back with another installment of TestCast. This features the 2nd installment of their interview with James Bach and this time around James discusses all things pairwise.
Finally, Back to Work is a special treat for me this week. Dan Benjamin is away on vacation, and Merlin decided to take the show in an interesting direction by interviewing Jonathan Coulton (the independent musician who is deservedly referred to as "the geeks Muse"). It's a fun interview and it is surprisingly "on pointe" for Merlin, but then I've heard that Jonathan has that effect on people.
Looking forward to seeing what next week has in store for us all. Happy listening :).
Thursday, August 25, 2011
Weekend Testing Americas: Developing Effective Charters with James Bach
Actually, I'm glad they did, because they helped me realize something I've been struggling with for some time. It'[s one thing to make a test charter or a test mission, but how can we make them more effective? More to the point, how can we craft them so that they are appropriate for the testing session at that time?
To help explain this, imagine you have a group of people you are going to send out to test something. They have one hour. they have to maximize that time, and therefore they need to be able to hit the ground running as fast as humanly possible. Can you adequately describe what needs to be done so that everyone in the group can do that? What if we had a whole group of testers specifically trained to be able to do that, not just for Weekend Testing sessions, but all the time?
This is the skill that James Bach will be working with us to develop and improve this Saturday. Normally, I would be cautious to not over-hype or over-promote these sessions because we might be overrun, but in this case, I think it will prove worth it, so I'm breaking my "limited distribution" promotion (Twitter and direct email) to talk about and announce this session.
So do you want in? If so here's what you need to know and what you've gotta' do:
Date: Saturday, August 27, 2011
Time: 11:00 a.m. - 1:00 p.m. PDT (2:00 p.m. - 4:00 p.m. EDT)
To join the session:
1. Please send an email message to wtamericas@gmail.com with the subject line "WTA18" and a confirmation that you would like to attend the session.
2. Please add "weekendtestersamericas" to your Skype ID list if you have not already done so. Please ask us to add you to our contact list.
3. On Saturday, August 27th, approx. 20 minutes before the start of the session, I will set up the group. If you ping me on Skype at that time, I will add you to the session. If you have replied via email and stated that you will be attending the session, if you are online at that time, I will automatically add you.
Remember, these sessions are "chat" only, no call in is necessary, but you have to be on Skype to participate.
Look forward to seeing you there :).
Wednesday, August 24, 2011
I'll Be at PNSQC... How About You :)?
PNSQC has a broad option of topics speakers and activities, and this year, one of their track speakers is, well... me :).
I will be giving a talk titled "Delivering Quality One Week at a Time: Lessons Learned in Weekend Testing", and I will be delivering it in two ways. First will be a formal track session on Monday, October 10th at 1:30 pm. I will also be delivering a modified presentation during the social hours and poster paper presentation times during the conference. That way, if you don't get to see my technical presentation, you can always catch it in this more personal format.
In case I'm not enough of a draw (yeah, as if :) )... the keynote speakers will be:
- Goranka Bjedov from Facebook exploring "The Future of Quality"
- Rob Sabourin of AmiBug.com, Inc. discussing "Value Sync".
- Jim Benson, talking about "Personal Kanban"
- Michael Bolton, talking about "Standards and Deviations"
- Diana Larsen, discussing "Starting New Projects on a Trajectory Toward Success"
- Erik Simmons, on "21st Century Requirements Engineering"
In addition to the keynotes, invited speakers and other presenter, there will be a full day of in-depth workshops. The technical papers are available for your review with the Conference At-a-Glance.
So, do you want to come and join us? It's not too late. Register Now! I look forward to seeing you there :).
Tuesday, August 23, 2011
Let Codecademy Teach You How to Program!
I would have said the same thing a few days ago... and then I discovered "Codecademy".
Codecademy is a clever idea, and it's a fun way to get your hands into general programming. At the moment, there's a simple set of modules built around JavaScript, but it's really neat the way they have structured this. It feels like you are in a "programming chat" with another user, and you can actually keep tabs on your progress, earn badges you can display, share details on your Facebook profile (if you are so inclined) and see graphical representations of what you've completed. Really, it's a clever system, and it's actually fun to use. It's a bit sparse at the moment; those expecting a one stop shop of all thing programming related will have to wait awhile... or they can actually offer their own lessons if they have the knowledge and skill. This has great potential to be to the programmer what Wikipedia is to the encyclopedia. It's a community driven service, and you can sign up to get notifications when new modules or courses are made available.
In short, if you've ever wanted to get into programming, have limited experience, or just like playing with fun tools, give Codecademy a visit. It's a lot of fun and, hey, you just might learn something :).
Thursday, August 18, 2011
Online Book Review: Learn Ruby the Hard Way
First of all, I love the title of this “book”, and I love the concept behind it. Zed Shaw originally wrote this for Python, in a book called "Learn Python the Hard Way". Rob Sobers made a language equivalent conversion/translation to Ruby. Rob is quick to point out that, while he has made the conversion to Ruby, and has made the book relevant to Ruby programmers, the concept and approach is still Zed's.
Zed (and Rob) have written something noteworthy, a shot across the bow to anyone who laments the loss of the “old ways”. When I talk about the old ways, I’m referring to the old books and magazines where those who wanted to run the programs had no choice but to type out the lines verbatim from the pages from the books or magazines, run them, figure out where we messed up, and ultimately get them to run.
From Learn Python the Hard Way:
The Hard Way Is Easier
LPTHW emphasizes precision, attention to detail, and persistence by requiring you to type each exercise (no copy-paste!) and make it run, as well as to read up on outside topics and to return to exercises and ideas that you don't understand, and understand them.
At the end of LPTHW, you'll know the basics of coding, and be ready to move on to more challenging books. Or at least you'll have tried something new.
The ability to have books and texts online is wonderfully convenient, and the ability to cut and paste code in quickly is a great advancement… but it comes at a cost. Cut and paste helps us to get the ideas down quickly and see them in action, but there just isn’t a replacement for “muscle memory”, the long and often arduous process of typing out the lines of code, forcing us to slow down and physically, manually mull over those lines. I sometimes laugh about the fact that I still remember shell programming tips I learned 20 years ago, but I can barely remember things I did in intense Java study sessions just a couple of years ago. Why is that? It’s because I had to type out every single one of those shell programming examples. There was no CD-ROM, there was no “web site” to download code from. It was type or do without.
“Learn Ruby the Hard Way” expects the programmer to do exactly the same thing. The explicit first instruction is to type in the examples, verbatim, and no cheating. No copy/paste, no macros, and no advanced IDE (they do recommend using gedit as an IDE and it’s very basic and straightforward, very few bells and whistles). There are over 50 exercises, many of them long, repetitive and tedious… and that’s awesome! I’m totally serious here! Especially for us testers. We often try to find the quickest way to accomplish a step or a process when it comes to programming (because, come on, we’re not programmers, we’re testers, we don’t have time for this stuff, right?). Well, the more time I spend with this cumbersome and tedious system, the more appreciation I have for it. There’s no quick gains here, there’s no fast “a-Ha!” moment, and yes, occasionally I roll my eyes at the “master of the obviousness” of a lot of the examples. But there’s definitely a method to the madness here. This isn’t a platitude and concept book, this is a workout book. There’s a lot of code, there’s a lot of questions, there’s a lot of extra credit, and there’s a lot of time to be spent soaking in this stuff. The more that I mess with “code”; be it Cucumber, RSpec or general Ruby, there just isn’t any better method to learning it than just the raw doing it, over and over and over again.
So for those who have gone through a number of the commercial books and feel, yeah, OK, but am I really getting this, I recommend giving “Learn Ruby the Hard Way” a good and vigorous look. If you get irritated and fed up with it, sit back and allow yourself a smile, because that’s a good sign that it’s actually doing what it’s supposed to. It’s the hard way, as the title implies, but sometimes it’s the hard ways that prove to be the best ways :).
Zed (and Rob) have written something noteworthy, a shot across the bow to anyone who laments the loss of the “old ways”. When I talk about the old ways, I’m referring to the old books and magazines where those who wanted to run the programs had no choice but to type out the lines verbatim from the pages from the books or magazines, run them, figure out where we messed up, and ultimately get them to run.
From Learn Python the Hard Way:
The Hard Way Is Easier
LPTHW emphasizes precision, attention to detail, and persistence by requiring you to type each exercise (no copy-paste!) and make it run, as well as to read up on outside topics and to return to exercises and ideas that you don't understand, and understand them.
At the end of LPTHW, you'll know the basics of coding, and be ready to move on to more challenging books. Or at least you'll have tried something new.
The ability to have books and texts online is wonderfully convenient, and the ability to cut and paste code in quickly is a great advancement… but it comes at a cost. Cut and paste helps us to get the ideas down quickly and see them in action, but there just isn’t a replacement for “muscle memory”, the long and often arduous process of typing out the lines of code, forcing us to slow down and physically, manually mull over those lines. I sometimes laugh about the fact that I still remember shell programming tips I learned 20 years ago, but I can barely remember things I did in intense Java study sessions just a couple of years ago. Why is that? It’s because I had to type out every single one of those shell programming examples. There was no CD-ROM, there was no “web site” to download code from. It was type or do without.
“Learn Ruby the Hard Way” expects the programmer to do exactly the same thing. The explicit first instruction is to type in the examples, verbatim, and no cheating. No copy/paste, no macros, and no advanced IDE (they do recommend using gedit as an IDE and it’s very basic and straightforward, very few bells and whistles). There are over 50 exercises, many of them long, repetitive and tedious… and that’s awesome! I’m totally serious here! Especially for us testers. We often try to find the quickest way to accomplish a step or a process when it comes to programming (because, come on, we’re not programmers, we’re testers, we don’t have time for this stuff, right?). Well, the more time I spend with this cumbersome and tedious system, the more appreciation I have for it. There’s no quick gains here, there’s no fast “a-Ha!” moment, and yes, occasionally I roll my eyes at the “master of the obviousness” of a lot of the examples. But there’s definitely a method to the madness here. This isn’t a platitude and concept book, this is a workout book. There’s a lot of code, there’s a lot of questions, there’s a lot of extra credit, and there’s a lot of time to be spent soaking in this stuff. The more that I mess with “code”; be it Cucumber, RSpec or general Ruby, there just isn’t any better method to learning it than just the raw doing it, over and over and over again.
So for those who have gone through a number of the commercial books and feel, yeah, OK, but am I really getting this, I recommend giving “Learn Ruby the Hard Way” a good and vigorous look. If you get irritated and fed up with it, sit back and allow yourself a smile, because that’s a good sign that it’s actually doing what it’s supposed to. It’s the hard way, as the title implies, but sometimes it’s the hard ways that prove to be the best ways :).
Wednesday, August 17, 2011
A Scoutmaster's Key, or What Others See In You
Last night, the boys in the Troop petitioned the council office and wrote in on my behalf to have the Scoutmaster's Key awarded to me. This is an award that takes three years of active tenure and a lot of activity and a productive program to earn, and Scout leaders can turn the paperwork in after they have completed all requirements. So what makes this different? I didn't turn in any paperwork for this. My scouts did. They sent in the application and wrote a letter to the council office on my behalf. Frankly, that makes it worth a lot more to me.
Very often, we look to see what we are worth in the world, whether it be our salaries, our titles or other aspects that we choose to use to identify ourselves with. Scouts like recognition, and that desire for recognition doesn't change when we are adults. Cub Scouts like lots of patches, Boy Scouts like the rank patches and the medals, adult leaders are all about "the knots". Check out any adult leader who's been doing it for a decade or more, and you'll see a leader with a bunch of square knot patches right over their heart looking like a Soviet era general. Is it a little silly? Maybe, but it represents a lot of years of service and dedication. Most of them are training and tenure related; you do the time and the required training, and you get the knot when you finish. While it's cool to claim recognition, I think it's even better when it comes out of the blue and by the ones that are most connected to what you are doing. In my testing world, being recognized as a Miago-do black belt is in the same category. I can't claim it for myself, it has to be given to me by others who believe I have earned the right to have it. That makes it more meaningful.
So to my tester friends out there, think to yourself what you appear to be in the eyes of others. Knowing you do something awesome is a great feeling. Knowing that other people feel and believe that you do something awesome makes it that much more cool :).
Monday, August 15, 2011
Test Framing, or "Helping Someone Make a Decision"
I was describing to some friends of mine that "Test Framing" was a hot topic at CAST, and that I wished I could attend the session (was involved elsewhere). We discussed a bit about the ways that test framing comes into play when we work, and how we could explain test framing. I gave them an example of a recent situation that helped me with framing a situation, and then apply various testing ideas and critical thinking skills. Whether or not this is classic test framing is open to debate.
Anyone who knows me knows that I like to find ways to save money. I don't consider myself to be "cheap", but I also don't like spending money needlessly or foolishly. However, we often do things just because we have always done them or there doesn't seem to be a real benefit to doing them another way.
For the past six and a half years, I've worked in San Francisco. I live about 15 miles south of San Francisco, and in my town I have the benefit of two transit options. There's Bay Area Rapid Transit (BART) and CalTrain. Both travel about the same distance from my home town, but drop the passengers off in different sections of town. When I first started using BART, it made sense to take it because the office I worked at was literally upstairs from the Montgomery Street Bart station. Go up the escalator and turn left. I could time my departure from work within two minutes and still make my train. Insane convenience, plus trains from my stop and to my stop every 8 minutes. Framed like that, there's really not much reason to consider an alternate mode of transportation, even if it's less money. That's some significant convenience… but is it worth a 60% premium?
Honestly, I didn't consider it worth considering, even after our office moved from Market street (just up the stairs from BART) to Montgomery street (plus three blocks north of Market, or even further away from the other option). However, after I changed jobs and my company moved after being acquired. I found myself in an interesting position… my office was now roughly half way between the two commute choices (four blocks south to CalTrain, or three blocks north to BART? Well now, that's a little more interesting. Let's do some math.
From San Bruno to San Francisco and back on BART (including the $1 a day parking) that works out to $8.80 per day. Multiply that out 22 times and we're looking at roughly $195 per month or $2323 a year.
From San Bruno to San Francisco and back on CalTrain (they charge $4 a day to park in their lot, but there's plenty of nearby street parking for Free) works out to $5.50 per day, $121 per month, $1,452 per year. In short… is it worth it for me to walk a block to save $3.30 every day, $72.60 a month, or $871 a year? The answer is yes, of course it is.
But wait, both BART and CalTrain have a discount option for frequent commuters. How does it compare when those are factored in? Bart offers a 6 1/4% discount for high value ticket purchases, and if you use a Clipper card, these are applied automatically. So there's a discount benefit applied there. How is it with CalTrain? Well, here's where the gap widens considerably. CalTrain offers a monthly ticket for $73.00, which is a 40% discount over their daily rates, or a 60% discount from what BART charges, and that's AFTER the BART high value ticket discount. All told, taking CalTrain instead of BART saves me $4.99 a day, $24.96 per week, $109.82 a month, or $1,317.84 per year.
So here's the next piece of this… just cause I like to play what if's… Taking the convenience factor out of the equation, had I opted to take CalTrain from the very beginning of my time working in San Francisco (back in March of 2005) up until now, all things considered, had I banked the difference in ticket prices, the net savings over six years would have been $8400! Put into perspective, that's the cost of a decent used car, a semester of tuition at quite a few private universities (not to mention state schools), and could have paid for the equivalent of a mostly remodeled bathroom or a home landscaping project.
This is an example of framing a situation and examining the ramifications of choices. Do I beat myself up over the choice I made? No, because it made much more sense at the time to do it the way I did. The options were there at times, but the time required to get from CalTrain to my old office and back took me out of doing other things that mattered to me, and thus it was a non-starter. Still, there was a lot I hadn't considered, and looking back, maybe I should have. What would my physical fitness profile have been like if I had opted for the longer walk? Would I be in better shape and weigh less today with all that walking under my proverbial belt? Would that time spent walking allowed me to think up various ideas that I wouldn't have had the time to consider because I was focused on maximizing my time? It's easy to play these games and get frustrated about what could have been, but that's not the point. The point is that we sat down with scenarios, considered the options available, and came to a conclusion based on that information.
Now, to add additional details to this, and just to show it's not so cut and dry, CalTrain runs on a less frequent timetable. BART runs trains that can get me from San Francisco to San Bruno every 8 minutes in prime commute time. CalTrain's schedule gives me a train every hour regularly and a few express trains to choose from during the day, for roughly a train every 45 minutes. That's a lot less convenient, true, but is it so much less to make the savings not worth it. Absolutely not.
Take a scenario. Lay out all of the parameters you can find. Compare and contrast. Consider the benefits. Consider the disadvantages. Weigh the costs. Weigh the savings. Then present the whole story… and make a decision based on your new-found understanding. Repeat for every scenario you face :).
Anyone who knows me knows that I like to find ways to save money. I don't consider myself to be "cheap", but I also don't like spending money needlessly or foolishly. However, we often do things just because we have always done them or there doesn't seem to be a real benefit to doing them another way.
For the past six and a half years, I've worked in San Francisco. I live about 15 miles south of San Francisco, and in my town I have the benefit of two transit options. There's Bay Area Rapid Transit (BART) and CalTrain. Both travel about the same distance from my home town, but drop the passengers off in different sections of town. When I first started using BART, it made sense to take it because the office I worked at was literally upstairs from the Montgomery Street Bart station. Go up the escalator and turn left. I could time my departure from work within two minutes and still make my train. Insane convenience, plus trains from my stop and to my stop every 8 minutes. Framed like that, there's really not much reason to consider an alternate mode of transportation, even if it's less money. That's some significant convenience… but is it worth a 60% premium?
Honestly, I didn't consider it worth considering, even after our office moved from Market street (just up the stairs from BART) to Montgomery street (plus three blocks north of Market, or even further away from the other option). However, after I changed jobs and my company moved after being acquired. I found myself in an interesting position… my office was now roughly half way between the two commute choices (four blocks south to CalTrain, or three blocks north to BART? Well now, that's a little more interesting. Let's do some math.
From San Bruno to San Francisco and back on BART (including the $1 a day parking) that works out to $8.80 per day. Multiply that out 22 times and we're looking at roughly $195 per month or $2323 a year.
From San Bruno to San Francisco and back on CalTrain (they charge $4 a day to park in their lot, but there's plenty of nearby street parking for Free) works out to $5.50 per day, $121 per month, $1,452 per year. In short… is it worth it for me to walk a block to save $3.30 every day, $72.60 a month, or $871 a year? The answer is yes, of course it is.
But wait, both BART and CalTrain have a discount option for frequent commuters. How does it compare when those are factored in? Bart offers a 6 1/4% discount for high value ticket purchases, and if you use a Clipper card, these are applied automatically. So there's a discount benefit applied there. How is it with CalTrain? Well, here's where the gap widens considerably. CalTrain offers a monthly ticket for $73.00, which is a 40% discount over their daily rates, or a 60% discount from what BART charges, and that's AFTER the BART high value ticket discount. All told, taking CalTrain instead of BART saves me $4.99 a day, $24.96 per week, $109.82 a month, or $1,317.84 per year.
So here's the next piece of this… just cause I like to play what if's… Taking the convenience factor out of the equation, had I opted to take CalTrain from the very beginning of my time working in San Francisco (back in March of 2005) up until now, all things considered, had I banked the difference in ticket prices, the net savings over six years would have been $8400! Put into perspective, that's the cost of a decent used car, a semester of tuition at quite a few private universities (not to mention state schools), and could have paid for the equivalent of a mostly remodeled bathroom or a home landscaping project.
This is an example of framing a situation and examining the ramifications of choices. Do I beat myself up over the choice I made? No, because it made much more sense at the time to do it the way I did. The options were there at times, but the time required to get from CalTrain to my old office and back took me out of doing other things that mattered to me, and thus it was a non-starter. Still, there was a lot I hadn't considered, and looking back, maybe I should have. What would my physical fitness profile have been like if I had opted for the longer walk? Would I be in better shape and weigh less today with all that walking under my proverbial belt? Would that time spent walking allowed me to think up various ideas that I wouldn't have had the time to consider because I was focused on maximizing my time? It's easy to play these games and get frustrated about what could have been, but that's not the point. The point is that we sat down with scenarios, considered the options available, and came to a conclusion based on that information.
Now, to add additional details to this, and just to show it's not so cut and dry, CalTrain runs on a less frequent timetable. BART runs trains that can get me from San Francisco to San Bruno every 8 minutes in prime commute time. CalTrain's schedule gives me a train every hour regularly and a few express trains to choose from during the day, for roughly a train every 45 minutes. That's a lot less convenient, true, but is it so much less to make the savings not worth it. Absolutely not.
Take a scenario. Lay out all of the parameters you can find. Compare and contrast. Consider the benefits. Consider the disadvantages. Weigh the costs. Weigh the savings. Then present the whole story… and make a decision based on your new-found understanding. Repeat for every scenario you face :).
Sunday, August 14, 2011
Beyond Being Prepared: What Can the Scouts Teach Testers?
What was great about this was the fact that this talk and many others were streamed to other AST members and, well, anyone interested, all over the world. Claire Moss, a tester and active blogger (@aclairefication on Twitter), did a terrific write-up of the whole talk and the flow of the talk. So terrific, I don't think I could do it much better justice by recapping it here, but to say "go see Claire's blog and read her summary".
Also, to her comments about the Girl Scouts Oath and Law, it's very similar to the Boy Scout Oath and Law in purpose and intent, and it all comes back to what I've said many times... if we all would agree to live by and conduct ourselves based on the Boy Scout (and Girl Scout) Oath and Law, then we would not need to have such a large number of "ethics"discussions and standards. We'd already be doing all that!
There are a couple of comments I wanted to add about the experience itself, so that's more of what this represents. First, the model of team development that I referred to has an official name. I've just referred to it as the "Forming-Storming-Norming-Performing" model or the "four stages of team development" model for so long I always assumed everyone knew hat I was talking about. Time to give due credit. This model was developed by Bruce Tuckman in 1965 and a pretty good run down of the model can be seen here. There is an additional step that was added later on in the 1970s, and that is "Adjourning" since for many, the team responsibilities do not go on indefinitely. In this same page, the ideas of what the leader does and how they pivot is described as the Hersey and Blanchard's Situational Leadership model. The terms they use are "Telling-Selling-Participating-Delegating", which are in many ways just bigger words than those used by the Boy Scouts in their EDGE(TM) acronym (Explain-Demonstrate-Guide-Enable).
All in all, I had a great time delivering this talk, and making something that I use in the Scouting movement relevant to testers. I really appreciated the fact that it was a topic that hit home with many testers, and that there were those out there who took the time to tweet about their enjoyment of the talk and to even do a full write-up. If there are others out there who have blogged about it or referenced the talk, I'd like to know so I can thank them directly. Also, while the talk was streamed, I'm hoping it was also recorded, and if so, I'm hoping to be able to post a video of the talk when/if it is posted.
Thursday, August 11, 2011
On Being A "Late Bloomer"
I had a chance to have a really awesome experience this past week. A lot of cool things happened to me when I was in Seattle (OK, Lynwood :) ) when I went up to the CAST conference. I met and interacted with colleagues from all over the world. I signed autographs for people (seriously!) and laughed as people referred to me on Twitter as "the Rock Star Tester" (alluding to my past life as a musician, not that I'm a "rock star" at testing. Ajay Balamurugadas, Markus Gaertner, Matt Heusser... now there's your real rock star testers :) ). No, my epiphany came in a tutorial being done by Anne Marie Charrett called "Career Management for Software Testers". I was in a group with a bunch of other testers and we were sharing career high and low points as well as analyzing characteristics of our focus and responsibility... and it came clear as day. I'm a late bloomer.
We sometimes make jokes about late bloomers. They are those people that are quiet and unassuming in certain ways, and then all of a sudden, BAM! they are off like a whirlwind, they seem to gather momentum, and opportunities open up where before there seemed to never be any. For years, I though there was a disconnect between what I was doing for a living and what my potential could be. Looking through my notes from the seminar, though, I realized something different. It's not that I didn't have opportunity, it's that I didn't actively pursue it. Note: this is not a pity party, it's an observation, and I finally put it into words in this tutorial. I'm going to share it here.
Two times in my life, I made some very specific decisions. They were hinge-pin moments in my life, and they shaped my reality and my destiny radically. The first happened shortly after my 18th birthday. I decided I wanted to be a musician. More than that, I wanted to be a "rock star". But I did more than just want... I actively and doggedly pursued it, for the better part of a decade. I learned every aspect of it, and I threw myself headlong into that world. Because of that, I had a level of success. Luck and timing weren't on my side to completely grab the brass ring, but I went farther than about 95% of aspiring musicians did, and for that, I have very few regrets (a lot of mistakes, some of them painful and costly ones, but few regrets :) ). The second one happened when my son showed an interest in wanting to be a Scout. This was when he was about to finish Kindergarten, and it happened during the tech downturn after 2001-2002. I made a decision again, that I wanted to be his Scout Leader, and so I voluntarily downshifted my life to allow me the flexibility to do exactly that. I really wanted to share those years with him, and as such I also wanted to have that scouting experience for myself, too. I'd been involved in Scouting as an adult leader since I was 25, but this time I really dove into it, and because of that, I think I held just about every scouting leadership position possible.
This whole time, though, I puttered along as a lone tester or a contributor to small teams. I was just this guy doing my job, so I could do those other things that really mattered. Well, as is often the case, life changes, and different phases make their marks. My "rock star" life is long behind me, and though I had a chance to revel in it for a night back in 2009 to celebrate the 20th reunion of my most successful band forming (and the release of our CD around the same time), I have no illusions I'm putting the band together again. Likewise, my son is now an Eagle Scout, a few days shy of 15 years old, and looking forward to having other people be his leaders now, or him being the leader to others, as is his right. It's no surprise that my love affair with music and Scouting happened when they did. But software testing was always there in the background. It's what I did, it was my competency, even if at times I could only barely say that. Testing is a somewhat forgiving friend, though, in that, when you are ready to put your all into it, it's there to give you it's all back. It's been almost two years since my son earned his Eagle Scout award. Not coincidentally, it's also been almost two years since I started my journey into diving headlong into testing, with every fiber of my being.
Amazingly enough, as I've poured more of my heart into it, more interesting and unique opportunities have come my way. Most of the things that I do have been for free; that's how you know you really dig something, when you're willing to do it endlessly for no compensation at all, and stil do it with a smile, you know you've got something important.
I tell my kids about the apple tree we have in the back yard. It's an odd gnarled thing. It didn't produce any meaningful fruit for well over 10 years, and then we noticed something. As the weather seemed to get a bit colder and wetter (which it has the past few years in San Bruno) the tree started producing fruit. It wouldn't bloom at the time other apple trees did, though, it would bloom in late August (like it is now) and it would produce its apples ready to be eaten in late December or early January. Seemed an odd time, but when you cut those apples open and tasted them, man they were fantastic. A little research, and I discovered what I had. I had a Honeycrisp apple tree, and yes, they are "late bloomers". They grow and form their apples as tiny things for years, and then start giving their full yields well after the other trees have long since been harvested. Yet they are without a doubt my favorite apples. My career, I've realized, has followed a similar pattern. Why I waited until I was 41 to go headlong into testing, I do not know, other than to say that I had other goals that needed to be met first. I needed to get those out of my system first, but now, I have the energy and the desire to give it my all... and it seems that opportunities tend to embrace those who are already willing to roll up their sleeves and get to work.
So here's a shout to my fellow testers out there who may be a little gray at the temples, who may wonder if they've been passed by as others have forged ahead... ask yourself, what are your goals, really? What have you really spent your time doing? I know my answer. First, it was rock & roll, then it was snowboarding, and then it was my growing family and being a dad and leader to my son and daughters. Interestingly, all of the opportunities that came my way came because I was willing to give my all to them, when I'd not only do it for free but pay for the privilege to do it. Thomas Edison is credited with saying something to the effect of "Opportunity is missed by most people because it is dressed in overalls and looks like work". I believe that. When we area ready and willing to embrace the work, then we are ready to also embrace the opportunities that come with it. It took me 19 years in the tech industry, but I think I finally got there. I'm passionate about testing because I was ready to be passionate about it, and testing was there for me to be passionate about :). It may not always be this way, but I've decided to ride this wave for all its worth for as long as I can. Let's see where this old dog will roam!
We sometimes make jokes about late bloomers. They are those people that are quiet and unassuming in certain ways, and then all of a sudden, BAM! they are off like a whirlwind, they seem to gather momentum, and opportunities open up where before there seemed to never be any. For years, I though there was a disconnect between what I was doing for a living and what my potential could be. Looking through my notes from the seminar, though, I realized something different. It's not that I didn't have opportunity, it's that I didn't actively pursue it. Note: this is not a pity party, it's an observation, and I finally put it into words in this tutorial. I'm going to share it here.
Two times in my life, I made some very specific decisions. They were hinge-pin moments in my life, and they shaped my reality and my destiny radically. The first happened shortly after my 18th birthday. I decided I wanted to be a musician. More than that, I wanted to be a "rock star". But I did more than just want... I actively and doggedly pursued it, for the better part of a decade. I learned every aspect of it, and I threw myself headlong into that world. Because of that, I had a level of success. Luck and timing weren't on my side to completely grab the brass ring, but I went farther than about 95% of aspiring musicians did, and for that, I have very few regrets (a lot of mistakes, some of them painful and costly ones, but few regrets :) ). The second one happened when my son showed an interest in wanting to be a Scout. This was when he was about to finish Kindergarten, and it happened during the tech downturn after 2001-2002. I made a decision again, that I wanted to be his Scout Leader, and so I voluntarily downshifted my life to allow me the flexibility to do exactly that. I really wanted to share those years with him, and as such I also wanted to have that scouting experience for myself, too. I'd been involved in Scouting as an adult leader since I was 25, but this time I really dove into it, and because of that, I think I held just about every scouting leadership position possible.
This whole time, though, I puttered along as a lone tester or a contributor to small teams. I was just this guy doing my job, so I could do those other things that really mattered. Well, as is often the case, life changes, and different phases make their marks. My "rock star" life is long behind me, and though I had a chance to revel in it for a night back in 2009 to celebrate the 20th reunion of my most successful band forming (and the release of our CD around the same time), I have no illusions I'm putting the band together again. Likewise, my son is now an Eagle Scout, a few days shy of 15 years old, and looking forward to having other people be his leaders now, or him being the leader to others, as is his right. It's no surprise that my love affair with music and Scouting happened when they did. But software testing was always there in the background. It's what I did, it was my competency, even if at times I could only barely say that. Testing is a somewhat forgiving friend, though, in that, when you are ready to put your all into it, it's there to give you it's all back. It's been almost two years since my son earned his Eagle Scout award. Not coincidentally, it's also been almost two years since I started my journey into diving headlong into testing, with every fiber of my being.
Amazingly enough, as I've poured more of my heart into it, more interesting and unique opportunities have come my way. Most of the things that I do have been for free; that's how you know you really dig something, when you're willing to do it endlessly for no compensation at all, and stil do it with a smile, you know you've got something important.
I tell my kids about the apple tree we have in the back yard. It's an odd gnarled thing. It didn't produce any meaningful fruit for well over 10 years, and then we noticed something. As the weather seemed to get a bit colder and wetter (which it has the past few years in San Bruno) the tree started producing fruit. It wouldn't bloom at the time other apple trees did, though, it would bloom in late August (like it is now) and it would produce its apples ready to be eaten in late December or early January. Seemed an odd time, but when you cut those apples open and tasted them, man they were fantastic. A little research, and I discovered what I had. I had a Honeycrisp apple tree, and yes, they are "late bloomers". They grow and form their apples as tiny things for years, and then start giving their full yields well after the other trees have long since been harvested. Yet they are without a doubt my favorite apples. My career, I've realized, has followed a similar pattern. Why I waited until I was 41 to go headlong into testing, I do not know, other than to say that I had other goals that needed to be met first. I needed to get those out of my system first, but now, I have the energy and the desire to give it my all... and it seems that opportunities tend to embrace those who are already willing to roll up their sleeves and get to work.
So here's a shout to my fellow testers out there who may be a little gray at the temples, who may wonder if they've been passed by as others have forged ahead... ask yourself, what are your goals, really? What have you really spent your time doing? I know my answer. First, it was rock & roll, then it was snowboarding, and then it was my growing family and being a dad and leader to my son and daughters. Interestingly, all of the opportunities that came my way came because I was willing to give my all to them, when I'd not only do it for free but pay for the privilege to do it. Thomas Edison is credited with saying something to the effect of "Opportunity is missed by most people because it is dressed in overalls and looks like work". I believe that. When we area ready and willing to embrace the work, then we are ready to also embrace the opportunities that come with it. It took me 19 years in the tech industry, but I think I finally got there. I'm passionate about testing because I was ready to be passionate about it, and testing was there for me to be passionate about :). It may not always be this way, but I've decided to ride this wave for all its worth for as long as I can. Let's see where this old dog will roam!
Tuesday, August 9, 2011
CAST 2011 - Day 2
Day 2 started out with an interesting TWiST... yes, that's a pun, and yes that's on purpose. Matt Heusser, Markus Gaertner, Ajay Balamurugadas and I (with Adam Yuret joining us later) did a Live podcast where we discussed the CAST testing challenge and our approach to how we went about doing it. It was a lot of fun, and I'm hoping that we'll get a good podcast out of it (first time recording live with the Snowball in Omni mode).
Day 2 is a little interesting for me, in that I'm in less of a "attendee mode" today and more of a "presenter mode". Following James Keynote, I set up and ran WTA3D, which meant that the attendees online participated along with people at the conference. This was be a blending of two models, the Weekend Testing online model and a class about facilitation of Weekend Testing charters and missions for those in attendance. Thus, I was on for a few hours and my blog output was definitely diminished. Also, I want to give a shout out to the panel discussion that I will not be able to attend (can't be in two places at one) having to do with the "How to Reduce the Cose of Software Testing" book. As a contributing author, I have to say that missing this is killing me, but WTA3D is what paid my way to the conference, so I'll be dancing with the one that brung me :).
The session today for WTA3D was very fun and had a great energy both from the attendees online and the attendees in the room with me presenting. We decided to change things up and let the participants see behind the curtain as to how Weekend Testing sessions worked, and the things that we actively do when we are setting up the sessions, designing the mission and charters and actively leading an facilitating the sessions. For our actual testing session, we focused on eBay and performing what are called Testing Vacations (I think Elizabeth Hendrickson gets credit for that phrase). The idea is that we had several small objectives (actually, ten of them) and we decided to have groups take on certain challenges and report on how they achieved them, and to encourage others to comment on their testing approach and method. The session went for three hours and fifteen minutes (longer by 50% than a typical Weekend Testing session) but the participants seemed to enjoy the session. Plus, we expected people would come and go and thus structured it that way.
During lunch, we received the results on the testing challenge, and I'm happy to say that, even though the Miagi-do team wasn't eligible to win a prize, we scored very high on all categories... except one. We took the risk of issuing what's referred to in the racing world as a "Black Flag", and said that we felt the application was not fit for testing, and spelled out the reasons. Apparently, we "ticked off the developer" and that put us out of contention, but it was also interesting to hear the organizers of the competition say "If Miagi-do was an eligible team, the choice for first place would have been really difficult." Frankly, I can't ask for a better outcome (well, OK, it would have been nice to win outright :) ), but I'm happy about how that all went down, and how great it was to work with such a great group of testers, literally spanning the globe... and I'll stand by our team issuing the Black Flag, I think it was the right thing to do :).
Lunchtime also announced the members who were elected to the Board of Directors. I can report now that the new board members are Matthew Heusser, Cem Kaner... and Michael Larsen :). Yep, I got elected to the Board of Directors, which is both thrilling and dreadfully sobering at the same time. I'm excited to see what the coming years has in store, and I'm excited to take on this challenge. after the elections, I discussed with the board that I would be willing to take on the role as Treasurer for the organization. I still have to be officially voted in, but it looks as though that's the direction this is heading :).
After lunch, I participated in a forum discussion about the Black Box Software Testing classes. I have to say, this is an area that is near and dear to my heart, since the whole point of my blog is backing away from mis-education and making an effort towards re-education (n the good way, not the internment camp way ;) ).We had a vigorous discussion with Selena Delesie, Doug Hoffman, Mimi Mendenhall, and myself talking about the future of the classes, setting expectations, and geting through the dreaded first quiz. It also made me smile to realize that so many people had that same experience, yet had overwhelmingly positive things to say about the course as a whole. That makes me feel confident that there's a great opportunity in these classes and I'm hoping to see them grow and expand.
I was able to be an attendee again for the final track session, and I chose to attend Sajjadul Hakim's "Understanding the Gut Feelings in Testing". I enjoyed hearing Sajjadul discuss the ways that both the conscious and unconscious mind work together. In reality, we all work on gut feelings, but the expert tester has more than gut feeling to work with. We have heuristics, we have ways of analyzing what we see, but often, we stil have that unmistakable "feeling" that makes itself known when they test. the best way to describe this is that they have already conditioned themselves to these ideas, and because they have conditioned themselves, they have a deep reserve of knowledge and experience to draw from. I find myself struggling with this myself, in that I have lots of intuition, but I don't really trust it much of the time. Many times, that intuition does prove to be true, but it's fallible enough to make us doubt our intuition. But if we continue testing and seeing these things happen over and over again, then we get to trust that intuition more and more.
At the end of the day, Matt and Markus gathered Ajay, Elena and me together and anounced that, based on our performance in the CAST testing challenge, all three of us deserved to receive our black belts in the Miagi-do school of software testing. For the record, I respect both Matt and Markus a lot, and while I get the idea that the belt system in Miagi-do is a little corny and helps us not take ourselves to seriously, it does mean I had the chance to work with testers I admire and respect, and after several hours of intense focus, having them say "yeah, Michael, you get this, you are genuinely and solidly competent as a tester" really means a lot to me. For those curious as to how long it took me to update my blog with the new designation, the official answer is "two minutes"; enough time to whip open my laptop and get to the page to edit :).
Peter Walen and I were able to facilitate the Education Sig meeting and we had a good group come and join us. We discussed some cool ideas that we'd like to see the Education SIG take on, as well as opportunities for the SIGs to get involved in conferences or other events directly and make time so that we can complete initiatives that have been in limbo for some time. Also, we got word that the script and the syllabus for the Test Design class for BBST is finished and that we wil be looking at the class being available some time in late September or early October. Again, I'm excited to see it, and I'm looking forward to being a participant in it.
Tomorrow it will be the 1/2 and full day tutorials. By their nature, I'm guessing the twet stream will be a lot smaller, as most of the people at the conference will have left. I'm for sure attending Anne Marie Charret's tutorial on "Managing Testing Careers". We'll see what else tomorrow brings, but one things for sure, the adventure ends tomorrow at 5:00 PM and then it's time to get back to Sea-Tac and get on a plane to come back home.
That's it for me for today :).
Jon Bach started the day with a recap of some of the issues that we had yesterday and the solutions made today to resolve most of them. How cool is it to have a bunch of testers looking at issues... and actually having the power to do something about it? As a side detail, it was fun to see the ten comments taken "out of context" during the testing competition, and I had to laugh when my comment of "you have to be nice to a parrot, or parrots will kick your ass!" making it on the board (LOL!). I'll explain later what that means, but hey, consider it a teaser for now.
James Bach keynote is covering the "Cool New Things" in the software testing world, and it's been interesting to see the ideas he's discussed, such as the collapse of the Software Testing Factory, the "Death of Quality", the Politics that have led us to where we are today, and some of the reality that Agile is bringing to the practice of software testing. James make the comment that "Agile seems to be about index cards moving along a wall" meaning that people are focusing on the technique, rather than the skill that the approach instills, which is disciplined craftsmanship and focus on development. Which brings us to what James thinks is the "next cool thing" and to him, it's "Intersubjectivity Revolution", where more of us are stepping away from making up nonsense metrics, and instead giving true qualitative assessments. James also gave a shout to the new movements taking place in the testing world, and it felt really awesome to see him mention Weekend Testing and showing such praise for it as a truly organic movement and one that goes so totally against the grain of the way things are right now (especially in India, where it started, which James mentioned he thought was absolutely amazing considering India's history and culture related to testing in general. It's the rebels that formed Weekend Testing :) ). James also focused on test coaching and teaching test coaching, so that those of us who teach testers can get better at teaching testing. James closed his talk with some cool tools and some cool books, including Wittgenstein and the idea that things like tacit and explicit knowledge are important to understand, and the idea that we need to put people into uncomfortable situations for them to really learn. It also could lead to Post Traumatic Stress Disorder, but hey, small price to pay for knowledge, right :)? During the Q&A, James talked about the testing play book, which is a listing and details that are pertinant to structuring their threads.
Day 2 is a little interesting for me, in that I'm in less of a "attendee mode" today and more of a "presenter mode". Following James Keynote, I set up and ran WTA3D, which meant that the attendees online participated along with people at the conference. This was be a blending of two models, the Weekend Testing online model and a class about facilitation of Weekend Testing charters and missions for those in attendance. Thus, I was on for a few hours and my blog output was definitely diminished. Also, I want to give a shout out to the panel discussion that I will not be able to attend (can't be in two places at one) having to do with the "How to Reduce the Cose of Software Testing" book. As a contributing author, I have to say that missing this is killing me, but WTA3D is what paid my way to the conference, so I'll be dancing with the one that brung me :).
The session today for WTA3D was very fun and had a great energy both from the attendees online and the attendees in the room with me presenting. We decided to change things up and let the participants see behind the curtain as to how Weekend Testing sessions worked, and the things that we actively do when we are setting up the sessions, designing the mission and charters and actively leading an facilitating the sessions. For our actual testing session, we focused on eBay and performing what are called Testing Vacations (I think Elizabeth Hendrickson gets credit for that phrase). The idea is that we had several small objectives (actually, ten of them) and we decided to have groups take on certain challenges and report on how they achieved them, and to encourage others to comment on their testing approach and method. The session went for three hours and fifteen minutes (longer by 50% than a typical Weekend Testing session) but the participants seemed to enjoy the session. Plus, we expected people would come and go and thus structured it that way.
During lunch, we received the results on the testing challenge, and I'm happy to say that, even though the Miagi-do team wasn't eligible to win a prize, we scored very high on all categories... except one. We took the risk of issuing what's referred to in the racing world as a "Black Flag", and said that we felt the application was not fit for testing, and spelled out the reasons. Apparently, we "ticked off the developer" and that put us out of contention, but it was also interesting to hear the organizers of the competition say "If Miagi-do was an eligible team, the choice for first place would have been really difficult." Frankly, I can't ask for a better outcome (well, OK, it would have been nice to win outright :) ), but I'm happy about how that all went down, and how great it was to work with such a great group of testers, literally spanning the globe... and I'll stand by our team issuing the Black Flag, I think it was the right thing to do :).
Lunchtime also announced the members who were elected to the Board of Directors. I can report now that the new board members are Matthew Heusser, Cem Kaner... and Michael Larsen :). Yep, I got elected to the Board of Directors, which is both thrilling and dreadfully sobering at the same time. I'm excited to see what the coming years has in store, and I'm excited to take on this challenge. after the elections, I discussed with the board that I would be willing to take on the role as Treasurer for the organization. I still have to be officially voted in, but it looks as though that's the direction this is heading :).
After lunch, I participated in a forum discussion about the Black Box Software Testing classes. I have to say, this is an area that is near and dear to my heart, since the whole point of my blog is backing away from mis-education and making an effort towards re-education (n the good way, not the internment camp way ;) ).We had a vigorous discussion with Selena Delesie, Doug Hoffman, Mimi Mendenhall, and myself talking about the future of the classes, setting expectations, and geting through the dreaded first quiz. It also made me smile to realize that so many people had that same experience, yet had overwhelmingly positive things to say about the course as a whole. That makes me feel confident that there's a great opportunity in these classes and I'm hoping to see them grow and expand.
I was able to be an attendee again for the final track session, and I chose to attend Sajjadul Hakim's "Understanding the Gut Feelings in Testing". I enjoyed hearing Sajjadul discuss the ways that both the conscious and unconscious mind work together. In reality, we all work on gut feelings, but the expert tester has more than gut feeling to work with. We have heuristics, we have ways of analyzing what we see, but often, we stil have that unmistakable "feeling" that makes itself known when they test. the best way to describe this is that they have already conditioned themselves to these ideas, and because they have conditioned themselves, they have a deep reserve of knowledge and experience to draw from. I find myself struggling with this myself, in that I have lots of intuition, but I don't really trust it much of the time. Many times, that intuition does prove to be true, but it's fallible enough to make us doubt our intuition. But if we continue testing and seeing these things happen over and over again, then we get to trust that intuition more and more.
At the end of the day, Matt and Markus gathered Ajay, Elena and me together and anounced that, based on our performance in the CAST testing challenge, all three of us deserved to receive our black belts in the Miagi-do school of software testing. For the record, I respect both Matt and Markus a lot, and while I get the idea that the belt system in Miagi-do is a little corny and helps us not take ourselves to seriously, it does mean I had the chance to work with testers I admire and respect, and after several hours of intense focus, having them say "yeah, Michael, you get this, you are genuinely and solidly competent as a tester" really means a lot to me. For those curious as to how long it took me to update my blog with the new designation, the official answer is "two minutes"; enough time to whip open my laptop and get to the page to edit :).
Peter Walen and I were able to facilitate the Education Sig meeting and we had a good group come and join us. We discussed some cool ideas that we'd like to see the Education SIG take on, as well as opportunities for the SIGs to get involved in conferences or other events directly and make time so that we can complete initiatives that have been in limbo for some time. Also, we got word that the script and the syllabus for the Test Design class for BBST is finished and that we wil be looking at the class being available some time in late September or early October. Again, I'm excited to see it, and I'm looking forward to being a participant in it.
Tomorrow it will be the 1/2 and full day tutorials. By their nature, I'm guessing the twet stream will be a lot smaller, as most of the people at the conference will have left. I'm for sure attending Anne Marie Charret's tutorial on "Managing Testing Careers". We'll see what else tomorrow brings, but one things for sure, the adventure ends tomorrow at 5:00 PM and then it's time to get back to Sea-Tac and get on a plane to come back home.
That's it for me for today :).
Monday, August 8, 2011
CAST 2011 - Day 1
Well, I am in Seattle, (Lynwood, WA, to be more precise ) and the start of the CAST Conference is officially just a few minutes away. We had a bit of a celebratory get together last night at a Thai restaurant near our hotel here (poor place probably didn't know what hit them with 26 testing geeks pretty much taking over 23/rd of the restaurant. I had a great time sitting with Anne Marie Charret, Scott Allman, Fiona Charles and Paul Holland. We had a rather engaging discussion about ethics in testing and the little ways that we often cross that line each day without even knowing it, and how important it is to keep aware and alert in those instances. I also sat down an learned how to play set, which is an interesting game with shapes, colors and shading, and the ability to determine what a set is within the rules of the game. Matt Heusser, Michael Bolton, Adam Yuret, Paul Holland and Ryan Freckleton made for a fun time of it.
To kick things off this morning, we have a gathering of the Miagi-do School of Software Testing at breakfast. Elena Houser, Markus Gaertner, Matt Heusser, Ajay Balamurugadas and I are all sitting at a table together, and Matt just made a big announcement to all of us... he is planning on having a peer conference specifically for Test though leaders and senior testers looking to make the move towards becoming consultants, with the idea that we can influence more development and understanding with the testers that are just entering the field. The title for the conference is "Test Coach Camp" but hey, don't hold to that, it may very well change. The details are of course, preliminary, but as of right now, the thought is that the conference will be held sometime in October 2012 and at the moment, leaning towards Orlando as a location. More to come on this as we get closer t it happening. Markus just made a presentation to Ajay of Jerry Weinberg's book "Becoming a Technical Leader" with a mock up cover saying "Miagi-do: Best Practices for the Black Belt Level". I'd have to say I agree, this is a great title for this purpose :).
Not to all, if you would like to follow along with Michael Bolton's keynote this morning, it's being broadcast live.
Jon has taken the stage and we have officially kicked off the conference. Jon Bach is on stage now and we are going through the administrivia, including an update on Cem Kaner's health. Cem said that there was an issue with the family, but he didn't give details. we are happy to hear everything is OK, but sad he and Becky are not here.
Doug Hoffman and James Bach are speaking about the program ideas and how they came to be. for those not familiar with the way the program came together this year, there was no call for speakers directly; James got a little flack about this from Fiona Charles and others that there wasn't a direct call for people to present. This did, however, bring to the fore an idea about giving a call for people to talk about things and present an idea to be considered byt a committee to decide who wants to speak. from that the emerging topics track was born... and I'm actually going to be the first person to speak in that track :).
Paul Holland is explaining the three card system that is used at CAST. The facilitator sees one of the cards being held up and then has the opportunity to ask certain questions. A green card represents a new question, a yellow card allows you to ask a question on the same thread. A Red card allows you to jump to the top of the queue. It means "what I have to say is more important than anyone else in the room". this is a cool way to manage questions threads, and allows those participating to actually "confer" in their conference. What a concept :).
Michael Bolton took the stage for the first morning keynote and described a show that CBC (Canadian Broadcasting Corporation) produces called "Ideas". It's a broad range of topics. Often the shows are one-offs, but they occasionally do series programs, the program that Michael highlighted was "How to think about Science" (a program that Michael has sent me to a few times for individual podcasts). One fo those shows described the founding of the scientific method, and the rather wild fight that ensued to make that possible. This was made famous in a book called "the Leviathan and the Air Pump" and it has a number of interesting hypotheses, the idea that we can measure something to get to an actual fact. the challenge is that experimental tests, while they can provide a lot of information, it does not really "prove" that something works. In fact, the unreliability of equipment and other things cause many issues and makes the point that testing and experimentation, while helpful, can easily be gamed and tweaked to support any sides story.
Michael continues to show that the world is a complex, variable and messy place... there's lots of complexity, uncertainty, and challenges that will stymie any direct and "static" approach. Context driven testing makes it clear that there will be messy complexity, and there will be times where what works in one case won't work somewhere else. There is so much detail in Michael's talk i can hardly keep up with it (LOL!). A great opening, and if you can't see it live, check it out later on blip.tv (link to be added later). I'm witnessing my first "card" Q&A session, and this is pretty cool to watch. So many questions and the ability to have them follow a thread has made or a really great discussion about whether or not it is valuable to switch our language to "I disagree" rather than to say "you're wrong". Some agre with this approach, some disagree, and it is interesting to hear so many follow-on comments. Also, I found it amusing that the first red card to be thrown at this conference was by James Bach :).
the first "talk of the morning that I am attending is "Paths for Self-Education in Software Testing" with Markus Gaertner. there's several reasons why I chose this talk (Markus being my Miagi-do Sensei notwithstanding :) ) this is a topic that is very near and dear to my heart. Most of us do not aspire to be software testers. I don't really know of anyone who as a kid or a teenager said "I want to be a software tester when I grow up" or "when I go to college I am going to study software testing". Nope, for most of us we got into the field because of a need, and we discovered we liked doing it, and then we have to figure out how to do our jobs by various methods. Markus makes the point that most of us are going to have to be responsible for our own education. One of the key things to start with is feedback. Here's where writing a blog, or writing articles or presenting talks at conferences, as well as social media interaction will be significant. The beauty of this is that there is often a one:one feedback level. The challenge is that sometimes you don't get *any* feedback in these areas. Another area that Markus recommends it to learn how to program. this has been part of my current reality in my new job. It's the first time that I have had to seriously look at programming and writing tests on a regular basis that has required this, and I can safely say this does provide a new appreciation for what the developers are doing. Some may also argue that this is getting in the way of actively testing; while we focus on programming, we are not actively testing. I can see both sides of this argument, to tell the truth. Markus makes the point that there are two methods for looking at information and learning. There's the Hypothesis approach, where we read about and focus on the analytical aspects. On the other end is synthesis, which focuses on the things that we actively do (weekend testing, testing dojos, Miagi-do, etc.). The key point is that we don't learn just from study, and we don't learn just by practice, we need to do both in conjunction with one another, and then we will maximize our ability to work with and understand the material.
During lunch, we had a chance to talk about the Board of Directors election, where Pete Walen, Matt Heusser and I talked about what we hoped to bring to the Board of Directors .Addtionally, Cem Kaner had an email he sent read in. For the record, I think the entire group of candidates are awesome, and if I make it, I will serve to my full ability, and if I don't, I will not feel bummed because any and all of them will do a great job... but hey, if you want to vote for me, I'll not object :).
So I presented a talk in the Emerging Topics track. My talk was titled "Be Prepared: What Can Boy Scouts Teach Testers?". For those thinking this will be a talk about tying knots or camping, you'll be disappointed. Actually, it's going to be sharing a bit of the training that we espouse and the emphasis on "EDGE", the way that teams develop. Just about every team goes through four stagesof team development. This is actively taught in scouting, and it's part of the advancement criteria for scouts, so they lean this pretty early on. I thought it might be worthwhile to talk about this among testers, because there are many parallels. The four stage of team development are referred to as "Forming" (gathering people together so that they can accomplish a goal), "Storming" (where different ideas about the outcome or goal are expressed, and trying to figure out who wants to go which direction), "Norming"(where the team aligns towards the objective or goal) and then "Performing" (where everyone is working towards the objective). The Acronym EDGE stands for "Explain, Demonstrate, Guide and Enable" and each step is associated with a different stage in team development. the point is that we need to pivot and change our approach to deal with each level, and that external input can change those dynamics, taking a team that is performing well and busting them down to an earlier level.
Ajay Balamuguradas discussed weekend testing and the successes/challenges that they (we face). I wanted to see this talk so that I could see and consider Weekend testing from one of the founder's perspectives, and see how he has dealt with the challenges that we do here in the Americas. It's heartening to see that their challenges are our challenges an vice versa. many of the issues they are dealing with ring true with our experiences. Some feedback from the audience was to make sure we actively considered the feedback from the participant and see if their expectations were met, and if not, why not? Also, it was interesting to hear some of the issues and challenges that testers themselves have with the format of the weekend testing approach. All in all, I think Ajay did a really good job.
Matt Heusser taked about the Economics of test automation and how automation is good when it is part of a "balanced breakfast" (his preferred phraseology) and that in many cases, what we invest in and the return of investment we get is often not at all worth the amount of time we put into it. Matt brought up the idea of "inattentional blindness" and that automation by its very nature (especially the click and follow to get a value type) is akin to walking through a minefield. We may find bugs in the process as we go through making the tests, but in the future, we'll likely never find another bug with those tests unless something changes in the front end, because we're just walking in the path of the mines we've already detonated. Those tests, unless they are specifically varied, will not help us find new bugs because we are limited to the actual paths that we follow. I see the point, and I agree that automation is going to be a part of the equation, but it should not be elevated to being the be all and end all of the test process. Oh, and it's one of the most imaginative placings of "Keynes and Hayek 2nd Round" I've yet seen (LOL!).
During one of the breaks, Matt decided to try me out to see if I was ready to test for a black belt. I won't say anything about the challenge because it will diminish the ability to use the challenge for future students, and I felt that I did pretty well with it. During the debrief, I was told about the things that they felt I did right, but that there were some areas that, upon reflection, were somewhat obvious that I should have considered. Granted, this is outside of software and dealing with a situation that I had not considered, b ut there's some really great information i gleaned from this challenge. I also determined I wasn't quite ready for the black belt challenge, and I'm OK with that. It shows me that there's a lot of areas I should still be looking at that I didn't consider, so there's definitely more for me to learn before I can really consider myself a black belt.
To close out the night, the Miagi-do team got together so that we could participate in the testing challenge. We asked Matt if he'd participate, and he reminded us that he was a conference organizer and that if he was on a team they would be ineligible for the cash prize. We all said "we don't care, we want to see what the Miagi-do school can do together in real life" and with that, we were off to the races. It was a race, in that we pounded on the test application for really close to the 4 hours that we were allotted Markus Gaertner took on the role of being the "testmaster" and we did several 20 minute tight and focused testing sessions. It was really fun, very exhausting, but incredibly cool to be working directly with so many testers that I knew by reputation only, and now I had a chance to really get my hands dirty side by side with them, and it was an awesome time! Will we win? We don't know, and honestly, it doesn't matter (we're not eligible for the prize anyway, but the chance to work together was worth the time and energy all by itself). At the end of the day (10:00 PM, a group of us decided to go and find some lace to eat and decompress. Nothing like 30 testers roaming the streets of Lynnwood at night (LOL!).
All in all an awesome first day, hope you enjoyed the stream of consciousness. More to come as I start talking about Day 2!
To kick things off this morning, we have a gathering of the Miagi-do School of Software Testing at breakfast. Elena Houser, Markus Gaertner, Matt Heusser, Ajay Balamurugadas and I are all sitting at a table together, and Matt just made a big announcement to all of us... he is planning on having a peer conference specifically for Test though leaders and senior testers looking to make the move towards becoming consultants, with the idea that we can influence more development and understanding with the testers that are just entering the field. The title for the conference is "Test Coach Camp" but hey, don't hold to that, it may very well change. The details are of course, preliminary, but as of right now, the thought is that the conference will be held sometime in October 2012 and at the moment, leaning towards Orlando as a location. More to come on this as we get closer t it happening. Markus just made a presentation to Ajay of Jerry Weinberg's book "Becoming a Technical Leader" with a mock up cover saying "Miagi-do: Best Practices for the Black Belt Level". I'd have to say I agree, this is a great title for this purpose :).
Not to all, if you would like to follow along with Michael Bolton's keynote this morning, it's being broadcast live.
Jon has taken the stage and we have officially kicked off the conference. Jon Bach is on stage now and we are going through the administrivia, including an update on Cem Kaner's health. Cem said that there was an issue with the family, but he didn't give details. we are happy to hear everything is OK, but sad he and Becky are not here.
Doug Hoffman and James Bach are speaking about the program ideas and how they came to be. for those not familiar with the way the program came together this year, there was no call for speakers directly; James got a little flack about this from Fiona Charles and others that there wasn't a direct call for people to present. This did, however, bring to the fore an idea about giving a call for people to talk about things and present an idea to be considered byt a committee to decide who wants to speak. from that the emerging topics track was born... and I'm actually going to be the first person to speak in that track :).
Paul Holland is explaining the three card system that is used at CAST. The facilitator sees one of the cards being held up and then has the opportunity to ask certain questions. A green card represents a new question, a yellow card allows you to ask a question on the same thread. A Red card allows you to jump to the top of the queue. It means "what I have to say is more important than anyone else in the room". this is a cool way to manage questions threads, and allows those participating to actually "confer" in their conference. What a concept :).
Michael Bolton took the stage for the first morning keynote and described a show that CBC (Canadian Broadcasting Corporation) produces called "Ideas". It's a broad range of topics. Often the shows are one-offs, but they occasionally do series programs, the program that Michael highlighted was "How to think about Science" (a program that Michael has sent me to a few times for individual podcasts). One fo those shows described the founding of the scientific method, and the rather wild fight that ensued to make that possible. This was made famous in a book called "the Leviathan and the Air Pump" and it has a number of interesting hypotheses, the idea that we can measure something to get to an actual fact. the challenge is that experimental tests, while they can provide a lot of information, it does not really "prove" that something works. In fact, the unreliability of equipment and other things cause many issues and makes the point that testing and experimentation, while helpful, can easily be gamed and tweaked to support any sides story.
Michael continues to show that the world is a complex, variable and messy place... there's lots of complexity, uncertainty, and challenges that will stymie any direct and "static" approach. Context driven testing makes it clear that there will be messy complexity, and there will be times where what works in one case won't work somewhere else. There is so much detail in Michael's talk i can hardly keep up with it (LOL!). A great opening, and if you can't see it live, check it out later on blip.tv (link to be added later). I'm witnessing my first "card" Q&A session, and this is pretty cool to watch. So many questions and the ability to have them follow a thread has made or a really great discussion about whether or not it is valuable to switch our language to "I disagree" rather than to say "you're wrong". Some agre with this approach, some disagree, and it is interesting to hear so many follow-on comments. Also, I found it amusing that the first red card to be thrown at this conference was by James Bach :).
the first "talk of the morning that I am attending is "Paths for Self-Education in Software Testing" with Markus Gaertner. there's several reasons why I chose this talk (Markus being my Miagi-do Sensei notwithstanding :) ) this is a topic that is very near and dear to my heart. Most of us do not aspire to be software testers. I don't really know of anyone who as a kid or a teenager said "I want to be a software tester when I grow up" or "when I go to college I am going to study software testing". Nope, for most of us we got into the field because of a need, and we discovered we liked doing it, and then we have to figure out how to do our jobs by various methods. Markus makes the point that most of us are going to have to be responsible for our own education. One of the key things to start with is feedback. Here's where writing a blog, or writing articles or presenting talks at conferences, as well as social media interaction will be significant. The beauty of this is that there is often a one:one feedback level. The challenge is that sometimes you don't get *any* feedback in these areas. Another area that Markus recommends it to learn how to program. this has been part of my current reality in my new job. It's the first time that I have had to seriously look at programming and writing tests on a regular basis that has required this, and I can safely say this does provide a new appreciation for what the developers are doing. Some may also argue that this is getting in the way of actively testing; while we focus on programming, we are not actively testing. I can see both sides of this argument, to tell the truth. Markus makes the point that there are two methods for looking at information and learning. There's the Hypothesis approach, where we read about and focus on the analytical aspects. On the other end is synthesis, which focuses on the things that we actively do (weekend testing, testing dojos, Miagi-do, etc.). The key point is that we don't learn just from study, and we don't learn just by practice, we need to do both in conjunction with one another, and then we will maximize our ability to work with and understand the material.
During lunch, we had a chance to talk about the Board of Directors election, where Pete Walen, Matt Heusser and I talked about what we hoped to bring to the Board of Directors .Addtionally, Cem Kaner had an email he sent read in. For the record, I think the entire group of candidates are awesome, and if I make it, I will serve to my full ability, and if I don't, I will not feel bummed because any and all of them will do a great job... but hey, if you want to vote for me, I'll not object :).
So I presented a talk in the Emerging Topics track. My talk was titled "Be Prepared: What Can Boy Scouts Teach Testers?". For those thinking this will be a talk about tying knots or camping, you'll be disappointed. Actually, it's going to be sharing a bit of the training that we espouse and the emphasis on "EDGE", the way that teams develop. Just about every team goes through four stagesof team development. This is actively taught in scouting, and it's part of the advancement criteria for scouts, so they lean this pretty early on. I thought it might be worthwhile to talk about this among testers, because there are many parallels. The four stage of team development are referred to as "Forming" (gathering people together so that they can accomplish a goal), "Storming" (where different ideas about the outcome or goal are expressed, and trying to figure out who wants to go which direction), "Norming"(where the team aligns towards the objective or goal) and then "Performing" (where everyone is working towards the objective). The Acronym EDGE stands for "Explain, Demonstrate, Guide and Enable" and each step is associated with a different stage in team development. the point is that we need to pivot and change our approach to deal with each level, and that external input can change those dynamics, taking a team that is performing well and busting them down to an earlier level.
Ajay Balamuguradas discussed weekend testing and the successes/challenges that they (we face). I wanted to see this talk so that I could see and consider Weekend testing from one of the founder's perspectives, and see how he has dealt with the challenges that we do here in the Americas. It's heartening to see that their challenges are our challenges an vice versa. many of the issues they are dealing with ring true with our experiences. Some feedback from the audience was to make sure we actively considered the feedback from the participant and see if their expectations were met, and if not, why not? Also, it was interesting to hear some of the issues and challenges that testers themselves have with the format of the weekend testing approach. All in all, I think Ajay did a really good job.
Matt Heusser taked about the Economics of test automation and how automation is good when it is part of a "balanced breakfast" (his preferred phraseology) and that in many cases, what we invest in and the return of investment we get is often not at all worth the amount of time we put into it. Matt brought up the idea of "inattentional blindness" and that automation by its very nature (especially the click and follow to get a value type) is akin to walking through a minefield. We may find bugs in the process as we go through making the tests, but in the future, we'll likely never find another bug with those tests unless something changes in the front end, because we're just walking in the path of the mines we've already detonated. Those tests, unless they are specifically varied, will not help us find new bugs because we are limited to the actual paths that we follow. I see the point, and I agree that automation is going to be a part of the equation, but it should not be elevated to being the be all and end all of the test process. Oh, and it's one of the most imaginative placings of "Keynes and Hayek 2nd Round" I've yet seen (LOL!).
During one of the breaks, Matt decided to try me out to see if I was ready to test for a black belt. I won't say anything about the challenge because it will diminish the ability to use the challenge for future students, and I felt that I did pretty well with it. During the debrief, I was told about the things that they felt I did right, but that there were some areas that, upon reflection, were somewhat obvious that I should have considered. Granted, this is outside of software and dealing with a situation that I had not considered, b ut there's some really great information i gleaned from this challenge. I also determined I wasn't quite ready for the black belt challenge, and I'm OK with that. It shows me that there's a lot of areas I should still be looking at that I didn't consider, so there's definitely more for me to learn before I can really consider myself a black belt.
To close out the night, the Miagi-do team got together so that we could participate in the testing challenge. We asked Matt if he'd participate, and he reminded us that he was a conference organizer and that if he was on a team they would be ineligible for the cash prize. We all said "we don't care, we want to see what the Miagi-do school can do together in real life" and with that, we were off to the races. It was a race, in that we pounded on the test application for really close to the 4 hours that we were allotted Markus Gaertner took on the role of being the "testmaster" and we did several 20 minute tight and focused testing sessions. It was really fun, very exhausting, but incredibly cool to be working directly with so many testers that I knew by reputation only, and now I had a chance to really get my hands dirty side by side with them, and it was an awesome time! Will we win? We don't know, and honestly, it doesn't matter (we're not eligible for the prize anyway, but the chance to work together was worth the time and energy all by itself). At the end of the day (10:00 PM, a group of us decided to go and find some lace to eat and decompress. Nothing like 30 testers roaming the streets of Lynnwood at night (LOL!).
All in all an awesome first day, hope you enjoyed the stream of consciousness. More to come as I start talking about Day 2!
Friday, August 5, 2011
Podcast Friday: Continuous Deployment, James Bach, Scionology and Paleo
Wow, it's Friday already? Where does the week go? That means it's time to review and comment on the various podcasts released in the past week that I've found interesting, entertaining, and informative.
Over at Software Test Pro, we've delivered another healthy helping of TWiST. In this episode, Matt sits down and talks with Noah Sussman of Etsy, the site dedicated to crafters of all types and making them storefronts to sell their wares. To say that this is a dedicated and passionate audience would be an understatement. Noah discusses developing and testing a site like Etsy, which emphasizes Continuous Deployment. Lots of buzzwords surround the notion of C.D., but Noah describes the reality of how Etsy does it and how they test it.
Bruce and Trish are back again this week with the next installment of Testcast, and this time they have a guest on the show, the inimitable James Bach. James always makes for an entertaining interview, and this is no exception. James describes the situations where he has decided to walk from a job rather than sacrifice integrity, as well as some of the tools that James finds valuable to help him in his day to day testing efforts This is the first part of what I'll guess is a two part interview, so I'm curious to see what Testcast will bring us next week.
The wild ride that is "Back to Work" is still one of my favorite listens, but again, it takes a bit of time to get into it, and often the first 20 minutes are banter that rewards the regular listener. First time listeners may well get lost in this, so I'm warning you now :). Episode #27 "Danny, Hold The License Plate" describes in equal parts the ongoing banter that Dan and Merlin share, but they also "vamp" more on the idea of "positions of strength" and knowing if and when it's time to walk away from a job (hey, I sense a theme this week :) ), as well as the idea behind subconscious information processing. Anyway, if you have been listening since I started cheerleading for them, then you will probably dig it. If this is your first time, you might want to listen with 1/2 an ear for the first 25 minutes or so ;). By the way, if anyone scratches their heads about the frequent mentions of "Squidword" in the show, they're referring to John Siracusa, who appears with Dan on the 5by5 show "Hypercritical".
Freakonomics is back and this week they investigate the "Church of Scionology". Nope that's not a typo, it's the idea that many companies keep it in the family and keep the leadership of companies handed down to the eldest son or some other member of the immediate family. Many family owned companies have this distinction, and the economists of Freakonomics ask "is this a good thing?" In many cases, families who put in the time and effort to become good executives and competent administrators and pass that ethic down to their kids do very well. Not all families do this, though, and the fact is, in many cases, the skills needed are not to be found in the family. This show goes through some examples of families like Anheuser-Busch and Yuengling & Son (both brewery's, interestingly), and the difference in "heir-run firms" in the U.S. and in other counties, and a country that takes the "Scion" approach to a unique level… Japan. Here, keeping it in the family has a whole different meaning, where if the son isn't up to the task, the parent will adopt a son, an adult of 25 or 30 years old able to take on the business… AND TAKE ON THE FAMILY NAME. Seriously, this one is fascinating and a recommended listen.
For my "out of the blue" podcast pick for this week, which may or may not have anything to do with testing whatsoever, is called "Latest in Paleo". It's a 5by5 property, and it's hosted by Angelo Coppola. It's based around the Paleo diet (which I will confess up front I don't follow) but there's lots of interesting things he covers, and the premise of the show is something I like a lot, which is the idea that "human beings are not broken by default" and that we should be open to viewing the place "where scientific evidence intersects with evolutionary clues". Anyway, I find it interesting; you may as well.
And finally, if you are interested in hearing the results of "The Great AST Board of Directors Debate", well, you're in luck. All of the candidates (Matthew Heusser, Cem Kaner, Michael Larsen, Catherine Powell and Peter Walen) are represented and pretty much the whole interview is up (we did some formatting for sound and time limitations). If you want to listen, go here.
So what are you listening to this week? Anything testing related?
Over at Software Test Pro, we've delivered another healthy helping of TWiST. In this episode, Matt sits down and talks with Noah Sussman of Etsy, the site dedicated to crafters of all types and making them storefronts to sell their wares. To say that this is a dedicated and passionate audience would be an understatement. Noah discusses developing and testing a site like Etsy, which emphasizes Continuous Deployment. Lots of buzzwords surround the notion of C.D., but Noah describes the reality of how Etsy does it and how they test it.
Bruce and Trish are back again this week with the next installment of Testcast, and this time they have a guest on the show, the inimitable James Bach. James always makes for an entertaining interview, and this is no exception. James describes the situations where he has decided to walk from a job rather than sacrifice integrity, as well as some of the tools that James finds valuable to help him in his day to day testing efforts This is the first part of what I'll guess is a two part interview, so I'm curious to see what Testcast will bring us next week.
The wild ride that is "Back to Work" is still one of my favorite listens, but again, it takes a bit of time to get into it, and often the first 20 minutes are banter that rewards the regular listener. First time listeners may well get lost in this, so I'm warning you now :). Episode #27 "Danny, Hold The License Plate" describes in equal parts the ongoing banter that Dan and Merlin share, but they also "vamp" more on the idea of "positions of strength" and knowing if and when it's time to walk away from a job (hey, I sense a theme this week :) ), as well as the idea behind subconscious information processing. Anyway, if you have been listening since I started cheerleading for them, then you will probably dig it. If this is your first time, you might want to listen with 1/2 an ear for the first 25 minutes or so ;). By the way, if anyone scratches their heads about the frequent mentions of "Squidword" in the show, they're referring to John Siracusa, who appears with Dan on the 5by5 show "Hypercritical".
Freakonomics is back and this week they investigate the "Church of Scionology". Nope that's not a typo, it's the idea that many companies keep it in the family and keep the leadership of companies handed down to the eldest son or some other member of the immediate family. Many family owned companies have this distinction, and the economists of Freakonomics ask "is this a good thing?" In many cases, families who put in the time and effort to become good executives and competent administrators and pass that ethic down to their kids do very well. Not all families do this, though, and the fact is, in many cases, the skills needed are not to be found in the family. This show goes through some examples of families like Anheuser-Busch and Yuengling & Son (both brewery's, interestingly), and the difference in "heir-run firms" in the U.S. and in other counties, and a country that takes the "Scion" approach to a unique level… Japan. Here, keeping it in the family has a whole different meaning, where if the son isn't up to the task, the parent will adopt a son, an adult of 25 or 30 years old able to take on the business… AND TAKE ON THE FAMILY NAME. Seriously, this one is fascinating and a recommended listen.
For my "out of the blue" podcast pick for this week, which may or may not have anything to do with testing whatsoever, is called "Latest in Paleo". It's a 5by5 property, and it's hosted by Angelo Coppola. It's based around the Paleo diet (which I will confess up front I don't follow) but there's lots of interesting things he covers, and the premise of the show is something I like a lot, which is the idea that "human beings are not broken by default" and that we should be open to viewing the place "where scientific evidence intersects with evolutionary clues". Anyway, I find it interesting; you may as well.
And finally, if you are interested in hearing the results of "The Great AST Board of Directors Debate", well, you're in luck. All of the candidates (Matthew Heusser, Cem Kaner, Michael Larsen, Catherine Powell and Peter Walen) are represented and pretty much the whole interview is up (we did some formatting for sound and time limitations). If you want to listen, go here.
So what are you listening to this week? Anything testing related?
Thursday, August 4, 2011
WT...3D?!
Nope, that's not some cool new robot, or some odd new protocol, it's the designation of the first Weekend Testing event to be held as part of a testing conference (well, that I know of anyway, I could be wrong on that front :) ).
Still, Weekend Testing will be coming to the Conference for the Association for Software Testing (CAST). Actually Weekend Testing will be represented at CAST in two ways. Ajay Balamurugadas will be presenting a talk titled "Weekend Testing: Skilled Software Testing Unleashed" Monday, August 8th at 1:00 pm PDT. I will be conducting a live Weekend Testing Session from CAST on Tuesday, August 9th, starting at 10:45 am PDT and running until 12:45 pm PDT. This will be akin to being a Weeknight Testing session for those in the U.K. and Europe, and would probably be a late night for those in India or a very early morning for those in Autralia/New Zealand. It will of course be during work hours for those in the Americas, which will either be a negative or a positive for various people (those who have complained they would attend if it wasn't on a weekend, well, here your chance :) ).
So why the "3D" part? Well, because we will be in a live room for the attendees of CAST so that they can learn specifically how to facilitate Weekend Testing sessions, and see how it works behind the scenes. So for those attending CAST, whoever wanted to know the ins and outs of running Weekend Testing, here's your chance. For those of you who want an excuse to do some testing fun on a Tuesday (or Wednesday if you are in the Far East :) ), then come and join us.
How, you say? To join at CAST, come by the WIFI lounge in the Lynwood Convention Center. To join remotely, add "weekendtestersamericas" to your Skype ID list and email "WTAmericas@gmail.com" to let us know you would like to participate.
Hope to see you there :)!!!
Still, Weekend Testing will be coming to the Conference for the Association for Software Testing (CAST). Actually Weekend Testing will be represented at CAST in two ways. Ajay Balamurugadas will be presenting a talk titled "Weekend Testing: Skilled Software Testing Unleashed" Monday, August 8th at 1:00 pm PDT. I will be conducting a live Weekend Testing Session from CAST on Tuesday, August 9th, starting at 10:45 am PDT and running until 12:45 pm PDT. This will be akin to being a Weeknight Testing session for those in the U.K. and Europe, and would probably be a late night for those in India or a very early morning for those in Autralia/New Zealand. It will of course be during work hours for those in the Americas, which will either be a negative or a positive for various people (those who have complained they would attend if it wasn't on a weekend, well, here your chance :) ).
So why the "3D" part? Well, because we will be in a live room for the attendees of CAST so that they can learn specifically how to facilitate Weekend Testing sessions, and see how it works behind the scenes. So for those attending CAST, whoever wanted to know the ins and outs of running Weekend Testing, here's your chance. For those of you who want an excuse to do some testing fun on a Tuesday (or Wednesday if you are in the Far East :) ), then come and join us.
How, you say? To join at CAST, come by the WIFI lounge in the Lynwood Convention Center. To join remotely, add "weekendtestersamericas" to your Skype ID list and email "WTAmericas@gmail.com" to let us know you would like to participate.
Hope to see you there :)!!!
Tuesday, August 2, 2011
Of Rifles and Shotguns: Understanding Our Tools
One of the conversations that has been bandied around a lot is how relevant a particular tool is to a testers arsenal. During last night’s debate, Phil Kirkham to add some levity, but to also make a point “asked ‘Should QTP die?’, which relates to commentary written by Paul Hammant at his Inversionism blog. My answer was that we need to somehow get beyond the mysticism of tools and see them for what they are, means to an end, and not wrap so much expectation around what tools people use.
I say this now because I’ve had to shift the tools I’ve used over the past six to nine months. In my previous job, we used a lot of NUnit and TestComplete was the tool that I used to do the automated testing that I did do (which admittedly was not very much). In my current environment, I am learning the various intersections of Selenium, WebDriver and Capybara, and how to effectively interact with them using Ruby, RSpec and Cucumber. Which is better? Which would I defend to the death? Well, neither, really. They are tools, and they have a purpose for their environment. One grouping would not work as well in the other environment and vice versa. My suggestion is to use the tools that are best suited for the task at hand, and to understand when each is required, more than getting hung up on the tool used.
Last Saturday, I had the opportunity to bring my Scout Troop up to the Los Altos Rod and Gun Club. This is an area up on Skyline Boulevard between Saratoga and Boulder Creek. It’s up in the mountains, well away from eyes and ears. An ideal place to shoot guns of varying types. This day, we came up with several .22 caliber rifles, 2 .12 gauge shotguns one .20 gauge shotgun, and a few handguns, including a friends Smith and Wesson .41 Magnum (which I’ll talk about more later on ;) ).
As we were cleaning and preparing the equipment to shoot, I noticed that some boys who were good with the shotgun were not so good with the rifle, and vice versa. What was also apparent was that, those boys who did better at one type of shooting ended up spending most of their time doing that particular kind of shooting. Rifle aficionados who had trouble getting the shotgun to do what they wanted felt frustrated. Shotgun aficionados were having trouble aiming the rifle precisely. Both, I think, neglected to realize that their respective tools required different levels of thinking about how to use them. I demonstrated to one of the boys that, if they understood the tools they had, both their abilities as well as their limitations, they would be able to use them effectively. To illustrate this, I asked them if they’d watch me for awhile and see how I react. I had never shot a shotgun prior to this trip. If fired rifles and handguns, and have a personal love for the art of black powder rifles and muskets of yesteryear, but a shotgun was a new experience for me. As I tried to get the feel of a few guns, I noticed that the smaller 20 gauge was difficult for me to look down and aim, so after a few shots, I put it down and focused on another shotgun, one of the .12 gauges. At first, I was not hitting any of the clay targets as they were being launched, and part of me was getting frustrated. I was waiting for the target to get to where I had lined up my aim, and I pulled my trigger at the right time, but no dice, the target wasn’t being hit.
As I looked at the shotgun and the cartridge, I came to a conclusion… I was treating the shotgun like a rifle. A rifle and a projectile fired from a rifle can be likened to a bolt of lightning. It’s precise, it’s targeted, and when it hits, it hits one place. That’s not at all how a shotgun works. Instead of a bullet, it fires lots of little beads and the beads spread in a broad area. In short, the “shot” of a shotgun is more akin to a cyclone, and the area a cyclone hits doesn’t have to be precise. It just has to be in the general area to feel its effect. With that, I changed tactics, not necessarily worrying about taking exact aim at the target, but following the target and then, without waiting too long, shooting. This change went from me hitting few targets to hitting every single one of them. At one stage, I went 24/24 (I mention this merely because the Boy Scout merit badge requirement states that a shooter much hit 12 out of 24 targets two times to qualify for the badge. It felt good to show my scouts that not only did I hit more than 12 our of 24, but that I did a perfect round, and I did it by understanding the way the shotgun worked and using it to its full advantage.
Our tools are not what define us as test craftsmen. They are aids in that process of definition, to be sure, but they alone will not make us great testers. They may well not even make us decent automators, either. By looking at the job at hand, and by actively focusing on what we need to do, and what the testing tool is actually capable of doing, rather than how we wish we could do it, then we will be able to get beyond the tool story and focus more on the purpose of the tool, which is to get the cumbersome work out of our way and allow us to focus our attention on more pressing testing matters and skills.
Oh, and as to that Smith and Wesson .41 Magnum handgun? First off, man that sucker has a kick like you wouldn't believe, and it is very loud, louder than any gun I've ever personally shot! It disavows you right quick of the television productions that show people coolly and easily holding a revolver with one hand and just casually shooting and hitting their mark. No way; without considerable control and balance, the shooter in questions will have a hard time controlling the shot, and might even find themselves being knocked over! Which also goes to show, tools and their hype may not be all that they seem :).
I say this now because I’ve had to shift the tools I’ve used over the past six to nine months. In my previous job, we used a lot of NUnit and TestComplete was the tool that I used to do the automated testing that I did do (which admittedly was not very much). In my current environment, I am learning the various intersections of Selenium, WebDriver and Capybara, and how to effectively interact with them using Ruby, RSpec and Cucumber. Which is better? Which would I defend to the death? Well, neither, really. They are tools, and they have a purpose for their environment. One grouping would not work as well in the other environment and vice versa. My suggestion is to use the tools that are best suited for the task at hand, and to understand when each is required, more than getting hung up on the tool used.
Last Saturday, I had the opportunity to bring my Scout Troop up to the Los Altos Rod and Gun Club. This is an area up on Skyline Boulevard between Saratoga and Boulder Creek. It’s up in the mountains, well away from eyes and ears. An ideal place to shoot guns of varying types. This day, we came up with several .22 caliber rifles, 2 .12 gauge shotguns one .20 gauge shotgun, and a few handguns, including a friends Smith and Wesson .41 Magnum (which I’ll talk about more later on ;) ).
As we were cleaning and preparing the equipment to shoot, I noticed that some boys who were good with the shotgun were not so good with the rifle, and vice versa. What was also apparent was that, those boys who did better at one type of shooting ended up spending most of their time doing that particular kind of shooting. Rifle aficionados who had trouble getting the shotgun to do what they wanted felt frustrated. Shotgun aficionados were having trouble aiming the rifle precisely. Both, I think, neglected to realize that their respective tools required different levels of thinking about how to use them. I demonstrated to one of the boys that, if they understood the tools they had, both their abilities as well as their limitations, they would be able to use them effectively. To illustrate this, I asked them if they’d watch me for awhile and see how I react. I had never shot a shotgun prior to this trip. If fired rifles and handguns, and have a personal love for the art of black powder rifles and muskets of yesteryear, but a shotgun was a new experience for me. As I tried to get the feel of a few guns, I noticed that the smaller 20 gauge was difficult for me to look down and aim, so after a few shots, I put it down and focused on another shotgun, one of the .12 gauges. At first, I was not hitting any of the clay targets as they were being launched, and part of me was getting frustrated. I was waiting for the target to get to where I had lined up my aim, and I pulled my trigger at the right time, but no dice, the target wasn’t being hit.
As I looked at the shotgun and the cartridge, I came to a conclusion… I was treating the shotgun like a rifle. A rifle and a projectile fired from a rifle can be likened to a bolt of lightning. It’s precise, it’s targeted, and when it hits, it hits one place. That’s not at all how a shotgun works. Instead of a bullet, it fires lots of little beads and the beads spread in a broad area. In short, the “shot” of a shotgun is more akin to a cyclone, and the area a cyclone hits doesn’t have to be precise. It just has to be in the general area to feel its effect. With that, I changed tactics, not necessarily worrying about taking exact aim at the target, but following the target and then, without waiting too long, shooting. This change went from me hitting few targets to hitting every single one of them. At one stage, I went 24/24 (I mention this merely because the Boy Scout merit badge requirement states that a shooter much hit 12 out of 24 targets two times to qualify for the badge. It felt good to show my scouts that not only did I hit more than 12 our of 24, but that I did a perfect round, and I did it by understanding the way the shotgun worked and using it to its full advantage.
Our tools are not what define us as test craftsmen. They are aids in that process of definition, to be sure, but they alone will not make us great testers. They may well not even make us decent automators, either. By looking at the job at hand, and by actively focusing on what we need to do, and what the testing tool is actually capable of doing, rather than how we wish we could do it, then we will be able to get beyond the tool story and focus more on the purpose of the tool, which is to get the cumbersome work out of our way and allow us to focus our attention on more pressing testing matters and skills.
Oh, and as to that Smith and Wesson .41 Magnum handgun? First off, man that sucker has a kick like you wouldn't believe, and it is very loud, louder than any gun I've ever personally shot! It disavows you right quick of the television productions that show people coolly and easily holding a revolver with one hand and just casually shooting and hitting their mark. No way; without considerable control and balance, the shooter in questions will have a hard time controlling the shot, and might even find themselves being knocked over! Which also goes to show, tools and their hype may not be all that they seem :).
Monday, August 1, 2011
Join Us For A "Twitter Testing Town Hall"
Catherine Powell posted about this earlier today and I'd like to follow suit :).
Later this evening (6:00 p.m. PDT, 9:00 p.m. EDT) I and three other candidates will be participating in a Twitter Testing Town Hall meeting to answer questions about AST, who we are, what we do, and why you should vote for us. the details about the debate are as follows:
Who: Matt Heusser, Michael Larsen, Catherine Powell and Pete Walen
What: A chance to ask any and all of us about why we are running for the AST board of directors and what we hope we can bring to the organization.
Where: It'll be on Twitter (http://twitter.com)
When: August 1, 2011 at 6:00 p.m. Pacific, 9:00 p.m. Eastern
Why: Because we want to not only tell you why we are running, but to also hear what *YOU* would like to see the board of directors make for priorities in 2011-2012 and beyond.
How: Simply jump on Twitter and post with the #ASTElect hash tag. You can aim any questions to any of the individual candidates, or ask us all. If you want to ask me a question, direct the tweet to @mkltesthead.
Looking forward to a fun and spirited event. Come join us :)!!!
Subscribe to:
Posts (Atom)