Onboarding and Not Getting Mau Mau'd

Yesterday was day one at SocialText, and it's safe to say that the experience could be summed up by envisioning drinking from a fire hose. In no particular order, my day consisted of:

- getting the details ironed out to get me into the numerous public and private git repositories.
- getting email and machine access ironed out.
- meeting the development and testing teams and getting a feel for what we need to be doing.
- attending the first stand-up and learning the priorities.
- seeing one piece flow enacted in a Kanban system.
- looking at the testing framework and seeing what holds it all together.
- learning how we create and modify tests (that are actually defined in our wiki product).
- getting a feel from my team what has come before, what we need to deal with now, and where we'll be going from here.
- learning the creative rules for how to effectively park in the business district of Palo Alto, and how to use the daily changing parking hangers.
- a lot of HR specific on-boarding details.

- and an interesting reading assignment; read Tom Wolfe's short story "Mau-Mauing the Flak Catchers".

Say what?

Yeah, I thought that was an interesting title, and our Quality Director had a point to it.

In the original story, which takes place in the late 60's in San Francisco, the Flak Catchers are the municipal government (aka "the man") and they are trying to deal with a number of outreach programs towards those in the community that are decidedly not "the man". The story shows, often farcically, how the various groups seeking to utilize the programs used confrontation to  work the system, to get their initiatives and priorities covered, sometimes at expense to other groups, who likewise used the same tactics to get what *they* wanted.

In addition to using confrontation as a tool, they also found ways to game the system. The net result? The Flak Catchers ran around dealing with every "Mau Mau" pushed on them. The overall effect was to create a system that made the situation worse for everyone.

As testers, we are used to being in the role of bearing bad news, as well as trying to deliver good quality. In lesser hands, this has the potential of being pushed, cajoled, metaphorically bribed to "let others get what they need". In short, testers get Mau Mau'd all the time! The point being driven home to me was simple... there's a difference between collaboration and working effectively with the various teams, and getting Mau Mau'd. We want to encourage the former. We will very much do all we can to prevent the latter! As a former Lone Tester who often didn’t have the benefit of a leader willing to make that kind of pledge, I consider this to be awesome, and I hope that more testing teams will consider doing the same.

Oh, and for those wondering, I took the train home, ate dinner, and went straight to bed! This, I think, stands in as one of my most exhausting first days on the job ever, in all of the best ways. Let's see what day two has in store for me :).

Sikuli: Some First Impressions

Today marks a transition in many things.

From Sidereel to SocialText.
From Scrum to Kanban.
From San Francisco to Palo Alto.
From Entertainment to Collaboration.
From External Facing to Intra-Facing.
From Ruby on Rails to a hybrid of technologies including an old friend, Perl!

It's the latter aspect that has given me cause and curiosity to look into and learn about an interesting testing framework. That framework is called Sikuli, and a "visual language" called Sikuli Script.

Sikuli started as a project at MIT. It's now an open source tool that can be used with a number of different applications. It can be used with the web, it can be used with Flash apps, it can be used with compiled applications on a number of different platforms. Yeah, OK, that's all fine and good, but aren't there plenty of tools out there that already fit that space? Why use another one?

I thought much the same thing, until I thought about a few of the applications I've wanted to poke around with in the past... some of them just aren't designed with test-ability in mind, or to be more charitable, some programs just bedevil the expectations of many tools currently available. Some apps don't have much in the way of an open API to access and help with the process. Selenium works great when you can access the object layer. What do you do when you can't access those attributes so easily? What if the front end is all you have, and all you are going to get? It's here that Sikuli starts to get interesting.

Sikuli can be run in a number of different ways, and the most likely way it will be run from a first timer's perspective is to use its IDE. The IDE puts front and center a number of function calls and simple tools that the user can take advantage of to make scripts. These scripts are similar in a lot of ways to Selenium/WebDriver and Capybara in what they do, with an interesting difference. The function calls can take images as their arguments. Not paths to images, actual images on the screen. Here's a simple example using a Win32 application I use with my scout troop called Troopmaster. The following is a very basic screenshot and just a couple of commands.

This admittedly trivial example performs a very simple set of instructions:

Load an app (Troopmaster).
Wait for a value on the screen to appear.
Open the Merit Badge Counselor tool.
Click on the "Add New" button (so we can create a new Merit Badge Counselor).

That's it! All very straightforward, all very basic stuff. The cool thing is that, in many ways, doing little more than these kind of steps, you can accomplish a lot of tasks. Sikuli uses image recognition to help determine where you want to do certain things. Based on those images, often even a non programmer or tester can put together tests or automate tasks to help them accomplish certain goals (it should be noted that Sikuli is not positioned solely as a testing framework. It's also used as a sort of "macro language" to help with automating basic repetitive tasks).

Now, of course, there's a lot more Sikuli can do and there are some frustrations and challenges that need more than just  "point here, click this, fill this in, Click OK". While very basic and trivial tasks can be done without extensive programming knowledge, to get beyond the training wheels basics, it helps to know what the architecture and language structure is. Sikuli is written in Jython, which is a Python implementation that allows the user to import and access many Java library functions, as well as to compile the source code down to a JVM. The user also has the full breadth of the Python language. If I ever wanted to have a good excuse to spend time with Python and get familiar with more than the basics, here's a great opportunity to do exactly that.

Again, this post is not meant to be an all encompassing tutorial. I installed it on my PC last week to get familiar with it, and wanted to get some first impressions out there. So where do I go from here? I want to get more familiar with doing things that are non trivial, and the best way I know how to do that is to, well, publicly declare that I'm going to do it. Does this sound like a new set of entries for the Practicum page? Hey! That's what it sounds like to me, too! Thus, it's time for another "bold boast"... let's see what we can do with Sikuli, and what we can't. Let's see in real time if it's a workable tool or if it's another "interesting, but..." kind of a framework. Also, let's give me a good excuse to poke around with and dive deeper into Python, let alone Jython and how it adds to this mix (to be frank, I'd never even heard of Jython before I downloaded this app, so I know almost nothing about it or its inner workings).

If you'd like to play along at home with me, you can get Sikuli and learn more about it at http://www.sikuli.org/ 

Book Review: Think Like A Programmer

Yesterday, I posted a review of a now "classic" think-like-a-programmer book; Andy Hunt and Dave Thomas' "The Pragmatic Programmer". I commented that it was interesting to see this book from the perspective of 13 years later and what was still being practiced actively and where we may have moved on, as well as the suggestions they made to be effective and, yes, pragmatic programmers.

To book end this experience, I wanted to look at another title that was in a similar vein, but much more recent, as in this title was released just a few months ago. This book, V. Anton Spraul's "Think Like a Programmer", covers much of the same ground as "The Pragmatic Programmer", but does so with a much narrower scope. While "The Pragmatic Programmer" looked to focus on many different aspects of being effective, "Think Like a Programmer" puts the bulk of its energy on one issue; problem solving and the tools necessary to approach problems and develop solutions. The goal of this book is to help answer that age old challenge... I understand the syntax, I can read code, I can modify code, I can work with other people's code and understand what it's doing, but when I sit down in front of a blank editor, I'm lost!

"Think Like a Programmer" takes the reader down a number of paths to help explain some of programmings more challenging aspects and do so with generally basic coding structures. The entire book's examples are in C++, so there is a unity to the problems being presented. While the examples are in C++, all but a few of the problems could be ported to other languages like Java, Ruby, Python, etc.. The chapter on pointers might be the sole exception, and the chapter on classes comes from the perspective of a language that can be used with both procedural and object-oriented approaches.

I am not a programmer by trade. I did enough C++ programming in college to recognize the structures and the methods used for the solutions, so there was nothing in the code itself that was terribly frightening or all that advanced. Beginners, or those who have never seen any C++ code, may feel a little lost in spots, but Anton takes the time to explain every line. The goal of the book is not to focus specifically on coding syntax, but on the problem solving domain. Getting good and usable code, that's a definite bonus, and he makes the case for doing all of the things that Andy and Dave talk about in "Practical Programmer".

The problems all use standard elements of the C++ programming language. Arrays, pointer, classes and recursion all get a chapter dedicated to their own issues. Problems are presented and a detailed breakdown as to how to go about solving them is shown. Each chapter has a variety of exercises to work through.

The last chapter focuses on allowing the programmer to devise their own game plan to solve problems, and each game plan  will be unique to that particular programmer. Strengths and weaknesses are rarely the same, so making a "best practices" list for everyone would be pointless. Instead, Anton works the reader through methods and aspects that can help them create their own unique problem solving methodology, using all the tips and techniques practiced in the book, and leveraging their own individual strength, weaknesses, and areas of focus and interest. One thing to be aware of... there are no answers to the exercises provided. That's by design. the point to the exercises is to see what you would come up with, and help break the cycle of "blank page, I'm lost!"

Bottom Line:

Seasoned developers may find this a bit basic for their tastes. Rank beginners might find the examples intimidating. Those in between, even those who are not C++ programmers, will likely learn a good deal and help de-mystify a few areas by working through the examples and problems. As a tester, rather than a programmer, I think that these titles are helpful to look at the issues that programmers face, as well as the issues and methods used to solve problems. Since we have to test those solutions, understanding how programmers get there and the tools they use to get there is helpful. "Think Like a Programmer" is a solid step in helping both programmers and testers look at these situations in interesting ways.

Retro Book Review: The Pragmatic Programmer

Having written reviews for many Pragmatic Publishing books over the past few years, I always wondered if it made sense to go to the source of where this "Empire" grew from.

Before Pragmatic Publishing, Andy Hunt and Dave Thomas wrote "The Pragmatic Programmer: From Journeyman to Master". Published in 1999, it is definitely a product steeped in its time, its languages and its practices. Having worked at a company that went from mini to mega over the course of ten years in the 90's, I recognized most of the practices described when I'd skimmed the book at bookstores or in company libraries over the years. I wondered, would it be worth it to read now? I mean really, it's 13 years old. The programming and testing world has changed dramatically since then... or has it?

Picking up the book was made very easy a while back when it was offered on Amazon for Kindle for $1.99. Heck, for $1.99, I'm totally willing to do an anthropology experiment. My big question, though... as a software tester and not a traditional programmer, what insights would this offer me?

Having gone through this book from the perspective of a software tester, I would honestly say I think it acts better as an anthropological read than it might as a programming guide. Heresy? Maybe, but hear me out.

My guess is that, for many programmers, much of this advice is already well ingrained  It certainly seems to be in the Agile teams and adherents that I have met (remember, this book was written in 1999, which means Dave and Andy, as well as many others, have proven to be quite prescient with their advice, as many programmers have taken it to heart). For a software tester like me, though, this was a wonderful chance to "see how the other half lives", or at least aspires to live.

Many of the tips that are presented seem obvious, almost comically so. Yet when I've gone back and reviewed a number of projects I've been on and interacted with the programmers that worked on those projects, I realized that much of this "common sense" definitely was missed by quite a few programmers I've interacted with. The list of tips that they offer and their explanations are actually a terrific cheat sheet for software testers. By understanding these pragmatic lessons, we can understand what programmers strive to do well, and if they fall short, we can respond with where they are falling short, in ways that they might actually appreciate and understand.

The book has a lot of Java, C and C++, which makes sense since that was the predominant group of languages at the time, but they also make the point to mix in several other less familiar languages and approaches, because they wanted to make the book as code agnostic as possible, yet allow real code to be showcased to make the points necessary.

For me, the true landmark of this book is not the advice that they espouse here, but what Dave, Andy and many other authors since then have done in the wake of The Pragmatic Programmer being published.

One complaint I would level, and perhaps it's a holdover from the times and how I view things today, is that "testing" as a topic is at the very back of the book. Everything is presented in a clean and orderly manner, but frequently, it would reference testing, and say look to [topic about testing] for further details. I chuckle at this now because this is definitely counter to the way that Pragmatic Publishing puts out titles today. In many cases, testing is in chapter one or two! Evolution or necessity, I don't really care, I'm just happy to see that evolution take place.

Bottom Line:

If you are a beginning programmer looking to become a great programmer, and you want to approach the topic from an attitudinal and discipline approach, I think this book is still very relevant. If you want to approach programming from a nuts and bolts perspective, I'd suggest getting knee deep into a language first and then come back to this (Zed Shaw's "Learn [Code] The Hard Way" lessons seem to be very much kindred spirit to the ideas and ideals of "The Pragmatic Programmer", and learning there first and coming back to this would not feel jarring or out of place). If you would like to have a treatise for the standard that programmers should hold themselves to, and a way to "get inside their skin and understand them better", then I think The Pragmatic Programmer can be and should be a must read. It's also an early glimpse into the dynamics and philosophies that would one day develop into one of my favorite publishing entities. From that perspective, this book is pure gold.

Easily the best $1.99 I've spent all year :).

Shadow Boxing, Round 2

"Oh come on, I had to ;)!"

It's now been thirty days since I made the commitment to try an experiment, some "Better living through Chemistry", so to speak. Thirty days ago, I took my first Concerta, and I've been taking it most weekdays ever since.

For those coming in late, feel free to do a search for "Shadow" on my blog and you'll be able to read the whole story, but this is in response to finally deciding to treat Adult ADHD with a doctor's guidance. The added benefit is that I'm taking an exploratory mindset to this. I want the treatment to work, but even outside of all that, the concept of Adult ADHD fascinates me, and I want to see if I can understand how the treatment works.

So first things first... the thought that my core personality would change. According to those that I have asked to see if I was behaving or acting strangely, so far no reports of radical shifts. I seem to be my normally goofy and energetic self, with a slight difference. According to some, my speech patterns have changed a little bit. To put it simply, I'm a classic motormouth; I talk around ideas and in conversations. I think out loud. This has, in the past, translated to my being "overly loquacious". While taking Concerta, people have commented that I am doing this less. Don't get me wrong, I'm still a rather wordy fellow, but it seems I don't mind a little silence now, here and there :).

I was curious to see if my diurnal rhythm would be changed. I have a tendency to naturally want to wake up at 4:00 AM many mornings, and I have a very strong mental state from about 4:00 a.m. to about 7:00 a.m.. I then fade a little from that high between about 7:00 a.m. and 10:00 a.m.. From 10:00 a.m. to about 2:00 p.m. I'm at kind of a low tide (not useless, but it's definitely not full throttle Indy 500 style engaged and active). From 2:00 p.m. until about 5:00 p.m. I enter another "brain blast" period (that aforementioned Indy 500 mode). From 5:00 p.m. until about 8:00 p.m., I dig into that mid range again, and from 8:00 p.m. until bed I'm back to that "low tide" state. That's been my historic rhythm for, well, years and years. While on this medication, those periods still map relatively the same time-wise, but the peaks and valleys are less pronounced. This means my "low tide" feels stronger and I can focus better at those times, but that also means that the "blinding brilliance" of those full throttle moments is also a bit more regulated. Ultimately, if it helps me to be more effective for longer periods, and with less noticeable up-shifts or down-shifts, I think I can live with that :).

Concerta acts as an appetite suppressant. I find myself much less frequently running to the fridge or the cupboard during my "flow" periods, and it doesn't feel like I'm Jonesing for food. In short, those "boredom munchies" have been greatly curtailed. I've lost about 10 pounds in the past month with little in the way of changing exercise routines or other habits, so that's been an interesting outcome.

I'm finding that I can focus more on unpleasant or less fun tasks. Entering that "flow state" also seems to be quicker when I need to tackle a big project. It's not a 100% "wow, I'm now able to dig into unpleasant tasks and just be awesome!" Yeah, I wish. I still have to do a bit of psych up and use some of my ever familiar tricks (pomodoro timer, hiding "eye candy", etc.) but I'm finding that I rely on them less than I used to.

I was concerned that taking this medication would mess with my sleep patterns, but actually, they have improved. I think that may also be in part due to the fact that I am now effectively not consuming caffeine. Since I wanted to see what would happen with the medication outside of any additional CNS stimulation, caffeine is mostly out of the equation (I'll have an occasional soda with a meal if it's there, but I don't seek it out). I'm finding that, if I can get seven hours of consistent sleep a night, I'm pretty good to go all day with focus and effective intensity. If I get less than six hours, I am less effective and focused, and if I get more than eight hours, I'm likewise less focused. Seven hours seems to be the sweet spot for me, at least for now.

One of the great changes, and this was one I did not expect, was that Concerta has helped quiet down a number of my anxieties and frustrations. I'm not going to claim a "Peter Gibbons" level of tranquility (for those who don't get that reference, go see "Office Space", and it will make sense :) ), but by finally quieting down some things that were freaking me out, I was able to separate symptoms from root problems, and get some much needed clarity on where I want to point my energy. That clarity culminated in my seeking a new opportunity and, well, changing jobs. I will confess, that was not where I thought this would lead, but it's been a fascinating and very exciting outcome nonetheless.

Yesterday, I had another appointment to evaluate the levels, the reactions and where we go from here. It looks like we'll hold at 36mg per weekday for the next sixty days, and see if there's any retrogression over that time. Again, I am aware that this is not a "silver bullet"; I am still me, and I still have many habits, interests, desires, phobias and dislikes that still shape me. The medication does not erase those, but it does give me an extra tool to help manage them and put them in proper perspective.

Round Three... bring it on :)!!!

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.

Book Review: Getting Results the Agile Way

There are many things in life I appreciate. I appreciate ideas that can help motivate people. I appreciate methods that can help build clarity and purpose, I appreciate ways to help people look at new situations in a  different way. I also appreciate a fantastic bargain. thus when I saw Scott Hanselman's tweet late last week that "Getting Results the Agile Way" by J.D. Meier was available that day for free as a Kindle download, well, I had to jump on it.

Many of us in the software development and software testing sphere are familiar with many of the aspects of Agile software development. We think of things in  aspects of collaboration, sprints, stories, small iterative deliverable items, and continuous evaluation and improvement over time. these seem like excellent topics for organizations, and many organizations have done well to adopt them. Many of us who work in these organizations often use these techniques in our work life, but we shut it off when we leave the office. J.D. asks a basic question... why?  If Agile is such a great approach for developing software, why don't we use it to develop the rest of our lives?

This in part is the primary message of "Getting Results". It's the idea of making ourselves agile by using Agile techniques. When I use small "a" agile, I mean the actual ability to be nimble, adaptable and having the ability to change course and approach easily and quickly. When I use large "A" Agile, I'm referring to the methodologies that are associated with the named practices.


Note, "Agile Results" is a registered trademark. It's a system that is being marketed. Don't be distracted by that premise. Think of it as similar to "The Total Money Makeover" that Dave Ramsey offers and espouses. It's his system, but the system can be tailored and modified to meet your own individual context and needs. You could practice it lock, stock and barrel, or you could take a few ideas and try them out to see how they work in your own particular world.

The idea behind Agile Results is a simple and lightweight framework that lets you get control over your day, week, month and year. If you're using something already that works for you, the Agile Results approach is not meant to supplant them, but give you some additional tools to better use the tools you already have.

The key to agility is that, when things change, you need to be ready and able to change along with them. Instead of having a big to do list that you just grind away at, open up and focus on areas that have needs (so called "Hot Spots") and leverage your strengths and weakness to achieve better and more meaningful results.

If there's any one core element to take away from this approach, I would have to say that it is "the rule of three". Think of every thing you would like to accomplish, and break them out into four distinct regions; the day, the week, the month and the year. Now for each of those, think of the three things you most want to accomplish in each. If you want to just sample this idea, start with one day. What three things would you be really happy about if you were to complete them today? List them, visualize the outcome you want, and then time box and focus specifically on those areas to get them completed. If you do all three and still have energy, bite off a fourth thing, or more if you have it in you. Stretch this idea out to a week (what three things do you really want to accomplish this week), then to a month (what three things) and then to a year (again, what three things). The day level is, of course, an immediate view. The week level is a 500 foot view, the month is 15,000 feet, and the year, well, let's picture that guy jumping out of a balloon at the edge of our atmosphere, shall we :)?

The book is split up into several sections. the first part explains the system and the bare minimum to visualize and try it. The second part goes into details for each given regional focus (day, week, month, year). The third part discusses benefits and challenges that can help us maximize the effectiveness in the areas where we are strong, and identify areas that we may have weaknesses. It's tempting to think this is just about work results, but it's not. This model allows people to focus on may regions of their life (the so called "hot spots" such as home, relationships, work, fitness, mental health, spirituality, fun, etc.). The fourth section is a rather large Appendix that reiterates many of the areas and makes them available as reference checklists and templates.

There is definitely a feeling of repetition and covering the same material as you read through the book. That's by design, and while it might be a put off for some, don't be so quick to shuffle through. It's meant to start out bare bones, and then to give you an area to consider later on in greater detail. why? Because for many of us, we will not be hit with everything on the lists as challenges at the same time. Some areas we are naturals at, other areas we may need more hand holding and guidance, and it's different for everyone, and it's different for the same person at different points in time and in different aspects of their lives. J.D. is aware of this, and again, this is by design. You may find yourself skimming these areas, and that's OK, but don't be surprised if you come back later and read them more in depth.

Bottom Line:

"Getting Results the Agile Way" is a focus on balance, and on outcomes rather than processes. this book will not provide the same rote template for everyone, nor should it. If you currently have a system, you may find these ideas may enhance it. If you don't have a system, this is a pretty neat and low maintenance approach. Either way, give the ideas a spin, or check out http://gettingresults.com/ to see more of the ideas in action. No purchase required :).