Timeless Skills for Modern Testers - a #PNSQC2019 Live Blog

This is going to be fun! I've shared a podcast or a few with Gerie Owen. She's been a frequent guest and panelist on "The Testing Show" over the past few years and I realized today that this was the first time I'd actually met Gerie in person :).

Gerie's talking about developing and enhancing a new set of skills for "Modern Testers", the skills that are timeless and would/should carry us through our entire careers. Selenium is a transient skill. It can be important but it's likely to be superseded by something else. Communication, however, is a skill that transcends tools and will ultimately reward people who emphasize and put the time and attention into mastering that skill.

The irony with this talk as I'm liveblogging it is that we are talking about devices, and the fact that to really understand what is going on, we should put down the devices and actually listen.  Ummm, I plead the fifth ;).

Seriously, though, there is an ever-present reality that we don't really listen to "listen", we listen to reply. I'm guilty of that, I confess. It takes a real commitment to step back and say "I'm going to really listen here. In fact, I'm going to completely de-emphasize my "need to reply". Often I find that that can be surprisingly effective. Frustrating, yes, but effective.

Collaboration is an often-used word and we like to believe that we are working towards collaborating with others on our teams. Again, it's important to understand hat the purpose of collaborating actually is. Why are we doing it? What do we hope to gain from it? Yes, we can be working on a common goal, or we can be trying to accomplish a particular task. Sometimes one of the best ways to collaborate is to steer a little clear of the people who always talk or dominate the conversations. I have found value in starting with the quietest person in the room. Not to the point of having that person dread the idea (I will change up who I ask questions or who I encourage to talk first) but I strive to hold off on the main drivers going first out the gate.

It's not always possible to have complete and open communication all the time but we should all be aware of the silos that can develop. I've had the experience of both being the person with the knowledge, or trying to work with another person with the important knowledge and having to deal with the issues of efficiency vs. effectiveness. I've struggled with this much of my career where I've just said "oh heck with this, I know what to do, I'll just do it myself." Is that efficient? It certainly can be. Is it effective? Maybe not. What makes me think that my knowledge and skill are the best ideas for that moment? The fact is I don't know and I won't know if I always do what I've always done.

Creativity is a dark art. It's an aspiration and so often it's something we feel we are lacking in. The fact is, we are not creative, we create. Let that sink in for a second. Creativity isn't an ephemeral state, it's a verb, an action. We do stuff and we get better at doing stuff if we keep doing it. This is a tangent, but I hope it will make sense. My kids and I are actively involved in re-enactment of different eras. To that end, I work on clothes and garb for many periods. On the surface, you might think that would mean I'm an amazing bespoke tailor. Well, no, not really, but through practice and effort I can do some decent stuff, or at least make items that will pass the "five-foot test". It may fail at super close scrutiny but for the primary purposes, it works well enough. Also, over time, as I get better and more practiced, I get to a point where my work can be looked at more closely and feel good about the efforts I've put in.

One thing we need to be careful of is the biases that can filter into our efforts and activities. As testers, we are often taught to identify biases and fallacies. However, it's one thing to identify fallacies in others. It's another to identify them in ourselves and then counteract them.

Most of the things that Gerie has talked about are all within the realm of each of us to accomplish but they will require effort and practice for us to get good at them. None of us will become experts overnight. It will take time and experience to get good at these things :).

The Testing Show: Hiring and Getting Hired

It's been a big year for The Testing Show and this is the last episode of the year that is 2017. We were happy to have Gwen Dobson join Jessica Ingrassellino, Matt Heusser and me to talk about the changes that have taken place in the testing market over the past few years.

We riffed on a number of topics including the laws that prohibit asking about salary histories, having that discussion about money and making the best case for your worth, marketing your skill set and leveraging the variety of platforms at our disposal to help sell ourselves and our personal brands.

It's been a great deal of fun to produce and participate in this podcast and I'm looking forward to the new topics and guests we will have in 2018. I am actively working on a two-parter for January with a special guest that you are just going to have to wait and see/hear who it is, but I can say I've wanted to interview this person for a long time and I'm excited about presenting these episodes, along with some other changes for the show in 2018.

With that, please jump in and have a listen to
The Testing Show: Episode 50: Hiring and Getting Hired:

Good Ideas are Spawned From Bad Or Failed Ideas

My elder daughter and I have been working on a number of small projects together over the past few months and every once in awhile, I will get a comment from her where she says "wow, how did you know what to do in that situation? We hadn't faced it before, and you quickly figured out a way to deal with it. How is it so easy for you? Why can't I do that?"

I chuckled a little and then I've told her a maxim that I've used a bunch (and I'm sure I've said it here at some point, too)... "Good ideas/solutions come from good judgment. Good judgment comes from experience. Experience comes from bad ideas/solutions/judgment." In short, she sees that I can come in and consider an idea and implement it (in some things, I do have my limits, and they are legion). What she doesn't hasn't seen is the countless times I've tried similar things, failed at them, regrouped, reconsidered, remeasured, tried again, and repeated this process until I happened upon something that worked.

As a Scout leader, I've had the benefit of decades of teaching a few generations of kids how to do some basic stuff (note, I said basic, not easy or simple). We teach how to tie a handful of knots. We teach some basic cooking techniques. We teach how to handle items like an ax, a knife, and a saw. We teach how to safely use fire. We teach some basic wilderness survival tips. Each time through this process there is always a similar "wave" that I witness. At first, there's an excitement level, but that quickly gives way to a mild boredom. Seriously? This is such a big deal? Snooze! Still, I push on and demonstrate what I can and encourage them to practice what I am showing them. A hallmark of our Scouting year typically takes place three months in for a typical scout. That's the "silent campout". Not silent in the sense that there's no talking or interaction, but silent in that the leaders (i.e. me and the other adults) make it a point to not discuss any of the campout particulars with the troop. They have their campsite, we have ours. they are within eyesight of each other, and we reserve the right/authority to intervene if a situation is deemed unsafe. Outside of that, we let them pick the camp area, bring in all needed items, and then we leave them to it. They construct the camp, they cook their meals, they clean, they tend fires, and do all of the other things that we have taught them over a few months.

Each time, the outcome has been similar. The bored expressions often give way to genuine concern or in some cases panic. Wait, what was I supposed to do at this point? Did I pack what we needed? Did I cook that long enough? Am I going to be able to properly contain the fire? You get the idea. They make mistakes, they get frustrated, and then they approach the problem(s) from different angles. They confer. They discuss options. They experiment. Some of those experiments fail, but some succeed. They note the ones that were successful. The next morning, fewer mistakes, less frustration, and almost no panic. The process, while ragged, gets smoother and more refined. Almost to a person, this experience makes for a change of attitude, and then when we talk about "the basics", they are not so jaded and bored. they realize that basic stuff often is harder to physically do in a regular and smooth manner. Like everything, it takes actual practice and it takes some working through frustration. Do it enough, and you start to actually get good at those basics and then you forget that there was a learning curve at all.

My point with this today is that, too often, I think we approach aspects of what we do (testing, coding, administration, learning new stuff, getting out of our comfort zone) with the same mindset. We start out enthusiastic, we get bored and jaded and then we panic when what was supposed to be so simple doesn't work out to be. It's OK to feel these things. In fact, it's necessary. Over time, as we stumble, learn, practice and perfect, we too might forget exactly what it takes to do basic things and make them look easy. May I encourage you not to? You never know who may be watching and feeling discouraged because they can't seem to "get it". We've been there, we know how that feels. Let's make sure we remind others that basic doesn't necessarily mean easy, and that good ideas/solutions often come from bad ideas/attempts.

Water Flowing Underground

Well, it's the end of another eventful year. Much has happened. I've been involved in many interesting endeavors, and I've learned a lot about myself this year. This was a topsy-turvy year for many, both in the pop culture and political sense. It seems for many we are making decisions to look for ideas and think about things in ways that agree with our views of the world. That's both rational and long term bad for us. I won't be talking about politics with this post, other than to say that I believe local action and local involvement has to be where we all start because that's where we individually have the most control and effect.

The title this year of this post is "Water Flowing Underground", and yes, this is yet again a lyrical nod to the Talking Heads song "Once in a Lifetime". Why did I choose this line for 2016? It felt like this was a year of digging. If I wanted to get to the water that would sustain me, I would have to work for it, and in many cases, work harder than I have before.

First, let's start with a little bit of "Aedificamus". This was a year I focused on being more quantified in my actions. I measured my food. I measured my exercise. I wore a fitness tracker each day. I set a goal and I came darn close to achieving it, and then part of me stopped paying attention. No, that's not really true. The truth is I grew weary of the level of activity and focus needed to hit the aggressive goal I had set for myself. What's more, I discovered that I was capable of being injured in ways that took far longer to be healed than I imagined possible. I developed golfer's elbow (which is odd because I don't play golf). Seriously, though, what that means is that I developed a repetitive stress injury on the inside of my elbow, at the joint where my humerus and ulna meet. It's made lifting weights and doing a number of exercises challenging. I have to be careful as to how I lift things and how I use my elbow. In addition, in the latter part of the year, I developed plantar fasciitis in my left foot. What that has meant is that my previous gung-ho approach to walking 10,000 plus steps each day is now determined by how my foot feels in any given day. The net result is that I gave up some of my progress on my weight loss. I'm still considerably less than I was at the start of this journey, but compared to this time last year, I'm actually up about ten pounds. Still, I am wearing the clothes I bought for the smaller framed me, and they still fit comfortably, but I have a reminder that I need to mend and I need to keep healthy, plus I need to figure out some adaptations to my training and eating so I can get back to making progress, even when my body doesn't want to cooperate.

Next, I made a conscious decision to scale back on several areas so that I could focus on a few key areas I've really wanted to develop. That meant taking a step back from freelance writing and yes, even contributing to this blog, so that I could help bring forth a new venture. That new venture that started this year is "The Testing Show", a podcast that I produce, edit, transcribe and publish each week through QualiTest and on iTunes. I knew going into this that I had a goal for the production quality and listening experience for this podcast. To that end, I think it's safe to say that I've spent more cumulative time on this show than any other initiative I've been involved with this year. As well as being a regular panelist on the show (along with Perze Ababa, Jess Ingrassellino, Matt Heusser and Justin Rohrman), I also edit every show and produce a transcript and show notes for each episode. In short, if you like the flow of the show, the accuracy of the transcript and the relevancy of the show notes, I get to take the credit for that. If you don't like them or find any of the above in need of improvement, I am also the one to talk to about that. Without going into details, I probably spend anywhere from six to eight hours producing each episode. That's because I want the listening experience to be clean, and I want the transcript to be as accurate as possible. Do I have to edit the shows so that every "um", "ah", "like", "you know", and circular verbal tic is removed? Probably not, but I value podcasts that go that distance. Shows like Freakonomics, Planet Money, and Hardcore History are my gold standards. I aspire to have our shows be that clean and that focused. Sometimes I succeed, sometimes I miss the mark. Each time I learn something new and get just a little bit better.

On an additional physical level, I took on what was possibly the biggest trek of my life, as well as the biggest challenge to the way I live and work every day by going off the grid and hiking into the New Mexico wilderness in July of this year. As Scoutmaster of a Boy Scout Troop, we put together an expedition to spend sixteen days in the Southwest, twelve of them at Philmont Scout Ranch and the surrounding Carson National Forest. We hiked for ten days, covered about eighty miles on foot, climbed over a few mountain ridges, dealt with extremes of temperature, and learned how to orienteer for real in spaces where there were no trails. Most of all, I had to make the decision to turn leadership over to a group of 14-16-year-olds and put my trust and faith in them that they would make the right decisions for the ten days we were on the trek. I am very much of the mind that I often do things myself if I don't trust that they will be done the "right way". Well, the Philmont Way doesn't care what the adult leaders think outside of an advisory capacity. What the boys decide determines the outcome, and we agreed to that. Most of the time, it turned out OK. Occasionally, I had to be sneaky and offer suggestions or show where we needed to go, but I was admonished by my co-leader that I needed to keep such interventions to a minimum. We all made it through intact, some scrapes, some bruises, a little altitude sickness here and there, but overall, much better for the experience. What's more, I learned that I had it in me to hand over control to others, and I learned to accept that my way need not be the only way. It about drove me crazy at times, but I was happy for the experience nonetheless :).

On the conference side this year, I decided to focus on my own area this year. Philmont was going to take a lot of time this year, so I decided that I would not travel for conferences this year. I was happy that STPCon came to Millbrae, CA, and I was also happy that the organizers told me, in no uncertain terms, that I had BETTER submit some talk proposals, as they were literally less than five miles from my home. To that end, I presented talks on the Intersection of Accessibility and Inclusive Design and shared a workshop on How to Teach New Testers. Those topics were also worked on and developed more in the Bay Area Software Testers meetup, along with our quarterly Lean Beer discussions, which opened up new areas for me to dig this year.

On my everyday work side, we've been making changes to our core team. Some of our most seasoned veterans have moved on to other endeavors. I've celebrated four years at Socialtext, and I am now the fifth most senior person in our company. That seniority is measured in weeks and months in a few of those cases. This means my leaning on more knowledgeable people gave way to my having to dig even more and learn even more than I ever thought possible. I now feel like the one that people come to for answers, both in the testing sphere and, more frequently, in the programming sphere. While I can safely say I have a lot more to learn in that latter area, I do feel that I am working in an environment that will let me dig as deep as I want to with as much energy as I can muster, and I will be encouraged and helped along the way. That's one benefit of working for what is, in effect, a very small company, even though that company is an acquisition of a much larger one. We are left to run as a scrappy little team, and that scrappy little team encourages everyone to dig if they want to.

So what does 2017 look like? I'm hoping to get back out and participate in conferences again, whether it be as a participant or as a speaker. I'd like to attend some development conferences or some broader industry events, and see if I can help develop a broader message of testing and quality. I'm aiming to expand Weekend Testing Americas to do more events at different times other than just on Saturdays (that's what people have said they want to see, so we will certainly give it a try). All in all, I am optimistic, and if there are areas that I am less optimistic about, I am going to remind myself that if it is within my sphere of influence and control, I best do all I can to influence events and outcomes as much as I can so that I can be optimistic going forward. One thing is for sure, water's flowing underground. If I want to get to it, it's up to me to dig for it. Same as it ever was ;).

Adventures in Empathy - Simulating mild vision loss with the Cambridge Inclusive Design Toolkit

Last year, I spent a fair amount of my presentation time talking about ideas behind Inclusive Design, and how the both enhance and help contribute to performing Accessibility testing. One of the resources I suggested was the Inclusive Design Toolkit developed and used by the University of Cambridge. In addition to a wealth of information on their site, their methods go beyond software. Since they test numerous physical items, they do not rely on software tools only but have actual physical tools that you can use.

One of those is their Cambridge Simulator Gloves. These are rigid pieces of flexible plastic that can be adjusted to simulate a variety of physical issues with hands (e.g. rheumatism, arthritis). These are seriously cool pieces of kit, but they are pricey (£155 per pair, which is at this writing close to $200). Less expensive but also seriously cool are the Cambridge Simulation Glasses. These are considerably less expensive (£30 for a set of five glasses, which is less than $40 as of this writing), and therefore are easier for individuals looking to dabble in Inclusive Design to do so. The University of Cambridge is quick with orders and I received mine within a week of placing it. For shipments coming from the UK to the USA, really, that's pretty good.

Here's the single user Cambridge Simulation Glasses pack.

OK,  so what in the world is this?

The idea behind the simulation glasses is that you as an individual can experience progressive vision loss. Personally, I can already empathize because I have developed classic middle-aged person near-sightedness; I need readers to type this blog post, for example:

Not a fashion accessory, but also not a permanent fixture on my face (yet).
I do need them anytime I try to read or type anything.

If you are not already wearing prescription glasses, contacts, or need readers just yet, you may be wondering how you might be able to simulate mild vision loss. The simulation glasses do exactly that. Just put a pair on, and you will experience a little bit of fuzziness to your vision. If you want to intensify the effect, put on another pair of glasses over the top of the ones you are currently wearing. The kit comes with five pairs of glasses, and believe me, by the time you have put on all five, you will find it challenging trying to read much of anything.

If you wear glasses, you wear these over the tops of the ones you are wearing to give you a graduated simulation.

The loss of visual quality as you stack glasses.

The image above gives you an idea as to how fuzzy your vision gets with these, but it is even more jarring as you actually wear them. aAt the maximum level, you can really see how frustrating it is when you try to look at a screen or an object that has low contrast. Trying to determine what it is, much less how to use it, can be a real struggle. Again, there are software tools that simulate this, but there's something very interesting about being able to put on these graduated "fuzz" devices and try to do everyday tasks I take for granted.

For those who are interested in experiencing your apps, or your everyday products in a new way, and to develop a bit of empathy for your less visually normative friends (and those who live long enough will most likely get to join our ranks), then I do encourage getting these simulation glasses. They are worth the expense, and they do help reshape and reframe the way you see the world... or don't see it, in this case.

Become an Influential Tester: Live from #STPCON

When we get right down to it, we are all leaders at some point. It's situational, and sometimes we don't have any choice in the matter. Leadership may be thrust upon us, but influence is entirely earned. I would argue that being influential is more important than being a leader. Jane Fraser, I think, feels the same way :).

Influence is not force, it's not manipulation, and it's not gamesmanship. Sadly, many people feel that that is what influence is. Certainly we can use those attributes to gain influence, especially if we hold power over others (titles are somewhat irrelevant in real influence. People who respect you will walk though fire for you regardless of your title. People who don't respect you may put forward a brave face and pay lip service, but behind your back, they will undermine you (or at the most benign level just ignore you).

So how can we get beyond the counterfeit influence? I'm going to borrow a Coveyism (meaning I'm stealing from Steven Covey, he of the "7 Habits of Highly Effective People" fame). To have genuine influence, we need to build "emotional capital" with our associates and peers. That emotional capital needs to be developed at all levels, not just with upper management. One sure way to develop emotional capital is exchange information and experiences. In my world view, that means being willing to not be the sole proprietor of my job. IF I know how to do something, I try to make HOWTO docs that spell out how I do it. Some might think that would be a detriment, i.e. where's the job security? Fact is, my job is not secure without emotional capital, and sharing my knowledge develops that capital. It also frees me up to explore other areas, safe in the knowledge that I am not the silo, you do not need me to do that thing, because i've shown many others how to do it.

Persuasion is a fine art, and it's one that is often honed with many experiences of not being persuasive. Persuasion is, in my opinion, much easier when you are dispassionate an objective, rather than passionate and enraged. Making a clear case as to why you should be listened to takes practice and experience, and developing a track record of knowing what you need to do. Over time, another aspect of persuasion gets developed, and that is respect. Respect is earned, often over long periods of time, and unfortunately, it's one of those resources that can be wiped out in a second.

Influence often comes down to timing. Unless the building is on fire, in most cases, timing and understanding when people are able to deal with what you need to present and persuade about helps considerably.

Over time, you are able to develop trust, and that trust is the true measure of your emotional capital. If your team trusts you, if you have made the investments in that emotional capital, they will go to bat for you, because you have proven to be worth that trust. Like respect, it's a hard earned resource, but it can be erased quickly if you fall short or prove to not be trustworthy.

Being able to work with the team and help the team as a whole move forward shows to the other members of the team that you are worthy of respect, trust and that you deserve the influence you hope to achieve. Note: leadership is not required here. You do not need to be a leader to have influence. in fact, as was shown in an earlier talk today, the leader or first adopter has less influence than the first follower does. That first follower is showing that they have faith in the first person's objective, and by putting themselves in the position of first follower, they are the ones that influence more people to sign on or get behind an initiative.

A key component to all of this is integrity. It may not be easy, you may not always be popular, you may wish to do anything else, but if you keep true to your word, your principles and you own up to shortcomings or mistakes without shifting blame, you demonstrate integrity, and that integrity, if not always outwardly praised, is internally valued.

Active listening is a huge piece of this. To borrow from Covey again, "seek first to understand, before you try to be understood". It's often hard to do this. We want to be right, and often, we put our emphasis on being right rather than being informed. We all do this at some point. Ask yourself "are you listening to what the speaker says, or are you too busy rehearsing the next thing you want to say?" If it's the former, good job. If it's the latter... might want to work on that ;).

Ultimately, influence comes down to reliability and dependability. People's perception of both of those is entirely dependent on your emotional capital reserves. You are not reliable and dependable, you demonstrate reliability and dependability. Over time, people perceive you as being reliable and dependable, and the relationships you foster help determine how deep that perception is.

Leading Change from the Test Team: Live at #STPCON

http://bit.ly/JRChange

Think of a village next to a river. Early in the morning, someone is hear drowning in the river. A person runs in to save that drowning person. Later, another two people are coming down the river, drowning, and two people run in to save the drowning people. A little leter, five people come down the river, drowning. This time, our hero gets dressed and starts running upstream. As the village elders yell and ask what he is doing, he responds "I'm going upstream to see who or what is throwing people into the river".

This is a cute and yet good reminder that, at times, we need to stop dealing with the immediate crisis to see where the root problems lie. Another common joke is "when you are up to you rear in alligators, we often forget the job is to drain the swamp."

John Ruberto points out that, sadly, most change efforts fail. The primary reasons are that we often fail to build a good case as to why the change is needed. There's a model called "the change curve" where we start with denial, put up resistance, then embark on exploration, and finally we commit to the change.

Making change needs two important things. First, it needs to have an initial leader, but just as important is a first follower. When a first follower steps in and participates, and most important, the leader embraces and accepts them, that encourages others to do so as well. Over time, those not participating will start to because their non-participation will be very visible, and now not following is the strange course. In other words, the most important leadership role is not the actual leader, but being the first follower.

First and foremost, we need to build the case for change. What's the need? Where can we get supporting data for the need for change? What would happen if we didn't implement it? What is the urgency? Pro tip: the higher the urgency, the more notice and attention it will get. However, often the most important changes needed don't rise to the level of most urgent. However, if left untreated, something important can certainly rise to most urgent (especially if the time left untreated results in a catastrophic bug getting out in the wild).

Next, we need to communicate in the language of our intended audience (as well as those who might not be in our immediate audience, since they may have influence on direction). Ideas need to map to a vision. Features need to communicate benefits. We do pretty well on the former, but we could use some help with the latter. In short, don't communicate the what and not communicate the WHY!

We can communicate the needs, we can speak to the value, but we need to validate the hypothesis as well. That means "Scientific Method" and experiments to confirm or dispute our hypothesis. It's important to remember that the Scientific Method is not a one and done, it's a continuous cycle, especially when we hope to make changes that will work and, more important, stick. Don't give up just because your first hypothesis doesn't hold up. Does it mean your whole premise is wrong, or does it mean you may need to refine your hypothesis? We won't know until we try, and we won't know for sure if we don't genuinely experiment, perhaps multiple times.

Next, we have to rollout our change, and observe. And be ready to adapt and adjust. John used a cool image from Sweden in 1967 when the switch from driving on the left side of the road to the right went into law. Even with all the testing and experimentation, there was still some chaos in the initial implementation, and it took some time to adjust and resolve the issues that resulted. For us, we need to be open to feedback and ask, consistently "how can we improve this?"

We of course need to show progress. If everything has gone according to plan thus far has worked, but we are not showing progress, we may need to be patient to ensure we have adopted the change, but at some point, we need to objectively evaluate if our efforts and changes are really valid. it's of course possible that we could hit all cylinders and adopt a change that doesn't really achieve what we hoped. Does that mean the change was irrelevant? Possibly, but it may also mean that, again, we need to adjust our hypothesis. Typically though, sticky changes have to show progress worthy of the change.

In short, remember to be in love with the problem, and try to address the problem. Don't be too married to any solution that doesn't really accomplish the goal of solving the problem. Good goal to shoot for :).

Integral Quality - Live at #AgileTD

Wow, we are at the closing keynote. Didn't I just get here? Seriously, I know it's Thursday afternoon, but time has sort of lost its meaning to me these past few days. Nevertheless, we are at the final keynote talk, and Olaf Lewitz will be closing out Agile Testing Days.

Have we considered the ways that amazing things get created? Is it all an obvious need that just gets met, or does it happen because we notice something, and then we push forward because we believe in the cause and delivering something to meet a need. I think truly great initiatives start from the latter, and many times, I think serendipity has a lot to do with it as well.

Too often, I think we look at what others do, but we don't turn that lens on ourselves. rather than "what can the organization do to be successful, with me coming along for the ride" perhaps a better question is "what can I do to make this organization amazing?"

Olaf asked us to say what we are grateful for through this conference. It would be too messy to do this in person, but there is something I can do, and I'll do it here :) :

Thank you, Madeleine Greip, and the Agile Testing Days organizers, for inviting me to speak at this wonderful event.

Thank you, Meike Mersche, for being a wonderful tour guide, showing me around Potsdam, and buying me Red Bull Cola, as well as being a bright and happy face to see every morning.

Thank you to each and every person who attended my talk, gave positive feedback, retweeted or wrote about what I said (especially Kim Knüp, who dedicated a full blog post of her own to my talk).

Thank you, all speakers, for your time and your talent and energy. You've given me so much to write about these past few days.

Thank you, Albert Gareev, for being my partner in crime and asking me to make 2015 a year of Accessibility, and challenging me to make it the primary focus of what I wrote and spoke about for the year. I have learned a lot because of that, and I think there's so much more we can do :).

Thanks to the readers of TESTHEAD, for being willing to follow along with me when I go on these mad dashes at conferences and posting a dozen or two posts in just a few days.

One of the interesting comments Olaf shared was the idea that, if we remember back to The Matrix, there's a metaphor of a blue pill and a red pill. Blue pill means ignorance and just going with the flow. Red pill means waking up and seeing things as they really are, good and bad. Interestingly, when we have the ability to make choices, we tend to be solidly on the side of the option that gives us choice, and specifically those options that we genuinely understand what is happening.

"Options have value. Options expire. Never commit early unless you know why."

Quality is, frankly, a bizarre thing. It's not elegant and clean. In fact, quality is messy, nebulous, and wholly subjective. Jerry Weinberg's statement of quality is "quality is value to some person". With the number of persons out there, there are just as many definitions of quality as there are people to perceive it. Therefore, the first person who has to decide that quality is sufficient is me. Point blank, would I want to use the software I am testing? If so, why? If not, why not? If I have a steady litany of why not's, then I have a duty and obligation to voice those concerns, even if I may be the only person who recognizes them as such. In short, I have to know what I want first. From there, I need to know what the organization wants, and then I need to know what my customers want (and by that, I mean what all my customers want).

Human organizations have had several revolutions. First was the Tribal Revolution, followed by the Agrarian Revolution, then the Industrial Revolution, and currently the Information Revolution. If James Burke is right, we are in a period of transition, where what was once known and owned by an elite few, will be available to everyone. The bigger question is... what's next? What's the next big revolution? What will the new paradigm be when it comes? How will we fit in it (assuming it happens in our lifetimes)? We have a chance to shape that new future, and we have the opportunity to start with ourselves and our organizations. If we want to see change and better quality. Let's start with ourselves, and take it from there.

Agile Leadership Lessons - Live at #AgileTD

Selena Delesie and I have known each other for about five years. I met Selena as one of my co-participants in the BBST classes, and we have had an ongoing correspondence and bumping into each other at events over the past few years. Selena has focused on being a coach and a consultant. She has a broad range of experiences and a unique presentation style, and I'm excited to see her delivering a keynote today :).

Ask yourself, if you could have dinner with any person alive, who would it be? Why? What do like about them? For me personally, I'd like to hang out with Gerald Weinberg and earn a bit about how he got where he is today. I'd also like to hang out with Larry Winget for awhile because I think he's a hoot and his personality is bigger than life.

Selena emphasized that her "must meet" is Richard Branson, and while she didn't get to meet him directly, she did get to interact with him at an event she was attending. She said that some of what she admires about Richard is his ability to listen deeply. We tend to want to make our views known, and by doing so, stake our claim on our knowledge and experience. More important is being able to listen deeply and learn to understand the challenges people are facing. My expertise doesn't matter if the expertise I have won't help the people I'm conversing with or hoping to lead or help.

How can we improve on collecting information and ideas? In general, the best thing is to just stop and listen to the people we are working with. Ultimately, it's all about the people on your teams that you work with. It's important to realize that, if you are going to be a technical leader for a team, your goal is not to make yourself shine, but to make the entire team shine. As a leader, your goal is to help other people be successful. If that's not your thing, you need to consider a different line of work. Additionally, do all you can to make people smile. When people smile, they open up and amazing things happen.

Who can you improve your relationship with? For me, I think it is important to have a good overview of the business as a whole, so foster relationships with people outside of your immediate team. Build relationships with people who can help you understand what is happening in the entire organization. As you learn what other people in your organization deal with, and what their pain points are, we can help alleviate that pain, or look at our work differently.

Be addicted to learning. Discover what domain knowledge exists in your organization, and be prepared to go where the needs are, rather than just what you want to do. For me, the most pressing need in our organization at a time was to understand the entire build process for our software, and that led to me becoming the release manager for our company. Do i know everything about the process? Hardly, but I have a chance to learn and experiment regularly, and provide basic improvements to the process here and there, and that's made a world of difference in my work reality this past year.

We don't learn by following rules. We learn by experimenting, by doing, and yes, by falling over and getting back up again. It's a challenge to learn new things, especially in areas that are not comfortable to us. It's also important to carve out the time to get good at what we do. Part of that requires us being willing to say "how may I be of service to you?" It's not enough to just show up and do things for our benefit alone, we need to be wiling to be of service to each other and our organizations.

Another question to consider is "what problem are we helping to solve?" One member of the audience said "harnessing all of the brainpower of the organization". Another said "to get a better shared understanding of the software we are developing". Another said "hiring more team members". For me, it's "making sense of the infrastructure and feature needs to help identify the real critical issues that our customers need".

Agile means being adaptable and flexible, and yet we still find that old habits die hard. We may think our teams are agile, but in many ways, there is a lot of tradition and process to overcome, and many of the methods we use are often counter-productive. Remember that change is a given, but how you respond is a choice. Don't be afraid of adapting and trying something different.

 

Knowing When To Step Down

For the past four years I have had the joys & frustrations of working with an organization, as well as serving on its Board of Directors. That organization is the Association for Software Testing (AST). The positions I’ve served in for those four years include three years as the organization's treasurer, and this past year (so far) as its president. These years have been filled with successes and challenges, satisfying goals completed and frustrating loose ends still to be resolved.

In August, at the Conference for the Association for Software Testing (CAST), those candidates who wish to run, or who are up for re-election, will put their hats in the ring and make a case as to why they should be selected. Earlier this year, I anticipated I would be creating a post asking for your support. Instead, I am putting this post together to encourage others to run and get involved, as I will not be seeking a third term.

Why am I making this decision, and why am I talking about it now?

First, I want to give those who want to run for the board a chance to get their names out and be considered. Second, I want to discuss some of the things being involved with the board entails, and how you can be effective or hope to be effective. Third, I believe that becoming entrenched within an organization for too long can be a hindrance to moving forward, whether intentional or not.

Due to circumstances in both my work and personal life, and the time and attention needed in areas important to me (my family and my career), it is clear the time and attention I can provide to AST, in the role of a board member or executive officer, is no longer sufficient to be effective. To make the time to be effective, I will have to pull away from two critical areas. My kids are at a key point in transitioning from teenage years to adulthood. My work environment has changed due to the death of my director. I've stepped in to fill many of the roles he played. In short, the conditions that made it possible for me to be effective as a board member are not there now. To keep serving in this capacity would be a disservice to the organization. I want to make sure that the work I care about regarding AST can be accomplished. I still want to be part of that mission, but I have to be realistic as to what I can offer and do.

For the first three years of my involvement, I was the treasurer. That meant I had to make sure our financial house was in order. Making sure the money that came in and the money that went out was accounted for was my primary responsibility. Once you get a handle on it, you can do it reliably and have time to think about other things. During the years I was treasurer, we made great strides in breaking out where our money was going, and how to use that money effectively to help local and international initiatives. I still think the AST Grant Program is one of the best kept secrets of our organization. It’s there, but only a handful of people take advantage of it.

Three times a year, we gather together as an in-person group to discuss the business of AST. We have done our best to pick a central location to minimize traveling costs.  For the past four years, that has meant the U.S. midwest or east coast. One of those tri-annual board meetings also coincides with CAST. Anyone who runs will need to be cool with being able to travel for those meetings.

Getting seven people to agree to a decision can be daunting. While we can reach consensus on a number of areas, sometimes we just don’t have the bandwidth or the agreement to put those items into motion. We have been criticized for moving too slowly. The fact is, in some areas, we do move slowly. We are aware that we represent a large and diverse membership. No decision we make will please everyone. Still, we try our best to make choices and develop positions that will benefit the entire organization, rather than be of benefit to only a small number of members. Additionally, if we must make a choice, we will choose not do something if the alternative is to do something poorly.

Once a month, we get together for a monthly conference call to discuss business that needs to be moved forward, and making the time to have that call happen each month is important. Outside of these calls, and triannual in-person meetings, the work of the organization needs to get done and moved forward. Often, real life interferes with that happening.

If you are interpreting my words here as saying “those who wish to run need to have both vision and bandwidth to make sure things get done”, you have interpreted correctly. If you are reading this and thinking I am dissuading others from getting involved, that is the opposite of my intention. I encourage those who do want to run for the board to do so, and do it loudly! While there have been stressful moments, it’s also been fun, and I’ve been really excited about what we have been able to do. I think CAST is one of the best software testing conferences out there. The vision of AST and the members of the board and its various committees make it possible. I think that BBST is a very valuable series of classes. I’ve enjoyed being an instructor these past several years. Even though I will not be on the board after November, 2015, my involvement with BBST will continue. I intend to keep teaching, and aiming to help improve the process and delivery of that teaching.

My recommendation for those interested in running would be to look at something AST does, and demonstrate how you can help sustain and/or improve what we are doing. If AST is not doing something you think we should be doing, make a case as to why you feel you can make that possible, and how you can help make that happen. In the past, those who've been elected had a goal they wanted to see achieved, and they had the energy to see it through. If this fits you, I wholeheartedly encourage you to see our Election page, and make a bid to run for AST's Board of Directors.

I want to thank the AST membership for four memorable years. Thank you for giving me the opportunity to serve in this capacity. I’m leaving the board, but I am not leaving AST, nor will I stop focusing on initiatives I feel are important. I must adjust to current realities, and serving on the board is a commitment of time, talent and energy. There’s a great group of people already there, and we will need great talent going forward. You could be one of those people.

The Value of Mise en Place

I have to give credit to this idea to a number of sources, as they have all come together in the past few days and weeks to stand as a reminder of something that I think we all do, but don't realize it, and actually utilizing the power of this idea can be profound.

First off, what in the world is "mise en place"? It's a term that comes rom the culinary world. Mise en place is French for "putting in place", or to set up for work. Professional chef's use this approach to organize the ingredients they will use during a regular workday or shift. I have a friend who has trained many years and has turned into an amazing chef, and I've witnessed him doing this. He's a whirlwind of motion, but that motion is very close quartered. You might think that he is chaotic or frantic, but if you really pay attention, his movements are actually quite sparse, and all that he needs is right where he needs them, when he needs them. I asked him if this was something that came naturally to him, and he said "not on your life! It's taken me years to get this down, but because I do it every day, and because I do my best to stay in it every day, it helps me tremendously."

The second example of mise en place I witness on a regular basis is with my daughter and her art skills. She has spent the better part of the past four years dedicating several hours each day drawing, often late into the evening. She has a sprawling setup that, again, looks chaotic and messy on the surface. If you were to sit down with her, though, and see what she actually does, she gathers the tools she needs, and from the time she puts herself into "go" mode, up to the point where she either completes her project or chooses to take a break, it seems as though she barely moves. She's gotten her system down so well that I honestly could not, from her body language, tell you what she is doing. I've told her I'd really love to record her at 10x speed just to see if I can comprehend how she puts together her work. For her, it's automatic, but it's automatic because she has spent close to half a decade polishing her skills.

Lately, I've been practicing the art of Native American beading, specifically items that use gourd stitch (a method of wrapping cylindrical items with beads and a net of thread passing through them). This is one of those processes that, try as hard as I might, I can't cram or speed up the process. Not without putting in time and practice. Experienced bead workers are much faster than I am, but that's OK. The process teaches me patience. It's "medicine" in the Native American tradition, that of a rhythmic task done over and over, in some cases tens of thousands of times for a large enough item. Through this process , I too am discovering how to set up my environment to allow me a minimum of movement, an efficiency of motion, and the option to let my mind wander and think. In the process, I wring out fresh efficiencies, make new discoveries, and get that much better and faster each day I practice.

As a software tester, I know the value of practice, but sometimes I lose sight of the tools that I should have at my beck and call. While testing should be free and unencumbered, there is no question that there are a few tools that can be immensely valuable. As such, I've realized that I also have a small collection of mise en place items that I use regularly. What are they?

- My Test Heuristics Cheat Sheet Coffee Cup (just a glance and an idea can be formed)
- A mindmap of James Bach's Heuristic Test Strategy Model I made a few years ago
- A handful of rapid access browser tools (Firebug, FireEyes, WAVE, Color Contrast Analyzer)
- A nicely appointed command line environment (screen, tmux, vim extensions, etc.)
- The Pomodairo app (used to keep me in the zone for a set period of time, but I can control just how much)
- My graduated notes system (Stickies, Notes, Socialtext, Blog) that allows me to really see what items I learn will really stand the test of time.

I haven't included coding or testing tools, but if you catch me on a given day, those will include some kind of Selenium environment, either my companies or my own sandboxes to get used to using other bindings), JMeter, Metasploit, Kali Linux, and a few other items I'll play around with and, as time goes on, aim to add to my full time mise en place.

A suggestion that I've found very helpful is attributed to Avdi Grim (who may have borrowed it from someone else, but he's the one I heard say it). There comes a time when you realize that there is far too much out there to learn proficiently and effectively to be good at everything. By necessity, we have to pick and choose, and our actions set all that in motion. We get good at what we put our time into, and sifting through the goals that are nice, the goals that are important, and the goals that are essential is necessary work. Determining the tools that will help us get there is also necessary. It's better to be good at a handful of things we use often than to spend large amounts of time learning esoteric things we will use very rarely. Of course, growth comes from stretching into areas we don't know, but finding the core areas that are essential, and working hard to get good in those areas, whatever they may be, makes the journey much more pleasant, if not truly any easier.

The Case for "Just a Little More" Documentation

The following comment was posted to Twitter yesterday by Aaron Hodder, and I felt compelled not just to retweet it, but to write a follow up about it.

The tweet:

"People that conflate being anti wasteful documentation with anti documentation frustrate me."

I think this is an important area for us to talk about. This is where the pendulum, I believe has swing too far in both directions during my career. I remember very well the 1990s, and having to use ISO-9001 standards for writing test plans. For those not familiar with this approach, the idea was that you had a functional specification, and that functional specification had an accompanying test plan. In most cases, that test plan mapped exactly to that functional specification. We often referred to this as "the sideways spec”. That was a joking term we used to basically say "we took the spec, and we added words like confirm or verify to each statement." If you think I'm kidding, I assure you I'm not. It wasn't exactly that way, but it was very close. I remember all too well writing a number of detailed test plans, trying to be as specific as possible, only to have it turned back to me with "it's not detailed enough." When I finally figured out what they really meant was "just copy the spec”, I dutifully followed. It made my employers happy, but it did not result in better testing. In fact, I think it's safe to say it resulted in worse testing, because we rarely followed what we had written. Qe did what we felt we had to do with the time that we had, and the document existed to cover our butts.

Fast forward now a couple of decades, and we are in the midst of the "Agile age”. In this Agile world, we believe in not providing lots of "needless documentation”. In many environments, this translates to "no documentation" or "no spec” outside of what appears on the Kanban board or Scrum tracker. A lot is left to the imagination. As a tester, this can be a good thing. It allows me the ability to open up different aspects, and go in directions that are not specifically scripted. That's the good part.

The bad part is, because there's sparse documentation, we don't necessarily explore all the potential avenues because we just don’t know what they are. Often, I create my own checklists and add ideas of where I looked, and in the past I’ve received replies like “You're putting too much in here, you don't need to do that, this is overkill." I think it's important for us to differentiate between not overthinking and over planning, and making sure that we are giving enough information and providing enough details to be successful. It's never going to be perfect. The idea is that we communicate, we talk, we don't just throw documents at each other.  We have to make sure that we have communicated enough, and that we really do understand what needs to happen.

I'm a fan of the “Three Amigos” model. Early in the story, preferably at the very beginning, three people come together; the product owner, the programmer and the tester. That is where these details can be discussed and hammered out. I do not expect a full spec or implementation at this point, but it is important that everybody that comes to this meeting share their concerns, considerations and questions. There's a good chance we still might miss a number of things, because we didn't take the time here to talk out what could happen. Is it possible to overdo it? Perhaps, if we're getting bogged down in minutia and details, but I don't think it is a bad thing to press for real questions such as “Where is this product going to be used? What are the permutations that we need to consider? What subsystems might this also affect?" If we don't have the answer right then and there, we still have the ability to say “Oh, yeah that's important. Let's make sure that we document that.”

There's no question, I prefer this more nimble and agile method of developing software to yesteryear. I would really rather not go back to what I had to do in the 90s. However, even in our trying to be lean, and in our quest for a minimal viable products, let’s be sure we are also communicating effectively about what our products need to be doing. My guess is, the overall quality of what comes out the other end will be much better for the effort.

How I am Overcoming "Expectational Debt"

A phrase I have personally grown to love, and at times dread, is the one that Merlin Mann and Dan Benjamin coined in 2011 during their Back to Work podcast. That phrase is "expectational debt". Put simply, it's the act of "writing checks your person can't cash" (there's a more colorful metaphor that can be and is often used for this, but I think you understand what I mean ;) ).

Expectational Debt is tricky, because it is very easy to get into, and it is almost entirely emotional in nature. Financial debt is when you have to borrow money to purchase something you want or need, and it invariably involves a financial contract, or in the simplest sense a "personal agreement" where the money owed will be paid back. It's very tangible. Technical debt is what happen in software all the time, when we have to make a shortcut or compromise on making something work in the ideal way so that we can get a product out the door, with the idea that we will "fix it later". Again, it's also tangible, in the sense that we can see the work we need to do. Expectational debt, on the other hand, is almost entirely emotional. It's associated with a promise, a goal, or a desire to do something. Sometimes that desire is public, sometimes it is private. In all cases, it's a commitment of the mind, and a commitment of time and attention.

I know full well how easy it is to get myself into Expectational Debt, and I can do it surprisingly quickly. People often joke that I have a complete inability to say "no". That's not entirely true, but it's close enough to reality that I don't protest. I enjoy learning new things and trying new experiences, so I am often willing to jump in and say "yeah, that's awesome, I can do that!" With just those words, I am creating an expectational debt, a promise to do something in the future that I fully intend to fulfill, but I have not done the necessary footwork or put the time in to fully understand what I am taking on. Human beings, in general, do this all the time. We also frequently underestimate or overestimate how much these expectations matter to other people. Something we've agreed to do could be of great importance to others, or of minor importance. It's also possible that we ourselves are the only ones who consider that expectation to be valuable. Regardless of the "weight" of the expectation, they all take up space in our head, and every one of them puts a drag on our effectiveness.

Before I offer my solution, I need to say that this is very much something I'm currently struggling with. These suggestions are what I am doing now to rein in my expectational debt. It's entirely possible these approaches will be abandoned by yours truly in the future, or determined not to work. As of now, they're helping, so I'm going to share them.

Identify your "Commitments"

Get a stack of note cards, or use an electronic note file, or take a 365 day single day calendar, whatever method you prefer, and sit down and write out every promise you have made to yourself and to others that you have every intention of fulfilling. Don't just do this for things in your professional life, do this for everything you intend to do (family goals, personal goals, exercise, home repairs, car repairs, social obligations, work goals, personal progress initiatives, literally everything you want to accomplish).

Categorize Your "Commitments"

Once you have done this, put them in a priority order. I like to use the four quadrants approach Steven Covey suggests in "Seven Habits of Highly Effective People". Those quadrants are labeled as follows:

I. Urgent and Important

II. Important but Not Urgent

III. Urgent but Not Important

IV. Not Urgent and Not Important

My guess is that, after you have done this, you will have a few items that are in the I category (Urgent and Important), possibly a few in the III category (Urgent but Not Important), and most will fall into Categories II and IV.

Redouble or Abandon Your "Commitments"

These are questions you need to ask yourself for each commitment:

- Why do I think it belongs here?
- Will it be of great benefit to me or others if I accomplish the goal?
- Is it really my responsibility to do this?
- If I were to not do this, what would happen?

This will help you determine very quickly where each of the items fall. Most expectational debt will, again, fall in categories II and IV.

For your sanity, as soon as you identify something that falls into Category IV (Not Urgent and Not Important), tell yourself "I will not be doing this" and make it visible. Yes, make a list of the things you will NOT be doing.

Next is to look at the items that fall into Category III. These are Urgent but Not Important, or perhaps a better way to put this is that they are Urgent to someone else (and likely Important). They may not be important to you, but another person's anxiety about it, and their visible distress, is making it Urgent to you. It's time for a conversation or two. You have to decide now if you are going to commit time and attention to this, and figure out why you should. Is it because you feel obligated? Is it because it will solve a problem for someone else? Is it because you're really the only one who can deal with the situation? All of these need to be spelled out, and in most cases, they should be handled with a mind to train up someone else to do them, so that you can get out of the situation.

The great majority of things you'll want to do, and want to commit to, will fall in Category II. They are Important, but they are not Urgent (if they were Urgent and Important, you'd be doing them... probably RIGHT NOW!!!). Lose weight for the summer. Learn a new programming language. Discover and become proficient with a new tool. Plan a vacation for next year. Read a long anticipated book. Play a much anticipated video game. These are all items that will, in some way, give us satisfaction, help us move forward and progress on something, or otherwise benefit us, but they don't need to be done "right now". Your goal here is to start scoping out the time to do each of these, and give it a quantifiable space in your reality. I believe in scheduling items that I want to make progress on. In some cases, getting a friendly "accountability partner" to check in on me to make sure I'm doing what I need to do is a huge incentive. A common tactic that I am using now is to allocate four hours for any "endeavor space". I also allocate four hours in case I need to "change tracks" and take care of something else. This may seem like overkill (and often, it is), but it's a shorthand I use so I don't over-commit or underestimate how long it will take to do something. Even with this model, I still underestimate a lot of things, but with experience I get a bit better each time.

This of course leaves the last area (Category I), the Urgent and Important. Usually, it's a crisis. It's where everything else ends up getting bagged for a bit. If you ever find yourself in an automobile accident, and you are injured, guess what, your getting treatment and recovery rockets to Category I. In a less dire circumstance, if you are the network operations person for your company and your network goes down, for the duration of that outage getting the network to work is Category I.

I hate making promises I can't keep, but the truth is, I do it all the time. We all do, usually in small ways. Unless we are pathological liars, we don't intend to get into this situation, but sometimes, yes, the expectations we place on ourselves, or the promises we make to others, grow out of proportion to what we can actually accomplish. Take the time to jettison those things that you will not do. Clear them from your mind. Make exit plans for the things you'd really rather not do, if there is a way to do so. Commit to scheduling those items that provide the greatest benefit, and if at all possible, do what you can to not get into crisis situations. Trust me, your overall sanity will be greatly enhanced, and what's more, you'll start to develop the discipline to grow an expectation surplus. I'm working towards that goal, in any event ;).

Experience is Earned, Expertise is Granted

This title is meant to be a little provocative, and some may disagree with it, but I've been thinking about this topic quite a bit recently. First of all, I want to say thank you to Ryan Arsenault and the folks over at uTest for showcasing me in their first "Ask the Expert" blog entry. The questions I was asked centered around career choices for testers and ways that we can succeed, or at least do better than we are now.

I cannot help it, part of me feels very strange using the word "expert" to describe myself at anything. I'm happy to use words like experienced, educated, practiced or even proficient, but "expert" carries a strange weight to it. It's so subjective, and it feels like, once you've been branded one, that there's only one way to go from there, and that's down. Moreover, I don't really believe there is such a thing as an "expert", because that implies that that person has learned all there is to learn and has mastered all there is to master... and that's just fundamentally wrong on so many levels.

I've come to realize that we all own our experiences, and that we all have opportunities to learn from our successes and our mistakes (oh, how much I have learned from my mistakes). This is why I have no problems talking about my experiences or my observations. They are mine, and as such, are certainly open to interpretation, or debate, or scrutiny, or even outright ridicule at times, but they are wholly mine. Expertise, however, is a judgment call. I personally have very little trust in people who proclaim themselves to be "experts" at anything. However, I place a lot of credence on other people who tell me that someone is an expert. Why? because they are witnesses to the skill, acumen and judgment being displayed, and they can then decide if the term "expert" makes sense.

It also often comes down to "expert compared to who?" I have many interests, and things that I spend a lot of time getting into. When I tell people I was a competitive snowboarder for several years, it conjures up an image in their minds; I must be an expert snowboarder. They may even watch me ride, and come to that conclusion because of the technique I can muster and the terrain I can ride on. Yet put me alongside other riders I used to compete with, and any questions of my so called "expert" level goes right out the window. That doesn't take away from what I have learned, the events I've participated in and the medals I won, but to use those hallmarks to say I am an "expert" is, in my mind, misleading. Still, to others who have never raced, or are newcomers to the sport, to them I am an expert, insomuch as I can show or teach them things that they do not know.

Again, I thank uTest for giving me an opportunity to share my experiences, and I am honored to be part of their "Expert" panel. I don't know if I deserve the moniker, but they seem to think so, and so do their readers, and ultimately, I guess that just means it's up to me from here on out to either prove them right, or prove them wrong. Here's hoping my actions and efforts do more to strengthen the belief in the former, rather than proving the latter ;).

In Through the Side Door: Advice from an Unconventional Career

First off, Happy New Year to all of my friends and readers out there. I wish you all a great 2015 with the hope that what you strive to do and accomplish will be met.

About two years ago, I was given the opportunity to do a talk for a conference that would be happening in India called ThinkTest. My friend Smita Mishra extended an invitation to me to participate, and while I could not actually travel to India at that time, we decided to try something unorthodox. Why not video-tape my talk, and we would whittle it down to a presentation length and make it available to those who wanted to view it? Since I found myself in a hotel room near Chicago for an extra day, I decided to turn the room into a makeshift film studio and talk about my career as a software tester, its ups and downs, and other things that helped make it a reality.

Sadly, due to an automobile accident that incapacitated Smita for awhile, the conference had to be canceled. The talk project was, of course, put on hold, and then, over time, other initiatives took center stage, and I forgot about the talk and the recordings... that is, until a couple of months ago. Lalit Bhamare of Tea Time With Testers, asked me if we could use the material for his new project, TV for Testers. I said "sure", and he then proceeded to gather the clips I had recorded and delivered to Smita into the talk that is presented here.

In Through The Side Door

First, I feel it only appropriate to say... this is a long talk! I had originally recorded it with the idea that we would cherry pick the best parts and make a shorter presentation (something around forty minutes) but through correspondence with Lalit, he asked if it would be OK to present the entire talk, in its (mostly) unfiltered form. He felt that there was a lot of insights I offered that would be of value to those who, likewise, came to their careers from peripheral avenues, and the asides and segues, in his opinion, actually added to the value of the talk. So, again, that's what we decided to do. Lalit posted the talk on TV for Testers today, and I am now saying to those who would like to check it out, please do so.

Again, my thanks to Smita for asking me to put this together, and my thanks to Lalit for deciding he wanted to have it be seen. If you take the time to watch it, I also thank you for doing exactly that. To borrow from and paraphrase the recording artist Seal, "I hope you enjoy the presentation; it was the best material I had at the time" :).

Book Review: Zero to One

As a birthday/Christmas present, a  friend sent me Peter Thiel’s “Zero to One” in a four CD audio format. Peter reads through and presents nearly four hours of audio that goes much faster than the elapsed time would indicate. On the audio production aspects and delivery, it does very well. Having said that, how about the book as a whole?

Zero to One is a book about being an entrepreneur. For many of us, we may stop right there and think “ehh, I’m not an entrepreneur, so this book isn’t for me”. I would encourage anyone with that attitude to not think that way. Regardless of whether or not we work for a company, or we are the founder of a company, or we do freelance work in various capacities, all of us are entrepreneurs. In the curation of our own careers, absolutely we are. To that end, we want to create, to do something interesting, and maybe, dare we say it, change the world.

Most businesses we will see tend to copy someone else in some capacity. They are content to copy what has been successful for others. This is what Peter refers to as "One to N” improvement. It’s incremental, it’s a shaving of time, it’s an improved efficiency, it’s streamlining of process. It may keep you afloat, but it will not rocket you ahead. For that, you need a different approach, a true sense of innovation, a mindset that will bring you from Zero to One.

Thiel presents many anecdotes from the past thirty years in Silicon Valley, with many familiar stories, ups and downs, and memories, oh the memories (having been at Cisco Systems in the 1990s, and with several smaller companies through the ensuing fourteen years, Thiel’s stories are not just memorable, they are my history, and some of the stories hit a little too close to home ;) ).

The book is structured around seven questions that any company (and any individual) should be ready and willing to ask themselves before they commit to a venture or creating what they believe will be a “killer startup”. Those questions are:

Zero to One:  Can you create something new and revolutionary,  rather than copy the work of others and improve upon it?

Timing: Is NOW the time to start your business? If so, why? If not, why?

Market Share:  Are you starting as a big player in a small or underserved market?

People: Do you have the right people to help you meet your vision?

Channel: Can you create and effectively sell your product?

Defensibility: Can you hold your market position 10 and 20 years from now?

Secrets: Have you found a unique opportunity or niche others don’t know about?

Additionally, Thiel encourages that any product that will qualify as a Zero to One opportunity will not just compete with other options, but it will offer a 10X level of improvement over what has come before. If it doesn’t, then competition may overtake and erode anything you may offer. Harsh, but perfectly understandable.

Thiel addresses topics like success and failure, of disruption and collaboration, of replacement and complementarism, and of the fact that any real good technology, no matter how good, needs to be sold and marketed. Engineers believe that if their products is as good as they think it is, it will sell itself. History shows time and time again that that is not the case, and Thiel comes down hard on the side of sales being a driver, and that sales must be shepherded.

Bottom Line: Zero to One makes the case that true entrepreneurship needs to start from the idea of doing something unique, and being willing to look at the seven questions realistically and determinedly. If you cannot answer all seven of the questions with a YES, your odds of success are greatly diminished. Even if all seven can be answered with yes, there are no guarantees. This book is not a tell all guide as to how to be an entrepreneur, but it does give some concrete suggestions as to how to approach that goal. It’s a what and a why book, not a how book, at least not a "formula" how book. It does, however offer a lot of suggestions that the future entrepreneur, company worker, or freelance creator could learn a lot from. If you get the book, read it twice. If you get the audio version, listen to it three times. I think you’ll find the time well spent.

Diversity is More than Skin Deep: New Uncharted Waters Post

A short post to say that I have a new entry up over on the IT Knowledge Exchange Uncharted Waters blog. It's titled, "You Keep Saying Diversity, Does it Mean What You Think it Means?"

As I discussed in my live blog posts at EuroSTAR a couple weeks back, many of the discussions are based around "external diversity". Understand, the current environment for many companies and events makes that conversation extremely relevant. I am sensitive to the fact that there is not a broad representation in the computer sciences or in information technology, and yes, gender, ethnicity, and mobility are important areas to focus on.

Less discussed are the areas inside of each of us that make us unique, and dare I say it, possibly hard to manage. This article is meant to keep the conversation going and look at the other less obvious areas where diversity may be taking a hit, even while we are focusing on external factors.

Please have a look, share your comments on the article page, and hey, while you're at it, perhaps consider making Uncharted Waters a regular stop. Between Matt, Justin and myself, we post a number of interesting articles about software delivery, technology, work, the changing technical landscape, and yes, even some software development and software testing, too.

From Mid-Town Manhattan, it's #TestRetreatNYC

In the offices of LiquidNet, a group of intrepid, ambitious testers met and decided to discuss what aspects of testing mattered to us. Test Retreat is an Open Space conference, where the sessions begin when the participants want to have it begin (and end), the people who are there are the people who need to be there, and the law of two feet rules. We took some time to discuss topics, pull together similar topics and threads, and then head into our places to talk about the stuff that is burning us up inside.

---

The first session I attended was based around developing a testing community within a city or region. As many of us were part of different communities around the world, there were a variety of experiences, ranging from very small markets with perhaps a hundred testers total, to large regions with hundreds of thousands of testers, but little in the way of community engagement. 

Rich Robinson led the discussion and shared his own experiences with growing and scaling the community in Sydney, Australia. Rich shared that there were three areas that were consistently asked for and looked at as the goals of the attendees: looking for work, finding out the latest trends, and honing and sharpening skills. Rather than try to be all things to all people, they developed a committee and separate initiatives, with committee members focusing on the initiatives that mattered to them. For the group that wanted to get work, they made an initiative called “opportunity seekers”, and focused energy on those who had that as their biggest objective. For those who want to focus on latest trends, they have an avenue for that as well. 

Different regions have unique challenges. In the Bay Area, we have an overabundance of meetups for technical topics, of which a handful of them relate to software testing. As a founder of Bay Area Software Testers (BAST), Curtis Stuehrenberger, Josh Meier and I have chosen to try to focus on areas that are not as often discussed (we tend to steer clear of automation tools and techniques, since there are dozens of other meetup groups that cover those topics). Another challenge is frequency. In some cases, regular and frequent meetings are key. In others, having them less frequently works, but the key is that they meet regularly (monthly, every six weeks, or quarterly seem to be the most common models).

Rich also shared that their initiatives branch away from the formal meetup sessions, and have other opportunities that they initiate that occur outside of the formal meetup times. By having each initiative have people committed to it and resources to help drive those initiatives, buzz gets generated and more people get involved. One of the key things that Rich emphasized was getting people involved and engaged for these initiatives. The Sydney tester group has a committee of ten members that helps make sure that these initiatives are staffed and supported.

Another challenge is the local regions. Some cities have sprawl, others are difficult to get to in a timely manner due to traffic and population density. For example, the San Francisco Bay Area has four general regions: San Francisco (and the upper San Francisco Peninsula, Silicon Valley (and the lower San Francisco Peninsula), the East Bay, and the North Bay. With a few exceptions, people who participate in one generally do not regularly participate in the others. To reach out to a broader community in these sub-regions, it may require using technology and remote-access options for people to participate. 

Ultimately, growing a community takes time, it takes dedicated people, it takes a range of topics that matter to the attendees (including making sure that food and drink is there ;) ). To get those people you want to be involved, it helps to be very specific about what is needed. Saying “I need help with this” is less effective than saying “I need this specific thing to be done at this time for this purpose”. Specificity helps a lot when recruiting helpers.

—

The next session was “Sleep No More”, presented by Claire Moss, and focused on the model of the performance/play called Sleep No More (which is, in some ways, described as “an immersive performance of Macbeth”). It’s a darkened environment, all participants wear masks, no photography, no talking, just experience as the person sees it. Exploratory Testing, in many ways, has similarities to this particular experience. Claire used a number of cards to help display the ideas, and one of the first ideas she shared was “fortune favors the bold”. Curiosity and a willingness to go in without fear and deal with a substantial amount of “vague” is a huge plus. If you already have that, you have a strong advantage. If this is not natural for you, it can be developed.

Each room in the Sleep No More experience was part of the performance, and at any time, rooms could be empty or have people filter in during the performance. There are “minders” in the event that help to make sure that people don’t completely lose track of where they are. At times, there are very personal experiences that take place based on your tracks and where you go. Claire described a very intense experience of the performance based on where she went and what she observed and chose to follow up on. She also said that, up to this point, no one that she knew had anything like the experience she had.

The experience of Sleep No More was bizarre, creepy, full of strange triggers, and the potential to go into wildly unexpected direction. Software testing in many ways mirrors this experience. While there may be familiar areas and ideas, very often, our choices and angles may take us into very unexpected places. To give an example of the scope of the space, this was in a six story building, in an area that used to be a hotel (and whole areas of the building were gutted, in some spaces multiple floors were open to the air and visible). 

Claire described a feeling of “amazement fatigue”, where the level of stimulus is so high that there is no way to take it all in. The participants have to make conscious choices as to where they will go, and many of the participants will have wildly different experiences. Sometimes, they would follow a character, only to watch them go through a door and close and lock it, so that they couldn’t be followed any longer. This reminds me of following threads of a feature, and being brought to a dead end. People will observe different things, and they will also observe what other people do, and what they focus on. This can give us clues as to areas we want to explore next. 

This experience sounds amazing, and I am definitely interested in going and doing it myself, if time and commitments permit me to do so. Looks like I will be attending the August 10 performance :).

—

The next session was based on “Leadership”, and Natalie Bennett led the session with the idea that she wanted to see where individuals felt their experiences or needs for leadership were, as opposed to her telling us what she felt about Leadership and how to do it. Questions that Natalie wanted to discuss were:

- What is the purpose of a test team lead?
- What is it for?
What makes it different than being a test manager?

The discussion shifted from there into ways that test team leads and test managers were similar and where they differed. Some of the participants talked about how they led by example, and that they divvied up the work among the group based on the people involved and what they were expected to do. Team leads in general do not have hiring/firing authority, and they typically do not write reviews or have salary decision input. In other environments, the team manager and team lead are one in the same. There are some who are cynical about the effectiveness of this arrangement, while some feel that it is possible to be both a team lead and a team manager.   One attendee who is a Director of Q.A. for her company said that she was “the face of Q.A.” to the organization, and as such, she was setting the direction and expectations for the organization, as well as for her own direct reports.

Team leads are expected to teach and coach the members of their group, as well as be the point of contact for the group. It’s seen as important that they be able to focus on and develop their own role and make it responsive to their own environment. The team lead stands up for the group, and defends them from encroachment of issues and initiatives that are counter-productive to their success. Responsibility and authority tends to be on a sliding scale. Different companies allow for a different level of authority for the leads. Some give a level of authority that is just short of being an actual manager. In others, the leads is considered a “first contact” among equals.

One of the bigger challenges is to deal effectively when team members are failing. Failing in and of itself is not bad. It’s important to learn, and failing is how you learn, but when the failing is chronic or insurmountable, there needs to be a different level of interaction. Lean Coffee, direct mentoring, or even a serious re-consideration of experiences and goals can be hugely beneficial, both for the individual and the team as a whole.

—

Matt Heusser led a session about “Teaching Testing”, and some of the challenges that we face when we teach software testing to others. When we have an engaged and focused person, this usually isn’t a problem. When the person in question isn’t engaged, or is just going through the motions, then it’s a little more difficult.  The question we focused on at first was “what methods of teaching have worked for you?” Testing is a tactile experience, rather than looking at an abstract questions. We are familiar with questions like “how do you test a stapler?” or “how can you test a Rubik’s Cube?”. The presentation of this challenge may be the most important aspect. For some, they might look at “how do you test a stapler?” as demeaning. They are professionals, what is this going to teach me?

In my experience, one of the things I found to be helpful is to actually spell out how challenging the exercise could be. Rather than ask “How do you test a stapler?”, I might instead say “Tell me the 120 ways that you can test a stapler to confirm it’s fit for use?” This sets a very different expectation. Instead of saying “oh, this is trivial”, by seeding a high number, they may want to try to see how they might be able to meet or exceed that number. They become engaged.

To borrow a bit from Seth Godin, there are two primary goals for everyone. It’s the important aspects that we need to learn, regardless of the discipline. The first is to focus on authentic problems. The second is to be able to lead. Domain knowledge is a huge factor in helping to identify authentic problems. It’s not the only means, but getting to really know the domain can help inform the testing ability. Another important aspect is to understand how people learn, Everyone goes about learning a bit differently. Helping each person learn how they learn can be a huge step in helping to teach them. Sometimes the most ripe area of learning is to wade into an area where people disagree, or where there might be a number of people or groups where there might be dysfunction, where team members don’t talk to each other, or there’s simmering hostility between people. If there’s hostility between two programmers, and they write software that interacts with each other, it’s a good bet that there might be a goldmine of issues between their interaction points (I think this is a very interesting idea, btw :) ) .

Key to teaching testing is the ability to reflect and confirm what has been taught and learned, and for me, I think that Weekend Testing does this very well. The benefit of Weekend Testing, beyond just doing the exercise, is that we can see lightbulbs turning on, and there’s a record of it that others can see and learn from. Creating HowTo’s can also be a helpful mechanism for this. 

—

This section is the talk that Smita Mishra and I gave about “Hiring Testers and Keeping them Engaged Once We’ve Hired Them”. I recorded this session, and I will transcribe it later ;).

—

Claire Moss led a session on “Communicating to Management” and we went through and considered a list of questions that are important to frame the conversation(s):

What does quality like to our organization?

Why spend money on testing?

What does testing do?

What value are we getting out of testing?

I read this about QA, and it says we should do this… why aren’t we doing this?” 

These are all questions that we need to be prepared to answer. The question is, how do we do that?

There are several methods we can use, but first and foremost, we need to determine what we need to speak with management about, and if possible, use the opportunities to help educate them about what it is we can do, and at the same time, get a clear understanding about what their view of the world is.

Looking to standards and practices that are helpful can give us guidance, but it doesn’t always represent our reality. Information needs to be specific to explaining where we stand at the given time. Testing is primarily focused on giving quality information to the executives so that they can make qualified decisions. That is first and foremost our mission. Information that we can effectively provide is: 

- Framing of the ecosystem on a global scale (browser standards, trends, data usage histories)

- Impact on customers (client feedback, analytics data)

- Clarify issues and questions (heading off the executive freakout)

- Managing expectations (especially when dealing with something new)

- Explaining how likely issues brought to their attention really are problems worth investing in

- Explaining risk factors and methods to mitigate those risks

—-

At the end of the day we had a lot of new idea, feedback for some new initiatives, an emphasis on better communication, more focused due diligence, and the fact that so many participants had a lot they felt they could contribute. This was a fun and active day, and a lot of learning and connecting. One of the key things I am always impressed about when it comes to these events is that we really have a lot of solid people in the testing community, but we need even more.

I encourage every tester that admires craftsmanship, skill, and thinking make it a point to come to these now annual events (this is the third of these, so I think it’s safe to say that it’s a thing now ;) ). Once again, thanks Matt (Heusser) and Matt (Barcomb) for organizing what has becoming my favorite Open Space event. May there be many more.