Letting Go and Making Changes

I'll say it right now. I'm anti- New Year's Resolutions. I've said it before, I'll say it again. there is no need to wait until New Years day to make commitments and keep them, or to get rid of things from their lives that are not bringing them any joy or utility. Still, it's an uphill battle, since so many of us are wired to think this way through cultural expectations, there's just some things that we can't avoid. With that, I'm going to give some thoughts to "Letting Go and Making Changes" so that 2013 will be the best year ever (ugh, too cliche? Oh well ;) ).

I pledge to play more video games - wait, what?! Yep, I came to the stark realization that I had not played a single major console title this year, from any manufacturer. How many times did I power up my DS to play my Japanese tutor game? Twice. What other games did I play on my DS this year? Not a one. Why in the world would I want to play more of these things? Because they give me a mental sharpening every once in awhile. They allow me to look at a story in a deeper way. they let me practice something over and over to find different possibilities. In short, they help me think, and if there's anything I'd like some more practice and ability in doing, it's thinking differently. Thus, I want to spend a little time each day (and may I emphasize a little time, I'm talking maybe 30 minutes a day max) to try to do a little more playing.

I pledge to write less, and write more - Sometimes I get frustrated that I don't blog as much as I used to, and then I dawned on me... I'm actually writing as much if not more, but posts that used to make their way into my blog are now showing up in other places (Zephyr, Smartbear, the Testing Planet, SummerQAmp curricula, and other places that I'm writing for). The problem is that I feel like I have to write the equivalent of a magazine article for each blog post, and that's a lot to ask someone to do daily, or even three times a week (which has been my running average for the past few years). Rather than trying to compete with myself to write even more when I've used up ideas, my plan is to develop ideas over several days and take different looks at ideas over several posts rather than try to jam everything into a long post that almost feels like a full magazine article or a chapter of a book. Please, let me know if this idea is appreciated, or if you'd prefer the longer but less frequent posts.

I want to do more with less - this is a multi-pronged goal, and it's one that needs a little explaining. It seems like there's always a need for more. More clothes, more gadgets, more environments, more tests, more words, more stuff... all of which needs more time and more mental attention. It also comes down to more money being spent. I'm a book hound. I love to read, I love to talk about and review books. I love to hear other people's opinions of them. This is a double edged sword. In one sense, if I get a book, I feel guilty when I can't or don't finish it. Also, books are often bought to be utilitarian tools for the long haul, and I pull from them when I need them, which means some books sit for years before I find a reason to pull them open again. therefore, this year, my goal is to get through the books I have (and review them) and also to examine places where books or information can be had for free, and review them in the same way as I do with my more formal book reviews. Additionally, I want to try to see if I can place constraints on what I need to do effective work. I don't mean become a monk who walks around with nothing but a MacBookPro to do everything, but ultimately, I want to see just how little I need to be maximally effective. Think of it as a zen exercise, one I hope to share over the coming weeks and months.

I want to know how you are doing - how was your day? what did you learn today? How is the family doing? Do you need help with anything? I like to believe that I do this a lot, but the truth is, I don't do it nearly enough with the people that really matter (my wife, my kids, my immediate neighbors, my church community, my immediate co workers, etc.). I'm great at doing this with people I barely know, or who only know the TESTHEAD Michael. Somehow, it's easier. There's a record, it's something I can sum up fairly quickly. I can be pithy. I can write about it. It can be stored and discussed at a later time by others. In short, it's relatively easy and with limited downside to do it openly and on the Internet. Real life interactions with real and very intimate people are rarely as easy. Those relationships are often messy. They are delicate. they have a lot of moving parts, and often, it's difficult to dis-engage to go do something else. When someone who really matters has a problem or an issue, you (gasp!) actually have to do something about it, and often not on your preferred timeline. There's much more of a sense of urgency, and much more of an immediate need. I need to be aware that, if I ask my daughter how school is going, and she says "not well", I need to be willing to get into the reasons why "not well is the answer, and then, I need to be willing to set down other goals and priorities to help, then and there, with the "not well aspect" and try to improve it, or do the best I can to help the situation meaningfully. I'm told by my kids, immediate family and others that I do an OK job at this,. but really, I can do better, and really, I should and need to do better. these are the people that matter the most to me. Shouldn't I do a better job at having a finger on the pulse of their lives?

So there it is, my non resolution resolutions. here's the thing... they don't matter if they are not done, and they are just as useful on June 12th as they are on January 1st. I hope to make 2013 a productive and happy one, for me and mine, and for everyone else I can be of service to. Here's to future days.

Access Matters: My Experiences with JAWS

One of the more interesting aspects of my recent move over to Socialtext is that I'm dealing with a product that is used in many corporations, and, as I recently discovered, within the federal U.S. government. Because of these customers, I've come face to face with an interesting new aspect of everyday testing that, so far, I've heard about, and heard other people doing, but never did any of it myself.

For those who are not familiar with the whole idea of "adaptive software", it's any range of software enhancements that make it possible for users to interact with a computer in ways that  they might not physically be able to. To start of this little series of articles, I'll be talking about a screen reader application that is part of our testing suite. That tool is called JAWS.

JAWS is an interesting application in that it is designed to take any text that would appear on a screen and will read out the user what is appearing on the screen. More than just reading out the text on a page, it's also reading out the elements that are appearing on the screen. Think of the challenge that this might represent. Imaging, if you can, what it would be like to interact with your computer if you were sight impaired, or more dramatically, completely blind. to experiment with this, I make the following suggestions:

1. Blindfold yourself so that you cannot see your screen at all.

2. grab hold of your mouse or keyboard and try to open up a common application that many of us might take for granted (Google Chrome to access Facebook, as an example).

Just with that, what would you do? How do you know where to find the application? How can you be sure you are able to open the application and navigate? With JAWS, the challenge is broken down into screen elements that are "spoken". there are certain hot keys that can be set, and those hot keys can correspond to frequently used applications. Within those applications, the screen reader then "speaks" to you an tels you what element it is able to interact with that that given moment.

Once you get to the element you are interested in, hitting the tab key or enter key will focus the screen reader on the next element to be accessed. If this next element is a large block of text, you can then have the contents "read to you" by  one of the voice synthesis engines used in the application. On the surface, this sounds col, and it is. Having said that, I'm also finding that, as a sighted user, they are also frustrating tools. this is why I'm doing my best to try to turn of my "sighted biases" and see how they interact when I don't have the luxury of my sight to work with. The blindfold test really draws a distinction as to how challenging this testing can be, not just from the perspective of "does the app work" but "what experience is delivered in the process?".

When I work with these tools in a "sighted" environment, it's easy to get impatient and overlook the various clues given, but put a blindfold on, and those clues become very important. It still feels very  awkward, since JAWS reads everything on the screen. Every punctuation mark is called out. Parenthetical statements (which, I have to admit, are part of my writing style) suddenly become very tedious. I ran a timed test of my blog posts being spoken by JAWS, and wow, maybe I need to practice a little more brevity.

Sometimes all it takes is a change in perception or a change in the way we view the world, or in this case, when we can't view the world, to really see how difficult it can be to accomplish what we ultimately see as simple tasks. they're simple because we have adapted over time to understand them. However, all it takes is a change in reality (or a blindfold) to help one realize that our neat and ordered world can be thrown into complete chaos, and the tools that we have at our disposal, while they may work, might be tremendously foreign and intimidating. I've found this new approach to dealing with software from a non-sighted perspective to be fascinating, and I will most likely be doing a lot more of it in the coming weeks and months.

Same As It Ever Was?

According to the Internet, and Mayan prophecy, December 21, 2012 is supposed to be the end of the world. I figure, if this proves to not be true, this will be something to allow me to celebrate a wonderful year of testing. If it does prove to be true, well, no one will be here to read this, so I suggest reading this quickly ;).

2012 was a pivotal year for me, in that I had a chance to do many things I'd never done, I had a chance to participate in a number of unique opportunities, and I made some decisions that have really made me question if it made sense to do things the same way I've done them for so long. Also, for those astute musical nerds out there, I'm referencing Talking Heads "Once in A Lifetime" once again with the title. It's proven to be quite a versatile song for these posts over the past few years.

When I wrote the first of these recaps in 2010, I was preparing to leave a job I had worked at for almost six years, and very much looking forward to a new adventure in a new capacity. In 2011, I shared many of the lessons I'd learned from making that step, and how being involved in the broader community had become very important to me. Thus I find it interesting that, here at the end of 2012, I am writing this message at yet another company, at the start of yet another "excellent adventure". "Same as it ever was?" seemed rather fitting, as this was not a year of business as usual. Not by a long shot!

2012 was a year of travel and outreach, and the opportunity to learn about and work with a number of interesting initiatives. I concluded my dive into Ruby and learning as much of the language as "Learn Ruby the Hard Way" would inspire me to do. This was a project started in 2011, and it ran for three months. I learned a lot along the way, and grew to appreciate many of the nuances of Ruby and how it works. My personal library of Ruby titles is huge now, which is a little ironic since, in my new role at Socialtext, I am looking at code that written mostly in... Perl :). Some might comment that I've wasted my time with all this Ruby focus, but I don't think so at all. What I've been able to do is approach a language at a deeper level than I ever have in the past, and do so with the eye of sharing my experience with others. That helped me internalize a lot more of it. Don't get me wrong, I'm not what I would consider a great programmer, nor even a moderately good one. Still, there's a level of appreciation and achievement I'm quite proud of, and I feel it will help me look at other languages and be a little less intimidated.

My friends Lynn McKee and Nancy Kelln invited me to participate in the POST 2012 workshop up in Calgary, Alberta, Canada, back in March. I was the facilitator for this event, and help the participants present their topics, discuss their ideas and critiques, and I also had a chance to present the idea of Weekend Testing as a service that any company could incorporate and associate with its test teams. An aded bonus, Lynn took me to Sunshine Village, one of the ski resorts in Banff National Park. Yep, I got to tick off a bucket list event... I snowboarded in Canada!

I had the pleasure of going to New Orleans to help plan out many of the events that would be part of the CAST conference for 2012, and visit some of the areas of the city (Bourbon Street, Royal Street, etc.) that I'd only heard stories about. It also gave me a chance to participate in the first Workshop day of STP-CON Spring 2012, likewise in New Orleans. I had the experience of being able to go and participate in and live blog five different workshops, and participate alongside many other intelligent and engaged testers.

I presented my first full paper and presentation at a conference this year. It was originally to be at PNSQC 2011, but a broken leg sidelined me and I was unable to present it. A friend who felt bad that I couldn't give my talk contacted Lee Copleland and suggested my talk would be a good fit for their conference. Lee read the paper and decided "yes, we'd like to see this presented" and offered me a spot on the program at STAR EAST 2012 in Orlando, Florida. I acepted and presented my talk. Additionally, I won Best Paper for "Delivering Quality, One Weekend at a Time". For the record, that was a seriously cool experience!

Weekend Testing in the Americas had a more regular schedule at one session per month. As we held our sessions throughout the year, we noticed an interesting pattern. There is a group of regular attendees that often participate. We have a number of brand new testers that come on and try it out a few times, then disappear. We have a number of one-offs, those who try it and never come back. Because of this, I determined it would be a good idea to get some additional brains into the mix to help develop sessions, content ideas, and other areas of focus. Albert Gareev has continued to be a great help to me in this regard, and we welcomed JeanAnn Harrison and Dan Gold into the mix of regularly contributing facilitators. Seriously, thank you to all of you, it made this year's sessions more enjoyable, and it gave me peace of mind to know that, if I couldn't be there for a session, that it would happen and all would be well. Additionally, I appreciate the influx of fresh ideas and different approaches.

Early in 2012, I had a chance to answer an article written about the SummerQAmp program, and what it hoped to accomplish. That proved to be a fateful message, in that I started a collaboration with the organizers of SummerQAmp and, along with members of the Association for Software Testing and other interested test professionals, we started writing what we hope will become a complete and practical introduction to the world of software testing. We delivered several modules and ran a beta test of the materials with a number of interns, and the response was "This is great! Can we have more of this?!" The answer, I hope, will be "Yes", and make no mistake, that will be a primary focus for me and for the AST EdSig in the new year. If you'd like to participate, please drop me a line!

I was invited to participate in Test Coach Camp, which happened the weekend prior to CAST 2012. This was an open-space conference event, where a number of testers participated and presented a variety of topics. I had the chance to present three different sessions (mentoring interns, teaching leadership skills, and a systematic deconstruction of Weekend Testing and the question "if we rebuilt it, what would you like to see us do?"). CAST 2012 also was the first chance to present the idea that has been my focus for much of the year, looking for that elusive balance between Test Driven Development, GUI Automation and Exploratory Testing. This topic showed up in a number of formats this year, and each time I approached it, I learned something new. First, it was a paper submission for PNSQC, then an emerging topics talk at CAST, then a full presentation at Agilistry Studios, and finally as a poster paper presentation that I gave (dozens of times) at PNSQC.

2012 saw me branch out and start contributing articles to a number of different outlets. Thanks to  ST&QA, Testing Planet, Atlassian and Zephyr for allowing me the opportunity to write for a broader audience, and for their giving me a chance to open this blog up to more testers and people interested in my writing. This year I also set a record for traffic with a post that is now number 1 with a bullet on TESTHEAD. Which post? Learning to Tell Different Stories, where I compared the storytelling tradition in Japan to what us "westerners" are used to, and how the differences and nuances open us up to asking different questions once we see and understand that there are different ways of seing things beyond our own world view. I also enjoyed participating in ST&QA's "Ask  the Tester", where I had the chance to answer a number of questions from the broader testing community. Also, I was a presenter in the Agile Transitions Online Conference for Software Test Professionals, where I presented my talk on "Being a Lone Tester on an Agile Team".

TWiST had another year of great conversations, great participation, and crossing the 100 episode mark (as of this week, we're up to episode #127). I always think of the old television maxim that, for a show to live on forever, it needs to pass 100 episodes to be eligible for life in syndication. I'm not sure if that's applicable for a podcast, but it's great to see that there is an appreciative audience, and that we can bring these discussions and ideas to you each week. I also enjoyed the various panels I participated in, and the shows I could contribute my ideas and thoughts to various discussions. Finally, I would be remiss were I not to say thank you to Justin Rohrman and Mark Tomlinson, who stepped in this year to help me edit episodes and do some of the "grunt work" that goes into getting these shows ready to be packaged and released. Seriously, your help is greatly appreciated!

During 2012, I continued my active involvement with the Miagi-do School of Software Testing, where Matt and Markus decided that I had earned the right to be advanced to a Black Belt Level Instructor. It's both gratifying and humbling to be associated with so many great testers, and while I now have the title of Instructor, sometimes I wonder who the real teacher is. I feel like I learn more from those I interact with than they likely learn from me.

As I have taken on the role as Chair of the Education Special Interest Group within the Association for Software Testing, I made the decision to step out of an active teaching role for the time being. While I will still be teaching some classes, I wanted to focus this year on giving others the opportunity to step up and learn how to lead the BBST classes and encourage those who haven't had the chance to assist and get a chance to teach as well. My goal for 2012 was to broaden our instructor pool, and that will continue to be a primary goal for 2013.

Hanging up my Lone Tester status was definitely not something I could have foreseen earlier this year, but looking at the interactions with others in so many other mediums, perhaps I should have seen it as inevitable. I decided that through all of the interactions I have had with my fellow testers, and with some feelings of frustration with my role as a lone tester, that I would put out some feelers and see if there were some test teams that would be interested in having a "Veteran of the Psychic Wars" join them. I have to admit I was surprised that so many responded, and so quickly. Thus, with the chance to "practice what I preach" regarding interaction, engagement and peer involvement, I made the decision to make the move from Sidereel, where I was a Lone Gun, to Socialtext, where I now work with a small but focused team of four testers... and by the way, we're looking for another tester to join us after the new year, so if you're interested (and local ;) ), let me know.

So many people have made this an amazing year for me, and to mention everyone by name will likely mean I'll leave someone out, so if I do, please don't feel slighted (and hey, if you do, email me and I'll put you in... blogs are cool like that :) ). Cheers and much appreciation to Aaron Scott, Albert Gareev, Anne-Marie Charrett, Becky Fiedler, Ben Simo, Benjamin Yaroch, Bill Baker, Catherine Karena, Cem Kaner, Dan Gold, Dee Ann Pizzica, Doug Hoffman, Elisabeth Hendrickson, Francis Adanza, James Bach, Janette Rovansek, JeanAnn Harrison, Jeff "Toxic" Burchell, Jon Bach, Justin Rohrman, Keith Klain, Ken Pier, Kevin Haggard, Lee Copeland, Lynn McKee, Mark Tomlinson, Markus Gaertner, Marlena Compton, Matt Barcomb, Matt Heusser, Mimi Mendenhall, Nancy Kelln, Patti Swift, Pete Walen, Peter "Pantera" Arzhintar, Rich Szeto, Rick Baucom, Scott Barber, Shampa Bannerjee, Thomas Ponnet, Timothy Coulter, and Zach Larson. Thank you for challenging me, for making me question my ideas, my motives, and my goals. Thank you for helping me make it possible to make changes, take burdens off of my shoulders and help me so that initiatives I started are being shepherded and able to keep going. Thank you for what has honestly been, at least as far as software testing is concerned, my greatest year (and remember, I said the same thing last year, and the year before that).

Oh, and should the world not end on December 21, 2012, then let me suggest that we follow the wise advice of Abraham Lincoln, who said:

"Be excellent to each other. And... PARTY ON, DUDES!"

I'll Be the Roadie...

As my son gets older and takes on more interesting challenges, it's been interesting learning a bit how his mind works and what interests him. Currently, he has an interest in film production.

This past weekend, he told me that he needed to do some work for his final in Film, and he decided he wanted to do something where he interviewed street performers in San Francisco, specifically the stretch between Fisherman's Wharf and Pier 39. Seeing as I really only have a handful of these opportunities left (he's a Junior in high school now; three more semesters and he'll be graduated and off to college), I wanted to help him meet his objectives.

At first, there was some resistance. "Dad, it's OK, I don't need help, I can do this on my own!" Well, of course you can, dude, but that's not why I'm asking to come along. I wanted to see if there were ways I could see how he works and understand what he does, and in the process, be of some assistance to him (and sure, keep an eye on him, just a little... I'm a Dad, cut me some slack here ;) ). I finally swayed him with some simple words. "You handle the vision and the talking. I'll be your roadie." Meaning, I'll carry all of the gear for you, and you focus on finding the people you want to film and talking to them. He liked the sound of that, and thus, we were off to the City.

Seeing as it was a cold, foggy Saturday (typical for San Francisco) and expected to rain (not as typical) we were concerned that there might not be enough people to interview in the time we had allotted, so I offered to do some advanced scouting with him. As we walked towards Fisherman's Wharf, he noticed a Rastafarian bongo player setting up with a coffee can for tips. My son walked up to him and asked him if he could film him and use him in his project. No answer. Stone silence but him playing his drums. I waited to see how my son would react, and what he would do. Would he ask again? Would he move on? Do something else? I realized this was a different level of communication for my son than he was used to, and decided that this was a time that a "Seasoned roadie" could offer some assistance. I reached in my pocket, took out a few dollar bills, placed them in the drummer's coffee can and asked him the same question. He lit up a bit and said "sure, what would you like to know?" With that, we set up the microphone and camera, and Nick did a quick and somewhat stilted interview with the drummer. Not real communicative, but that's OK, we have to start somewhere.

As we walked down Fisherman's wharf several times, we noticed there weren't any performers out. Was it the weather? Were we just early? What could we do as a contingency plan. It was here I suggested to my son that, maybe, talking to some people on the street about their experiences with street performers might prove to be interesting. It would offer a different perspective to his project. He thought about it for a minute and said, "sure, let's give that a try". We set up the gear again, and we waited. Most people just walked past us hurriedly, but a couple of people did stop to talk with us. After  about ten minutes, he decided we should take a look farther down the wharf and back to Pier 39.

When we made it back to Pier 39, there was a performer with a Chapman Stick. I lit up at this, since I was very familiar with the instrument, and maybe my fan boy-ness got the better of me, but I suggested that this would be a great person to talk to. Since he was also set up in a prime spot right outside of Pier 39, I figured he was likely a professional who rented the space (turns out I was correct with that assumption). I also figured, if I could strike up a conversation with him about his instrument and what I already knew about it, that might work in our favor, too. I mentioned how much it blew me away when I first heard Tony Levin playing the Chapman Stick in the early 80's with King Crimson, and of curse the performer was familiar and we talked about other musicians who likewise used the instrument. thus, when we asked if we could interview him for my son's project, he was very gracious and let us record several numbers and he provided a lot of great interview commentary.

As we walked a bit further back towards Fishermans' Wharf, I noticed a lady and a gentleman get out of their car on a side street in Dickens' era garb. Performers? Certainly. Street performers? Hmmm, maybe not, they were near the Cannery, and that has a pretty swank hotel in it. My guess is they were performers for the hotel by  the level of their outfits, but I figured, hey, they're here, let's see if they'll talk to us. My son agreed, and we went over to chat with them. Turns out they were waiting for another member of their group, and yes, they worked for the hotel, but they were happy to talk to us about what they did, and why they enjoyed performing here particularly, and when their third compatriot arrived, they sang a song for my son to film.

As we were feeling pretty flush with the excitement of capturing two good interview subjects, we walked back to the wharf and noticed an elderly man dressed like he was from the Roaring Twenties performing a magic act on a portable table. MY son looked at me, winked and said "let me handle this one!" He went up and talked to the man and asked if he'd be willing to be interviewed. the magician said sure, but not for free. I casually handed my son $10, and motioned to the box on the table. He put in the $10 and then the magician said he'd be happy to perform his entire act for him, provided he'd be willing to send him a copy of the footage (sure thing!).

After filming this, it was starting to rain, and we figured that this was going to be it for the day. As we were walking back to the car, my son saw, across the street, one of the guys he really wanted to interview... the elusive and legendary "Bush Man". This guy is famous (and infamous) for scaring and freaking out tourists, and he would have definitely made for a fun part of the project, but with the rain coming down and not wanting to risk damaging his equipment, he decided to let it go.

All was not lost, however, since just around the corner, under a protective awning, one of the "Gold Statue Dancers" was there. For those not familiar with the "Statue dancers", they typically stand perfectly still until someone steps up and drops some money into their cup, and then they start dancing in a robotic fashion. This one stood on top of a milk crate, and incorporated the crate into the performance, actually sliding and stepping with it (quite proficiently, I might add). At first I was leery, thinking this guy wouldn't want to be interviewed, but my son, having seen how the rest of the day had gone, decided to give it a try. He walked up, dropped a $5 into the dancers cup and asked if he could ask him some questions. Gold Statue Dancer Man turned out to be the most animated and entertaining of all the interviews, as well as the longest.

As we drove home, I told him a bit about how today was a good example of what I do as a tester every day. With him as my product owner (my customer) I acted as roadie and helped set up the gear, helped evaluate situations, offered suggestions of avenues to try, provided support and alternative approaches when things weren't panning out, and provided some domain knowledge to help him communicate with the performers where needed. Mostly, though, I provided him with information that may or may not have been effective in helping him make decisions about what to do. All in all it was a successful outing, and a god reminder to me that "playing the roadie" can be a good metaphor for good testing, both in software and in film production.

And Now, Some Shameless Marketing :).

One of the things that we all do as new hires at Socialtext is introduce ourselves to the broader company, as well as those who work in different places other than Palo Alto, and those who work with other companies (Socialtext is now part of a family of companies). As part of that, I answered a few questions, and the last question had an interesting challenge:

Post a video telling us "what fires you up about working at Socialtext?"

The result of a few minutes of futtzing and playing around and exploring an application is below. Could I have done a better job? With enough time, I'm sure I could have done lots better. Had I had my son direct it, it would probably be a quantum leap better. For a few minutes playing around and seeing if I could figure out iMovie without ever having used it before, I like it :).

So here's my little promotional clip:

And for those who don't want to wait for the download, here's the gist of the dialog:

"I guess you could say that I am having a Sy Sperling moment here... "I'm not just an employee, I'm also a client!" 

I've been actively using and working with Socialtext for the past several years. I worked with a number of software testers to write the book "How to Reduce the Cost of Software Testing".




Where did we write, edit, and review the material to be included in the book? Socialtext!

Many of my blog posts have also been crafted and reviewed by other testers before publication on my blog here in the Socialtext wiki.

I interact with a number of people who, along with me, edit audio files so that they can be mixed down and published as podcasts. Where do we communicate and manage that work? If you were to say "Socialtext" you would be right again!

In short, now, I get to work with, influence, and get deep into the guts of an app I already work with pretty extensively. Even with that, I'm still just scratching the surface of what the product can do, as has been amply demonstrated to me these past couple of weeks.

I'm fired up because I get to work on something that I use, and rely on, every day. To also see that Socialtext itself works the same way, and actually uses the product it creates, to perform and manage its work, is also awesome. It's great to work with a company that does its best to "practice what it preaches".

Have I Found What I'm Looking For?

As those who follow my blog might notice, I tent to mangle pop culture references to make my titles or make other post points when I write here. Today is no exception.

As many of you may be aware, I started a new job on Monday, November 19, 2012. You might also notice that this blog has been quiet since Tuesday, November 20, 2012. That is not a coincidence! Much of my time the past two weeks, with the exception of Thanksgiving weekend and some much needed time with my family, I've been dealing with a single minded focus; coming to grips with the paradigm shift I've undertaken.

For years, I was the lone gun. I was the guy who either had the answers, or needed to get the answers. I was mostly responsible to myself, and mostly took care of things on my own. Today, I'm the polar opposite of that world view. I'm part of a testing team with some rather talented people, and we communicate about our findings... a lot. Socialtext uses a tool called Colloquy, which is, effectively, an IRC client. There's two main chats that go on all day, every day. One's for dev, the other is for testing. When I say these conversations go on all day, that's exactly what I mean. We all contribute, we all share what we see, we all keep each other updated as to what we see and what we find, and those chats inform where we go next, what we do next, and what the developers see next. So I'm on that window and I'm typing a fair amount each day... and I came to a realization as I was doing it.

There's somewhere else that I do this. Once a month, for a couple of hours, I and a number of other testers get together, via a chat mechanism, and we talk testing. We pick an app, we explore it, we find issues, we talk about them, we decide where to go next based on what we learn, and we discuss what we learn. If what I'm describing sounds a lot like Weekend Testing, that's because it is what I'm describing. A couple of years ago I lamented "oh, wouldn't it be really cool if an organization actually used the Weekend Testing model? Think of what we could all learn! Think of what we could share! Think of how much wasted time could be avoided because we are actually communicating!"

For the past few years, I've dreamed of seeing something like this exist. I've hoped, but had my dreams either dashed by indifference, or the feeling that there's no time to do such a thing. I often wondered, though, what would a company look like that actually did this? Now I know. It looks like Socialtext. It looks like that because they actually leverage what they learn and they use it together. If something is going off the rails, we all know pretty quickly. If something looks promising, we're encouraged to explore it. Explore and share what we find. Feedback is almost immediate, and it's refreshing, exhilarating, infuriating, exhausting, maddening, and enlightening, all at the same time. It's the chance to live the Weekend Testing model and ethos full time. The funny thing is, though, it's left me with little energy to do many other things, at least for the near term.

So, for those wondering why I've been so quiet as of late, there's the reason. Also, be careful what you wish for... you just might get it :).

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

The Value of A Poster Paper Presentation

I realized with all the talk I did a couple of weeks ago about PNSQC, and all of the talks I witnessed and participated in, I didn't talk very much about my own talk and, specifically, the Poster Paper presentations I made. I have to admit, when I took on the challenge of giving a Poster Paper presentation at PNSQC, I was doing it more out of curiosity than anything else.

The topic in question was my presentation of "Balancing Acceptance Test Driven Development, GUI Automation, and Exploratory Testing". I'd presented this paper in a 20 minute format at CAST, with Q&A following. I'd presented this talk in an hour long format, with Q&A following, at Agilistry, so I was really curious to see... could I deliver the same message, and get across the same essential points, with just 5 minutes of engagement, and could I do it multiple times?

The answer was very interesting, and not at all what I expected.

Instead of me delivering the same talk multiple times, each person or group of people would engage me in a different way. Each wanted to have a different  discussion about the same material. What was also interesting was that the areas that I thought were the most important would still have some relevance, but an idea that I offered as a "take away" and kind of a small "well, you could do this" became much more pronounced. The little takeaway, I realized, was the real kernel behind what I could do. That little kernel has, I think the potential to be something much bigger, and frankly I'm interested in seeing it become something bigger.

What's that kernel? The idea that we need to take a different look at test automation. So often, we do A to B tests. We set up tests to run a number of scripted scenarios. We run multiple examples of essentially the same scripted tests. In my presentation, I likened this to a train. Sure, with randomization, you could switch the order of the containers and the order of the cars, but they're still behind an engine, and they are still taken, on the rails, from Point A to Point B. If we go along for the ride, the view rarely changes.

As part of my presentation, as an off handed "takeaway", wouldn't it be interesting if instead of treating our tests like a train, we treated them like a taxicab? What if taxicabs were our operational metaphor? Imagine making our tests so that they could take us to the deepest darkest corners of our applications that we test. Once we reach those mysterious back alleys, the cab lets us off... and now the fun begins. What is it like to work on a system where a user has just logged in 10,000 times? Suppose you had a way of filling in every single visible text field on a site, and each confirmation took you to some place you might never have considered?

I thought the idea was interesting. The participants at PNSQC, each time I delivered the conversation, kept pushing me... tell me more about this taxicab! How could we use it? What would we have to do to set such a thing up? How could we develop such a setup? The truth is, I don't have an answer for that, at least, not yet... but I have to say I am itching to see how we could do it!

Had I just presented my talk, that taxicab element might still just be an interesting theoretical tidbit. Now, after so many discussions with so many different people, I realize this is something that could really change the way that test automation is both perceived and performed, and I'd love to be part of that reality. I often said I'd need a good reason to want to dig deeper into programming beyond necessity; it would need to be an authentic problem that fascinated me. I may have just found it!

TESTHEAD REDUX: Testing Training? What's That?

Wow, what a difference two and a half years makes!

When I first started my blog, this was one of my first entries (entry number 5, to be exact). It was my first firing salvo, aimed at my frustration as to the value of the testing training I had seen to date, most of which, even then, I was not really thrilled with. I should also note that this is the first entry that received a comment... and it was from Matt Heusser! Interesting to think that this would be my first "formal" meeting of Matt, and what has transpired in the 30 months since would be, well, amazing to discuss... but that's another story (possibly a book's worth of material, to tell the truth).

Having said all that, my point was, I felt it was time to come back and see what I said and what I believe today, now that I'm older and, supposedly, wiser... or more jaded and cynical. Sometimes the two can be hard to tell apart ;).

To be fair, the above statement isn’t as common as it used to be. There are now many options regarding testing training and how to get it. However, up until just a few years ago, being a tester and getting actual training related to testing was not an easy endeavor. Training for programming? Yes. Training for systems administration? Definitely. Training for engineering principles? Just look at MIT or Caltech or any number of engineering schools. Still, you would have been hard pressed to find a school that had an actual course of study related to software testing (and for that matter, just finding a single course was not a wide spread available option).

Today's reality is that there are two types of testing training that exist, and they can vary in value. There is what I call "vocabulary training", where the goal is to cover a lot of ground at a fairly theoretical level, and then take an exam or series of exams to show how well you know the material. The other is what I call "experiential training", where you actually get your hands dirty and test, try things out, talk about your experiences, and have others review your progress. I currently help run and facilitate two versions of this today.

The first and most formal version is the Association for Software Testing's Black Box Software Testing classes. These combine both the theoretical and the experiential aspects, and they allow testers the chance to test their understanding and challenge other participants understanding. So whereas, before, I would say there's nothing out there, today I would say that is absolutely not true.

The second source of "experiential learning" that I am involved with is Weekend Testing, and these events are almost exclusively experiential, done with a Skype connection and a group of willing and active participants. There are chapters around the world, but the India and Americas chapters seem to be the most active at this immediate point in time. Experience level varies dramatically, peer testing is an attribute, and each session is different from the one before. There's no need to feel "I don't know enough to participate." We treat it as a safe environment for everyone to come in, learn, practice their craft, and make connections and share ideas. It's also a lot of fun.

Show of hands, how many testers had any genuinely formal training in how to do their job short of perhaps a quick orientation from a test team lead or test manager? How many people actually participated in training beyond this introductory level? If my experience is indicative of the majority of testers, I’m willing to bet that number is probably very low.  

Today, while there are many who have sought out formal training, the vast majority of testers that I talk to still have this issue. Things are changing, in that I think the Meet-up culture is starting to encourage people to get out and talk about these things and offer alternatives to official training activities.

Testing Blogs: If you look to the side of these posts, you will notice that I have a roll of a number of test blogs. There are hundreds, but these are the ones I keep returning to again and again. I return to them because they challenge the way that I think about things, or they provide me with solid information and ideas to explore. There are hundreds more out there, and to be totally honest, I’d love to have TESTHEAD fill that role for people as well (it’s going to take awhile to develop the credibility so that it will be worth that to someone, but hey, I aim to try :) ).

This has become my number one source for information. several sites do aggregation of just tester's blogs, so those sites are my first stop if I am really interested in seeing what testers have to say and what ideas are being discussed. What's interesting to see if who has changed in my blog roll since I started this. That's to be expected; bloggers come and go based on their energy levels and what they are involved in. What is cool is to see how many are still there two and a half years later that were on my original list :).

Testing Magazines and Communities: There are several magazines and groups that publish information that is readily available to everyone, and while they still require a subscription fee to get everything they offer, the amount of information they offer to the general public for free is substantial. Some of my personal favorites are Software Test and Performance magazine and their online collaboration site and Better Software magazine and the folks at Sticky Minds.

Still mostly true, but I have to add two more well deserving groups. The first is the Association for Software Testing (AST). I didn't even know they existed when I first started my blog, but I've certainly gotten to know a lot more about them since then! Helping deliver, maintain and develop their educational offerings has been an eye opening experience, and it has helped me interact with a bunch of terrific people, many of whom have become good friends since. The second is the Software Testing Club and "The Testing Planet". This loose knit confederation of testers has some great discussions, and I always look forward to when the next issue of TTP is available.

Webinars and Online Training Sessions: both STP and Better Software listed above host a series of webinars that cover different areas of software testing on a regular basis. Most of the sessions are free and are open to the public, and many of the sessions are “tool agnostic”, meaning that they talk about principles and practices that can be used with any of the common test tools, or applied to home grown solutions. 

Since this was written, I've discovered lots of areas where we can get more information and see live screencasts and pre-recorded webinars of topics useful to testers. Add to that the phenomenon of entire courses of study being made available online. Think of Coursera, Khan Academy, and other initiatives that have become well known that are making it possible for anyone willing to invest the time and energy to learn about any topic. I've also found myself branching into more software development discussions and groups, even though my primary focus is not programming. Codecademy and NetTuts+ are two great sites for this type of interaction.

Books: These were the titles that made my short list two and a half years ago:

• “Testing Computer Software” by Kaner, Falk and Nguyen
• “Effective Methods of Software Testing” by William Perry
• “Linchpin” by Seth Godin 
• “Secrets of a Buccaneer Scholar” by James Bach
• “Software Testing: Fundamental Principles and Essential Knowledge” by James McCaffrey
• “Software Test Automation” by Mark Fewster and Dorothy Graham
• “Surviving the Top Ten Challenges of Software Testing” by William Perry and Randy Rice

What titles do I consider essential today? While many of these are still valid, I've found that I'm turning to different resources now. "Testing Computer Software" has been replaced by "Lessons Learned in Software Testing" (Kaner, Bach & Pettichord) as my backbone "go to" testing book. In addition, Gerald Weinberg's "Perfect Software and Other Illusions About Testing" has become a perennial favorite. I will still recommend "Linchpin" and "Secrets of a Buccaneer Scholar", and add "Explore It" by Elisabeth Hendrickson.

Interestingly, the books that have helped my testing the most have been, shall we say, not testing books at all, but rather, those that focus on philosophy and inquiry, and help us see things in a different way, or at least understand how we have come to see different things over time. I'll also give a plug for my favorite "book discovery" of them all, in that it's not really a book, but a companion volume to a television series; "The Day the Universe Changed" by James Burke.

Wikipedia’s Software Testing Portal: [...] The Wikipedia software testing portal is an example of where this vast resource of people and small contributions comes together to make for a very large repository of information related to testing. Note: a phrase I famously use among friends and colleagues is “Caveat Lektor Wiki”, and this is no exception. Using Wikipedia as a sole resource for anything is never a good idea, but to get started and develop some basic ideas and understanding, it’s a great tool, and again, will provide many jumping off points if you wish to explore them.

Having had a chance to see many discussions about the content and the accuracy of the information, I will now say that "Caveat Lektor Wiki" still applies, but yes, much of the information would stand to being an introduction to ideas that testers may not be as familiar with. Having said that, I also think that we as a community have the responsibility to review the information, and if we see it is in error, challenge it or add our own voices to explain why. It's our collection of experiences that makes that repository, so if you find something is in error or is badly worded, do your part to help make the explanations better (said with a healthy dose of 'Physician, heal thyself!", I might add).

Just like two years ago, I still agree that knowledge begets knowledge, training begets training, and opportunity begets opportunity. Also, as Matt mentioned in the comment to my original post, if you can't get to an official training opportunity, band together with other testers in your area and make your own. Hold a local peer conference for a day, have a writing workshop on testing ideas, host your own local bug party. Whatever it takes, there's rich ore to be mined out there, it just requires that we pick up a shovel and dig.