Today I had a chance to see just how well I was doing in my quest to learn Cucumber, RSpec and Ruby, and better move along the project of developing "Behavior Driven Smoke Testing"... naah, no cool acronym there, but it's been an interesting experience nonetheless. The Project that I'm working on is referred to internally as "Mordor", and it seems somewhat fitting. It was actually named by a co-worker with the idea that the "All-seeing Eye" would be checking on everything. Said co-worker was referring to the Eye of Sauron, but he, not really being a Tolkien fan (and he said so himself, I might add ;) ), confused the land of Mordor with the character of Sauron. I explained that the idea of a land surrounded by volcanic mountains that prevented invasion from without but also kept its inhabitants locked in seemed very fitting as a name for a smoke testing project.
As I demoed my tests for the first time in front of the whole engineering group, I had a chance to "defend" my own development work, so to speak. Overall, it was a good experience, and I learned a great deal about how to better implement and approach automated testing from different perspectives.
First, while I was given some praise for the detail and care I'd taken, I was also encouraged to not spend so much time on certain areas. These were smoke tests to check for broad and fast confirmation of functionality, not deep probing examinations of key areas. There would be time for those tests later, but it was wise to have ten tests that covered twenty functional areas rather than having ten tests that covered just one. Currently, I'm closer to the latter than the former, but I'm learning and getting better, so that helps.
Second, while data driven testing is a great method of reusing tests, it can be maddening in that it doesn't give the same kind of feedback a single linear test gives. It's certainly desirable to make tests extensible, but save that for after you have confirmed beyond a reasonable doubt that you have a clean test first.
Third, "red, green refactor" really is a strong as people say it is, and I am progressively worse as we go down that continuum. On the bright side, having gone through several dozen scenarios and scenario outlines now, I'm getting to the point where I don't have to look up each example, and I'm finding where repetitive actions can be grouped together into single line statements and stored in a steps file (you don't have to store just RSpec or ruby statements in a steps file, you can also chain existing cucumber feature statements into single line groupings and use them like a shared library. Yes, I realize that for many out there, this is total master of the obvious type stuff, but for me, this is the first time I feel like I'm really getting traction and making real moves with an automation framework.
Which brings me to fourth; a little every day. If I let a few days slip between making new tests, the rust accumulates fast, but if you give a little bit each day, even if it's just 30 minutes a day, you can keep the momentum moving in your favor. Fortunately, the past few weeks I've been able to get way more than 30 minutes a day.
It's been an interesting experience full of dark and light moments, things that are scary and make no sense, and things that work quickly once you get your flow going. Dare I say it, BDST, and writing tests in Cucumber, RSpec and Ruby is, gasp, actually pretty fun! I'm no great shakes just yet and I doubt that any hardcore Ruby developers need worry about me poaching their jobs just yet, but I am heartened by the fact that i seem to really be getting somewhere with this, finally. Who knows what the next few weeks will bring, but I hope it's ever more green and ever better refactoring. I'm looking forword to it, even if I must walk a dark path to get those skills :).
Thursday, June 30, 2011
Tuesday, June 28, 2011
Book Review: The Secret Ninja Cucumber Scrolls
First, some background. My exploration into Cucumber has been relatively recent, starting with shortly after the Selenium conference and accelerating with my company giving me an initiative to automate a range of user facing smoke tests. With this, the idea of Cucumber being the weapon of choice was somewhat decided for me, both by history and by recommendation from my teammates. There are a number of resources on the Internet regarding Cucumber, and there are also a couple of books out there related to Cucumber as well (most notably "The RSpec Book
", which I'm also currently reading).The challenge I've faced with many commercial books is that they usually, for sake of printed pages, have to focus on just one language or implementation, and leave the users to either match the implementation, or figure out their own environment on their own. Sometimes that's easy to do, and sometimes, due to inexperience or lack of familiarity with specific tools, a lot gets lost in translation. Additionally, a lot of books go into great and specific detail that would be helpful to an implementer of a framework, but tend to trip up more novice testers.
The Secret Ninja Cucumber Scrolls overcomes both of these issues quite handily. First, the book is written from three environment perspectives; Ruby, Java and .NET. As you might well guess, these environments have significant differences and architectural approaches, and as such, require different steps. The book itself is about 150 pages. When split between three environments, that means each environment gets about 50 pages worth of treatment. Because of this, the language specific tutorials and details tend towards the essential and most useful, which is a real blessing. For many testers, there isn't a need to have a mountain of prose and examples for every conceivable option. Get us up and running with the key insights and we'll gladly tinker around the edges to grow the set and the skills. The Secret Ninja Cucumber Scrolls adheres to this philosophy and does so very well.
Additionally, as you might guess, with its tongue in cheek title, the text and examples are likewise tongue in cheek. Most examples relate to how Chuck Norris can kick anyone's butt (I don't need to explain the Chuck Norris meme to this crowd, right? Yeah, I didn't think so ;) ). It's this fun irreverence and humorous style that makes the book enjoyable to read, and the split between the different styles makes it easy to hone in one what's important to me. Additionally, I really appreciate the fact that each area uses different tools and different frameworks and explains how to set each up, integrate the pieces, and work towards making each area work with clear examples. While I am not currently using Java or .NET for my testing, the fact that I can implement them in those environments and have the guidance necessary for them as well is comforting and encouraging. Who knows, I may need to do so some time down the road; it's great to know one book can cover all three to a good extent.
Will this be the be all and end all for Cucumber? Likely not. Will it be an excellent starting point? Absolutely! Do I plan to get more involved with it beyond here? I sure do, and this book has done more in a shorter amount of time than anything I've yet come across. If you are considering exploring Cucumber as part of an overall automation framework, start here. You'll learn what you need to to be productive very quickly, and with three environments to practice with, you're sure to find something that will work for your given area of focus.
Sunday, June 26, 2011
"Rock Star Euphoria" and "Roadie Reality"
On Thursday night, I had a great experience. I had a chance to sit down to dinner with Jon Bach, Michael Bolton, Jeff Fry, Doug Hoffman, and David Liebreich. This was a fantastic collection of "rock star" level test nerds, and we had a great dinner and a great conversation. I was on cloud nine, but through the night as I was talking about some of the things I was excited about, Michael looked at me with a wry smile and said something that was an epiphany to me. I'm paraphrasing this, so I don't want to go into all of the details, but he basically commented on the fact that there was a time when he had no idea who I was and then suddenly, I was everywhere. He said that it was fun to get a chance to be known and have a little notoriety, but that sometimes that notoriety is a double edged sword. It's great to have goals and a platform and even a desire to be in the mix, but we run the risk of losing our focus or being too focused on the wrong things.
This week, I came to a conclusion... I'm a hypocrite. I talk a mean game about being prepared, doing important work, and focusing on the things that really matter, yet I'm guilty of veering off course and not focusing on what really matters. Instead, I've been chasing the things that are fun and that I am passionate about. Here's the thing, it's pretty easy to do the stuff that's, well, easy, or the stuff that makes us feel like we've got it all covered. We take on more and more of those so called challenges while they are fun, and we get that heady sense of "rock star euphoria". When I was a musician, I often looked forward to performing. It was the whole point of slogging in the studio, practicing my scales and plinking out chords and melodies on a guitar or bass to write songs. Most of us did this because we looked forward to that hour on stage when we were on top of the world. That's what I mean by rock star euphoria. Problem is, we can't always be on stage. I can't sing my lungs out every night, it's just not possible. If I did, I would lose my voice regularly and I'd need to rest the voice. We can perform a lot, but ultimately, we'll stop giving really good performances if we do it too much.
I enjoy writing. I enjoy podcasting. I enjoy facilitating Weekend Testing. I enjoy being a teacher with AST. I enjoy getting ready to be a conference presenter (my newest goal and endeavor). These are great "performance" aspects, but they take time, and they take practice and slugging away well behind the scenes. The rock star euphoria I get when I push something new gives me a rush, but there's only so much voice in me (to extend the analogy). Even really enjoyable stuff, when we over commit, tends to leach and sap energy from the things we care about, and let's face it, it takes away from the things that are less enjoyable, but just as necessary. I'm starting to lose my voice. It's sapping me, and it's sapping my focus on home, on work, on scouting and on my own ability to focus and learn.
If I can focus on a problem and give it a name, I can actually do something about it. What's my problem? Like the days of old, I'm spending too much time on the "Live Show" and not enough time in the studio. I'm focusing on the things that are easy and enjoyable for me, things that have a big bang and bring a huge smile to my face, but aren't letting me stretch and grow in the ways that my team needs me to. My passion about testing is not in question; everybody knows I'm passionate about testing. How do I feel about technical development, about really embracing and understanding the underpinings of the operation, and being able to fit myself into what is needed? In short, talking a mean game about testing is one thing, growing into the core player that I need to be, especially when I need to focus on stuff that's not so "rock star", that's another thing entirely.
What can I do when I need to focus on the stuff that's not so "rock star" and is a lot more "roadie"? Here's what I'm doing. I'm making an effort to be more vocal about challenging goals, not just the ones that make me look good. I'm setting public goals around things that are actionable and show real progress over time. For me right now, this is spending time focusing on programming, which is a genuine slog for me. I'm doing what I can to broaden my tool-set, not just in the testing approach, but in understanding business development, the technical underpinnings of our products, and more than anything else, I'm making myself more project oriented and really getting a handle on the time it takes to do certain things, and how much of my attention is really needed to make them work.
Ultimately, we can't be rock stars everyday. We don't have the energy or the time, and to remain a rock star, we have to do the work necessary that will help us maintain that level. So I'm swallowing some of my own hypocrisy and stepping back, looking at the balance of "rock star" dreams, and the "roadie" tasks that are needed to help me get where I need to be. It's my hope that, if I can be more mindful of the time and energy it takes to do the stuff that really matters, I'll actually be able to sustain the energy needed to enjoy and savor those rock star moments.
This week, I came to a conclusion... I'm a hypocrite. I talk a mean game about being prepared, doing important work, and focusing on the things that really matter, yet I'm guilty of veering off course and not focusing on what really matters. Instead, I've been chasing the things that are fun and that I am passionate about. Here's the thing, it's pretty easy to do the stuff that's, well, easy, or the stuff that makes us feel like we've got it all covered. We take on more and more of those so called challenges while they are fun, and we get that heady sense of "rock star euphoria". When I was a musician, I often looked forward to performing. It was the whole point of slogging in the studio, practicing my scales and plinking out chords and melodies on a guitar or bass to write songs. Most of us did this because we looked forward to that hour on stage when we were on top of the world. That's what I mean by rock star euphoria. Problem is, we can't always be on stage. I can't sing my lungs out every night, it's just not possible. If I did, I would lose my voice regularly and I'd need to rest the voice. We can perform a lot, but ultimately, we'll stop giving really good performances if we do it too much.
I enjoy writing. I enjoy podcasting. I enjoy facilitating Weekend Testing. I enjoy being a teacher with AST. I enjoy getting ready to be a conference presenter (my newest goal and endeavor). These are great "performance" aspects, but they take time, and they take practice and slugging away well behind the scenes. The rock star euphoria I get when I push something new gives me a rush, but there's only so much voice in me (to extend the analogy). Even really enjoyable stuff, when we over commit, tends to leach and sap energy from the things we care about, and let's face it, it takes away from the things that are less enjoyable, but just as necessary. I'm starting to lose my voice. It's sapping me, and it's sapping my focus on home, on work, on scouting and on my own ability to focus and learn.
If I can focus on a problem and give it a name, I can actually do something about it. What's my problem? Like the days of old, I'm spending too much time on the "Live Show" and not enough time in the studio. I'm focusing on the things that are easy and enjoyable for me, things that have a big bang and bring a huge smile to my face, but aren't letting me stretch and grow in the ways that my team needs me to. My passion about testing is not in question; everybody knows I'm passionate about testing. How do I feel about technical development, about really embracing and understanding the underpinings of the operation, and being able to fit myself into what is needed? In short, talking a mean game about testing is one thing, growing into the core player that I need to be, especially when I need to focus on stuff that's not so "rock star", that's another thing entirely.
What can I do when I need to focus on the stuff that's not so "rock star" and is a lot more "roadie"? Here's what I'm doing. I'm making an effort to be more vocal about challenging goals, not just the ones that make me look good. I'm setting public goals around things that are actionable and show real progress over time. For me right now, this is spending time focusing on programming, which is a genuine slog for me. I'm doing what I can to broaden my tool-set, not just in the testing approach, but in understanding business development, the technical underpinnings of our products, and more than anything else, I'm making myself more project oriented and really getting a handle on the time it takes to do certain things, and how much of my attention is really needed to make them work.
Ultimately, we can't be rock stars everyday. We don't have the energy or the time, and to remain a rock star, we have to do the work necessary that will help us maintain that level. So I'm swallowing some of my own hypocrisy and stepping back, looking at the balance of "rock star" dreams, and the "roadie" tasks that are needed to help me get where I need to be. It's my hope that, if I can be more mindful of the time and energy it takes to do the stuff that really matters, I'll actually be able to sustain the energy needed to enjoy and savor those rock star moments.
Saturday, June 25, 2011
Secure Clouds? A Weekend Testing Follow-Up
With the stories in the news lately about security breaches with cloud services and server farms being raided by the FBI, it seemed like a good idea to have a discussion around testing for security in Cloud services and considering some of the implications and challenges with how to test them and what to test for. Our mission for today was as follows:
We all are the test team for a medium sized company (say 1,000 people). Due to the desire to spread to small regional offices, but keep key documents available we are looking at cloud options to store important documents. we want to make this as easy for our users as possible, so we are exploring numerous options in the marketplace today. There are some famous names like Dropbox, Sugar Sync, etc. that we can consider. The big concern with corporate, however, is security. How can we make sure that what we put online is safe?
Our mission is to explore testing options, and examine various services (pick additional versions if the two I’ve mentioned don’t float your boat), and report back on what we can do to test and confirm this approach (or not confirm it).
Some of the first thoughts that we came up with were to determine exactly what was meant by "safe" and if "safe meant "private" or if "safe" meant "secure". as maddening as testers can be, it's important to realize that these are markers driven by context and perception. There is no way to be 100% sure that a system is safe; likewise there's no such thing as a 100% safe system. The bigger challenges some into play in how to determine if a cloud based system is appropriate for sensitive documents that require a higher level of security.
In the first hour we brainstormed and drafted some ideas that were meant to help us guide our testing efforts and we captured all of that in typewith.me, a nice little tool for collaborative note taking. Each section that goes in is color coded for the participant, and chat transcripts can also be logged. At the end, a single document can be generated and presented, which is what we did.
If you'd like to check out the experience report or the typewith.me doc as well as to get a full list of attendees, please feel free to check out the experience report here.
Friday, June 24, 2011
PODCAST FRIDAY: Performance Test Conference, Web Security and Landing a Job
Hey everyone! It's Friday (late) and it's time to give a nod to the podcasts that may be of interest to testers some of them not necessarily testing related, but I hope worth your listening attention. So if you are out and about this weekend and want some quality conversation and learning, these may be right up your alley.
First, of course, I'm not going to lead off a podcast roundup without mentioning the one I produce ;). Episode #51 of "This Week in Software Testing" has Abbie Caracostas as our guest. Abbie is the director of training at Redwood Collaborative Media, which is the company that owns STP (and by extension, this podcast :) ). the primary topic of this podcast is the upcoming STP Performance Summit happening July 26-28, which will be delivered entirely online.
Second, Trish Khoo and Bruce McLeod return with the 3rd installment of TestCast, called "Do I Get the Job?" and as you might guess from the title, this is all about interviewing and discussing how to effectively interview for a testing position. A lot of the approach and terminology feels different to me, again, this show originates in Australia, so there's some local vernacular, but the ideas and thoughts are good to be considered by any tester regardless of locale (and don't wait until you are looking for a job to consider these things ;) ).
Over in 5by5 land, Dan Benjamin and Merlin Mann deliver a somewhat disjointed show this week, but even a disjointed "Back to Work" has lots of gold to mine, and "Assistant to the Regional Monkey" definitely delivers some quirky gold. there's a lot of tangents in this episode, and a fair amount of Buddhist philosophy, but some great advice about working your way through your trouble spots and realizing when you are being a hypocrite and dealing with it (blog post this weekend on that topic by your truly coming soon, by the way).
Dan Benjamin and John Gruber deliver a briefer version of The Talk Show this week. In "Hard Stop", John and Dan discuss various new mobile technologies (tablets and phones and how each market is striving to keep the mobile revolution going mainstream. the FBI raid of a data center and the woes of Dropbox also makes its way into the show, as does Stanley Kubrick and a note to projectionists (John Gruber and Stanley Kubrick, who'da thunk? ;) ).
Finally, for those who are not familiar with Scott Hanselmann and his podcast Hanselminutes, I'd recommend putting it on your watch list. a lot of his podcast topics are Microsoft centric, but before you tune out at that (all you hip Rails and old school LAMP folks out there ;) ), many of the ideas and topics do have crossover appeal, and this week, his discussion of "Web Security Basics with Barry Darrans" provides definite crossover appeal. what do we need to know today to be in the game when it comes to Web Security? What threats are out there and actively attacking sites, and what makes them different?
That's it for this week. Looking forward to a new batch of shows next week. Stay tuned and keep listening!
First, of course, I'm not going to lead off a podcast roundup without mentioning the one I produce ;). Episode #51 of "This Week in Software Testing" has Abbie Caracostas as our guest. Abbie is the director of training at Redwood Collaborative Media, which is the company that owns STP (and by extension, this podcast :) ). the primary topic of this podcast is the upcoming STP Performance Summit happening July 26-28, which will be delivered entirely online.
Second, Trish Khoo and Bruce McLeod return with the 3rd installment of TestCast, called "Do I Get the Job?" and as you might guess from the title, this is all about interviewing and discussing how to effectively interview for a testing position. A lot of the approach and terminology feels different to me, again, this show originates in Australia, so there's some local vernacular, but the ideas and thoughts are good to be considered by any tester regardless of locale (and don't wait until you are looking for a job to consider these things ;) ).
Over in 5by5 land, Dan Benjamin and Merlin Mann deliver a somewhat disjointed show this week, but even a disjointed "Back to Work" has lots of gold to mine, and "Assistant to the Regional Monkey" definitely delivers some quirky gold. there's a lot of tangents in this episode, and a fair amount of Buddhist philosophy, but some great advice about working your way through your trouble spots and realizing when you are being a hypocrite and dealing with it (blog post this weekend on that topic by your truly coming soon, by the way).
Dan Benjamin and John Gruber deliver a briefer version of The Talk Show this week. In "Hard Stop", John and Dan discuss various new mobile technologies (tablets and phones and how each market is striving to keep the mobile revolution going mainstream. the FBI raid of a data center and the woes of Dropbox also makes its way into the show, as does Stanley Kubrick and a note to projectionists (John Gruber and Stanley Kubrick, who'da thunk? ;) ).
Finally, for those who are not familiar with Scott Hanselmann and his podcast Hanselminutes, I'd recommend putting it on your watch list. a lot of his podcast topics are Microsoft centric, but before you tune out at that (all you hip Rails and old school LAMP folks out there ;) ), many of the ideas and topics do have crossover appeal, and this week, his discussion of "Web Security Basics with Barry Darrans" provides definite crossover appeal. what do we need to know today to be in the game when it comes to Web Security? What threats are out there and actively attacking sites, and what makes them different?
That's it for this week. Looking forward to a new batch of shows next week. Stay tuned and keep listening!
Thursday, June 23, 2011
What Can We Learn from "The World's Fastest Indian"?
I'm not sure exactly when or how my blog went from purely testing topics to my wanting to explore the things that motivate people, but somehow it has, and I'm not sure entirely how I feel about that. In any event, I wanted to go back in time and see if there was something I had written that would spark some new thoughts and new ideas on the topic. On my old personal blog (http://mklsmuse.blogspot.com/, mostly inactive now that I devote most of my blogging time to TESTHEAD), I went back and found a post I had written a few years back called "What Can We Learn from "The World's Fastest Indian
"? It's basically a movie review, but it's also one of my first explorations into the ideas of motivation. I may migrate a few more of my "retro posts" over here if I feel they are warranted and can be interesting to testers. I think this one fits the bill. Hope you'll indulge me :).
Originally posted at MKL's Muse on 11/07/2008.
I’m a sucker for inspirational stories that feature odd-ball characters that tend to beat the odds just out of sheer determination and force of will. A few years back a movie was made to celebrate such a person, and of course, because of its tie-in to my favorite motorcycle in the world, I had to watch this. Somehow I hadn’t heard about this being originally released, but when I was in the library, I saw the title, read the back cover, and decided that I had to see this!
In The World’s Fastest Indian, we see the story of Burt Munro, a man in his mid sixties at the time from Invercargill, New Zealand. The story is set in the mid 1960’s, and is based around Burt’s continuous tinkering and improving his 1920 Indian Scout motorcycle to get leaner and go faster. Watching how he works, how he lives, and how he keeps at his goal, no matter what happens, is definitely an inspiration.
What I loved about this story was the fact that Bert faced opposition from just about everyone, yet he kept at it. Through it all he received begrudging, and occasionally heartfelt, acceptance of his efforts. Watching him get from New Zealand across the ocean, and then from Long Beach to Bonneville Raceway was certainly an adventure, and a testament to a man’s ingenuity and resourcefulness. Here was an example of a man who made deals where he could, traded his services for help and accommodations, and stood strong to try to do what he felt he needed to do when everyone else thought he was nuts. Frankly, we need more stories like this, stories that prove that the can-do spirit is still alive and well in people (part of me would love to see what Burt Munro would be like today and with the nature of the motorcycle industry as it exists now; Burt died in 1978).
For more about Burt, check out his Wikipedia page HERE (caveat lector wiki, of course :) ), and about the movie The World’s Fastest Indian HERE (again, caveat lector wiki).
And now for my thoughts today for TESTHEAD... I still look at Burt Munro's story as inspirational. This was a man that lived with a single minded dream, to break the land speed record with an ancient and self developed motorcycle. Whenever I moan that I don't seem to be getting ahead, or I'm not learning what I need to, or somehow I'm not keeping up with what I should be, I remind myself of Burt and what he was willing to do to make a dream reality. Was Burt Munro a little nuts? Maybe, but his determination saw him through, in good times and bad, and frankly I still think there's a value in appreciating and admiring can-do spirit like Munro's. For those not familiar with Burt's story, and would like to see a very inspirational movie, I still recommend "The World's Fastest Indian". It's worth the time to watch, and I think I may need to watch this one again :).
"? It's basically a movie review, but it's also one of my first explorations into the ideas of motivation. I may migrate a few more of my "retro posts" over here if I feel they are warranted and can be interesting to testers. I think this one fits the bill. Hope you'll indulge me :).Originally posted at MKL's Muse on 11/07/2008.
I’m a sucker for inspirational stories that feature odd-ball characters that tend to beat the odds just out of sheer determination and force of will. A few years back a movie was made to celebrate such a person, and of course, because of its tie-in to my favorite motorcycle in the world, I had to watch this. Somehow I hadn’t heard about this being originally released, but when I was in the library, I saw the title, read the back cover, and decided that I had to see this!
In The World’s Fastest Indian
, we see the story of Burt Munro, a man in his mid sixties at the time from Invercargill, New Zealand. The story is set in the mid 1960’s, and is based around Burt’s continuous tinkering and improving his 1920 Indian Scout motorcycle to get leaner and go faster. Watching how he works, how he lives, and how he keeps at his goal, no matter what happens, is definitely an inspiration.What I loved about this story was the fact that Bert faced opposition from just about everyone, yet he kept at it. Through it all he received begrudging, and occasionally heartfelt, acceptance of his efforts. Watching him get from New Zealand across the ocean, and then from Long Beach to Bonneville Raceway was certainly an adventure, and a testament to a man’s ingenuity and resourcefulness. Here was an example of a man who made deals where he could, traded his services for help and accommodations, and stood strong to try to do what he felt he needed to do when everyone else thought he was nuts. Frankly, we need more stories like this, stories that prove that the can-do spirit is still alive and well in people (part of me would love to see what Burt Munro would be like today and with the nature of the motorcycle industry as it exists now; Burt died in 1978).
For more about Burt, check out his Wikipedia page HERE (caveat lector wiki, of course :) ), and about the movie The World’s Fastest Indian HERE (again, caveat lector wiki).
And now for my thoughts today for TESTHEAD... I still look at Burt Munro's story as inspirational. This was a man that lived with a single minded dream, to break the land speed record with an ancient and self developed motorcycle. Whenever I moan that I don't seem to be getting ahead, or I'm not learning what I need to, or somehow I'm not keeping up with what I should be, I remind myself of Burt and what he was willing to do to make a dream reality. Was Burt Munro a little nuts? Maybe, but his determination saw him through, in good times and bad, and frankly I still think there's a value in appreciating and admiring can-do spirit like Munro's. For those not familiar with Burt's story, and would like to see a very inspirational movie, I still recommend "The World's Fastest Indian". It's worth the time to watch, and I think I may need to watch this one again :).
Wednesday, June 22, 2011
Weekend Testing Americas #13 This Weekend: New Session and a Request
First, I'd like to announce that we will be holding a Weekend Testing session this coming Saturday (June 25, 2011) at 11:00 a.m. PDT (that's 2:00 p.m. EDT, 6:00 p.m GMT, and I'll let everyone else do the math beyond that :) ). The specific mission is still being formulated, but due to interesting news over the weekend from Dropbox and security challenges they have been facing, I thought it would be interesting to test around security with the proviso that we will not be doing anything deliberately destructive to the site (I believe in a form of the Hippocratic Oath when it comes to testing live sites; explore and discover, but handle carefully and with respect for the business and their services).
To help spread the word, I'd like to ask everyone to make a mention of this session in your venue of choice (Twitter, Facebook, LinkedIn, etc.) as well as direct email and other means. Joining a session is the same as always; please send a request to add "weekendtestersamericas" to your Skype ID list (we will add you). Also, to let us know if you will for sure be there, please send a message to "WTAmericas@gmail.com" and put WTA13 in the subject line, and a message saying you will be there, along with your Skype ID. This way we don't end up SPAMMING people who are not going to be there.
Finally, I am looking for testers willing to be facilitators for sessions. As of now, I'm the only continuous facilitator for Weekend Testing Americas. This means that the sessions are based around when I can be in town to hold and run the sessions. During the summer months, those are becoming harder and harder for me to commit to with the kids out of school and their activities adding to my time commitments. My goal with Weekend testing Americas was to have a loose group of facilitators who would be able to share the load and manage sessions with or without me. While I enjoy doing them, I don't want to see sessions only be once a month by default because that's all I can commit to. We can offer more sessions if more testers are willing to step up and facilitate.
If you would be interested in being a facilitator for Weekend Testing sessions, please send a note WTAmericas@gmail.com and let me know. I could then explain the process and the things that I do to run the sessions (note: it's not really hard to do, but it does require the willingness to lead a sometimes free willed bunch of people in discussions. Contrary to popular belief, you yourself do not have to be an expert tester to facilitate sessions (although having a good background in the areas proposed for given missions is certainly important).
I'm looking to expand the offerings for Weekend Testing Americas. Would you like to help make that a reality :)?
To help spread the word, I'd like to ask everyone to make a mention of this session in your venue of choice (Twitter, Facebook, LinkedIn, etc.) as well as direct email and other means. Joining a session is the same as always; please send a request to add "weekendtestersamericas" to your Skype ID list (we will add you). Also, to let us know if you will for sure be there, please send a message to "WTAmericas@gmail.com" and put WTA13 in the subject line, and a message saying you will be there, along with your Skype ID. This way we don't end up SPAMMING people who are not going to be there.
Finally, I am looking for testers willing to be facilitators for sessions. As of now, I'm the only continuous facilitator for Weekend Testing Americas. This means that the sessions are based around when I can be in town to hold and run the sessions. During the summer months, those are becoming harder and harder for me to commit to with the kids out of school and their activities adding to my time commitments. My goal with Weekend testing Americas was to have a loose group of facilitators who would be able to share the load and manage sessions with or without me. While I enjoy doing them, I don't want to see sessions only be once a month by default because that's all I can commit to. We can offer more sessions if more testers are willing to step up and facilitate.
If you would be interested in being a facilitator for Weekend Testing sessions, please send a note WTAmericas@gmail.com and let me know. I could then explain the process and the things that I do to run the sessions (note: it's not really hard to do, but it does require the willingness to lead a sometimes free willed bunch of people in discussions. Contrary to popular belief, you yourself do not have to be an expert tester to facilitate sessions (although having a good background in the areas proposed for given missions is certainly important).
I'm looking to expand the offerings for Weekend Testing Americas. Would you like to help make that a reality :)?
Tuesday, June 21, 2011
Writing a Talk at Disneyland
One of the more surreal aspects of this past weekend was the fact that, with the summer season, everyone who goes to Disneyland walks a lot, has some punctuated moments of fun, but in general, there’s a lot of waiting.
Lines can be long, and a wait of 30 minutes for an attraction is very normal. Disneyland helps to mitigate this somewhat with a system of “fast Passes”, where if you agree to wait for an hour or two, you can come back to an attraction and get through it very fast. Still, even with this, many rides and attractions don’t have them, so waiting is inevitable. So what’s a tester to do? The first was to introduce my kids to the game of “spot the mickey’s”. The second was to write a talk and have a first draft completed by Monday evening.
Wait, what?!
Yep, just before we were scheduled to leave on vacation, I discovered that the technical paper I presented, but didn’t get accepted because I submitted it incorrectly (I didn’t realize that I’d only submitted it for the Poster Paper program) was getting a second chance and consideration for the technical program as a “pinch hitter” so to speak. In other words, in the event that one of the presenters couldn’t follow through and present their paper, I would be a “back up”. I’m still presenting my ideas in the Poster Paper section, but having a technical paper means it gets published with the proceedings, gets peer reviewed and critiqued, and get an official submission also listing as a technical paper (which was what I wanted from the beginning). The catch? I’d have to have the paper finished by June 20th… yep, I’d have to write the paper while I was on vacation.
I’m sure if I explained the situation, I would have been able to get an extension, but part of me was intrigued by the challenge. Could I write a full technical paper while on vacation? Would I have enough time? How could I get it together? Would I make the deadline?
Let’s answer those in order ;).
Could I write a technical paper while on vacation? It turns out the answer is yes, but it required a bit of creativity on my part. I couldn’t walk through Disneyland and California Adventure with a laptop, but I could carry an iPhone or an Android. While this left me with a very small keyboard to work with, I found that after a couple of sessions I was able to actually make pretty good notes with it. The built in notes app for the iPhone actually did this pretty well and helped make hanging out in line less of a drag.
Would I have enough time? For the most part the answer is yes. I was able to hit most of the areas I intended and fully fleshed out those areas while I was waiting in line. There are a few areas towards the conclusion that I still had questions about and how to expand on them, but I had enough of an outline to get the main ideas down.
How could I get it together? Since the iPhone I’m using isn’t actually configured with a working phone (it’s a test device) ,I waited until I was at a wireless hot spot I could use, then sent emails to myself with the notes I had taken. Later, I incorporate those notes into a paper using the accepted formatting.
Would I make the deadline? OK, here I have to answer “yes” and “no”. Yes in that I feel I hit the major points needed for a first draft, no in that there were still some areas I had questions about and needed some more time to gather the materials necessary (as well as references).
So would I recommend that others write their next talk on an iPhone? If you have the ability to use a full-featured computer, I’d say “don’t bother” as it was rather tedious and took a lot of time. However, if you find that you are in a situation with literally time to kill (and when you are waiting in line at an amusement part, that’s the definition of “time to kill”) you can get a surprising amount done with a smart phone. The cool thing was that I was able to write 95% of a talk and still be there to hang out with and enjoy time with my wife and kids in a way that I hope they didn’t find too ridiculous (I’ll leave it to them to comment if they thought Dad was too distracted or not. I thought it worked out well :) ).
Lines can be long, and a wait of 30 minutes for an attraction is very normal. Disneyland helps to mitigate this somewhat with a system of “fast Passes”, where if you agree to wait for an hour or two, you can come back to an attraction and get through it very fast. Still, even with this, many rides and attractions don’t have them, so waiting is inevitable. So what’s a tester to do? The first was to introduce my kids to the game of “spot the mickey’s”. The second was to write a talk and have a first draft completed by Monday evening.
Wait, what?!
Yep, just before we were scheduled to leave on vacation, I discovered that the technical paper I presented, but didn’t get accepted because I submitted it incorrectly (I didn’t realize that I’d only submitted it for the Poster Paper program) was getting a second chance and consideration for the technical program as a “pinch hitter” so to speak. In other words, in the event that one of the presenters couldn’t follow through and present their paper, I would be a “back up”. I’m still presenting my ideas in the Poster Paper section, but having a technical paper means it gets published with the proceedings, gets peer reviewed and critiqued, and get an official submission also listing as a technical paper (which was what I wanted from the beginning). The catch? I’d have to have the paper finished by June 20th… yep, I’d have to write the paper while I was on vacation.
I’m sure if I explained the situation, I would have been able to get an extension, but part of me was intrigued by the challenge. Could I write a full technical paper while on vacation? Would I have enough time? How could I get it together? Would I make the deadline?
Let’s answer those in order ;).
Could I write a technical paper while on vacation? It turns out the answer is yes, but it required a bit of creativity on my part. I couldn’t walk through Disneyland and California Adventure with a laptop, but I could carry an iPhone or an Android. While this left me with a very small keyboard to work with, I found that after a couple of sessions I was able to actually make pretty good notes with it. The built in notes app for the iPhone actually did this pretty well and helped make hanging out in line less of a drag.
Would I have enough time? For the most part the answer is yes. I was able to hit most of the areas I intended and fully fleshed out those areas while I was waiting in line. There are a few areas towards the conclusion that I still had questions about and how to expand on them, but I had enough of an outline to get the main ideas down.
How could I get it together? Since the iPhone I’m using isn’t actually configured with a working phone (it’s a test device) ,I waited until I was at a wireless hot spot I could use, then sent emails to myself with the notes I had taken. Later, I incorporate those notes into a paper using the accepted formatting.
Would I make the deadline? OK, here I have to answer “yes” and “no”. Yes in that I feel I hit the major points needed for a first draft, no in that there were still some areas I had questions about and needed some more time to gather the materials necessary (as well as references).
So would I recommend that others write their next talk on an iPhone? If you have the ability to use a full-featured computer, I’d say “don’t bother” as it was rather tedious and took a lot of time. However, if you find that you are in a situation with literally time to kill (and when you are waiting in line at an amusement part, that’s the definition of “time to kill”) you can get a surprising amount done with a smart phone. The cool thing was that I was able to write 95% of a talk and still be there to hang out with and enjoy time with my wife and kids in a way that I hope they didn’t find too ridiculous (I’ll leave it to them to comment if they thought Dad was too distracted or not. I thought it worked out well :) ).
Sunday, June 19, 2011
Talking About Weekend Testing at PNSQC 2011
As we are just around the corner from July and registration, it seems only appropriate that I start talking about it now, right :)?
The Pacific Northwest Software Quality Conference will be held in Portland, Oregon October 10-12, 2011. The theme for this year's conference is "Delivering Quality" and I have submitted a proposal for the technical program around Weekend Testing. I had planned on presenting both a technical paper and a poster paper on the topic, but through my not realizing it, my submission was only processed for the Poster Paper part of the program (and it was accepted :) ). The difference between presenting a technical paper and a poster paper is that a poster paper is less formal. A technical paper is a track session and has a room with attendees for the dedicated topic. A poster paper is presented in a social setting and a number of presenters gather together to discuss their topics and those who want to hear about it. Smaller groups, but the chance to present the material multiple times.
I had gotten used to the idea that I was just going to present for the Poster Paper presentation section when I received word that my paper was being considered for a technical presentation as well (they saw that my intention was to submit for both programs). The good news, I get a shot at a technical paper after all. The challenge? The first draft is due on June 20th, i.e. tomorrow!
In any event, I'm excited for the opportunity to present what I have learned by facilitating Weekend Testing sessions, and how other organizations an use the ideas and spread the Weekend Testing approach to their organizations. I'm hoping you'll consider joining us, too.
The Pacific Northwest Software Quality Conference will be held in Portland, Oregon October 10-12, 2011. The theme for this year's conference is "Delivering Quality" and I have submitted a proposal for the technical program around Weekend Testing. I had planned on presenting both a technical paper and a poster paper on the topic, but through my not realizing it, my submission was only processed for the Poster Paper part of the program (and it was accepted :) ). The difference between presenting a technical paper and a poster paper is that a poster paper is less formal. A technical paper is a track session and has a room with attendees for the dedicated topic. A poster paper is presented in a social setting and a number of presenters gather together to discuss their topics and those who want to hear about it. Smaller groups, but the chance to present the material multiple times.
I had gotten used to the idea that I was just going to present for the Poster Paper presentation section when I received word that my paper was being considered for a technical presentation as well (they saw that my intention was to submit for both programs). The good news, I get a shot at a technical paper after all. The challenge? The first draft is due on June 20th, i.e. tomorrow!
In any event, I'm excited for the opportunity to present what I have learned by facilitating Weekend Testing sessions, and how other organizations an use the ideas and spread the Weekend Testing approach to their organizations. I'm hoping you'll consider joining us, too.
Saturday, June 18, 2011
First Hand Experience of an Airline Shutdown
When we got to the airport, I noticed that there was a huge line of people at the ticket counters, and that all of the ticket counters screens were showing the United logo... just the United logo. Nothing else. Ominous. Oh well, no worries for us, we already had our boarding passes, so we just skipped through security and went to our gate... and then we saw the true situation. The United computer system was down. Worldwide!
From here, I resorted to my numerous coping mechanisms. Gather the kids together, pull out the games and the books, pull out my laptop and start editing audio (believe me, when I'm faced with a wait, I always know I can fall back on that). After about four hours of no updates, though, I realized the truth... we weren't going to Santa Ana tonight. No one was flying anywhere on United. What's more, very few people were even able to make alternative plans or book on other airlines. The capacity for flights is maximized; there's little slack in the system. What's more, our electronic methods of surveillance and security do not know how to cope with this. The few flights that left during the evening were those where planes had already landed before the "glitch" and even they had some loud verbal discussion among flight crews as they "paper charted" their courses. Wow, was that an interesting conversation. The flight attendants were genuinely freaked out about a "paper" calculation of a night time flight over the Rocky Mountains. Honestly, I can't say I entirely blame them, but it punctuated the idea that our way of life is indeed in a way held hostage by our reliance on computer systems.
My youngest daughter kept asking me "Dad, can't you help them fix this?!" My daughter of course knows I'm a tester, but I think she has a little too overarching vision of just how powerful her Daddy is (LOL!). I had to explain to her that the problem wasn't here, it was in Chicago. What's more the problem wasn't just affecting us, it was effecting every airport United services, and the ripple effects of this might take a long time to sort out. She kept asking me questions about what could have happened and what could be done to fix it. It felt frustrating to say "I'm sorry, honey, but I really don't know what's going on." For me, that was the biggest aggravation. I can deal with computer shutdowns. I can deal with delayed flights. Heck, I was even prepared to spend the night in the airport armed with my two laptops and a USB stick loaded with books. All of that I can handle. The most aggravating aspect, though was the state of limbo. No one knew what was happening, and other than an intercom message that said "United is experiencing technical difficulties with their computer system. We are working to resolve the issue. We apologize for the inconvenience!", there would be no information.
As a tester, it's the information that I provide that adds value and allows us to make decisions. My problem was I was stuck in a fog. I couldn't make a decision. What was going to happen? Was my flight cancelled? Would it resume later? Do we need to pull the plug and go home (an option we had because we were still on the home leg of the trip. I can only imagine how fun this must have been for people trying to get back home)? It's not the problem, it's the lack of information following the problem that's the real kicker.
I often tell my kids that having a flexible attitude can help in a lot of negative situations. Being rigid in approach and thinking can cause a lot of stress and frustration. It's common to see people lose it when they are delayed. They don't really have a coping mechanism. They just fume, and I saw some people doing that. I liked Steven Covey's idea from "7 Habits" where he said to "always have a Plan B", or "carry the weather with you". The idea here is that I had no control over the flight to Santa Ana. It simply wasn't going to happen. We found that out at 1:00 AM and then proceeded to go home. We have another chance to try again tonight, and with that, we will see if we can work our game plan again. [Update: we managed to all get on the same flight and are now safely in Anaheim at our hotel, across the street from Disneyland. The airport was able to get back to normal within 18 hours of the system getting back online].
We lost half a day, but in that half a day, my older daughter made three new sketches in her art book, my wife made significant progress in a book she was enjoying, my son explored about every inch of SFO, and I completed a full pass of next week's TWiST for first round edits (the beauty of a captive 7 hour wait ;) ). In short, flexibility is needed, and for testers to make the best of the situations they face, they need to know when to zig, when to zag, and when to chuck everything and focus on something else. In truth, I will have to restructure some of my plans. I will now be taking a day off from work that I hadn't planned for, but I'm working today to help cover for that. I lost a day and delayed a vacation for a day. On the flip side, I can only imagine how many millions of dollars United lost through this ordeal, and how much lingering bad will might be sitting inside of various passengers minds. Will they book United again in the near future? Who knows?! Still, it's interesting to see the reactions of people and how they cope with these situations, and realizing that, even when things really don't go your way, it need not be the end of the world. A little flexibility can go a long way.
Friday, June 17, 2011
PODCAST FRIDAY: TWiST Turns 50!!!
For the past year, I have posted a weekly update about the TWiST podcast and my take on producing that show. Now that we've been actively producing the show for a full year, I've decided to retire that format in favor of just promoting the show directly as well as featuring other podcast to appear this week that I have found helpful or useful to testers.
First off, I would like to celebrate a milestone... TWiST turns 50 this week. Our 50th episode went live on Thursday and features the second part of our interview with Adam Yuret. In this weeks interview, we get to hear Adam discuss the idea that context-driven testing and Agile need not be exclusive of one another, and laments the fact that process and procedure and codifying of methods goes against the goals of both approaches. While we sometimes do “Plus” episodes as small segments, there was enough meat here to warrant it s own standalone show, hence the two part interview. Anyway, you can go here and check out TWiST's 50th episode for yourself.
As I reported earlier this week, I'm excited to see that Trish Khoo and Bruce McLeod have started up a podcast from Australia called TestCast. Their most recent episode is related to the evolution of software test automation along with Behavior Driven Development and Testing. It’s definitely worth a listen.
The ASP.NET team up at Microsoft does the Coding QA podcast, with a focus on automation and specifically .NET setups, but they cover a number of topics that would be worthwhile to any tester. This week in episode #57, Mark and Jim talk with Anton Piskunov to discuss automation and how to create effective and high quality test setups.
It's been awhile sing Pragmatic Publishing has pushed an episode, but The Pragmatic Podcast is back this week. Avdi Grimm is the guest and the subject is the new book "Exceptional Ruby" and handling exceptions and failures. This will likely be seen as interesting to anyone who programs in Ruby, as well as those of us who do testing or maintain sites that are based around Ruby and Rails.
As I've mentioned a few times, one of my current favorite podcasting hubs is Dan Benjamin's 5by5 network. The show that I give most of my "suck up" time to is "Back to Work", but there are a bunch of podcasts Dan produces or syndicates that cover a lot of interesting areas. My picks for this week are:
Back to Work #20: Muscle of Failure. I dedicated a blog post to this one on Wednesday, so take a look there for more of a review/discussion of these ideas.
Build and Analyze #29: The Way Siracusa Buys a Toaster. Dan has a lot of shows, and a great rapport with his guest hosts, so it's not uncommon for comments related to one show to appear in another (John Siracusa is Dan's guest host for "Hypercritical"). Outside of poking fun at John Siracusa, this show spends some time talking about the Twitter API, and what iCloud will be bringing to the web services arena.
The Talk Show #47: Nice Shirt, Handsome. If you are an Apple fan boy and want to know more about what's happening in the Apple universe, then Dan Benjamin and John Gruber should be on your regular rotation. This episode covers a lot of time talking about WWDC and the reason why Apple has managed to become the juggernaut who has emerged triumphant after a decade of staring down oblivion (few younger people realize that Apple was at one point in time seen as just a few quarters away from going down for the count around 2001). Also, the second half of the show is the continuing long form review of every James Bond film ever made, and this week they cover “The Living Daylights” (note, you certainly don’t have to listen all the way through this, but James Bond fans will probably greatly enjoy it :) ).
Finally, for those who would like to keep track of all testing podcasts, or at least those that we know about, please go and put testingpodcast.com in your podcast aggregator (or just add it to your bookmarks if you want to roll old school). Zjelko Filipin maintains the site, and I go in from time to time to do updates as well. If you would like to recommend podcasts for us to track, or podcasts you would like to see me add to my weekly roundup, by all means drop me a line. I'm always on the lookout to see and hear more from our fellow testers and want to encourage even more podcasting among our testing brothers and sisters. As Seal one boldly said... "Bring It On!"
First off, I would like to celebrate a milestone... TWiST turns 50 this week. Our 50th episode went live on Thursday and features the second part of our interview with Adam Yuret. In this weeks interview, we get to hear Adam discuss the idea that context-driven testing and Agile need not be exclusive of one another, and laments the fact that process and procedure and codifying of methods goes against the goals of both approaches. While we sometimes do “Plus” episodes as small segments, there was enough meat here to warrant it s own standalone show, hence the two part interview. Anyway, you can go here and check out TWiST's 50th episode for yourself.
As I reported earlier this week, I'm excited to see that Trish Khoo and Bruce McLeod have started up a podcast from Australia called TestCast. Their most recent episode is related to the evolution of software test automation along with Behavior Driven Development and Testing. It’s definitely worth a listen.
The ASP.NET team up at Microsoft does the Coding QA podcast, with a focus on automation and specifically .NET setups, but they cover a number of topics that would be worthwhile to any tester. This week in episode #57, Mark and Jim talk with Anton Piskunov to discuss automation and how to create effective and high quality test setups.
It's been awhile sing Pragmatic Publishing has pushed an episode, but The Pragmatic Podcast is back this week. Avdi Grimm is the guest and the subject is the new book "Exceptional Ruby" and handling exceptions and failures. This will likely be seen as interesting to anyone who programs in Ruby, as well as those of us who do testing or maintain sites that are based around Ruby and Rails.
As I've mentioned a few times, one of my current favorite podcasting hubs is Dan Benjamin's 5by5 network. The show that I give most of my "suck up" time to is "Back to Work", but there are a bunch of podcasts Dan produces or syndicates that cover a lot of interesting areas. My picks for this week are:
Back to Work #20: Muscle of Failure. I dedicated a blog post to this one on Wednesday, so take a look there for more of a review/discussion of these ideas.
Build and Analyze #29: The Way Siracusa Buys a Toaster. Dan has a lot of shows, and a great rapport with his guest hosts, so it's not uncommon for comments related to one show to appear in another (John Siracusa is Dan's guest host for "Hypercritical"). Outside of poking fun at John Siracusa, this show spends some time talking about the Twitter API, and what iCloud will be bringing to the web services arena.
The Talk Show #47: Nice Shirt, Handsome. If you are an Apple fan boy and want to know more about what's happening in the Apple universe, then Dan Benjamin and John Gruber should be on your regular rotation. This episode covers a lot of time talking about WWDC and the reason why Apple has managed to become the juggernaut who has emerged triumphant after a decade of staring down oblivion (few younger people realize that Apple was at one point in time seen as just a few quarters away from going down for the count around 2001). Also, the second half of the show is the continuing long form review of every James Bond film ever made, and this week they cover “The Living Daylights” (note, you certainly don’t have to listen all the way through this, but James Bond fans will probably greatly enjoy it :) ).
Finally, for those who would like to keep track of all testing podcasts, or at least those that we know about, please go and put testingpodcast.com in your podcast aggregator (or just add it to your bookmarks if you want to roll old school). Zjelko Filipin maintains the site, and I go in from time to time to do updates as well. If you would like to recommend podcasts for us to track, or podcasts you would like to see me add to my weekly roundup, by all means drop me a line. I'm always on the lookout to see and hear more from our fellow testers and want to encourage even more podcasting among our testing brothers and sisters. As Seal one boldly said... "Bring It On!"
Thursday, June 16, 2011
The Value of "Showing Up"
As many of you might have seen me post a time or two, I have contributed a chapter towards a book dedicated to "REDUCING THE COST OF SOFTWARE TESTING
". This has been an interesting journey, and as many of you know, I was a late addition to the project. In fact, I owe my being in the book due to being a reviewer early on, and because of an author having to drop out of the project, I had a momentary lapse of reason and suggested that, maybe, I could take a swing at a chapter.
With that, I submitted my chapter idea, went through a number of rounds of critique and review, and ultimately I got the green light for my chapter to appear alongside many people I respect and admire in this crazy little industry known as software testing.
A somewhat famous quote, and one that was echoed to me early in the process of writing this book, was that "80% of life is just showing up". The quote is attributed to Woody Allen. After experiencing a number of things over the years, I believe this quote to be accurate. Many opportunities in life will come our way simply because we are there when the opportunity arises. We have a chance to do something, and we say "Well, OK, why not? Someone is going to do this... why shouldn't I take a crack at this?!"
Of course, it's not really enough to just "show up". We have to make the opportunity amount to something if we want a chance to be called into service again. Still, in so many situations, we don't even get to the point where showing up is an option. In short, we tell ourselves "Oh, I'm not good enough, or I'm not smart enough, or I don't have enough experience". Another quote that works well with this, I think, is Wayne Gretzky's famous "You miss 100% of the shots you don't take."
The key from there is that, once we've shown up, we need to be prepared to give of ourselves and run with the opportunity that's been presented to us. The cute part of the quote is, honestly, the word "just"... which may make some people frustrated or think he's pandering or otherwise minimizing the effort. He's not. He's emphasizing that taking that first step, sticking your neck out, and then following through, is prerequisite to showing up. It all comes together for a successful venture that goes beyond just dumb luck. Don't get me wrong, lots of time dumb luck just happens, but it's rare.
Anyway, this is all a long winded way for me to say "our book is almost here!" and "I'd really love it if you all would reserve a copy and tell your friends about it". Who knows, with some good press, some forward thinking testers making the purchase and spreading the word, and organizations heeding the advice we give, we may well see more opportunities like this book appear in the future... and then maybe another tester out there will get the opportunity to "show up" and do something really cool. How awesome would that be :)?
". This has been an interesting journey, and as many of you know, I was a late addition to the project. In fact, I owe my being in the book due to being a reviewer early on, and because of an author having to drop out of the project, I had a momentary lapse of reason and suggested that, maybe, I could take a swing at a chapter.With that, I submitted my chapter idea, went through a number of rounds of critique and review, and ultimately I got the green light for my chapter to appear alongside many people I respect and admire in this crazy little industry known as software testing.
A somewhat famous quote, and one that was echoed to me early in the process of writing this book, was that "80% of life is just showing up". The quote is attributed to Woody Allen. After experiencing a number of things over the years, I believe this quote to be accurate. Many opportunities in life will come our way simply because we are there when the opportunity arises. We have a chance to do something, and we say "Well, OK, why not? Someone is going to do this... why shouldn't I take a crack at this?!"
Of course, it's not really enough to just "show up". We have to make the opportunity amount to something if we want a chance to be called into service again. Still, in so many situations, we don't even get to the point where showing up is an option. In short, we tell ourselves "Oh, I'm not good enough, or I'm not smart enough, or I don't have enough experience". Another quote that works well with this, I think, is Wayne Gretzky's famous "You miss 100% of the shots you don't take."
The key from there is that, once we've shown up, we need to be prepared to give of ourselves and run with the opportunity that's been presented to us. The cute part of the quote is, honestly, the word "just"... which may make some people frustrated or think he's pandering or otherwise minimizing the effort. He's not. He's emphasizing that taking that first step, sticking your neck out, and then following through, is prerequisite to showing up. It all comes together for a successful venture that goes beyond just dumb luck. Don't get me wrong, lots of time dumb luck just happens, but it's rare.
Anyway, this is all a long winded way for me to say "our book is almost here!" and "I'd really love it if you all would reserve a copy and tell your friends about it". Who knows, with some good press, some forward thinking testers making the purchase and spreading the word, and organizations heeding the advice we give, we may well see more opportunities like this book appear in the future... and then maybe another tester out there will get the opportunity to "show up" and do something really cool. How awesome would that be :)?
Wednesday, June 15, 2011
Bringing Symmetry to "The Muscle of Failure"
First, if you have not heard the show yet, go listen to the show. It's great fun and very informative, although the show's banter does tend to reward those who are regular listeners (newcomers will have no idea that the "no, you're thinking of..." is a regular bit in the show, and is deliberately nonsensical). Anyway, this week's main point was the idea of "Getting Started" and overcoming the obstacles of getting started doing something. A metaphor was used in the podcast, and I think it's very apt... the Muscle of Failure.
Put simply, the muscle of failure is the idea that fear, resistance, and lack of confidence, over time, gets as much of a workout as anything positive that we do. If we work a muscle regularly, it will build. If we work a muscle over the amount we work others, we get a lopsided development (think of those guys in the gym with huge arms and pecs but skinny chicken legs). Similarly, we work on muscles that have a disproportionate effect on us frequently as well, many times not realizing that we are doing it at all. Procrastination is an acquired skill. Yes, I just said that, and I'll say it again... procrastination is an acquired skill. We learn to procrastinate, and we practice procrastination. Why? Because we like the results. I know that's really weird and somewhat counter-intuitive, but it's true. We delay the start of hard things because they scare us, they are difficult, they are uncomfortable, they are unpleasant... even if the end result could be fantastic. Thus, we tend to work the muscle of failure because we like the result, and it gets worked and grows stronger each time we work it.
Years ago I remember reading Merlin talking about why he's so intent on focusing on ways to improve and increase the ability to do creative work, and when asked if he did all this because he was particularly good at it, he said no, he did all this because he was profoundly bad at it. I likewise have seen that I agree with this sentiment (for myself, I really can't speak for Merlin ;) ). It's easy to get on a roll and rock something when there is next to no effort. It's a lot harder to get in the groove when you don't know what you are doing, when you frequently fail, and you seem to take a long time to get out of the fail state.
In software development, I'm working through a book that talks about Behavior Driven Development
with the philosophy to fail first, then pass, then refactor. This advice goes beyond just software development and software testing, but can be applied to any goal. The trick is to get yourself used to failing first, and to make that an initial goal. Get in, allow yourself to fail, find out why it's failing, then make it work, and then review and refine what you've worked on. Then go on to the next piece. Don't unclutter an entire office. Instead, start with a folder, or an envelope, something small enough to find out the problems, then solve those immediate problems, then refactor your system to take on the next folder or envelope. Do this enough times, et voila... uncluttered office. It may seem to take longer, but you actually get more done because you've sliced down the complexity to a manageable level, and when all of the time is applied cumulatively, you may have spent a lot less time accomplishing the goal. What's more, you were able to do it without the muscle of failure getting all the attention.It's my belief that to succeed, we have to become intimate with failing, and we have to change our relationship with failure. Because we fear it, we give it too much undue attention. By actively embracing it, and making it an initial part of our reality, with the idea that the very next effort will be to fix the failure, we can work other muscles, and in the process develop symmetry. Fail first, fail often, but fail with a mind to fix the failure, and quickly.
Tuesday, June 14, 2011
Gonna See my Smiling Face on the Cover of ST&QA
As I stated in this blog a while back, I've been hoping to branch out and write in more places. I like this blog and I enjoy the freedom it gives me to do and write whatever i want to (and whenever I want to) and the freedom to experiment with ideas that may not work anyplace else... and let face it, a lot of the time they don't work here, either (LOL!). Still, the best way to grow is to take on different and unusual challenges, especially those that do not always fit with our exact comfort level.
This article covers a lot of the things that readers of this blog have come to expect from me, and in a way helped to solidify my philosophy into a few pages. That's the beauty of having a time bound and edited volume... you have to make your point and make it pretty quickly! I also didn't want to completely rehash a bunch of past blog posts, but in this case, well, it's inevitable; I talk about my own experiences, and this articles is, again, my own experiences, but hopefully in a way that you will enjoy reading.
So with that, I would like to encourage you to go and check out my article at Software Test Professional titled "The Challenges of the Lone Tester: Learn to Thrive". If you like it, leave some comments and rate it up on the site. If you don't, well, leave some comments, too :).
Monday, June 13, 2011
From Yeomen To Archers: Weekend Testing Plus?
A couple of months ago, Albert Gareev and I were discussing an idea relative to the way that Weekend Testing is constructed. In part, we have focused most of our efforts on one-off sessions, where the product does not repeat, and the testing goal doesn't repeat. It's self contained, people can come in when they want to, participate when they want to, and then go about their business. For most of the sessions, this is a perfectly logical model and it works well in most situations.
There comes a time, though, when the testing challenges or testing ideas need more time, or need multiple sessions to get a real handle on and have real discussions and practice with. Testing a website for an hour is one thing. Working on and practicing with a testing framework, or going through an extended level of testing RESTful services in a rich data web site, is a very different undertaking. The question we had was, how could we focus on testing that would fulfill both goals. Did it make sense to develop a second set of longer engagement Weekend Testing sessions?
Albert gave me a comparison to consider using Ancient Greece as an example (he knows I'm a total geek for history, so this metaphor worked for me :) ). The greatest body of Greek Hoplite troops, or for that matter English or French troops in the middle ages, were yeoman farmers. Another group that was developed were the Archers. Unlike the group of yeomen, the archers were expected to drill together and perfect their craft, often for years. It was with this comparison that Albert and I considered... what if we likewise were to develop some more open ended, more advanced test training ideas? Perhaps longer projects, related to one application with a greater level of engagement, possibly with the idea of making a squad of testers who worked on computer aided or automated testing, or in addition to finding bugs, worked and focused on fixing bugs where appropriate?
The first biggest challenge, of course, is that this would need to be a group of people that would meet regularly, and for longer than the two hour block normally set up for Weekend Testing. It might require an invite list, or some other self-selecting mechanism where team members would "sign on" for a project and commit to a particular period of time (Weeks? Months?). The idea would be that there would be a deeper and more involved commitment for a group, and that that group would actively mentor each other even more actively than we do in the current Weekend Testing structure.
So here's the question (and I welcome any feedback, positive or negative, on this idea)... Is there interest in pursuing such an approach, and if so, what would you as a tester like to see such a group cover?
There comes a time, though, when the testing challenges or testing ideas need more time, or need multiple sessions to get a real handle on and have real discussions and practice with. Testing a website for an hour is one thing. Working on and practicing with a testing framework, or going through an extended level of testing RESTful services in a rich data web site, is a very different undertaking. The question we had was, how could we focus on testing that would fulfill both goals. Did it make sense to develop a second set of longer engagement Weekend Testing sessions?
Albert gave me a comparison to consider using Ancient Greece as an example (he knows I'm a total geek for history, so this metaphor worked for me :) ). The greatest body of Greek Hoplite troops, or for that matter English or French troops in the middle ages, were yeoman farmers. Another group that was developed were the Archers. Unlike the group of yeomen, the archers were expected to drill together and perfect their craft, often for years. It was with this comparison that Albert and I considered... what if we likewise were to develop some more open ended, more advanced test training ideas? Perhaps longer projects, related to one application with a greater level of engagement, possibly with the idea of making a squad of testers who worked on computer aided or automated testing, or in addition to finding bugs, worked and focused on fixing bugs where appropriate?
The first biggest challenge, of course, is that this would need to be a group of people that would meet regularly, and for longer than the two hour block normally set up for Weekend Testing. It might require an invite list, or some other self-selecting mechanism where team members would "sign on" for a project and commit to a particular period of time (Weeks? Months?). The idea would be that there would be a deeper and more involved commitment for a group, and that that group would actively mentor each other even more actively than we do in the current Weekend Testing structure.
So here's the question (and I welcome any feedback, positive or negative, on this idea)... Is there interest in pursuing such an approach, and if so, what would you as a tester like to see such a group cover?
Sunday, June 12, 2011
TestCast: A Fresh & Funky New Podcast!
TestCast is a newcomer to the testing podcast scene, and features Bruce McLeod (@teknologika) and Trish Khoo (@hogfish), both of whom are veterans of the Australian test scene and beyond. Oh, did I mention that this is an Australian duo? Well, I just did, so there :).
As of this writing, they have two shows under their belt, and expect more to come. Their podcast is reminiscent of the banter often heard on shows like Dan Benjamin's 5by5 network, so I already like the format right there. They are "off the cuff" a lot of the time, and engage in both serious and silly banter which, again, makes for a really fun experience with what can oftentimes be a rather wonky topic.
Going forward, I'm planning to do recaps of weekly podcasts that I find appealing, interesting and relevant to testers. I'll probably include these with my PODCAST FRIDAY posts when I post up pointers to the new TWiST episodes, etc., so look for some more podcasting posts at a TESTHEAD near you :).
In the mean time, for those looking to get a taste go to TestCast and have a listen to their first two offerings. The first episode is centered around Community (and other varied topics) and the second is focused on developments in the automation sphere. If you, like me, enjoy getting your nerd on, this is a fun listen. Even if you are not specifically nerdy, there's still a lot to like in the duo of Bruce and Trish.
Fish Tanks and Unintended Consequences
Sometimes, nature has a way of showing you the unique, the weird and the downright unpleasant in ways you might never have expected. add to that a captive environment, and you might witness the truly unusual.
For those who have followed this blog the past couple of months, I've made mention of the fish that recently spawned in my largest tank. I have a colony of convict cichlids (Archocentrus Nigrofasciatum) and they had a large and very successful spawn. So successful, in fact that the other Convicts in the tank started eating them. To give the babies a better chance to survive, I decided to cull some of the larger males. This made for a large part of the tank open for the babies to swim free and unhunted.
Fast forward by about six weeks. I came upstairs to check on the babies, and I noticed that the "father" of the group had what looked like lesions on his back along and near his dorsal fin. at first I though that he might have contracted some kind of parasite or disease, but I decided it was important to observe first and see if I could get any clues. It took less than five minutes to learn what resulted in a nasty truth... the babies were cannibalizing him! Seriously, the babies were going up to the father (and later I would see that the mother was suffering a similar fate), pecking at the soft rays of the dorsal fin and the surrounding skin and flesh,, and eating them alive!
Part of me said that I wasn't going to interfere, and that I'd let the chips fall where they may, but this was too much to witness. As a result, I made the decision to remove the bitten and exposed Convicts into different quarters. The father I relocated to a 6 gallon hospital tank along with another adult male to keep him company. The mother I relocated to my son's 20 gallon tank with a bevy of other female Convicts (he jokingly calls this tank "the harem"). As a result the babies are now free to roam the tank without the parents corraling them. They are also free to be approached and dealt with by the fish that are in the tank, from those ten times their size to those who are fellow convicts but not their parents and will definitely chase them all over the tank if they try to nip at their fins or skin.
This is a lot like our software projects when we tinker and play favorites. When we play favorites and cherry pick our projects and where out time and attention will go, there will be "features" that will likewise grow and cannibalize the product. We as testers have a moral obligation to be on the lookout and look to see if development decisions may have unintended consequences. They may not be as severe or unusual as baby fish cannibalizing their 5 - 10 times their size parents, but there will be interesting problems nevertheless. To this end, it's important that we grow to understand what features have been added and how they interact with the whole system. Chances are, if we do so, we may well avoid the cannibal fish issues.
For those who have followed this blog the past couple of months, I've made mention of the fish that recently spawned in my largest tank. I have a colony of convict cichlids (Archocentrus Nigrofasciatum) and they had a large and very successful spawn. So successful, in fact that the other Convicts in the tank started eating them. To give the babies a better chance to survive, I decided to cull some of the larger males. This made for a large part of the tank open for the babies to swim free and unhunted.
Fast forward by about six weeks. I came upstairs to check on the babies, and I noticed that the "father" of the group had what looked like lesions on his back along and near his dorsal fin. at first I though that he might have contracted some kind of parasite or disease, but I decided it was important to observe first and see if I could get any clues. It took less than five minutes to learn what resulted in a nasty truth... the babies were cannibalizing him! Seriously, the babies were going up to the father (and later I would see that the mother was suffering a similar fate), pecking at the soft rays of the dorsal fin and the surrounding skin and flesh,, and eating them alive!
Part of me said that I wasn't going to interfere, and that I'd let the chips fall where they may, but this was too much to witness. As a result, I made the decision to remove the bitten and exposed Convicts into different quarters. The father I relocated to a 6 gallon hospital tank along with another adult male to keep him company. The mother I relocated to my son's 20 gallon tank with a bevy of other female Convicts (he jokingly calls this tank "the harem"). As a result the babies are now free to roam the tank without the parents corraling them. They are also free to be approached and dealt with by the fish that are in the tank, from those ten times their size to those who are fellow convicts but not their parents and will definitely chase them all over the tank if they try to nip at their fins or skin.
This is a lot like our software projects when we tinker and play favorites. When we play favorites and cherry pick our projects and where out time and attention will go, there will be "features" that will likewise grow and cannibalize the product. We as testers have a moral obligation to be on the lookout and look to see if development decisions may have unintended consequences. They may not be as severe or unusual as baby fish cannibalizing their 5 - 10 times their size parents, but there will be interesting problems nevertheless. To this end, it's important that we grow to understand what features have been added and how they interact with the whole system. Chances are, if we do so, we may well avoid the cannibal fish issues.
Saturday, June 11, 2011
What are YOU Watching?! A Weekend Testing Follow-Up
So this time, I will have to confess, I was a little more nervous than usual. After having run a dozen Weekend Testing sessions, you would think this would be no big deal. Normally it wouldn't be, but this was not an ordinary session. For starters, it was a session based on User Experience, which can be a challenging topic in and of itself. The second reason? I was putting my own company's product and site up for testing. Yikes!!!
I think in a small way every tester gets a little anxious when they invite other testers in to test their product. Yes, I said it, I am the Lone Tester at SideReel and by virtue of that, it makes it in part mine. What it absolutely makes it is a referendum on my own testing awareness and acumen. To be frank, I am well aware that I will not catch everything. I'm also well aware that I can't catch everything all by myself, and that's one of the great benefits of having a team come in, even if just for an hour. Still, it's an uneasy feeling to see comments come in and say "ooh, yeah, I didn't think of that!" or "hey, good catch, I don't know why I didn't see that!"
Considering the caliber of testers, both in range and level of experience that we get at these Weekend Testing sessions (and from all over the world, no less :) ), I'd actually have been surprised if they would only have found issues that I had already discovered, and also I welcome the additional insights as to areas I may have become somewhat jaded around, even after only a few months. Inattentional blindness is a real danger when you test alone. Adding eyes and insights help to mitigate the potential for inattentional blindness considerably.
The other aspect to also consider is the way that multiple users will approach the way they use the site. One of the interesting comments came from Perze Ababa when he asked me why there was a Track Show option for canceled shows. He then explained that, to him, you track shows that are current, because there's some new trail to "track". Shows that are older, completed or had been canceled had no fresh trail to leave, so is "tracking" the right metaphor? Truly, I don't know the answer to that, but it raised an interesting discussion point and pointed out again that, in many cases, User Experience is very much in the eye of the beholder.
Friday, June 10, 2011
PODCAST FRIDAY: TWiST #49 w/ Adam Yuret (Part 1)
One of the fun things about getting more involved in the testing community is that you get to know those people making a point of being players in the game. It's much like any scene, really. At first you are the neophyte looking to others as your inspiration and sources of information, but you don't have any direct connection to them. Over time, those names may become people you correspond with or otherwise interact with. As time progresses and you get involved, you work more collegially, and a relationship develops that's more one-to-one, and at some point, you then become one of those players yourself that others look to for inspiration. It's a neat feeling.
Why do I bring this up? Mainly because that's been the way that this podcast has gone for me. Most of the people interviewed at first were people I had no knowledge of other than their names. Later, there were a few people that I'd interacted with briefly and had a chance to do some testing related correspondence with. Through Weekend Testing, I've had the opportunity to learn more about and work directly with a lot of the testers that I've come in contact with, and now we are featuring an interview with someone I've met, come to know and collaborate with directly, and yeah, that's a really cool thing to experience.
So this week Matt sat down with Adam Yuret from VolunteerMatch.org. Adam's another of the "life experiences" school of testers, and he's also another tester who's spent a fair amount of his career in the lone tester camp. He also adds to that in the fact that he's a remote tester working with a team 1,000 miles away. Oh, and he took a three year sabbatical to sail the Sea of Cortez with his wife. Adam was one of the participants in the eBay mini-conf I wrote about a few weeks ago, and he's genuinely a great guy, but seriously enough from me, why note go to the site and listen to and listen to Episode #49 and Adam for yourself :).
Standard disclaimer:
Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to the podcasts and the entire library whenever you want to :). In addition, Pro membership allows you to access and download to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance.
TWiST-Plus is all extra material, and as such is not hosted behind STP’s site model. There is no limitation to accessing TWiST-Plus material, just click the link to download and listen.
Again, my thanks to STP for hosting the podcasts and storing the archive. We hope you enjoy listening to them as much as we enjoy making them :).
YT9MF65CTP4Z
Thursday, June 9, 2011
TESTHEAD Speaks!!!
Well, much of this is still in the works, but I'm trying to stretch out of my comfort zone a little bit, as well as bring some of what I know from other avenues into my testing world.
First, I have confirmation that I will be attending CAST 2011 in Lynnwood, WA in August. There are several areas I will be participating. First, I will be conducting a live Weekend Testing session at the conference for anyone who wants to participate (topic and target still TBD). I'm also participating in a forum about "How to Reduce the Cost of Software Testing" as a contributor to the book of the same title. Additionally, I'm participating in another forum regarding my experiences as both an assistant and lead instructor for the Black Box Software Testing series. Add to that me roaming around with a portable digital recorder, and there should be ample opportunities for discussion, review, conferring and potential podcasts.
Next, I have submitted and been accepted to speak at Pacific Northwest Software Quality Conference 2011. I presented a paper idea called "Delivering Quality One Weekend at a Time". Yep, it's a Weekend Testing related paper, and it will be done in the poster paper session times. Part of this is I think it will make for a more interesting approach to presenting the ideas, but more to the point, it's because I mis-read the submission policy and submitted it as a poster paper instead of as a regular paper. This is fine, though, as it will allow me the opportunity to practice the delivery several times :).
Another talk I'm developing is the one that I did as a lightning talk at the mini-conference Jon Bach, Shmuel Gershon, Doug Hoffman, Adam Yuret and I held last month at eBay. In that talk, I discussed the ideas that I've learned in the Boy Scouts with regards to developing teams, transferring knowledge and skills, and developing leaders. I realized that the same techniques used in the Boy Scouts were suited to testers, too. I presented this idea for STPCon Fall 2011 but found out that, even if it were accepted, I can't attend due to another commitment. Still, I really want to get this talk out there, so I'm looking for opportunities to present it. I've submitted an abbreviated version for CAST 2011 Emerging Topics... we'll see if it gets picked up.
One of the great things about our community is that they can tell when someone is spreading BS. I'd like to believe I'm one who isn't, but I won't know unless I get my ideas challenged. The best way to have those ideas challenged is to present them and let people take shots at them. So if you are going to be at any of the venues I've mentioned, or others that may yet appear, please feel free to attend and poke holes at my theories and ideas. I'd like the opportunity to consider anew what I do and how I do it, and I look forward to learning how I can be a more effective presenter and speaker.
First, I have confirmation that I will be attending CAST 2011 in Lynnwood, WA in August. There are several areas I will be participating. First, I will be conducting a live Weekend Testing session at the conference for anyone who wants to participate (topic and target still TBD). I'm also participating in a forum about "How to Reduce the Cost of Software Testing
" as a contributor to the book of the same title. Additionally, I'm participating in another forum regarding my experiences as both an assistant and lead instructor for the Black Box Software Testing series. Add to that me roaming around with a portable digital recorder, and there should be ample opportunities for discussion, review, conferring and potential podcasts.Next, I have submitted and been accepted to speak at Pacific Northwest Software Quality Conference 2011. I presented a paper idea called "Delivering Quality One Weekend at a Time". Yep, it's a Weekend Testing related paper, and it will be done in the poster paper session times. Part of this is I think it will make for a more interesting approach to presenting the ideas, but more to the point, it's because I mis-read the submission policy and submitted it as a poster paper instead of as a regular paper. This is fine, though, as it will allow me the opportunity to practice the delivery several times :).
Another talk I'm developing is the one that I did as a lightning talk at the mini-conference Jon Bach, Shmuel Gershon, Doug Hoffman, Adam Yuret and I held last month at eBay. In that talk, I discussed the ideas that I've learned in the Boy Scouts with regards to developing teams, transferring knowledge and skills, and developing leaders. I realized that the same techniques used in the Boy Scouts were suited to testers, too. I presented this idea for STPCon Fall 2011 but found out that, even if it were accepted, I can't attend due to another commitment. Still, I really want to get this talk out there, so I'm looking for opportunities to present it. I've submitted an abbreviated version for CAST 2011 Emerging Topics... we'll see if it gets picked up.
One of the great things about our community is that they can tell when someone is spreading BS. I'd like to believe I'm one who isn't, but I won't know unless I get my ideas challenged. The best way to have those ideas challenged is to present them and let people take shots at them. So if you are going to be at any of the venues I've mentioned, or others that may yet appear, please feel free to attend and poke holes at my theories and ideas. I'd like the opportunity to consider anew what I do and how I do it, and I look forward to learning how I can be a more effective presenter and speaker.
Wednesday, June 8, 2011
Getting Creative with Whatever We Have On Hand
On Monday, my daughter graduated from Elementary School, and as part of the graduation ceremony, there were several "talent" presentations, ranging from dance performances to musical performances, to a visual presentation on horse training and a student who showed fencing (seriously, it was cool to see :) ). My daughter said she wanted to sing for the talent portion, and she picked the song "The House That Built Me" by Miranda Lambert.
Once we knew that she wanted to do that song, we scouted the net for an instrumental version of the song. It took some searching, as most of the "karaoke" style tracks were MIDI performances and sounded very artificial. We finally found a version that was a recording made with actual instruments, including dobro and slide guitar for authenticity.
Then came the next challenge… how to encourage my daughter to simulate singing in front of an audience with what she would hear. I've kept most of my musical equipment from back when I was a performing musician, including microphones, a mixing board, studio monitor speakers, and outboard effects. Hooking up a microphone and a CD player, I was able to give my daughter a controlled environment to help her practice singing.
The problem I saw with this was that, while it would amplify her voice, it wouldn't give her the real feeling of how she would sound and what she would hear. As we talked about this, I thought this would be a fun little project for us to focus on together. Using the gear we had on hand, what could we do to make an environment that would be similar to what she would hear, so that she could practice and focus on her technique correctly?
As we considered ideas, she did something interesting… she took my little guitar practice amp, plugged the microphone into the input, and adjusted the amp so that it could be heard without feeding back, and then adjured the effect knob so that it had a little reverb on it. I explained that reverb simulates the space in an area where the voice would travel, and creates a short delay, like she'd hear in real life. With that, she was able to practice, focus on her technique, and effectively gauge how her voice might sound to her in a larger room than where we were practicing.
Her performance went well, I'm happy to say, and I'm proud of her both for her performance as for her willingness to be creative to help solve a problem. I explained that this kind of "out of the box" thinking was a hallmark of being a tester. Often, the method for testing something might be totally different than what we originally envision to test an idea. I was prepared to use a bunch of sophisticated outboard gear, mainly because I had it on hand, knew how to use it, and I thought it would be fun to get some bragging rights for showing my kid some cool gear. Her solution was totally different, but it worked, and it was up and running way more quickly than my original idea would have been. I smiled and told her that, many times, the best solution to a problem is the simplest solution that is effective.
I've told my kids that they can approach and accomplish anything that they set their minds to, but I'll admit it… I enjoy seeing my daughter think like a tester :).
Once we knew that she wanted to do that song, we scouted the net for an instrumental version of the song. It took some searching, as most of the "karaoke" style tracks were MIDI performances and sounded very artificial. We finally found a version that was a recording made with actual instruments, including dobro and slide guitar for authenticity.
Then came the next challenge… how to encourage my daughter to simulate singing in front of an audience with what she would hear. I've kept most of my musical equipment from back when I was a performing musician, including microphones, a mixing board, studio monitor speakers, and outboard effects. Hooking up a microphone and a CD player, I was able to give my daughter a controlled environment to help her practice singing.
The problem I saw with this was that, while it would amplify her voice, it wouldn't give her the real feeling of how she would sound and what she would hear. As we talked about this, I thought this would be a fun little project for us to focus on together. Using the gear we had on hand, what could we do to make an environment that would be similar to what she would hear, so that she could practice and focus on her technique correctly?
As we considered ideas, she did something interesting… she took my little guitar practice amp, plugged the microphone into the input, and adjusted the amp so that it could be heard without feeding back, and then adjured the effect knob so that it had a little reverb on it. I explained that reverb simulates the space in an area where the voice would travel, and creates a short delay, like she'd hear in real life. With that, she was able to practice, focus on her technique, and effectively gauge how her voice might sound to her in a larger room than where we were practicing.
Her performance went well, I'm happy to say, and I'm proud of her both for her performance as for her willingness to be creative to help solve a problem. I explained that this kind of "out of the box" thinking was a hallmark of being a tester. Often, the method for testing something might be totally different than what we originally envision to test an idea. I was prepared to use a bunch of sophisticated outboard gear, mainly because I had it on hand, knew how to use it, and I thought it would be fun to get some bragging rights for showing my kid some cool gear. Her solution was totally different, but it worked, and it was up and running way more quickly than my original idea would have been. I smiled and told her that, many times, the best solution to a problem is the simplest solution that is effective.
I've told my kids that they can approach and accomplish anything that they set their minds to, but I'll admit it… I enjoy seeing my daughter think like a tester :).
Friday, June 3, 2011
Perception is Reality for Most People
Do you ever find yourself participating in something that you think is perfectly normal, but others around you may have a totally different interpretation of what is going on?
I had that experience yesterday when our Boy Scout Roundtable group held a dutch oven cook-off and a flag retirement ceremony. A little background for recent readers, I am an active adult leader in the Boy Scouts of America and have been for 18 years. Every first Thursday in June, other adult leaders in our district as a way to celebrate the traditional "end of the scouting program year" hold a potluck dinner in a park in San Mateo, where leaders and scouts can enter Dutch Oven dishes in an informal competition. Our troop has two dishes which are consistent winners, our "Philmont Ranger Peach Cobbler" and our "Redwood Enchilada Pie" so of course we made those last night. Yes they turned out great. Yes, I'll share the recipes if you want them (leave me a note below if you want them and I'll get them to you ;) ).
The part that we also do, and it's a solemn ceremony that we hold each year, is a flag retirement ceremony. What's that, you may ask? Well, in the U.S., when an American flag is seen as being unfit for further use (meaning it has become torn, damaged, or otherwise has become old or ragged enough to no longer be serviceable as a flag, then the appropriate way to deal with the flag is to retire it. According to U.S. law, customs and traditions, the appropriate way to retire a flag is to burn it. Golden Gate National Cemetery, which is located in my home town of San Bruno, CA, is the resting place for over 120,000 veterans. Every year Scouts and Scouters place a flag on each tombstone for Memorial Day weekend as a show of respect. Over time, these small flags become worn and unusable, as do several larger flags. Therefore, GGNC gives us these flags to be retired in the ceremony we hold each June.
What made this year's experience just a little bit more interesting was that, as we were doing this flag retirement ceremony, most of us dressed in our full field scout uniforms, a teenaged boy walked up to us and calmly but with a concerned look on his face, asked "Excuse me, but could you please tell me what you are doing here?!" The look on his face showed that he was greatly concerned with our actions. My guess was that he saw what he'd seen many times on the news in the past, a flag burning, and jumped to the conclusion that we were somehow holding a protest, or otherwise desecrating the U.S. Flag. As I saw the concern in his eyes, I took him aside and explained to him the purpose of a flag retirement ceremony and the fact that this is a perfectly normal, respectful and government sanctioned way to retire flags no longer fit for service. As I explained the situation, the boy relaxed, smiled and said "Oh, OK, I didn't know that!", and returned over to a group of his friends. It was when he was walking back that I noticed a few of the teenagers were flipping us off. They too saw what we were doing, and I am guessing jumper to the same conclusion. As I watched the boy who asked us the question walk back, I could see a conversation ensued, and the boys who were flipping us off had a look of understanding cross their faces, and they lowered their hands, and went on to do other things, paying us no more mind.
As I drove home from this event last night, I kept thinking about this, and realized that we often operate under rules that we understand, but that others may have no idea even exist. When we create an application, or a service, we have to expect that many people will understand the "rules of the road" but many others will not. As an advocate of the customer, those of us who are testers have the mission and obligation to make sure that the whole story gets told, and that the issues we see are being addressed. Sometimes, though, we may not see an issue as an issue because we understand the underlying "culture" of the application. Without that perspective, we may have a totally different interpretation and perspective of what is going on. This experience reminded me that different people have a different level of understanding of what we may often consider as "everyday occurrences". We should be on the lookout for these opportunities. My guess is that, where misunderstandings exists, so do potential issues.
I had that experience yesterday when our Boy Scout Roundtable group held a dutch oven cook-off and a flag retirement ceremony. A little background for recent readers, I am an active adult leader in the Boy Scouts of America and have been for 18 years. Every first Thursday in June, other adult leaders in our district as a way to celebrate the traditional "end of the scouting program year" hold a potluck dinner in a park in San Mateo, where leaders and scouts can enter Dutch Oven dishes in an informal competition. Our troop has two dishes which are consistent winners, our "Philmont Ranger Peach Cobbler" and our "Redwood Enchilada Pie" so of course we made those last night. Yes they turned out great. Yes, I'll share the recipes if you want them (leave me a note below if you want them and I'll get them to you ;) ).
The part that we also do, and it's a solemn ceremony that we hold each year, is a flag retirement ceremony. What's that, you may ask? Well, in the U.S., when an American flag is seen as being unfit for further use (meaning it has become torn, damaged, or otherwise has become old or ragged enough to no longer be serviceable as a flag, then the appropriate way to deal with the flag is to retire it. According to U.S. law, customs and traditions, the appropriate way to retire a flag is to burn it. Golden Gate National Cemetery, which is located in my home town of San Bruno, CA, is the resting place for over 120,000 veterans. Every year Scouts and Scouters place a flag on each tombstone for Memorial Day weekend as a show of respect. Over time, these small flags become worn and unusable, as do several larger flags. Therefore, GGNC gives us these flags to be retired in the ceremony we hold each June.
What made this year's experience just a little bit more interesting was that, as we were doing this flag retirement ceremony, most of us dressed in our full field scout uniforms, a teenaged boy walked up to us and calmly but with a concerned look on his face, asked "Excuse me, but could you please tell me what you are doing here?!" The look on his face showed that he was greatly concerned with our actions. My guess was that he saw what he'd seen many times on the news in the past, a flag burning, and jumped to the conclusion that we were somehow holding a protest, or otherwise desecrating the U.S. Flag. As I saw the concern in his eyes, I took him aside and explained to him the purpose of a flag retirement ceremony and the fact that this is a perfectly normal, respectful and government sanctioned way to retire flags no longer fit for service. As I explained the situation, the boy relaxed, smiled and said "Oh, OK, I didn't know that!", and returned over to a group of his friends. It was when he was walking back that I noticed a few of the teenagers were flipping us off. They too saw what we were doing, and I am guessing jumper to the same conclusion. As I watched the boy who asked us the question walk back, I could see a conversation ensued, and the boys who were flipping us off had a look of understanding cross their faces, and they lowered their hands, and went on to do other things, paying us no more mind.
As I drove home from this event last night, I kept thinking about this, and realized that we often operate under rules that we understand, but that others may have no idea even exist. When we create an application, or a service, we have to expect that many people will understand the "rules of the road" but many others will not. As an advocate of the customer, those of us who are testers have the mission and obligation to make sure that the whole story gets told, and that the issues we see are being addressed. Sometimes, though, we may not see an issue as an issue because we understand the underlying "culture" of the application. Without that perspective, we may have a totally different interpretation and perspective of what is going on. This experience reminded me that different people have a different level of understanding of what we may often consider as "everyday occurrences". We should be on the lookout for these opportunities. My guess is that, where misunderstandings exists, so do potential issues.
PODCAST FRIDAY: TWiST #48 w/ Eric Jacobson
So for those who are interested, I've set up a little tracker in RescueTime because I wanted to see just how much time I spent on a typical interview each week.
Part of this comes down to my own personal tick; I have tried and I just can't get past the idea of releasing a talk or an interview with "um's" or "uh's" or stammers in it. If I could, I could cut the time way down, but since I won't, well, it takes me on average four hours of editing to produce a 30 minute show each week. Yeah, that's super nerdy, I know, but I think it adds to what I hope is a "polished" podcast. I don't know about the rest of you, but I treat many of my favorite podcasts as reference material; I go back and listen to many of them over and over again. It's my hope that these podcasts are not seen as "throwaway" weekly blurbs, but as real meat and potatoes stuff that people will want to hold onto and listen to over and over again as well.
Serious question, does the flow of the conversation feel normal and natural to you, the listener? I hear every click and pop, as wells every overly inflected point when I edit. Some of that is just not fixable without sounding really artificial, though I have joked with SideReel's resident audio editor that I have become the master of the "poor man's cross-fade", which is where you drop the volume on the last word and fade in on the first word where the edit takes place. Do you hear it? Is it enough to notice or comment on? If so, I'm genuinely curious.
So this week Matt sat down with Eric Jacobson. Eric works with Turner Broadcasting, and manages a team of testers. I liked this interview because he talked about what can be a challenging topic, and that's dealing with motivating testers. I know full well how it feels to be a tester who is just going through the motions, without any real purpose or focus, and I like what he has to say about helping testers get engaged and involved (it inspired an article I'm hoping will be published soon; I'll let you all know if it gets picked up). Eric also explains what it was like to be "invaded" by the Rebel Alliance at a conference last year, where he found out he didn't get the room he had hoped for, but they gave him a suite with a fold down bed, but a big space. This led to a meeting and talk session of the Rebel Alliance and a number of lightning talks by the participants (and video footage, too :) ). So anyway, if you're tired of my blathering, by all means go to and listen to Episode #48 for yourself :).
Standard disclaimer:
Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to the podcasts and the entire library whenever you want to :). In addition, Pro membership allows you to access and download to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance.
TWiST-Plus is all extra material, and as such is not hosted behind STP’s site model. There is no limitation to accessing TWiST-Plus material, just click the link to download and listen.
Again, my thanks to STP for hosting the podcasts and storing the archive. We hope you enjoy listening to them as much as we enjoy making them :).
Thursday, June 2, 2011
SDET in Training?
I've been a little out of the loop the past few days, and I've had a number of reasons. One of which is that I've just finished editing the next podcast for TWiST, and delivered it this morning. Once it's posted, I'll tell you all about it :). Also, there's the Week 3 of Bug Advocacy, which is heading into the Final Exam after Saturday, so I've been spending a lot of time there, too.
Still, those aren't the biggest areas I've been focusing my attention. Most of my time has been with a new reality. Getting ready for my first official "stand-up" on my development project. Huh?!
Yep, it's true, I have my first project that's a real development initiative (well a Development Test initiative, to be more accurate) but I can claim a project in GitHub, paired development time with other developers, and something that's been entertaining... a tester to test my code and fixes (because really, no developer should be testing their own stuff, right? Oh, and I use the term developer loosely here ;) ).
A couple of weeks ago at our most recent retrospective, it was decided that there was a need for a different level of automated testing. We have lots of TDD happening here, so there's a lot of focus on unit level testing and behavior driven testing, as well as automated acceptance tests, but even with those, we were still seeing issues that crept through to other environments. With that, it was decided that we needed a more user facing suite of tests, that covered what the user would actually see on each of these environments... and that I should be the one to lead up that project and get it into production. With that, I added the project manager and programmer hat officially to my job title.
In the past, I have had informal test initiatives. If I automated them or not was my own concern. Here, however, I have been asked to make it a genuine project, with real stories, real velocity points, and real people that I can call on to help me get things in place and to make sure that those initiatives are met. In short, I have to answer for them in an official capacity now. It's no longer just me doing things on my own. My test asets have become part of the company and I am expected to deliver on them... and I'm excited!
Most of my career, my test assets were just my own personal toolbox. If they helped me get something done, then great. They existed separately from the rest of the product, and were often not version controlled beyond on my local machines. I certainly never had a project in GitHub to pull and commit from. I do now! SideReel is making good on their promise to integrate me into the development team, and to be regularly involved in programming initiatives. Granted, at the moment, it's limited to me writing steps and procedures in Cucumber, b ut even there I'm having to cobble together a lot of different projects, applications and tools to accomplish my goals. Even a basic set of tests is interacting with tools like ruby, celerity, nokogiri, capybara, rspec, selenium, webrat, plus a bunch of others I'm going to need to get more familiar with.
I've been using The RSpec Book (review coming soon) to help me understand all of this, and to get into the mind of a TDD and BDD coder. Progress is moving along a little bit each day. I've been blessed with a developer that has been very patient and helped me build some of the background structures I'll need to accomplish a lot of the goals that we have. We made a conscious decision for this project to try to keep the focus on what the user would see and interacting at that level. This has already shown us some interesting challenges, the first of which is finding ways to make sure that the tests are not brittle (or to be fair, not as brittle as they might normally be). I've also been given a crash course in targeting actions to CSS locators. My tests are stil a little more verbose than I'd like, but I'm already seeing places where I can DRY up the code and make for more reusable pieces.
The real benefit of this is that I am being given time to do this every day; in previous jobs, it was hard to get the time to sit down and dedicate myself to doing any meaningful automation. Now, it's expected that the group will help take on testing roles within their pairings so that I can focus attention on automating tests. I will still confess that it's not a natural fit for me. I still feel like I'm playing in the wrong sandbox, but hey, I'm not complaining :).
So does this spell a future as an SDET? I'm not entirely sure that I'll go that far, but for now, I'm greatly enjoying the fact that I am expected now to wear a coders hat for a good portion of my time here, with the proviso that I still subject our applications to real world exploratory Test-Fu, which I am more than happy to do!
Still, those aren't the biggest areas I've been focusing my attention. Most of my time has been with a new reality. Getting ready for my first official "stand-up" on my development project. Huh?!
Yep, it's true, I have my first project that's a real development initiative (well a Development Test initiative, to be more accurate) but I can claim a project in GitHub, paired development time with other developers, and something that's been entertaining... a tester to test my code and fixes (because really, no developer should be testing their own stuff, right? Oh, and I use the term developer loosely here ;) ).
A couple of weeks ago at our most recent retrospective, it was decided that there was a need for a different level of automated testing. We have lots of TDD happening here, so there's a lot of focus on unit level testing and behavior driven testing, as well as automated acceptance tests, but even with those, we were still seeing issues that crept through to other environments. With that, it was decided that we needed a more user facing suite of tests, that covered what the user would actually see on each of these environments... and that I should be the one to lead up that project and get it into production. With that, I added the project manager and programmer hat officially to my job title.
In the past, I have had informal test initiatives. If I automated them or not was my own concern. Here, however, I have been asked to make it a genuine project, with real stories, real velocity points, and real people that I can call on to help me get things in place and to make sure that those initiatives are met. In short, I have to answer for them in an official capacity now. It's no longer just me doing things on my own. My test asets have become part of the company and I am expected to deliver on them... and I'm excited!
Most of my career, my test assets were just my own personal toolbox. If they helped me get something done, then great. They existed separately from the rest of the product, and were often not version controlled beyond on my local machines. I certainly never had a project in GitHub to pull and commit from. I do now! SideReel is making good on their promise to integrate me into the development team, and to be regularly involved in programming initiatives. Granted, at the moment, it's limited to me writing steps and procedures in Cucumber, b ut even there I'm having to cobble together a lot of different projects, applications and tools to accomplish my goals. Even a basic set of tests is interacting with tools like ruby, celerity, nokogiri, capybara, rspec, selenium, webrat, plus a bunch of others I'm going to need to get more familiar with.
I've been using The RSpec Book
(review coming soon) to help me understand all of this, and to get into the mind of a TDD and BDD coder. Progress is moving along a little bit each day. I've been blessed with a developer that has been very patient and helped me build some of the background structures I'll need to accomplish a lot of the goals that we have. We made a conscious decision for this project to try to keep the focus on what the user would see and interacting at that level. This has already shown us some interesting challenges, the first of which is finding ways to make sure that the tests are not brittle (or to be fair, not as brittle as they might normally be). I've also been given a crash course in targeting actions to CSS locators. My tests are stil a little more verbose than I'd like, but I'm already seeing places where I can DRY up the code and make for more reusable pieces.The real benefit of this is that I am being given time to do this every day; in previous jobs, it was hard to get the time to sit down and dedicate myself to doing any meaningful automation. Now, it's expected that the group will help take on testing roles within their pairings so that I can focus attention on automating tests. I will still confess that it's not a natural fit for me. I still feel like I'm playing in the wrong sandbox, but hey, I'm not complaining :).
So does this spell a future as an SDET? I'm not entirely sure that I'll go that far, but for now, I'm greatly enjoying the fact that I am expected now to wear a coders hat for a good portion of my time here, with the proviso that I still subject our applications to real world exploratory Test-Fu, which I am more than happy to do!
Subscribe to:
Posts (Atom)