I Am A Software Tester

What I Do

I test software.

I learn how the software behaves and report on it.

I do not break software.

I exercise software and look to address the questions of stakeholders around how the software works.

I consider formal "Requirements Documents" to be information points for my investigation, nothing more.

When the software is being developed or modified, I look to the reason why it is being developed or modified, not merely how.

I look for the need the software is intended to fill and the wish the software is intended to address.

I look for the value people wish and hope the software to bring.

When the value and business purpose, as stated by the stakeholders and sponsors of the effort, is not being achieved I stand up and say so.

When the "Documented Requirements" are not in alignment with the value and business purpose, as stated by the stakeholders and sponsors of the effort, I stand up and say so.

I say these things openly, in public, not in a closed room.

I look to see how I can contribute to the effort beyond exercising software.

I look to see how I can support the BAs in representing the wishes and desires of the stakeholders and sponsors of the effort,the customers on whose behalf we are working.

I evaluate and exercise stated requirements and search out those that are presumed.

I look to see how I can support the designers and developers in clarifying what is meant when documents are unclear.

I evaluate and exercise designs.

I try hard to smooth the effort and move work without sudden jerks, fits and starts.

I try to build consensus in the team over the behavior of the software and how it relates to the stated intention and purpose.

I try to speak for the customer when no one else does so.

I do not assure anything.

I challenge assurances.

I challenge assumptions.

I challenge presumptions.

I challenge the status quo.

I challenge my role on the project.

If I can not add value on a project in any way, I say so and withdraw when that is the best thing from the project, the group and the larger organization.

I help raise people up.

I help colleagues see what is possible, not merely what is now.

I help them be better at their craft when they express a desire to be better.

I strive to become better at my own craft and work to learn more.

I am not a master; I am an apprentice constantly learning my trade.

If people look to me for assistance, I will give it if it is in my power to assist them.

If people do not want assistance, I do not impose my assistance on them.

I try to make things better.

I try to make software better.

I try to make communication better.

I try to make myself better.

I think.

I am a software tester.

Observations from Test Leadership Camp, part 2: Defining Leadership

Test Leadership Camp was held the Thursday after CAST in Madison, Wisconsin.  These are my own thoughts based on notes, recollections and tweets made during the day.  I'll be writing up thoughts and recollections from this in several posts.  This is the second.  The first is here: http://bit.ly/1aXfJrY .

A less energetic, and perhaps more thoughtful, conversation at Test Leadership Camp which I participated in was one focused on defining leadership and test leadership in particular.  It may seem odd to have a session on "what is leadership" at a function ON leadership, however, with an eye to "define what we are about" this session was intended to frame future discussion and help the participants wrestling with how to express fundamental ideas. 

In no particular order, things I know were mentioned:  Gerry Weinberg's "Becoming a Technical Leader"  ; Matt Heusser's observation that "If you think you are a leader, every once in a while look over your shoulder.  If no one is following you are just some guy going for a walk;"  behavioral characteristics of what we'd expect in a leader; being a "leader" does not mean one is always a thought leader.

Lesson 1?  Too many people conflate "leader" and "manager."  For purposes of our discussion, the focus was on Leaders - not Managers.   

After much discussion, we landed on a fairly simple definition for a leader.  A Leader is one who influences others, who them want to follow (the leader.)  This seems almost obvious.  Except remember that some times, folks may not want to think about themselves as leaders.  They may simply see themselves as, themselves.  This is part of the conflation of Leader and Manager.  This is worth deeper thought.  (and not part of the discussion, which is the point of this post.)

One path we DID go down, was the idea of an unintentional leader.  They are doing their thing and - SHAZAM!  People are talking about them as if they are leaders.  The thing is, they are going somewhere and others seem to think that may be a good place to go as well - so they follow.  Whether they wish to be leaders or not, they are one.

This brought us to the idea of Authority and Leaders / Leadership.  In some instances, the authority is positional - it comes with their job.  For other folks, the authority comes not from their position, but from their experience.  When you have seen stuff, experienced stuff, and been around the block a couple of times you can, possibly, anticipate options and formulate possible paths based on those things - those experiences.  This gives them a different perspective from people working from theory and case studies.  In some contexts, this tends to lend a certain weight to their ideas and opinions. 

Two really straight-forward ideas.  The first was Leaders need to know themselves and be honest with themselves.  Leaders, in all forms, need to be aware of their own weaknesses and be honest about them.  In doing so, they must also learn from their mistakes.  Related to that, they must be open to learning from others.  

The second was one I've blatantly lifted from my lady-wife, Connie.  She comments on people being trustworthy "when their words and actions match."  Part of that also implies an honesty with each other (tied to the above point, of course.)  Having said that, the trust factor of the leader will go up when the people around that leader recognize that honesty. 

One important point was a simple warning - test (or any technical) leaders may not be "thought" leaders.  One thing interesting is that people may be sharing other people's ideas with their company or team, like, ideas they picked up from a conference, and make it clear they are not their ideas.  Still, for the company, they are "thought leaders."  Reporting other people's ideas may be a form of thought leadership in some form.  (Having said that, from my own experience, its a little uncomfortable for people to slap labels on you when the ideas are not yours and are still "cool things to look into more.")

Lesson 2?  The signs and traits of Leaders apply to more than Test Leaders.  These tend to apply to many forms of technical leaders.

Observations from Test Leadership Camp, part 1: Best Practices

Test Leadership Camp was held the Thursday after CAST in Madison, Wisconsin.  These are my own thoughts based on notes, recollections and tweets made during the day.  I'll be writing up thoughts and recollections from this in several posts.  This is the first.

Overall, I found the discussions and the ideas exchanged engaging and informative.  The drawback was it was impossible to be in all of them at once.  The first discussion I was in (with a floating group of participants involved) was around concepts of "Context Driven Testing." Right out the gate in the conversation was "There are good practices in context, but there are no best practices."  The short-hand version most folks use turns into "No Best Practices."

No "Best Practices"

What does this mean?  James Bach, Cem Kaner, Brett Pettichord and others have written on the topic at length.  Let us consider where the ideas behind CDT came from.  Generally, and this is my perception, they were a reaction to a mix of bad practices, untenable approaches to testing with much overhead and little to no value and, as more than one person describes it "Snake Oil."

A cornerstone of the "Snake Oil" approach is to rely on "best practices."  In testing, these tend to be something that worked well, by some measure, in some project at some point, somewhere in the past - either the company's or the individual's.

A heated part of the conversation was around what was meant by rejecting "best practices" in testing.  We settled on a phrase from Paul Holland - rejecting "best practices" means we "do not blindly follow process" models.  Simply because something, a practice, a technique, whatever, worked on a project once before, attempting to apply the same on another should be considered carefully before adopting or repeating the practice, even if it is for the same company, the same team and on the same software product. 

This actually is more than reasonable.  In my own experience, talking with test managers - the line managers supervising testers - they "get it" fairly quickly, if they are open to discussion.  If they are so tied up with other aspects of "Administeria" they are likely to reject any idea that does not originate from upper management.  This tends to be found in companies with several layers of management.

For smaller organizations, I find this tends to be less of a problem.  It may still be present, but there are fewer layers of pointy-haired bosses to deal with.

The challenge, as I see it and from experience, is getting the point of Context Driven Testing beyond the line manager and into upper levels of management.  The first stumbling block is the idea of "no best practices".

Here's what I mean.

Best Practices and Management

The idea of "no Best Practices" for managers with backgrounds other than technology is that it seems counter-intuitive.  They come from backgrounds where "Accepted Practices" are considered normal.  Anyone ever work under a big boss, a manager of managers, who was an accountant?  The idea of "Generally Accepted Accounting Practices" is ... pretty normal.  The concept of "Best Practices" seems a continuation of that.

Other times, people like to sound smart.  They want to be among the "cool kids" so will adopt their terms, buzzwords, and sometimes, bad habits.  If they use the "best practice" thing, and we walk in and tell them they are wrong, and all the stuff they've been talking about doesn't is smoke and mirrors - how well does that work?  Consider the Jesuits who went to Japan in the late 1500's.  How well did THAT work?

Even if they KNOW it is smoke and mirrors, they are unlikely to admit it to their own employees, particularly when they work several removes away from them.  They may admit it grudgingly to consultants, but there is little certainty that ONE person coming in contradicting the many others will make a dent.

One observation that came to me some time ago.  If you can't have a conversation with your boss's boss on something you are passionate about, or even on something you like and maybe they like as well, how are you going to get them to consider alternatives to what they have been told is a real thing?

Note - if you are working for a small company, like fewer than 50 people, and you can't discuss the differences between types of coffee with a CxO/President type, and you are both getting coffee from the pot in the break room, do you really want to work there?  (Don't ask how I learned that heuristic.)

Consider this - The CEO - the nemesis of many tech folks, is a human being.  They are remarkably similar to you in many ways.  They have their strengths and weaknesses and foibles and fears and... yeah,  Same thing with the CIO or any other CxO type person - or VPs or Directors of Whatever.  If you can't have a conversation on something you have in common, like coffee or tea or beer or music or something how do you intend to talk with them about this idea of "best practices"? 

The question is, can we reasonably and logically make a case, without causing offense, that refutes the notion of a simple solution that is "tried and true" without considering other options?  The challenge is to present the path that explains the fallacy of embracing practices simply because they worked, by some measure, in some other context, when other practices and techniques may prove of greater worth.

On Management or The Hole In My Bucket Problem

A second blog post written originally in long hand while camping at the Wheatland Music Festival.  The first one is here.

September 7, 2013

The idea behind "empowered" workers, staff, whatever, is a fantastic one.  It sends us off dealing with problems left and right.  We slay giants, send dragons to their doom and overcome all sorts of obstacles.  This model works amazingly well, until we run into a situation where it doesn't work and we need the support of a boss-type to knock a hole in the wall or find us a bigger ladder or help dig the tunnel under it so we can get on with what we are supposed to be doing.

Managers are good at that sort of thing, usually.  I had one manager several years ago who laughed at me once saying "Walen, can't you, just once, bring me an easy problem?"  My response was, "I don't need help with the easy problems.  I can deal with those.  When the problem is another manager, I need someone with at least as much stuff on his collar as he does to deal with it." (He was a retired Army officer, such references carried a certain weight with him.)

Usually, he'd deal with it.  Sometimes, he'd propose a solution I had not considered.  I'm not certain, but I suspect I contributed to him deciding to retire.  (If you're reading this - "Hi Gay!  How's things?  That M47 still looks pretty impressive.")

Then I've had other managers who were closer to the pointy-haired boss type from Dilbert.  The ones who apparently have no idea what their staff does, nor any appreciation for the complexities of the problems they are describing and need help with.  The result sometimes is "help" that is no help at all.

An Example.

Maybe you've heard the joke about a fellow walking through a field and observes (astutely) a hot air balloon roughly 100 feet above the field.  A fellow in the balloon's basket calls down to him "Can you tell me where I am?"

Being a very accurate observer, the fellow walking through the field calls back "Yes. You are in a balloon approximately 100 feet above the ground, 25 feet ahead and slightly to my left.  You are over a fallow field with tree's roughly 300 yards ahead of you, relative to me and 50 yards to the right, relative to me." 

The fellow in the basket calls down, annoyed "You must work in IT!  You have given me very detailed information, none of which helps me at all! Thanks for wasting my time!"

The fellow on the ground calls back "You must be a manager, probably in upper management.  You got yourself into this situation and now its my fault!"

And What Prompted This

These things came to my mind listening to some folks playing music in or campsite last night (Friday).  One fellow was a guy I used to play in a traditional/folk band with.  We used to play a mix of Irish and Scottish songs and traditional tunes.  He was playing guitar and singing with his sister, doing a bit their parents did when they were kids.

Maybe you've heard the some "There's a Hole In My Bucket?"  Where a fellow says to "Liza" "There's a hole in my bucket."  She very helpfully says "Well, fix it."  He does not know how (hence the problem.)  Which in turn Liza says "With some Straw, dear Henry" (the names sometimes change, but you get the idea.)

Well, poor Henry needs more guidance, "But the straw is too long."  "Then Cut it!"  Well, Henry does not know what to do about cutting so Liza suggests a knife.  The knife is not sharp enough to cut the straw, so sharpen it on a stone.  Except the sharpening stone needs to be wet to effectively sharpen the stone.  So get some water to wet it with and then sharpen the knife to cut the straw to mend the hole in the bucket.

Which leads Henry to respond "With what shall I fetch it (the water)?"  Liza serenely (more likely very frustrated by now) says "the bucket!"  

Which brings us back to "There's a Hole in the bucket, dear Liza, dear Liza.  There's a hole in the bucket, dear Liza, a hole."

As a children's song, its rather funny.  Henry is obviously clueless.  So Liza needs to explain everything to him. Except maybe he's tried these ideas and is still stuck. 

How many times have managers and leads and seniors leapt to a conclusion on how to fix a problem without considering the problem from the perspective of Henry.  The "obvious" solution may be not so obvious after all, when you look at all the pieces.

And So, 

Dear Liza, don't write off the problem before you understand Henry's frustration and his perception of the problem.

Managers and leads - Please take the time to hear what your people are really saying when the words sometimes fail them.  They will appreciate you more and you won't look and sound like Dilbert's pointy-haired boss.

On Leading, Managing and Sense of Purpose

This post was originally written longhand (as in by hand, in a bound journal, pen on paper) while sitting at a campsite at a traditional music festival.  Sometimes I go places where electricity is not needed and internet access seems inappropriate.  It helps to defocus sometimes over an extended period of time.

September 6, 2013

Sitting under a canopy at a campsite at the Wheatland Music Festival may seem an odd place to consider Leadership and Management. There are similarities between the two, which is partly why the terms are conflated so often.  The similarities and differences are being demonstrated all around me this afternoon.

One group, behind me, is discussing "setting limits on how much" soft drink, beer, whatever (not sure what exactly, other than the excited voices on the topic) can be had; how much per person per day to be sure each person gets their "fair share."  The primary concern seems to be on running out today, Friday, and not having enough to last through the weekend.

Another group, across the fire lane from us arrived at about the same time as the group behind us.  They set up their camp, set up tables and set out coolers and got out their instruments and began playing music.  Very good music.  They have been doing so for well over an hour.  About the length of time the first group has been discussing "limits" and "fair share."

The second group is more about what the Festival represents than the first.  They collectively and individually know what they are about and why they are there.  Granted, there could be a difference in age, maturity or something. 

Of the two groups, one appears to be mostly in their mid-20's, roughly 24-27 or so (I can't see them very well without being obvious.)  The other group. the one playing music, is predominantly in their early 30s.  (I took the direct approach and asked how long they had been playing and if they played together as a band and got their musical life story.) Age does not seem to be a major factor - a few years perhaps.

Maturity may be part of it.  Still, when the music stops, they tell much the same types of jokes and demonstrate the same style of humor as the other group has, off and on.  Frankly, when they are not playing music they remind me and my wife of, in her words, "puppies playing."  A bit of romping, a little rough housing, all in good fun careful to not hurt anyone.

Still, when one of them starts a tune, the others launch into it with fervor.  Their  this weekend seems to be to play music, meet people and have a good time.

The other group?  I'm not sure what their purpose is.  They seem to not know what their purpose is either.  They have, after well over an hour, agreed on a lot of rules, but I'm not sure if they have agreed on why they are there. 

They have defined a process model for something and agreed on how to manage the process model.  After some 90 minutes, they do not yet seem to have agreed on what purpose the process model is to serve.

They do not yet seem to have agreed on a reason for the process model to exist. 

Perhaps that is the difference.  One group has a shared purpose - a sense of why they are there.  "Leadership" of that group changes hands whenever someone starts a tune.  The other group?  They are managing their group but failing at leading it.

NOTE - Sunday morning, it became apparent that the non-musical group was a collection of people, parents and grown children and friends of each generation.  This made clear some of the phrases that came up over and over.  It should also be noted there is a shuttle bus that runs from the festival grounds to the nearest town with grocery stores, beer, wine and liquor stores and the like, every 30 minutes.  "Running Out" did not need to be a disaster, merely an inconvenience.  Their purpose seems to have been to have a good time.  I do not know if they succeeded.