Podcast Friday: Cakes, Transition, Salad and Mice, Oh My!

Hey everyone! It's been a few weeks since I've done a Podcast Friday entry, so please forgive me and let me help fix that situation.

First and foremost, let me draw your attention to the latest and greatest TWiST episode. This time around, Matt Heusser interviews Matt Kallman of Carnevale Interactive, and covers various topics such as what it's like to be a principal in a small company, how it feels to work with people who are maybe only interested in being testers for a short period or otherwise have other goals beyond just software testing, and what being a tester can do to help bolster a career as a product manager. It's all right here. Oh, and for those who follow my nerdy goings on with this podcast, this episode marks the beginning of my love affair with Blue Microphones. No, seriously, I bought a Blue Snowball USB mic and a shock ring for the capsule, and recorded the intro/outro, and really, this is probably the best "microphone" I've ever had the pleasure of using. Granted, this is nowhere near the caliber of their extremely awesome studio mic's (like the Bottle) but for a consumer grade, direct to PC microphone, the sound is awesome!!!

Also on the testing front, I need to give another shout out to Trish Khoo and Bruce MacLeod for their latest edition of Testcast. In Episode #5, called "Pass Cakes and Fail Cakes" Bruce and Trish roam around a number of topics, such as the sheer number of blogs they both have (Trish really has six blogs?! Wow!), and when to use production data in tests (and of course, when not to, which really is most of the time).

Dan Benjamin and Merlin Mann are back in the mix again with Back to Work #26. In this episode titled "Spaghetti Guy Hits Close to Home". It's an all over the map run, and really, that's what makes it fun, but if podcasts about work, productivity, finding jobs, selling cars, putting your house on the market, leveraging enthusiasm and finding your position of strength. And really, gang, there just isn't a bad show in the bunch for these guys. It's an acquired taste, I know, but if you can get into the Dan and Merlin vibe, it's pretty much always golden.

My last recommendation for this week is strangely appropriate for a testing and QA crowd. I'm somewhat amazed that I have not listened to this podcast before this week, but I've found it now, and I love it. Freakonomics Radio, which is based on the book of the same name by Steven D. Levitt and Stephen J. Dubner, emphasizes on what it refers to as "the hidden side of everything". Their most recent episode is called "Mouse in the Salad" and takes a look at the idea that, in a top end posh restaurant in New York, how in the world did a dead mouse make its way onto a diner's plate, what would such a situation do to your confidence in that organization, and what did they do about it? Additionally, seriously... how did the mouse get there?!

Oh, and here's a pending announcement, to be delivered as soon as I can humanly do it… the five candidates for the Association for Software Testing's Board of Directors (Matt Heusser, Cem Kaner, Michael Larsen, Catherine Powell and Peter Walen) sat down for a roundtable debate/interview session to discuss the upcoming elections and hopes and aspirations for the future of AST. We recorded two hours worth of audio and I am actively editing it, and want to get it out as soon as I can, so if I'm a little more quiet than normal, that's why. My goal is to try to get it out in time for the great Twitter debate which will be hosted on Monday, August 1, 2011 (more on that tomorrow :) ).

Happy listening :).

Simple Tweaks and Game Changers

This morning, I had the chance to sit down and play with my "new toy". As many of you know, one of the things I do each week is that I produce and edit the "This Week in Software Testing" podcast for Software Test Professionals. What you may not know is that I've worked with a portable and, for the most part, shoe-string environment, consisting of a simple USB microphone and a PC, using Audacity as the editing and production environment. This has been partly for necessity (I want to keep the environment portable) but also with the goal of keeping costs down (after all, when I started, I didn't know how long this would last or how many total episodes we would do). To this end, I've used a simple USB Logitech desktop microphone for the past year. For the record, it worked very well for very little money. I wouldn't call it a "studio grade" microphone by any means, but for what we've been doing, it got the job done :).

After producing a year's worth of shows, I decided it was time to make a jump up in microphone standards... actually, a slight mishap with the Logitech microphone necessitated the change.  By slight mishap, I mean I tipped over the mic stand I was using to hold it at a more natural level for me, and it sheared the plastic capsule. It still works, but the base now just dangles by the wire that leads to the microphone element. Could I fix it with some glue and some electrical tape? Sure, but with this happening, and looking at the future landscape for podcast recording and the time I invest in the process, I figured "oh what the heck, why not upgrade the microphone?!"

Sidereel does a fair amount of video production and also does some audio work that requires some "after the fact" voice over work. Since they are in the practice of doing daily recording and editing, I decided to ask what they use. It turns out they use a Blue Microphones Snowball, which is a mid priced USB microphone that plugs straight into a Mac or PC (or with an adapter can plug straight into a mixing board). It has three separate pickup patterns that can be selected and, in their estimation, is well suited for doing voice over work.

Due to the fact that I do a lot of keyboard checking and hand-level checking on my PC (i.e. my PC is my recording environment and my mixer, and I don't have the luxury of an isolated or quiet control room), I also decided to invest in a shock mount, which isolates the microphone from bounces and picking up transient noises or vibrations. Combined, this makes for a formidable tabletop microphone, stand and shock ring, with very near professional broadcast quality sound, and the whole rig cost less that $100.

It took me a little while to sit down with it and get its quirks worked out. It gives a much better sound pickup, which means my normal seating, projection, and delivery also had to be changed (lower quality mics have a certain charm in that they don't pick up all of the ambient noise or the little clicks and ticks of the movement of a speaker's mouth like this microphone does).

This reminded me that, often, when we add a new tool or a new piece of knowledge to our arsenal, we have the ability of really changing our game and doing things differently, and by necessity, we need do things differently. When I started using Cucumber to automate tests a couple of months ago, it by necessity required that I change my way of thinking about how to automate tests. The very nature of the tests I was responsible for (being able to make sure that our development environment and development changes capably made the transition from development machines out to the production environment, with two intermediate steps in between) also required that I look at my testing differently, and to realize that methods and approaches that worked for one group of developers and testers would, by necessity, require a different approach and level of thinking in this case. All it takes is one element, one change in our environment, and our adjustment to work with it can radically alter our approach and our every day efforts.

For the podcast recordings, I hope this will give me the opportunity to tackle more voice over options with better quality. In my day to day testing, it's my hope that I'll get to play with more that Cucumber, RSpec and Ruby can offer so I can be more effective in my active testing. New toys make for new ways of thinking. While the toy may be the catalyst, ultimately it's our brains and our reactions that make them work effectively... so go and do likewise :).

So, Why Should You Vote For Me?!

Well, actually, if you are not a member of the Association for Software Testing, I'm going to say the answer is "you don't have to". Actually, even if you are a member of the Association for Software Testing, you don't HAVE to vote for me… but I'd certainly be happy if you did.

Part of me feels like starting this with the lines of Admiral James Stockdale when he participated in the 1992 Vice Presidential debate… "Who am I? Why am I here?" Unlike Admiral Stockdale, though, I hope to be able to get to that much quicker and provide a reasonable answer (for those of you who are outside of the US and have no idea who James Stockdale is, no worries. For those of you stateside who don't know, you're obviously lots younger than me ;) ).

I am a tester. I am a teacher. I am a believer in the idea that "it's the people, stupid" that make any organization worth being around in the first place.In short, members of AST, I'm one of you, and really no more than that. I don't have any grand qualifications outside of having been a tester for 17 years. I've never managed a company's test team, I've never held an exalted title like "test director". Heck, most of my efforts have been as a lone tester over these 17 years. I have, however, experienced a lot of ups and downs in this industry, and it's helped me see that I'm not alone in facing those challenges.

I'm a strong proponent and a believer in the value of the Black Box Software Testing classes. To date, I'm a veteran of five Foundations classes (one as participant, four as instructor) and two Bug Advocacy classes (one as participant, one as instructor). I look forward to the opportunities to teach these classes because I learn something new every time.It's also as an instructor that I see the value and power of these classes. We are not seeking a "fill in the blank" one size fits all certification. We realize that testing is dynamic, context driven and varies with every test and tester. It's this view I would like to see more testers embrace and understand, as well as the rest of the software development world.

I believe strongly in the value of continuous education and active practice. It is with the eye towards continuous practice that I have led the charge for Weekend Testing in the Americas, and why I have facilitated each session since its inception. Each time we hold a session, I learn something different and help to teach something different to the participants. It's also in this continued growth and practice that Albert Gareev and I are developing "Project Sherwood", with the goal of developing the next level of "active practice" for testing skills.

Having produced nearly 60 podcasts, including some with me as the interviewer and interviewee, I have had the opportunity to become intimately familiar with the challenges and issues that span the testing discipline, and it's my desire to help see that discipline grow and develop.

Overall, my approach to politics can be best summed up as "neo-prudentist", which roughly translated means "I don't much care for politics, but I'm very motivated to find what works and help to promote and encourage it". I believe AST and its model to work and to be effective. I believe that the development and growth of the BBST course series, bot now and in the future, would be a tremendous help to the overall testing industry. There is a Test Design course in the works and almost finished and ready to be presented. There are many more possible courses that can be offered. As a board member, I'd like very much to see AST focus on further development of these courses and being able to present them to the public.

Finally, the reason I am here is "I was nominated", and for that alone, I am touched and honored. To quote Matt Heusser (a good friend and also a candidate), "If I am nominated,I will run. If I am elected, I will serve." Really and truly, it is that simple. I have no great promises to make, and I have no promises that I can use to sway your vote, other than this… AST is an organization I believe in, and am honored to be a member of and to serve. If I'm elected,I will serve to the best of my ability. If I am not elected… I will still serve to the best of my ability in whatever ways it may need me".

The rest, my testing compatriots, I leave up to you :).

How Did Robin Hood Handle This?!

So as some of you who have been keeping track of the various endeavors I talk about, Project Sherwood had its second run this weekend. In truth, I was a little concerned about this, because I knew that the second session would be more telling than the first. The first could be seen as a super-sized Weekend Testing session with maybe a more complex product than usual. The second session was picking up where we left off, including the fact that new people would be jumping into an already established field and expected to contribute quickly, without necessarily knowing 100% what was going on.

It was in this second area that I realized we had some work to do. We have the ability to communicate the product, we have the ability to show a mind map, we have a language to help us quickly determine what we are doing and what we are finding. What's missing? The method to tie it all together. In other words, we have the tools and we have the skills, what we seem to be missing is a "compelling narrative".

I think this is the point that most organizations come to at various times in their existence. It's one thing to tell a story, it's another to keep people hooked to the story and wanting to know more, and likewise want to keep participating with it. I think Sherwood has some great ideas, and it's got a lot of potential, but to make it to the next level and be effective, we cannot just be a knock-off of Weekend Testing. WT is built around the one-off, the single session that people gather, discuss an idea, concept or session in one go, and then go off and do other things. To that end, an experience report and chat transcript are plenty. Carrying that narrative over several sessions, especially when the communication level goes much deeper, that's more of a challenge, and stringing together several experience reports and going through multiple chat transcripts will likely not hold many people's attentions for very long. So we find ourselves having to go beyond the structure in place and develop new ways to communicate the narrative, so that those who are curious can follow along and be interested, and so that those who want to participate know what they are getting into and have a clear idea of how they can contribute.

Make no mistake, I am not criticizing Sherwood or lamenting these challenges, I in fact am smiling about them. It means that we have to stretch and consider new ideas, we have to open up the process and system to the entire band of Merry Practitioners, and we have already received lots of great suggestions and experiences to consider (Google docs, developing a wiki, using software to allow for multi-session mind-mapping, developing "Campaigns" for our testing efforts that can be published in advance, etc.). In short, there's no end to ideas and suggestions, it's how to weave them all together that will prove to be an interesting challenge. We are excited for the journey, and we hope you all will want to follow along, too :).

Living Inbox Zero

Merlin Mann is a point of inspiration for me in many ways. I like his philosophy, I like his approach to dealing with things, and I like the fact that he’s willing to admit that he’s not always really good at doing the things that he espouses, and that he is honest and open about that fact. In short, Merlin recommends a lot of the things he does not because he is really good at them, but because he is oftentimes really bad at them and wants to get better.

The idea probably most synonymous with Merlin is “Inbox Zero”. This is the idea that, every day, we should go through and sweep our email, text messages, etc., whatever it is that we use to stay up to date on things, and everything should be processed, either first thing in the morning or last thing close of business, take your pick. More to the point, it's not the number of messages, it's the percentage of your brain that's in your Inbox. Inbox zero really means "nothing left in the air, everything has been dealt with in one way or another".  It seemed brilliant, it seemed like a perfectly sound idea, and I admired it for three years… and then, just this past week, I put it to the test.

Wait, I’ve admired an idea and three years later started using it?! A little slow on uptake are we? Well…yes, it seems. It’s taken me a long time to realize that I’m an email hoarder, with a byzantine system of storage and tracking and nesting and up until last Wednesday, an Inbox that had 3000 messages. WHY?!! Simple truth is, I was going to get to it later, after I dealt with the messages I was waiting to get to, which meant I frequently forgot about messages, which meant I often had a flurry of new messages to remind me of the old messages, which meant I had to file, sort, shuffle, and reconsider what I was going to do…and on and on and on, ad infinatum ad nauseum.

Part of me wanted to declare email bankruptcy, just say “heck with it and flush them all”. However, I realized that was just dealing with a symptom, it wasn’t getting to the root of a problem, which was that I was letting things hang around as some weird self-validating trophy of who I was and thought I was. Merlin has stated numerous times, and I really believe this, that we often use our Inbox to decide who we have to be on that day. Much of it fit certain categories; newsgroup discussions I valued (and were archived elsewhere), access codes for services (which really didn’t belong in email anyway, talk about a security issue), receipts (again, don’t really belong in email) and past plans and agreements (which, upon further reflection, I may have looked at 10 messages again over the past 3 years). The final grouping was the most important, but also the one that really deserved better treatment… ongoing and active work. The point is, there are better ways to manage this stuff. An email Inbox should not be the place.

With this, I made a decision. How about we give Inbox Zero a try, and not just Inbox Zero, but as close to Email Zero as humanly possible? So here’s what I did:

• Reconsidered and revamped the byzantine folders. Instead of multiple folders for everything, now there is just a few with very general areas (testing, scouts, family, writing) and the idea that anything that's DONE is either archived or deleted (and by archived, I mean in a journal, not an email folder).

• Worked through and pulled out any and all “sensitive items”, and either moved them to documents or a spreadsheet so I could keep track of them in a “trusted system”. Once there, delete the messages.

• Dates, plans, appointments, etc., capture them in a calendar and then delete the messages.

• Blog about or Journal the truly valuable correspondence, or otherwise get that valuable information in a place where it was most relevant. Then delete the messages.

• Realize that Yahoo Groups has a storage mechanism for all messages. If I want to consult an archive, go there. Get it out of my email unless it’s actual "in process" details that I need to do something about right now.

With that, I achieved the zen state of Inbox Zero in three days, and I can say I’ve maintained it now for four. It’s an early win, and some may say not worth talking about if it’s that early, but I think it is, because here’s what my test has informed me:

• Reading email is way faster now.
• I’m much more likely to call spam spam and just delete it.
• I’m less likely to provide energy needed for other more important endeavors to scanning my inbox and searching my inbox for something that might be important.
• I deal with messages much more quickly and make decisions about them much more quickly.
• I’m very jealously guarding that Zero status in the Inbox. It was hard won, I want to keep it there.
• The important data points are now in places where they make sense and can be more quickly utilized and identified.

So is it worth it to go “Inbox Zero”? My preliminary findings say “YES”. Seriously, if for no other reason, see if the time you spend staring at email goes down as a result of doing it. I’m willing to be the answer will be “yes”. It certainly seems to be the case for me.

Cordgrass and Habits: When Testers Get Lazy

I live in a breezy area up in Northern California. In fact, I live in one of the breeziest places on the West Coast. There's this interesting area on the San Francisco Peninsula that stretches from Fort Funston towards the San Francisco Bay along the southern portion of San Bruno Mountain. This area acts like a funnel, and the breezes that result are so strong that they frequently cause a physical cut-off of the legendary San Francisco fog, to the point that the fog looks as solid as a curtain.

This breeze makes for clean air, but it also makes for an annoying reality for anyone who has a yard... invasive species spread like nobody's business out here. One of the worst is a grass called Spartina. It's also referred to as Cordgrass. It's a thick plant that sends rhizomes shooting out and snaking along lawns. If caught early, it can be pulled up and dug out. If it's left to grow, it will slowly match in with the lawn for awhile and send its runners out under the grass, until such time as it weaves into a solid mass and chokes off the original lawn. Even then, it will still look like regular grass... for awhile. Ultimately, though, it changes to a lighter green color, and grows into thick, rough spiky clumps, not at all fun to walk on or play on. When it gets to this point, it's a real challenge to remove it, often requiring a back-hoe to competely remove the topsoil and start again.

You're thinking to yourself "Michael's going to make a parallel to testing!" and you would be right. Sometimes we as testers get lazy in our practice. We just go with what we know and rely on the skills that we have always relied upon. They've stood us in good stead up until now, after all. So we go about and do things the way we always have, unaware that the technical world and infrastructure is constantly changing. When we do not focus our skills on these new areas as they become known to us, in many ways their presence becomes like Spartina. We don't want to uproot the technology, though, we want to understand it and work with it. We want to get to know it so that we are able to recognize it and how to work with it when we see it. If we ignore it, or if we don't seek to understand it, then the Spartina spreads, and it gets under our feet in ways we don't notice, until we reach a point where we must deal with it... and don't know how to.

I've come face to face with this over the past few months. The Web and the technologies that weave it together has really exploded. Some of the most complex applications imaginable now reside on the web. Sites we use daily utilize sophisticated mechanisms to bind CSS and HTML and database queries and Ajax together. For those of us who grew up with the surety and the "simplicity" of LAMP, it might be a bit bewildering to take a look at a web site today and see how much technology interacts with each other to give us the experience we often take for granted (and then try to understand how to test against it all).

In short, the world is changing all the time, and the wind blows stuff in every day. However, in our yards, if we take an hour every day and rake the grass, we can easily catch and ward off the invasive species getting a foothold and overwhelming our yard. Likewise, spending just an hour a day learning about the new developments out there (mobile, solr, MongoDB, ruby, Selenium/WebDriver, etc.), even if we don't become experts with them, we learn enough about them and how they interact to be ready to examine them without feeling overwhelmed. What's more, we might surprise ourselves with how "tidy" we can keep our technical skills. It doesn't have to be arduous labor. Just a little each day will do it... but it has to be each day. Otherwise, the weeds will choke you!

Danger: Blogger Who Reads!!!

Worry not, my Podcast grab bag will be going up later today, but since this is a blog mostly dedicated to what I at least hope will be based on education and re-education (the good kind, where we willingly learn new things, not the bad kind associated with Cold War era novels), I have decided to do some things to draw more attention to the books that I read and review. I once had an ambitious goal of reading and reviewing a technical book a week. I quickly came to the conclusion that was impossible, at least if I wanted to do the review or book any justice.

There are numerous areas where I draw attention to the books I'm interested in, am actively reading, or want to read. Unfortunately, the list seems to grow by the day, and the more books I find, the more books I learn about and want to do more with. This has led me to the practice of finding and requesting books that are still in development so that I can work with them before they are released. One company that does this very well, I feel, is Pragmatic Publishing.  The book that I am working through right now, and which is in Beta distribution, is "The Cucumber Book".

Cucumber is one of the more interesting ideas in testing that I've become directly involved in. It's not a panacea, but it is a way and a method to writing tests, and writing code for that matter, that focuses on the behavior of an application and testing to make sure that behavior is doing what it actually should be doing. The ideas behind Behavior Driven Development are very interesting, and as I am also working through The RSpec Book, (likewise from Pragmatic Publishing), I'm very curious to see how The Cucumber Book augments the information found in The RSpec Book.

Note, this is not a review... not yet, anyway. First, the book is not out yet, and is still being reviewed and formatted, thus it's like reviewing a restaurant while they are still doing the plumbing and hooking up the grills and ranges. Also, I don't review books until they are officially available to all, but I do like this format of Pragmatic Publishing to give access to those who are willing to buy the titles and have access as they are being written. Props for that :).

So my goal is to augment this site with more emphasis on the books reviewed to date, and make a listing and timetable for the books I've yet to review but want to. If you have titles that you think might be fitting (testing related, programming related, engineering related, scientific related, or heck, not related at all but you'd get a kick out of seeing me feature and review), let me know, and I'll see what I can add to my ever growing stack of titles :).

Selling the Story and Combating Apathy: TESTHEAD Branches Out!

This is exciting. Two different articles, on two different sites, within two days.  How cool is that :)?!

First, I want to give thanks to the folks over at Software Quality Connection for running my story about "Selling the Test Automation Story". This was a step out of my comfort zone, but I'm glad I wrote it. Too often, I think we get frustrated that we can't be as effective as we want to be, that we think things will just come to us and we will just naturally be effective. Automation is one of my biggest bugaboos; it doesn't come to me naturally, and it doesn't match my normal way of thinking. Still, if I only wrote about my successes, this blog would have a lot fewer entries in it... a LOT fewer entries (LOL!). The simple truth is, I learn more from my shortcomings and challenges than I ever do from my easy successes, so thank goodness for small blessings. It's not that we fail, but that we get up and try again after we fail that's important. Anyway, I'd appreciate it if you could go check out the article and then tell your friends about it :).

Second, The Testing Planet #5 is out today, and I am tickled pink to discover that my story on "Combating Tester Apathy" made the front page :). As of right now, the Testing planet is available as an actual print newspaper, and can be downloaded through Amazon, via Kindle or E-Reader format, or you can buy the first run PDF version. Later this month, the free PDF will be made available to one and all. This story owes a lot to Larry Winget, a guy I'm sure that regular readers see pop into my writing from time to time :). In fact, it was his book "That Makes Me Sick" that prompted me to apply the techniques to testing and to testers in general, starting with me. After writing the article, I realized that there was one other great danger that needs to be addressed, but wasn't included in the original article. I'm hoping to expand on it and maybe make another presentation for Issue #6 (hint; the three danger signs I originally talk about are stupidity (I rephrased it as "ignorance"), laziness and apathy. The fourth, I firmly believe, is distraction. I'll be expanding on that idea, be sure about it... as soon as I finish up everything else I need to (LOL!) ).

Again, my thanks to everyone over this past year and a half who have made TESTHEAD a regular reading stop. I was quite surprised to see how many page hits and reads there were when I was away at Scout Camp. Though not a huge number, for a niche subject matter like software testing, it was amazing to see how many people took the time to come and read my blog during the ten days I was nowhere near a computer. I really appreciate the word of mouth and people who have linked to my site, included me in their blog roll, and otherwise help me spread the word about TESTHEAD. You are the reason I'm getting the opportunity to write in other venues, and hopefully spread my message of continuous learning, overcoming obstacles, and hopefully not taking ourselves too seriously. I really am grateful!

The Dangers of Age, Ignorange & Arrogance: Lessons from Scout Camp

OK, it's been ten days since I've written anything. I've been away at Scout Camp with very limited email and Internet access (which feels really funny to say; up until two years ago I'd never had email or Internet at a Scout Camp, but I guess the times they are a changing :) ).

Some of the most humbling and compelling lessons that I can take into my daily testing walk often come to me in Scout Camp experiences, and this week was no exception. Without naming names, I learned a parallel that I can apply to my testing, and maybe you can to.

Let me set the stage... me and three additional adult leaders spent July 2nd through July 9th shepherding around and tracking 17 boys between the ages of 11 and 15 at Camp Hi Sierra in the middle Sierra Nevada mountains. Camp Hi Sierra is located about 30 miles east of the town of Sonora, at roughly 5300 feet of elevation. Our Troop is in San Bruno, CA which is at sea level. There are some realities that come with spending a week away from air conditioning, regular beds, and standard modern conveniences, and we actively encourage the boys to do things that will make them the most comfortable and function effectively. These are simple things like "drink lots of water (and if you think you are drinking enough, drink more, because you are not), wear plenty of insect repellent, and make sure to stretch and keep yourself limber, because it's easy to get injured in the mountains when you are not used to the elevation".

Every year, we have boys that come up with us who are newcomers to Scouting and Scout Camp. Often those newcomers are 11 year olds, and often they are older. You'd think that the ones who would be most susceptible to not listening to what they are told and who would get in trouble would be the younger inexperienced scouts. My experience over 18 years has proven this is not so. In fact, it is usually the older, inexperienced scouts that get themselves into trouble.

In the past several years, most of the injuries we have had to treat have been with boys 14 and older who have little to no experience with Scouting or camping. The younger scouts, when we tell them to do something, are pretty compliant and do what we ask them to. The older scouts, not so much. They think they have a handle on things, and that they know what they are doing, even when often, they don't. There's a macho component at play here. The older boys often don't want to admit that they are inexperienced, and consider it shameful to have to be at the level of an 11 year old who's never been on a camp out before, let alone away at Summer Camp. So invariably, these are the ones who say they are drinking enough water, but aren't. These are the ones who say they are putting on sufficient sun block and insect repellent, but aren't. These are the ones that say they are doing what they need to do to keep limber and stretched, but again, aren't. They know what they need to do. They are smarter than their adult leaders, and anyway, give it a rest guys, we're fine!

Well, for one of those boys, this act of "we're fine" led to chronic fatigue, dehydration, a multitude of insect bites, and back spasms so bad that we had to call an ambulance and have him taken to Sonora Regional Medical Center, and have his father come up and take him home six days into camp. He missed the last day of camp, missed the chance to complete two of his merit badges, and missed the opportunity to participate in camp wide games, the closing campfire and all of the other fun things that go with the closing days of Summer Camp. Fortunately, I saw him at our Troop meeting last night, looking much better, in brighter spirits, and a little more humble and teachable. He'd seen first hand that his attitude of being older, and how the combination of Ignorance and Arrogance, had worked against him. I think he'll be much more willing to learn from his leaders now, and quite possibly the younger scouts in his Troop as well.

I promised a testing tie in, so here it is. I find it rare that a junior tester or a young tester exhibits the combination of Ignorance and Arrogance. Ignorance, yes, but they understand they are ignorant, and are willing and looking forward to curing that issue as quickly and as effectively as they can. In truth, they are not the ones we should be worried about. It's the longer tenured, supposedly more experienced testers that are the ones in real danger. We often act as though we are above it all, that we've put our time in just by virtue of being in the industry. We often fail to realize that our skill set is based on the context of which we are used to working. Tools that work in one place do not often work in others, and we are occasionally blindsided by the fact that, what we though were skills that would serve us always, in all situations, often don't. We find ourselves (often in clutch situations) the equivalent of the sunburned, bug bitten, dehydrated and muscle spasming scout, unable to be effective when we most need to (and often really want to be).

So today, I encourage everyone to stop and look at their current surroundings. Get a feeling for what your testing environment and kit needs to be, not just what you and your experience think it ought to be. Confer with a mentor to make sure that you really understand the tools that you should be using, and don't be embarrassed that, just because you are a seasoned vet, that you may have a lot to learn. Also, don't be embarrassed that the role models and examples you may learn from may be those junior testers who have heeded the call and have worked hard to be current and focused on current ideas and approaches. By doing so, we all can make sure that our Age, Ignorance and Arrogance don't conspire to bring us to our knees, but can be mitigate and even transcended as we get better at the core things we need to be instinctively good at.

Going Dark for a Week... Maybe :)

For those who follow this blog, I'm about to embark of what is often an entertaining and exciting journey. For one week, I take off my tester's hat and I put on my team leader's hat, most specifically my Scoutmaster's hat. Yep, it's time for Summer Camp, a time of merit badges, canoeing, hiking, rock climbing, swimming, wilderness survival, nature and all those other things that a technologically driven life tend to shield us from.

Generally, these trips have been "internet free" but the last few years, even these wilderness outposts have made concessions to the wired world. It's possible that I may have internet access at Cam Hi Sierra, but if I don't I'm sure I'll survive somehow :).

Here's wishing everyone a great weekend, a great Independence Day celebration to my friends in the U.S.A., and a great week overall to all of my testing friends out there.

Be excellent to each other!

PODCAST FRIDAY: Performance, Old Tools, and "Death Throes"

Well, this was a relatively quiet week as far as podcasts go, but while it was quiet on some fronts, a big delivery came this week that I am  really excited about, and maybe some of you out there might be as well.

First, this week, Matt sits down with Scott Barber to discuss Performance testing and what lead Scott Barber to choose that path. Scott is probably one of the foremost voices on  performance testing... well, to me in any event. Any time I think of performance testing, Scott's name and image tend to show up strongly in my mind. This is the first of a two part interview, so if you'd like to listen to Part 1, it's right here :).

Second this week is a bit of retro weirdness with Merlin and Dan over at "Back to Work". In "My Baby Likes Aluminum Foil!", Merlin and Dan take a stroll down memory lane and all of the tools and apps that we used to use in the 90's and some of which still exist in some form or another today. It's not one of the strongest BTW to date, but it's a fun addition anyway, especially if you are into Merlin and Dan's quirky senses of humor (which I assuredly am).

Finally, this is really and truly the "Holy Grail" of podcasting to me, and since this is such a huge and epic delivery, I have to make mention of it. If anyone has followed my blog for long, you know that my "podcasting hero" and archetype for what I consider to be great quality podcasting is Dan Carlin. Well, this week, he delivered something huge, something amazing, and something I'm surprised hasn't driven him stir crazy at this point. "Death Throws of the Republic, Part VI". Now, to call this a "podcast" is a bit unusual. First, it is an astounding five and a half hours. Why? Because when Dan started this story, he thought there might be two or three shows worth of material, but each time he uncovered one area, another would come to light, and another and another. It was looking like "Hardcore History" would be come the "Fall of the Roman Republic" channel forever, so he decided to end the series with one massive episode, and massive it is. It's also amazingly riveting. While I can't say I listened to the whole thing at one sitting, I listened to most of it at one sitting. Yeah gang, Dan's that good! When I talk about what I want my podcasts to ultimately be... Dan is the gold standard. Why history for testers? I figure there might be a few arm-chair history geeks like me out there, and history often helps us make up heuristics as to how we see the world and how we test the world around us for "what works and what doesn't". I think it's a really valuable skill for a tester to have, a sense of history and knowing what came before and why.

Next week I will be out of the loop. I'll be up at Summer Camp with my Scout Troop. Internet connectivity may exist, or it may not, so if you don't hear from me for a week, well, now you know why :). Have a great week everyone, and a happy 4th of July for those in the U.S. celebrating it.