The Power of "Social Fabric"

Nine years ago, in April of 2003, I found myself at a formidable crossroads. The economy was sour (in many ways, even more sour than right now). This was the crater of the dot-com bubble burst, a time where I had gone from being highly sought after to practically unemployable. I tried all of the job sites, went through a number of interviews, tried all of the tricks that the headhunters presented, only to come up empty handed each time.

Fortunately, I had something that many of my peers at the time didn't have, a large cache of stock equity that I could call on to help through this period. Though it was only about 30% of its peak value, it was still enough that I and my family could go several years if necessary without my having to work. I figured that the time would be well spent to finish my university education, since one of the biggest hurdles was the lack of a university degree.

Two years later, I came out the other side of that experience (along with doing contract work for a game company to help slow down the burn rate of my life savings). I started working again, and for six years plowed along as I always had. I plugged along with the idea that what I know was the most important aspect, and that having that "shiny sheepskin" would solve all of my problems. I also decided that I would position myself in a different way. Instead of being another easy to replace cog, I would focus my attention and energies to being a standalone cog, one that had a broad range of experiences and could "do anything"... for some definition of "anything".

What was missing from all of this endeavor and effort was something fundamental. I was doing most of this in a vacuum. Maybe I read something someplace occasionally, or I searched online for some ideas, but in most cases, I just plugged along. Just me, myself and I. Isolated. Alone. For someone who had spent much of his career in technologies like inter-networking, virtualization, video games and distributed data systems, as well as having a lot of interaction with newsgroups, message boards and social sites (Friendster, Myspace, Facebook, Diaspora, Quora, etc.), I seemed to be enjoying the medium but missing the salient point. You're being superficially social... why aren't you doing it for your work?

That all changed in March of 2010, when I started TESTHEAD. It was my goal and my wish to be a part of the conversation, not just listen from afar and not contribute anything. Stepping into that role necessitated a change. It meant I had to come face to face with some things I didn't like.

I had to admit I might be wrong.
I had to admit I might be ignorant.
I had to admit I might not be as good as I always led myself to believe I was.

For many, that's a scary proposition. For ME, it was terrifying. It was also liberating, because I could now admit to my failings and weaknesses, and I could also identify my strengths. Opening myself up to this conversation let me meet people, experiment with opportunities, and dive into a broad range of endeavors. Some of them worked the first time out. Some I had to work aggressively at. Some opportunities dried up on the vine before we could make any real headway, but all of them put me in touch with amazing people, people who recognized what I wanted to do and often could help me do it.

At the end of October 2010, I was contacted by a friend that I used to work with who had seen all of my talk and evangelism about testing, and through subsequent conversations, I moved over to Sidereel and started a grand adventure. I enjoyed the product. I enjoyed the people. I enjoyed the culture of the team... mostly. There were some areas I started to realize that I was not being as effective as I had envisioned. Part of this has to do with the large number of moving parts I had to be aware of and come up to speed on. Part of this was the fact that a lot of automation needed to be done and I'd be expected to come up to speed on that, too. Part of this was a large site with four million unique users and anywhere from one million to two million unique views per day, not to mentions tens of thousands of shows, hundred of thousands of episodes (if not millions) and definitely millions of links. With one tester to test them all (well, as I said yesterday, one primary, dedicated tester).

Through several months, I worked hard at learning, getting opportunities to speak, write papers, make guest blog posts, present at conferences, teach classes, develop curriculum for the SummerQAmp initiative, and conduct and facilitate Weekend Testing events. I found myself thinking a great deal about the time I was spending on all of these initiatives. Why was I doing this? Why was I so animated about them? I realized that there was a common thread... it was my way of reaching out and having real, legitimate conversations about testing. More to the point, it was giving me an outlet to interact with other testers in a meaningful way, because in my everyday work world, I was not getting that interaction.

Because of this, I decided to reach out to a handful of people, mostly in the Bay Area, and ask a simple question; was there anyone who knew of a software testing team looking for a veteran tester? I was inquiring simply because, if I was going to make a move, part of it would be with the understanding that I was hanging up my "Lone Tester" status, and actively looking for a team. That team could be two people, including me, but hey, even one more tester makes for a better team than always going it alone. I expected to hear nothing more than "hey, we'll let you know if anything comes up".

As you might guess, that was not at all what happened.

Within 20 minutes of sending that BCC'd message, I received half a dozen replies, each of them effectively saying "You're available?! Call me!!!" Each had a line on an opportunity for a team that was looking, often their own teams. I was floored! I could have never imagined so many would be willing to go to bat for me. What was different this time?

The difference, one hundred percent, was the social fabric, and not just a superficial social fabric, but one I weaved and worked on every single day for close to three years. While I was terrified about putting my ideas out there and sharing my ignorance, I also realized that I was showing people a number of additional and valuable things:

It was OK to be human.
It was OK not to be a machine with 100% recall and perfect execution in all things.
I was OK with being shown I was wrong and learning from it, and improving on what I learned.
I was OK with giving talks where I shared both my fortunate successes and spectacular disasters.

People heard them, they critiqued them, they gave me new avenues to explore, and I wrote about them. I presented them as weekend testing sessions. I wrote articles talking about successes, failures and frustrations. I blogged... oh, how I blogged! Each of these things alone may not seem like very much, but when taken together, over three years, they tell a story of a tester who sought ways to engage the community and to be a part of it. Because of that, when it came time for me to consider another direction, there were many people willing and focused on helping me make that next step.

We talk a lot about social connections and having that "professional network", but if the professional network is just a list of names that you don't interact with or actually do something with, then that's all it will be when you have need to contact them. These were not just random names. They were people I had interacted with directly, done community work with, shared a stage or a classroom, collaborated on articles with, developed course materials with, or had seen me give talks or presentations in various places. In short, the people who answered my call didn't just know me, they knew my work, they knew my commitment, and they knew what I'd be willing to do with all my mind, might and passion (and much of the time, for zero payment).

Ultimately, I chose to go to work with SocialText in Palo Alto for a number of reasons. First, it's a testing team, where I can leverage off of the strengths of a number of testers, not just rely on my own. I'm also greatly looking forward to working with their Quality Director, as he's someone I've come to know and respect over the past two years. Most important, he understand the weird and wild world of software testers, especially hyper engaged software testers. My predecessors at SocialText are Chris McMahon and Matt Heusser... yes, that  Chris McMahon and that Matt Heusser :)! To say I have immense shoes to fill is an understatement. That prospect somewhat terrifies me, but it's also really exciting!

To those who wonder if the power of social ties is the real determining factor as to where you work and who helps get you there, the answer is an unequivocal yes! The old phrase of "it's not what you know, it's who you know" is partially true, but it should really be phrased "it's what you know, and if you can get people you know to enthusiastically back the fact that you know it", well, that can make a world of difference. Would all of these people have reached out to me had I not done all of these endeavors over the past three years? It's doubtful, but then, I'll never know... because had I not been hyper engaged in all of these endeavors, I would have never met any of them. That's the power of the social fabric. It's not in having a name, or in having a resume. It's in pushing your limits so that others can see you doing it, and persevering and learning, and sharing opportunities with others. The added dividend was the fact that people saw what I do, and what motivates me, and they decided "You know what? This could be interesting!" To which I say "you are right, and thank you for giving me a shot at another most excellent adventure."

TESTHEAD REDUX: Testing's "Lone Gunfighters"

Image URL: The Old Gunfighter

As I was first trying to design TESTHEAD and figure out what would be the core point, I played with a lot of different ideas. What could I really offer to the community? What would be my niche? What could I speak to differently than anyone else out there? There were a lot of us talking about changes to how we test, to looking at Agile practices, to integrating development and testing, and touching on testing automation, but I wasn't seeing the way I could add any kind of a fresh voice to those discussions. About a week in, though, I came across what was, really, the one thing that I could speak to very directly, and in a lot of different ways. That topic was what it feels like to be the sole tester in an organization.

Before I standardized on the term "The Lone Tester" (yep, it kinda' sounds like The Lone Ranger, so I ultimately went with that slightly poetic moniker) I played with lots of different terms and names. Regardless of what I called myself, though, the reality was the same. For all practical purposes, I was alone in my testing efforts. How did that shape me then? How does it shape me now?

THEN:

When the situation of the “Lone Gunfighter” happens, testing takes on an interesting hue. Now, it’s all on you, and when you are the last line of defense, you really are all there is between the product getting out into the wild and bad things potentially happening. Sobering is a good word for this situation.

NOW:

I'd say the big difference between then and now is the fact that, for all intents and purposes, I've put down the cudgel of "it's all on me". It may seem that way, but it's really not. In an Agile organization, there are other people testing, not just me. My role is that of the sole person whose primary responsibility is testing. For everyone else, it's a peripheral activity, but I've stopped believing that I'm the only one actively testing in the organization. What's more, I've dropped the conceit that I'm the only one qualified to test. That's an insult to the programmers, who to be honest can do quite solid testing, and think of things I don't.

THEN:

Many times, we can feel like we have no direction, or that we are being barked at to get this or that accomplished, with little to no support from others. By putting yourself into the mode of consultant, you change the relationship. Now you are providing a service to a customer, and in this case, the development team and the ones purchasing or using the product are your customers. When the development team becomes a customer and your goal is to provide top notch service to that costumer, your entire mindset and focus changes.

NOW:

I still see a lot of truth in that mindset, more so than I did when I first wrote about it, because in many ways, in the organizations I've been part of, I've often been held apart from the programming team. I'm not entirely sure if that was by design or by circumstance, but there is a sense that there are a lot of people who believe that testing should not become too "chummy" with the programmers. By being held as separate, like a service provider to the team, that "respectful distance" is maintained. Again, I've heard that many have gone beyond that relationship and have had a more casual connection, but that hasn't quite been my experience. Not yet anyway :).

THEN:

Make sure that you define your role as clearly as possible, and what you feel the expectations for your contribution should be, and let them say what they feel it should be as well. This agreement may be formal and in writing, or it may be something discussed in meetings or between team mates. Either way, get it out there so everyone knows the expectation and can work to meet or exceed it.

NOW:

I agree with this more now than I did then. This can doom you if you get it wrong, or be your biggest ally if you get it right.What's also important is to regularly revisit this topic. Situations change, and different people have different opinions and attitudes. I had a period where I had three directors and all three directors had a different idea what my contribution should be. That's totally OK, but it also reinforces why it's important to consistently get those who you are working with to come to a consensus as to what your role and contribution should be, and what the team actually values. One director thought that my developing technical chops and programming skills would be the best use of my time. Another thought exploratory testing was of much higher priority. Both are valuable, both are important, but different people put different weight on certain things. Knowing that and working with that in mind can be a big help.

THEN:

Get over the us vs. them mentality: If you have no idea what this means, congratulations, you work at a company that “gets it”. If you are all too familiar with this mentality, make the first steps to change that dynamic. Testing and development are allies, they both have the same goal, to ship a product that has high quality and that will meet the needs of its customers. No other attitude is going to help that other than development and testing working together to help solve problems.

NOW:

Nothing to add to it, I believe this 100%, now and then.

THEN:

Accept that you will not be an expert in everything: You will have knowledge gaps, and at times those gaps will be huge, but you have to make a clear assessment of your strengths and weaknesses and put them out there. Yes, make them known, the strengths and the weaknesses. Also, make a game plan to overcome those weaknesses where possible and telegraph the fact that you are working to close those gaps.

NOW:

How ironic that I was talking then about my knowledge gaps, only to step into an environment where there were ten times more moving parts! Again, a Lone Tester will not know everything, they will not be able to be all things to all people on the team, unless they are an especially rare kind of superhero. I'm not that person.  That need not be a barrier to success, but it needs to be addressed seriously and honestly. If you have big goals of making huge strides in a particular domain, know you will have to devote a substantial amount of "private time" to make that happen (meaning off the clock). On the clock, don't be surprised if you find yourself juggling five balls at once, all day, every day.

THEN:

When you are Lone Gunfighter, you may be able to find someone who can help you in the development group, but often they may have limitations as well (especially around testing questions and issues). Reach out to other testers you have worked with and ask questions. I still have mentoring relationships with friends who were instrumental in my development over the past 20 years, and I also occasionally get asked questions as to something I have experience in. I believe it’s important to have a mentor and to be a mentor, so look for opportunities where this can be utilized. 

NOW:

Twitter and the testing blogosphere is the single biggest resource of ideas, inspiration, cheer-leading, coaching and mentoring that a Lone tester could hope for. I follow around 400 people that are involved with testing or are thought leaders in software testing and software development. So many breakthroughs with ideas and approaches have happened through discussions that take place on Twitter (especially those that I just read between other testers) that I feel I can go there and be "spiritually fed" daily. That's not a saccharine sentiment, I actually mean that. I'm amazed at the discussions and insights I have learned from other testers all over the world.


Post Script:

The irony to writing this update is that, as of last Friday, November 9, 2012, I made a decision to, for now, hang up my Lone Tester status. That will deserve a much more detailed blog post, and I will be writing that soon enough. Many of the thrills of that line of testing are also many of its more draining challenges, and for me personally, some of my reflections on these ideas and the way that things have been for the past decade has made me desire the interaction of a testing team, where I can interact with and bounce ideas off of other testers. Not just testers in the Twitter/blogoshere world, but testers I'm sitting with, interacting with, mentoring and being mentored by them. To that end, I'll be starting a new adventure with SocialText on Monday, November 19, 2012.

#Agilistry or #PNSQC: Come Hear Me Speak!

This is a little self serving, but hey, I did the work for the papers and presentations to develop the topic, I want to have people hear it. That's not too much to ask, is it :)?

Next Thursday, September 27th, 2012, I will be giving a talk at Agilistry Studio in Pleasanton, CA on "Getting the Balance Right". This is an extension and follow-up/reboot of the talk I gave at CAST 2012 in San Jose.

This talk is being sponsored by the Agilistry Meet-Up Group, and there's still a spot available, so if you would like to attend, go and do your Meetup magic and come by :).

Some may be saying "that's great, but I won't be in the Bay Area on the 27th". Well, for those of you who will be attending PNSQC in Portland, Oregon October 8-10, 2012, you'll get a chance to hear me deliver this talk there, too, albeit in a modified format.

I am confirmed to be one of the presenters during the Poster Paper presentations, so I'll be delivering an "evevator pitch" of these ideas plus examples based on questions and feedback. Consider the Agilistry talk the full presentation, and the PNSQC talk a more tailored and dynamic presentation that I'll be delivering several times. There's also a chance that I may be able to deliver the full talk at PNSQC; we'll see how the final schedule shakes out.

Also, I will be participating in PNSQC's "Birds of a Feather" talk series on Monday afternoon about testing challenges and specifically how Miagi-do uses them to help develop and mentor testers, and how you can use the same techniques when creating test mentoring for your team (formally) or to improve and develop your own craft along with a few friends.

Hope to see you there, whichever "there" happens to work for you!

Pulling Out of the Shadows

Image from http://douglascootey.com/

The next few paragraphs should be a blinding flash of the obvious.

For those who have followed this blog for any length of time, you will notice and you will know certain things about me. You know I have a high energy level. You know that I am involved in a lot of endeavors, and enjoy those endeavors. You know that I like to write, sometimes a lot. You know that I enjoy investigating various aspects of life and the way things work. You also know that I believe strongly in being an open book about my life, my journey and the challenges that I face. So here goes, and if this is a surprise to anyone, you really aren't paying attention...

I am an adult with Attention Deficit Hyperactivity Disorder (Adult ADHD).

Nope, no self-deprecating humor this time. No jokes about “squirrel” or “shiny” or any of that. I have ADHD, and for the past 27 years, I have done my level best to try to deal with it in a variety of ways. The key point is that, for those 27 years, I have left out one piece of the puzzle, and entirely on purpose… medical treatment, and specifically, medication.

When I was younger, meaning around age 7 or 8, I first went on medication for ADHD. Like many kids in the 70s, I was put on Ritalin (Methylphenidate Hydrochloride) to help keep me under control. It worked amazing well in areas of focus and information retention, as well as getting good grades. What I hated about it was the person it made me; moody, angry, sullen, withdrawn, introverted, and isolated. I hated the latter elements so much that I was willing to do battle against the very benefits it provided. Over three cycles of my school life (elementary school, junior high and then in my first years at college) I used Ritalin. Each time, the same things happened. My grades and performance improved, but I became a raging tool in the process. Ultimately, I decided to just live life without the meds, because I didn’t want to be “that guy”, even if “that guy” could focus and be extremely effective.

Fast forward to today. As a part of playing with “The Hours”, investigating issues such as expectational debt, looking at my time commitments, my energy levels, where I choose to focus my time, and how it ultimately gets distributed, the tester in me decided it was time to do an even deeper dive. Enough with the immediate and superficial; let’s look at the past 20 years of my career! I spelled a lot of that out in my posts about meandering through 20 years of software testing, but I realized there was a lot I was leaving out. Not deliberately, but because I wasn’t willing to face what it meant to examine it at the time. Many of my career choices, the activities I participate in, all of the ups and the downs and the very way that I like to work (as a lone tester), all make sense when you put one phrase in context with all of it: Untreated Adult ADHD.

So what’s made me decide to do something about this now? I have three people indirectly to thank for planting this seed in my head and convincing me to act on it. Those three people are Merlin Mann, Scott Hanselman and Iris Classon. Merlin, as many of you may well realize, figures into lot of the things I talk about, because he’s where I heard about a lot of this stuff first (Expectational Debt deserves to be a service mark of Merlin Mann as far as I’m concerned ;) ). In one of the earlier Back to Work podcasts, he talked very directly and specifically about his own challenges with Adult ADHD and years of not treating it, and finally deciding to treat it. Scott Hanselman, in addition to being a vocal tech pundit, has also been quite vocal about his own challenges and issues with diabetes, and the fact that he’s been willing to put it out there for everyone to see first hand. He said he could have hid it, but why? Finally, it was on Scott’s podcast with Iris and her openly discussing her challenges with ADHD as a child and as an adult that made me decide “there’s no reason for me to hide behind it any more.” Besides, if I do hide behind it, it has to be the world's worst kept secret.

So today, I made the first steps into the fray of this. My primary physician just made the referral to the psychiatry department so that I can get this underway. Am I nervous? A little. At the same time, the tester in me would never forgive myself if I didn’t at least explore this avenue of who I am and if I can do something about it. It may turn out that I’m actually fine, and that I’m making much ado about nothing. If that’s the case, then I’ll have other avenues to explore. If I am diagnosed, there are a lot more varieties of treatment today compared to three decades ago. Also, this time, I’m not the sullen kid resenting the fact that I’m “different”, and wishing beyond hope that I could just make it go away. Instead, I now have the opportunity to actually look at this for what it is, and potentially change how I interact with my own brain. In a way, I’m excited about that. Perhaps there are benefits to being older, wiser and a bit world weary. Because I'm all of those, I’m willing to take it for what it is, and deal with it non-judgmentally, with open consideration as to where the road may lead. Like all good testers should :).

Army of One: The Moment You Know You're Wrong

I had an interesting experience last week. As I was going through what was effectively a monster of a change related to our product, the product owner and I almost got into a shouting match. It wasn't really a shouting match, but there was a ratcheting up of mutual frustration. We felt like we were talking past each other. As I was trying to show what I was doing, the answer back was "no that's not what I mean".


As  I kept trying to clarify the information I was receiving, I felt my frustration levels rise, and I started asking "is there something I'm missing here? Can you tell me where I'm mistaken?" I said this with a little bit more bitter of an edge than I intended, but that's how it came out. I was frustrated, the product owner wasn't making sense, and I was doing what was asked... until I heard one little statement. "Go to your profile page, now do you see the two icons next to the user name? That..." and that's where it all trails off because in that moment, it clicked. All of the confusion melted away. I understood what was being said. What's more, I understood that my design and my approach was wrong. I was so caught up in the thick of the changes and the interface that used them, I had completely forgotten about the legacy manner in which we did the same procedures.

Lone testers and the Army of One have to shuffle a lot of things. We have to juggle a lot of balls at the same time. To that end, communication is vital. When we fail to communicate, or when we get too caught up in the immediacy of our testing, we run the risk of becoming myopic, and losing sight of the bigger picture. The good news is that this was relatively easy to resolve technically. Inter-personally, it required me to step out of the office, get some food, and then politely apologize to the product owner for getting out of hand and not being able to see what they wanted to have me see. We both realized that we were talking past each other, so that was certainly a situation we were able to resolve quickly, have a laugh about it, and get beyond it.

Still, it reminded me that, when I'm on my own and doing the testing on my own, there isn't another tester to confer with and make sure I'm not being dense. I have to watch out for those moments. If I'm alert and ready, they can be handled quickly and carefully. When we don't prepare for them, well, a chat over a plate of humble pie might be in order.

Ask the TESTHEAD

I have an interesting opportunity.


Software Test and Quality Assurance (ST/QA) Magazine runs a feature called "Ask the Tester" where they pick anywhere from 10 to 15 questions and present them to the person selected. They then answer those questions and they become an article in the magazine.

For the May issue, that tester will be me :).

A number of people have asked me various questions already, but I wanted to throw this open to anyone who would be interested in participating. If you would like to ask me a question that has something to do with software testing, please include it as a comment to this message I will then submit the questions to ST/QA and they will pick the ones that they would like to use. If you would like to leave a Name and a City where you are located, I can pass that along as well as part of the question. If you don't leave a name, we'll just include "Name withheld" with the question.

So here's your chance.If you've ever had a question you have ever wanted to ask me (again that's related to software testing ;) ), now's your chance!

Into the Blue Again...

It's amazing to think that 2011 is almost over, and yes, while last year I lamented writing the obligatory "year that was" letters and somewhat lampooned them with my post last year titled "Well, How Did I Get Here?", that post resonated with many people. It is to date my most read and my most commented on article here on TESTHEAD, depending on which metrics you believe.  Based on the response to that post, I decided this year to just let it be known, this is a recap of the World of TESTHEAD, and the world of "Michael Larsen, Tester" for the year of 2011. The title this year is indeed, again, in homage to the seminal 1980 Talking Heads classic "Once in a Lifetime".

2011 was a year of transition for me personally. I took many leaps of faith this year, and as the title says, I willingly jumped into new areas and new responsibilities. Early in the year, I ended my employment with Tracker Corp, bringing to an end six years of learning, camaraderie and a focus on the .NET world of software development and testing. In exchange, I came to Sidereel, and a world of learning, camaraderie and Rails software development. This is telling, because I'd never worked with Rails before, and my involvement with Ruby prior had been from recommendations from co-workers that it would be fun to learn. Well, now it was more than "fun to learn", it was an occupational hazard (and necessity :) ).

With that, I started mapping out and learning a new site, a new programming language, a new model, a new way of storing data, and very different approach to developing software. I was no longer just a tester, I was to integrate with a fully Agile development team and work with and alongside of them. Oh, and I traded in a daily diet of Windows and PC's for a daily diet of Mac OS X and Darwin UNIX all sleekly wrapped in a Macbook Pro. Oh UNIX, how I have missed you!!! There  was just something comforting about leaving behind the world of MSI and EXE files and embracing tools such as ruby gems, homebrew and other options for installing software. Scriptable, customizable, and where Test Driven Development and Continuous Integration were not obscure buzzwords but actual practices that were, well, practiced! It's also been telling, humbling, and intriguing to learn about and use tools like Ruby, RSpec, Cucumber, Capybara, Selenium Web Driver and other areas of automating testing. I can safely say I have written more code this year than I have in the past 17 years prior!

2011 also saw the process of Weekend Testers Americas come into its own. What could have been a few experimental and jerky first few sessions got smoother, cleaner, and better understood, and we had some great successes during the year. While I'm not sure how much others have learned, I know that I learned a great deal from this process. What was great to see was that this initiative was embraced by people all over the world, and our participants reflected this fact, including testers who would come into our sessions at 12:30 AM (yes, after midnight) from India to participate. First off, that's dedication, and my hats off to everyone who did that, but more to the point, it spoke volumes about the service we were offering and the fact that people wanted to come in and participate, even at those insane hours. We had some help from some heavy hitters, too. Michael Bolton and James Bach both came in to guest host some of our sessions ("Domain Testing" and "Creating Testing Charters"), and Jonathan Bach helped me craft one of my breakaway favorite test ideas of this year, that of "Testing Vacations". In all, it was a banner year for Weekend Testing Americas, and I am so thankful for all of the participants that helped make it possible. I'm especially thankful for Albert Gareev, who in addition to being a regular participant, stepped up to become my partner in crime for this enterprise, and frequently helping me develop new ideas or take the process in different directions than I probably would have had I been left to my own devices.

2011 was a year of meeting and developing relationships with other testers. In January, I met Matt Heusser in person for the first time. As many of you know, one of my most involved and enduring professional relationships was with (and continues to be with) Matt. I produce the "This Week in Software Testing" podcast with him. I helped write a chapter for a book he was the principal editor for (more on that in a bit). I also was a sounding board for other ideas and offered several of my own in return. I had a chance to meet my fellow Weekend Testing Compatriots Marlena Compton, Markus Gaertner, and Ajay Balamurugadas in various places. Marlena and I had the pleasure of live blogging the entirety of the Selenium Conference from San Francisco, with our comments getting us branded as the "Table of Trouble" from the other participants. That was a fun memory, and it helped to set the stage for liveblogging other events throughout the year. Geting the chance to meet so many testers during this year in various capacities was a real highlight and much enjoyed aspect.

2011 also saw my commitment to being published. I made a decision that I wanted to write beyond the scope of TESTHEAD. As will probably come as no surprise, my first few articles were Weekend Testing based. However, I had the opportunity to venture into other topics as well, including two cover stories for ST& QA magazine; one being my article about "Being the Lone Tester" and another an excerpt of my chapter from "How to Reduce the Cost of Software Testing".  Speaking of that, 2011 saw me and 20 other authors get our names in print and become book authors. It was a pleasure to have the chance to write a chapter for "how to Reduce the Cost of Software Testing". A later development, one in which I, literally, just got word about and accepted, was a potential new book that discusses "The Best Writing in Software Testing". I have agreed to be a junior editor for this project, and we are aiming for a 2012 release of this title. In addition, I also published articles with sites like Techwell, the Testing Planet and Tea Time With Testers. As of now, I have eleven articles that have been published external to TESTHEAD, and it is my hope that I'll be able to write more in the coming years.

2010 was a first in that I attended my first testing conference. I made the commitment then that 2011 would be the year I would present at a testing conference. I received my opportunity to do exactly that. My first ever conference presentation was just 20 minutes, and it was at CAST 2011. I presented in the "Emerging Topics" track and discussed Stages of Team Development lessons I had learned from Scouting, and how they could apply to Testers. All in all, it went well, and even today, I still hear from people who said they appreciated the topic and liked my presentation. In addition, I also gave another full track session at CAST called Weekend Testing 3-D, where not only did i discuss how to facilitate Weekend Testing style sessions, we actually held a live session with participants from all over the world, and processed it in real time (this was the earlier mentioned "Testing Vacations" session that Jonathan Bach helped me develop. In addition, I proposed a track talk and paper for the Pacific Northwest Software Quality Conference titled "Delivering Quality One Weekend at a Time: Lessons Learned in Weekend Testing" and after writing the paper and  having it reviewed several times, received the nod to present it. However, fate struck, and I broke both bones in my lower leg (tibia and fibula), thus preventing me from delivering the talk (the organizers of PNSQC, however, still included my paper with the proceedings). Additionally, a friend who felt bad that I couldn't present at PNSQC forwarded my paper to Lee Copeland, the organizer of the STAR conferences. Lee liked the paper and asked if I'd be willing to present it at STAREast in April, 2012. I of course said YES! So I will get my chance to present this paper yet :)!

There is  no question that I learned a great deal from the TWiST podcast, both as a producer and as an active listener, but 2011 will be even more memorable in that I graduated from editing the show and as an occasional guest to being one of a handful of rotating regular contributors on the mic. It's been interesting to have people email me and say "hey, I heard your interview last week, that was a great show and a great topic, thanks for your comments and explanations". I thought it was especially cool when I had someone say that they felt that I'd make a great game show host (LOL!).

2011 saw my continued focus on working with the Miagi-do School of Software Testing. At CAST 2011, a number of us Miagi-do Ka, including Markus Gaertner, Ajay Balamurugadas, and Elena Hauser worked along with Matt Heusser at the CAST testing challenge. During that competition, I had the chance to show Matt and the other testers there what I was able to do, and due to that experience, Ajay, Elena and I were awarded our Black Belts. While the experience itself was great, it also came with the expectation that I be willing to mentor and teach other testers, an opportunity that I have gladly taken on and look forward to doing more of in 2012.

One of my most active projects for the year of 2011 was helping to teach the Black Box Software Testing courses for the Association for Software Testing. I had the opportunity this year to instruct, as either an Assistant or as a Lead Instructor, all three courses offered in the BBST series (Foundation, Bug Advocacy and we just completed the pilot program for Test Design on December 10th). I was in this capacity that I was also nominated to run for the Board of Directors for the Association For Software Testing. I never envisioned myself being a Director of anything, much less an international software testing organization! Still, someone in the organization felt I deserved a shot, and nominated me. What's more, someone else seconded it. Even more amazingly, a lot of people (perhaps many of you readers) thought I'd be a good fit for the position as well, since I was indeed elected to serve on the board. My two year term began in October. While daunting, it is also exciting to think that I may actually help shape the future of this organization in the coming years, and to help represent my fellow testers. Believe me, it's not something I take lightly.

Quite possibly the biggest "Into the Blue Again" moment of the year, though, happened at our first AST board meeting in October. It was at that meeting that Cem Kaner and Becky Fiedler announced their desire to have someone take over as the Chairman of Education Special Interest Group. While a part of me felt I was wholly inadequate for the task, another part of me felt that this was something essential and that it needed someone to spearhead it so that the education opportunities within the organization could be championed and further developed, while allowing Cem and Becky the opportunity to do what they really wanted to do, which was develop more and better testing courses. With that, I offered to chair the Education Special Interest Group. I'm not sure what was more surprising, the fact that I offered, or that the rest of the board took me up on it! Two years ago, Cem Kaner was a man whose books I had read and whose presence loomed large as a "testing guru" on high. The thought I would ever meet him seemed remote. The thought I'd actually take over for him and spearhead an initiative he championed never even crossed my mind!!! Still, that's what has happened, and I guess 2012 and beyond will tell us what I actually did with it. I'm hoping, and working towards doing, all I can to prove worthy and up to the task.

2011 was, really, a year where I took leaps of faith, lots of them, and discovered that I could do even more than I ever imagined I could. I've shared may of those journeys in TESTHEAD posts, and I thank each and every one of you who are actively reading this blog for your help in motivating me to take these leaps of faith. It's been another banner year for me, both in learning and opportunities. Overall, the experiences of the past year have given me confirmation that, if I were to jump "Into the Bue Again", that it would be a great chance to learn and grow, regardless of whether or not the outcome were necessarily successful, lucrative or advantageous. Granted, most of them have been, and those that haven't been, well, I'd like to think I failed quickly and early enough to learn from those experiences and correct my trajectory. Time will tell if that's true, of course. As in all things, there were many people that helped make 2011 a banner year for me.


Thanking a bunch of people is always fraught with danger, because invariably someone gets left out, and there have been hundreds of people who have been instrumental in making this a banner year for me. Still, there are many that stand out, so to that, my heartfelt thanks to Adam Yuret, Ajay Balamurugadas, Albert Gareev, Alex Forbes, Anne-Marie Charrett, Ashley Wilson, Becky Fiedler, Benjamin Yaroch, Bill Gilmore, Cem Kaner, James Bach, Janette Rovansek, Jason Huggins, Jon Bach, Lalitkumar Bhamare, Lee Copeland, Lynn McKee, Markus Gaertner, Marlena Compton,  Matt Heusser, Orian Auld, Rick Baucom, Selena Delesie, Shmuel Gershon,  Terri Moore,  Thomas Ponnet, Timothy Coulter, Will Usher and Zach Larson. Thank you all for helping me make those leaps of faith. More to the point, thank you for having the faith in me that I'd be able to actually do what you believed I could do! Thank you for what has honestly been, at least as far as software testing is concerned, my greatest year (and remember, last year was pretty awesome, too. I didn't think I'd be able to top that!).

Here's to an every bit as exciting and fun-filled 2012. I'm looking forward to seeing where I might leap next :).

Don't Rely on Your "Future Self"

For those who are familiar with my Personal Blog (mostly inactive now that I spend most of my writing time on TESTHEAD), I have a number of posts related to handling money and avoiding debt. I avoid debt for many reasons, but the biggest reason is that I do not trust the entity that I call my "Future Self".

My Future Self is implicit in any arrangement I make. Of course, I have only the best of intentions with My Future Self (I don't think any of us want to consider we will be slothful or shiftless or unreliable). Still, the truth is, My Future Self is just not as reliable and as pliant as I want him to be, and this gets more obvious the further out I look. Sorry for bringing this up again, but this point was really drilled home to me this summer. I had lots of plans that related to getting in shape so that I could consider making a shot at a "Legend's" division competitive run in the United States of America Snowboarding Association South Lake Tahoe Series once again (it has been several years since I competed, and I had high hopes I'd be able to get back on that horse again). Well, my bone breaks scuttled that plan thoroughly, certainly for this year. Imagine if I had bought a season pass and new gear with the hope I would be competing this winter! I would have made those purchases based on a Future Self that never materialized (and could not materialize).


When I take out debt (financial, technical, or other nature) I am, likewise, putting My Future Self on the hook to take care of it. In all cases, this involves interest (whether it's codified as an interest rate or not, any decision put off until later costs in extra money, extra effort, or extra emotions, bet on it). When I was younger, especially, I was much more willing to spend and pay later. I had the attitude of "So what, it's only money, I can always make more!" Well, yes and no. With small amounts, it's true, but did I really want to tie myself down to potentially a lot of work and effort later on for an experience or a memory that may not even be relevant those months, or years, later?


I have a back log of books that I have to read. Yes, have to, because I made a verbal agreement to review them. Many of them have been provided to me for free, and therefore, I have made a "gentlemen's agreement" to work through them. Thus, I have made sure that My Future Self must put aside the time to read, work, ponder and reason his way through them. If he does not, then he goes back on his word. That is something I do not want to see My Future Self (or My Current Self, frankly) ever have to do. No matter how I look at it, this is time I must spend on a verbal commitment. Of course, I believe this will be beneficial, a good investment both in the way of knowledge and experience, and I will have an additional artifact for others to look at and decide if they will consider it worth their time to read for themselves. Still, it's a process that depends on me carving out time to do it, and often, it feels like that time is harder and harder to come by.


In some ways, I think that "time debt" is the most dangerous of debts, even more so than monetary or technical debt (they are all intertwined, of course). This is, I'm sure, sounding ironic coming from me, someone who prides himself on being "frequently busy" engaged in many endeavors. It's one thing to be doing a lot of stuff. It's quite another to put ourselves into a time debt that we will never be able to effectively manage or eliminate. Additionally, there's no way to bank, stretch or ration time. You can't save up time to use on a rainy day; everyone gets the same 84,600 seconds; 1,400 minutes; and 24 hours as everyone else. Time can only be used, and any time we decide to do one thing, we are deciding not to do something else... and really, get the thought of "multi-tasking" out of your head. I do not believe humans can do it effectively. Even super fast computers don't actually multitask; they split their attention among a large number of processes and cycle through them. It's an illusion, and an expensive one when scaled out to a human life.


Consider this my way, both during this end of 2011 and beginning of 2012, to encourage everyone to "honor thy energy" (with thanks and pre-apologies to Merlin Mann ;) ), and please, do what you can to inconvenience and engage Your Present Self as much as possible, and don't overburden Your Future Self. They have enough working against them as it is without our help!

Maintenance Mode

As I was standing with our design director and talking about some of the new features planned in the coming weeks and months, I was excited about the prospects, I was intrigued at what that would mean for me in my testing, but at the same time, I had a sinking feeling... I realized that "Oh no, I have a whole bunch of tests that are going to effectively be broken with these changes".

This is a typical situation. I can count on the fact that I will be doing some tweaks and changes on the sites that I work with, and that my scripts are not going to be evergreen. At the same time, it can be frustrating to have to gut whole sections and retool scripts. These are times when I must admit, I've been tempted to just throw up my hands and say "Gaah, what's the point?!"

Here's where I want to ask the other Lone Testers out there... how do you deal with "Maintenance Mode"? I understand when you are working as a tester and you have the advantage of an automator or an automation team, but what do you do when *you* are the automator, and the exploratory tester, and the regression tester, and the fill in the blank tester? I don't have the opportunity to hand off the maintenance work, and when I do the maintenance work, I'm not testing.

I will say that I do find a lot of the rework options and the ability to create "macros" in the selector.rb file to be very helpful in the maintenance steps. I like this option because I can focus on just making the language of the steps be business rules and say "look for the following", while having all of the individual steps grouped together. the biggest problem with that approach, though, is that I often have to "unfactor my refactoring" and plug in the original group of steps to see what's no longer working.  Don't get me wrong, each time I do this, I learn a little bit more, and I learn which refactored steps are actually effective and durable, and which ones I need to reconsider and, well, refactor the refactoring.

I am serious, though, for those who often find they have to make large scale changes to their scripts, how do you effectively balance your work load and focus so that you can do both, or do you just let everyone know "I can do X, or I can do Y, but if you think I can do X and Y at the same time, you're nuts!" Right now, I'm doing the latter. I'm open to suggestions, seriously :).

Stop Being Invisible

One of the questions that I have been contemplating as of late is “where does testing fit into the overall organization?” I was given a chance to contemplate this recently because of a chance at SideReel. Our Director of Engineering decided to take on another role at another start-up, so we had a period of transition and I now have a new director. This new director asked me this question directly, and we had an interesting discussion because of it.

Unlike our previous director (a guy I like and respect a lot, so do not take this the wrong way), our new director comes from a strong operations and systems administration background. I say that because he was able to verbally describe something I’ve tried to explain to various organizations for years. Testing is nebulous. There are a lot of things that we do that are, for the most part, invisible to those who chase metrics and measurable hard deliverables. He also appreciates the fact that, like systems administrators, no one really notices you when the systems work well, they only know when things are broken, and then you are public enemy number one. This has been a pet peeve of mine for a number of years, and I’m still trying to come to grips with the best way and approach to raise visibility of testing and what we do. Cost containment is good, but raising the visibility on our value is, I think, ultimately better.

As a Lone Tester, I get both ends of the spectrum. I am often unnoticed (even in this small company) when things are moving along as they should, and I definitely get a center spotlight if something gets missed and makes its way out onto the production site (that’s not a complaint mind you, just a direct observation of fact). Be that as it may, what can we do to help raise that visibility? One of the things I do is right here, this blog. It’s a repository of my ideas and musings, not just for my general readers, but for those I work for, too. If you have a testing blog, don’t just have it be an external resource, but share it with your company and let people know what content would be relevant. I put the URL for the Practicum section for my most recent Performance Review, as well as a link to my book reviews and my articles published. Second, if you have a chance to participate in something where you can share your testing ideas with other teammates (even if they are not testers) take that opportunity. It doesn’t have to be elaborate, but even a quick brown bag on Heuristics or Domain Testing and the reasoning behind why we do them can be very eye-opening for a development team.

While I won’t say that we will be able to change perceptions immediately or that some organizations will really much care either way, there are some simple things we all can do to help raise our visibility and the way that we interact with our teams, and they don’t require us creating reams of documents that no one is going to read. They do require a different way of thinking, and perhaps a little showmanship and salesmanship, but with time and a bit of attention, it will be possible to change perceptions to our advantage.

Too Close to the Source?

I received an interesting email today from a reader who highlights something that's a challenge for any blogger. The deal is, you never really know how many errors or typos are in a post until you hit the Publish button. At that point, issues that you thought you proof-read, spell checked and read aloud two or three times come to the surface, and leave you with the feeling that "OK, I look dumb for missing that!"

The contributor made a very good point in their observation, however, and that is the fact that, for many of us who are blog writers, we know what we are writing and why we are writing it. We have a filter that often overrides what we are typing, and our brains fill in the blanks for us. Anyone who has been on Facebook for any period of time has probably seen a status update showing how a jumbled mass of words can be "unscrambled" by our brains and interpreted quickly. The fact is, we miss a lot, especially if we do longer entries. My review of Jerry Weinberg's "Perfect Software" was nine pages; this entry is less than one page. Where are the typos more likely to be? In the longer essays, of course, because we fill in the blanks more readily.

Remember how I said that I don't blog to show how good I am at something, but rather, I blog because I know deep down I'm actually pretty bad at it? I also do it to remind myself that sometimes a tester cannot be their own tester when they are reviewing their own code. Not only are they often *way* too critical of what they are doing and overcompensate and over-edit themselves, but they often miss things that are plain as day to someone who casually reads their posts.

One of the challenges and frustrations is the fact that I like to edit in a plain text editor because it's fast to take down notes in. If I import it into Word to do a spell check, sometimes it picks up obvious typos, but it doesn't pick up when I've made an entry and it auto-corrects the entry for me and chooses the wrong word. Well, just correct it. When I catch it, I do. It's when I don't that it's embarrassing.

Another technique I use is the "read aloud" method. This is when I stop and read through my post as though I were giving it as a talk. Honestly, I find lots of issues when I do this, but even with this technique, I miss things. It covers a lot of stuff and helps me find things where when i say it, I think "Now wait a minute, that's not right", but every once in awhile a word will just jump through and I'll miss it.

They say you never get a second chance to make a first impression, and I have to remind myself that many people who read my blog may be thinking to themselves "wow, a tester who doesn't even proof his posts... LAME!" The truth is, it's not that I don't proof them, it's the things that I miss when I do proof them, which I guess adds up to DOUBLE LAME!!! Be that as it may, the point is, I am oftentimes too close to my subject and I suffer at times from "blue room" syndrome. It's a condition where people who edit audio for extended periods get so caught up in the small fixes and tweaks that they don't even know what they are listening to any longer. The context has been removed. The same is true when we write. We think we're doing thorough review, but we're so down in the soil with the seeds that we're missing the flowers overhead and the weeds right next to us.

None of this is asking anyone to cut me slack. I'm writing this as a reminder to myself, and a warning to others. As an Army of One, I don't really have a reviewer or anyone who can review these on a schedule that's realistic, so I'm left with my own wits and the kindness of strangers. This is my way of saying "if you see me doing something boneheaded, please let me know." I won't take it personally, in fact, you'd be helping me open my eyes to something I've missed. Testers testing testers... it's a beautiful thing :).

Blocked on [X]? Then Do [X]!

So today I reach the end of the experiment with is the book club review of 'How to Reduce the Cost of Software Testing" 21 posts in 21 days. On top of that, I decided I didn't want to just be a total one-trick pony for three weeks, so I committed to writing an additional blog post each of those 21 days.

An interesting thing happened. Was each of those extra blog posts a winner? Nope, but then blogging is often hit and miss. You never really know which posts will grab people's attention, but you can sometimes guess. At first I feared I'd run out of stuff to talk about, but somehow I was able to come up with something, and often enough somethings to actually get a few days ahead and schedule several posts. It's a testament to Jerry Weinberg's idea of Fieldstone gathering; stuff is all around us, we just have to have the eyes to look and then follow through with the energy to pick the stones up to use them.

I often find it more difficult to write when I've taken a few days away from the blog. Then, unless I am finding myself dealing with a timed topic (a class, a meet-up, a podcast or something that needs to be talked about that day), it can be a real struggle coming up with something to write about. Lesson from the last three weeks is that you don't see stones when you aren't looking for them. Likewise, you don't see topics and ideas for those topics unless you are actually writing.

This also applies to my struggles with coding. I sound like such a  broken record here, but again, I need to remind people that I am not writing about coding and tech writing because I'm really good at it, I write about it because in reality I'm rather mediocre or exceptionally bad at it. However, the writing about it gives me an avenue to explore it in a different way when my brain is telling me "OK, dude, really, I've kind of had it with the (Cucumber, Ruby, Rspec, JavaScript, CSS3, fill in the blank)". It lets me actually see what I know and it gives me more reasons to keep applying what I am learning, even if that learning is terribly slow.

So yes, your painfully optimistic TESTHEAD friend is suggesting that, to fix what is ailing ya', do more of what is ailing ya' :). Thus, you can expect to see more posts about  (Cucumber, Ruby, Rspec, JavaScript, CSS3, fill in the blank) in the near future. Bet on it :).

Being a Human Test Case

As I write this, I am sitting in the waiting area at San Francisco International Airport. I'm waiting for my flight to be ready to board to go to Madison, Wisconsin, where I will be participating in the Association for Software Testings board meeting, and officially get sworn in as one of the Board of Directors and take on my role as the organizations Treasurer.

That's all well and good, but that's not the point of my post this afternoon. Instead, I wanted to share my experience of being a human test case. For sake of context for those who read this weeks or months later, I have a broken leg with a titanium plate helping hold it together. Thus I knew I'd be a piece of entertainment for the security detail today.

I arrived early enough so that I would have time to get through the line. Turns out that if you are gimpy like me, there's a special line to go through. Much faster, but that may also be because they know I'm a guaranteed fail. I offloaded all my stuff, emptied my pockets took of my shoe but left on my boot. Net result, no big surprise, I lit up the metal detector and went over to the special area to receive an advanced screening. While I was there, I started taking of my boot. The security detail looked at me like i was nuts. I was actually asked why I was taking it of, and I said, well, because I can, and I have a titanium plate in my leg, and a simple wave of a wand will tell you that. I was being helpful... maybe too helpful (LOL!). In any event, I was screened much more thoroughly and then when everything was shown to be in order, they let me retrieve my things and go on my way.

Now here's the interesting thing... that portable metal detector they could have waved over my leg to verify the metal detector went off because of the titanium in my leg? They never checked. Part of me was walking around with a bit of smug superiority, thinking "silly security people, a wave of a wand over my leg would have shown what caused the alarm to go off", but as I was thinking that, I realized that, really, I may not even be thinking on the same wavelength as they are. People with medical conditions probably come through all of the time (hip replacements, knee replacements) with considerably more metal in their bodies than I have, so they might look at the gimpy man as being a Trojan Horse. Identify the obvious issue (the titanium in the leg) but somehow ignore something else (like a hypothetical switchblade or a pack of C4 inside of the boot). Note, I have no idea what their objectives were, and I didn't stop to ask (they were plenty busy), but it was amusing to contemplate.

As I'm often fond of saying, testing is all around us, and if your not careful... you just might miss it. Actually, I think that's a bastardization of something Ferris Bueller said, but still, it's apropos ;). And with that, I hope you have a Happy rest of the Friday afternoon and evening. I have a plane to catch. Here's hoping we talk soon :).

Updated: Landed in Denver with no issues, but really, did the connecting flight have to be on the total other side of the airport? Maybe it's karma for writing this earlier (LOL!).

Some Very Small Cucumber Tips

For those who have been watching my transition from primarily being a manual tester to this generations concept of automated testing (I did a bunch of shell scripting in the 90's and worked with Tcl/Tk as an automation framework for some time. This was before the rage of record and playback tools took over the testing world). Now my world revolves around Cucumber, which uses Ruby to complete the plumbing (at least in my environment, I realize Cucumber is language independent :) ).

Over the past few months, I've been tweaking with it and discovered it can do some cool things, but most important, I think it's important that people realize what Cucumber isn't. Many people will tell you that Cucumber is programming put into plain English (or fill in your favorite language). It's not. In fact without the underlying language plumbing (again, take your pick), the English syntax does absolutely nothing. You have to define every statement that you use. Additionally, every statement has to have coherent code underneath it that ties in with each other statement. So when you see something like this:

    Given I am on the home page
    And I click "Sign Up" within ".login"
    When I fill in "Username" with "<username>"
    And I fill in "Password" with "<password>"
    And I fill in "Confirm password" with "<email>"
    And I fill in "Email" with "<email>"
    And I select "<time_zone>" from "Time Zone"
    And I select "<i_am>" from "I am"
    And I select "<year_of_birth>" from "Year of Birth"
    And I select "<country>" from "Country"
    And I click "Create Account"
    Then I should see "1 error prohibited this user from being saved" within ".errorExplanation"

You have to realize that every one of those statements has an underlying set of Ruby statements that make it coherent. Oh, and for those wondering, what's that stuff in the "<>"? That's syntax you can use with Scenario Outlines, a cool little technique to make tests easier to code if they will be run multiple times with the exact same parameters. The way that you take advantage of it is to make an Examples table:

Examples:
|username|password|email|time_zone|i_am|year_of_birth|Country|
|testname1|mypass12|mytest12@gmail.com|Pacific|male|1979|Canada|


I realize this is probably "blinding flash of the obvious" to some people, but it's little things like this that make me smile and find different ways to use Cucumber that I hadn't immediately considered.

Another neat things that was shown to me was to create a file called selector.rb. By creating this file, you can gather together steps that are frequently run and make one "plain english step". I'm not entirely sure why it's called selector.rb other than to give the user a chance to take their common calls to html elements and simplify their naming. While the ability to do that is cool, what I really like is the ability to chain serial commands like the following:


Given /^I log in to facebook with good credentials$/ do
  And  %Q|I fill in "email" with "myusername@email.com" within "#login_form"|
  And  %Q|I fill in "pass" with "aP@ssw0rd" within "#login_form"|
  And  %Q|I click "Log In" within "#login_form"|


The beauty of the above statement is that I only need to make a line as follows:

Given I log into facebook with good credentials

Note, this isn't a free ride. If you put a bunch of lines into a single line statement. It can be maddening to figure out exactly which line is causing the problem, because the error message will relate to the entire grouping. For that reason, try not to overload your selector.rb file with lots of multi-line statements. It makes for elegant and short looking tests, but the system sill has to parse all of the substitutions and run them. If anything goes wrong in the block, the entire block fails, and so does the rest of the test.

So there ya' go, some master of the obvious stuff, but it's make my testing a lot easier and in some ways a lot more fun :).

My Walk Through "Mordor": Lessons in Automation

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 :).

"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.

Gonna See my Smiling Face on the Cover of ST&QA

Well, OK, not really, but it is a really cool picture of the globe done in silicon trace imagery :). I do, however, get to say that I have a cover story in the May/June 2011 issue of ST&QA magazine, and for that, I'm rather excited. The PDF version of the magazine can be viewed here, and the individual articles have been posted on the Software Test Professionals site.

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 :).

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!

Time Management and the Value of Context

As I was listening to the most recent "Back to Work" podcast this week (that's the one that Dan Benjamin and Merlin Mann do over at 5by5), they discussed the various things that help you find inspiration, and that inspiration, while nice, doesn't really create anything all by itself. it's spending time and attention on things that actually matter that gets you to the point where you are creating great stuff.


During the discussion, they ventured of into understanding what you actually spend your time doing. If you could get a handle on all of the things you do, and were honest with your interaction with them, you would discover a lot about what really matters to you. There's a phrase that gets bandied about a lot that says "you are what you think". I disagree, I think the more appropriate measure is "you are what you do", because your thinking is encapsulated in your actions. I may say or think that I want to be come a solid Ruby programmer (as an example), but when I sit down and see what I spend my days doing, it's clear that programming in Ruby is not high on the list.


What if you could actually see what you do during the day, to the minute and second, and get a granular breakdown of the things you really do the most, and categorize them? Well, there's nothing outside of the brain and a notepad that can do that for you when you are off the computer, but for the time you are actually sitting at the computer, there are ways to do this. the one that Merlin an Dan discussed is a program called RescueTime, and it is set up to monitor all of the things that you do on your computer and break down the activities into categories, with a rough scoring for the activity, ranging from highly productive, productive, neutral, distracting, and very distracting. I installed this program, and decided to run with is default parameters.


Wow, was my report interesting the first time I ran it (LOL!).


According to the system, I did a terrible job. I was very distracted 7 hours out of the day, and according to the system, I should be fired immediately... except that the system in its default state doesn't know me or the context of what I do. Here's the thing... I'm a tester for a company called SideReel. SideReel tracks and allows users to connect to Internet Television, Movies and WebTV content. Therefore, the vast majority of my work involves checking the SideReel site and peripheral components to make sure that we can get to the sites that store the content, and verify that the shows that appear are the actual shows we link to. If you didn't know that, you would look at my time management report and say "wow, this dude is a total slacker! All he does all day is watch TV on the Internet", but understanding the company, you realize "OK, this dude is doing his job and is very focused on it!"


This reminds me of the value of context, and as a fan of the context-driven school of software testing, this should come as no surprise. Were this tool to just leave me with the default listings, it would be of little benefit to me, because it is misreading my reality. It may make sense in other areas, but it doesn't make sense in mine. For a bank, someone watching Internet television is spending time on entertainment and is therefore wasting company time. For me, watching television on the Internet is a source of business intelligence, and therefore is the most productive thing I can be doing. Actually, let me rephrase that, my confirming the episode should be where it is and can actually play is business intelligence. Going much beyond that, and actually watching the whole show, is not business intelligence. It then becomes entertainment and would definitely be a hindrance to my job... unless the whole point is to verify that the tools we have built can play an entire show... context is everything.


The cool thing about RescueTime is that each of the categories allows the user to determine what activities are valuable and which ones aren't. In this case, it helps to be very honest with yourself and realistically apply categories and ratings that make sense. Also, it's important to know that what's important and productive actually varies from day to day. Email to me is a distraction, but if I don't actually answer it or reply to it, it can build up to a point where it becomes very important, and then slugging through it becomes a very productive activity (compared to the consequences of ignoring it entirely). Facebook is generally considered a"very distracting" activity, unless I'm actually testing interactions with Facebook that day. At that point, Facebook becomes a power tool and the most important focus of my day.


My point is, tools like this can be really cool and they can show you what you really think is important, but keep two things in mind. First, it's a snapshot of what you actually do, which can be very telling. Second, all things have a context, and it's up to you to be totally honest about that context and how they are actually applied. If you are willing to be honest with yourself, you can learn a lot about what really matters to you, and then adjust accordingly so that those things that "should" matter to you can get more floor time.

Three Weeks In..

So it's now been just shy of three weeks at my new job. The reaction is one of many emotions: joy, frustration, interest, angst, curiosity, elation, bewilderment, and probably lots of other conflicting emotions. For the record, I'm glad I made the move and that I took on the new challenge. at the same time, I'm going through that inevitable "where exactly do I fit in with this group?" feeling as well.


Without going into too many details (remember, I don't tattle on or gossip about my companies), I have had the chance to go from a traditional development environment to an Agile environment. In many ways, it's a lot like what people have described as "living Agile" and at the same time, it's different than I expected. the key factor is that I'm in a way making things up as I go along. While this company does a lot with TDD and really does qualify as "test infected", there's still plenty for me to do. Often it involves me looking at older decisions and playing the "Bug Attorney" role and asking "so, why did we make this/that decision about this?" and overall, I'm being given the latitude to do exactly that. It blends well with my approach and desire to play Agent Joe Friday and ask for "just the facts, maam!"... which brings me to my next realization...

It's weird being the oldest person here. That includes any of the Founders, the CEO, Engineers, and Designers. I'm without question the oldest guy here, and in some cases, I'm working with people who could by age difference be my kids! In some ways, I relate well to them, and in other ways, sometimes I feel like I don't relate at all. Still, it's helped me learn some new perspectives and it's definitely helping me learn some newer tricks (geek skills don't really have an age barrier, and for that I'm grateful).


Some have asked me how it feels working for a company that lets you watch TV all day. The truth is, my job doesn't really cover much in the way of actually watching TV. Finding shows, tracking them, keeping a listing of up to date offerings, verifying the database entries are correct, referencing the right genres, and confirming that the pages look and behave as they should, I do a lot of. By the time I get to the point that I've verified that a show is in the right place and can be viewed, my work is done and its on to the next story. So no, I really don't get to watch much TV at all on the job.

What's been really frustrating, in a way, but totally expected, is that it's taken a serious chunk out of the time I have to write this blog! I'm in fire-hose mode at the moment, and so much of my free time is being spent to work on and learn stuff to help me in this new job. This, of course leads to the blogger's equivalent of "the law of inertia"; when I'm writing a lot of blog posts, it's easy to write more of them. When I take a break or focus on other things, it feels like it takes a Herculean effort to write new entries. It's taking a serious bite out of my finishing my current projects; I only have three chapters left of HWTSAM and Selenium 1.0 Test Tools. Before I found writing them to be easy and relatively quick. These last chapters are proving to be harder to write about and are taking more time.

So like all new adventures, there's some stretching and compressing and growing going on. Some of it is comfortable and fun, some of it is a little uncomfortable and challenging, but still fun :). The learning never stops, and the systems are dynamic, so there's always something new to learn and do. For that, I'm grateful!