On Value, Part 4: Testers Rising to the Challenge

This is the fourth  post which resulted from a simple question my lady-wfe asked at a local tester meeting recently.

This blog post described problems with value in testing.  The second blog post looked squarely at perceptions of testers as unskilled, non-knowledge workers and the lack of response from a large number of testers.  The third post looked more closely at the source of such perceptions on testers being unskilled, non-knowledge.  This post is a discussion of what testers can do in response to such perceptions.

How many people do we know who collect a paycheck for "testing software" who can not be bothered to do any more than their collective bosses tell them?

Story 1

I know one manager who is active in the community who went so far as to offer for pay for his team to go to any conference or training event they wanted to go to.  He offered to pay for AST's BBST courses (which absolutely rock, by the way).  He offered to send them individually where ever they wanted to go to learn, confer, whatever.  Not one person expressed any interest.

That is a problem.

Story 2 - one of my own

I remember one team I worked with.  I asked them what defects were being reported by customers of the software.  They responded with a long list of "Well, there's this and this and this and that and then this weird thing and..."  I asked if maybe we needed to reconsider how we tested.  UNIVERSAL RESPONSE:  "Why would we do that?  They are using the software wrong.  If they used the software right, they would not have those problems."

Story 3 - another one of my own

I remember another team I worked with.  That team, on the first day I was there, not just the boss, but the TEAM said "We have a problem with our testing.  We're doing the best we know to do and we catch a lot of stuff but there are still defects getting through and being found by customers.  If you have any ideas on how we can test better, let's talk about them."

Guess which team was a lot more fun to work with?  Guess which team saw broader product examination and evaluation?

These teams demonstrate precisely what I see as the problem with the majority of people in software testing today, and as long as I have been involved in software.  One group wants to learn more, does not know where to begin and dives in headfirst to learn.

The other group is perfectly justified in their minds that they need to change nothing.  The boss they had 3 bosses ago said "Just do it like this."  They do.  Now, several years on, they have not changed.  They added more people to do more of the same.

A Problem

In the stories above, the folks in story 1 demonstrated precisely one aspect of the problem.  The folks in story 2 demonstrated another.  The third group was the antithesis of both - and a hopeful sign.

While many people in many lines of work expect nothing more than they are given, in training, understanding, pay or ambition, others expect to be told precisely where they fit.  Anyone looking to develop them as craftsmen was a threat - upsetting the status quo is a, well, problem.

People want to walk in 2 minutes before starting time, do their thing and go home.  Ideally, they don't want to think about anything work related until its time to walk in the office door the next morning.

Fine.  I can really empathize with that.

I'm not talking about thinking about your job I'm talking about your profession - your chosen trade and craft.  Alas, it seems some folks don't think that way.

Upshot of That Problem

If you or people you know are in that camp, I fear you might want to look for another line of work.  I might suggest you look for a line of work that requires you to not do outside study, on your own, at your own expense.  Off the top of my head, I suggest you not look at these lines of work, all of which require you to do precisely that, if you wish to become good:

• Teaching (anything at any level);
• Law (anything related to law);
• Computer Software (that one is kind of obvious);
• Project Management (more than just software projects, lots of things need project managers);
• Accounting/Accountancy;
• Show Production (Music, Stage, Theater, Television, Motion Picture);
• Advertising;
• Distribution Center Management (that's how to run a warehouse);
• Commercial Truck Driving (or lorry driver);
• Commercial (other) Driver (bus, taxi, car-for-hire);
• Restaurant Manager/Owner (that one is really harder than most folks think);
• Chef (not a cook, but a proper Chef);
• Carpenter/Joiner;
• Construction Contractor/supervisor;

You get the idea.

Jobs that require you to do no development on your own are jobs that will go away - at least from you.  They may get sent to some other country where labor rates are lower - and low enough to off-set the cost of transporting the components or finished product back to end-market areas.  OR it will go away because a machine will do it instead of a human person.

We're big on buggy-whip analogies when we want to make a point about people not keeping up with changing times.  Well folks, Swiss Watches fell into the same boat as buggy-whips.  Not anachronistic, just too expensive and a function that can be done by a commodity item, instead of the product of an artist.

As I See It...

You can make all the cases you want about what value testing bring to a software organization.  You can talk about how your testing improves the quality of the software product.  You can talk about all this stuff.

It does not matter.

If someone or something can do the same thing you are doing, with about the same results, and it costs the organization less money, they will replace you.

Ask the thousands of manufacturing workers who lost their assembly-line jobs in the US starting, well, in the 1970's.  As the shipyard workers in Belfast and Glasgow in the 1950's and 60's.  Ask any of the miners anywhere, mining for anything, that have been displaced by machinery.

And that is the problem.

We, as a profession, have failed miserably in demonstrating that the Tayloristic management theory does not apply to software development - which includes testing.  

Why is this?

We have failed to address the solidly formed and closely held management belief that repeated practices will ensure quality products.  Concepts developed for assembly-line workers, when applied to knowledge work, fail.  Full stop.

Why is that?


Because no human being thinks in a linear manner.  We simply are not built that way.  Knowledge work requires a level of cognitive insight and practical experience to draw on to inform that insight when it is being done well.

Having everyone think about a problem in the same, precise, linear way is only possible if everyone involved has the same experiences, understanding, thought processes an bias. 

Introduce one variable that is different and the wheels fall off.  The model fails.

Addressing the Problem

After great thought, many conversations, and now at least four blog posts mapping my consideration of my lady-wife's question, what has been determined?

OK - I've edited this 4 times.  This is take #6.  And its also the most polite.

The simple fact is, we're pretty clueless when it comes to what testing is, how it is done and why we do it.  A fundamental failure.  The vast majority of people involved in software simply don't get it.  This is true of many people who are supposedly professional testers, their bosses, their bosses bosses, project managers, subject matter experts, developers and - anyone who works with them.

Testers MUST educate themselves.  If they rely on the company they work for, that will be a mistake.  They don't get it either.  They THINK they do, and they usually don't. 

I can give my definition for testing.  Some of you may say "Ah! He has clearly been influenced by the work of ... a bunch of people."  Some of you may say "Pete, you're wrong and here's why..."  Others might just say "Meh, whatever." 

That's fine.  But talk about it.  You don't need to agree with everything I say or what someone else says.  You do need to think.  Then you need to communicate.  Then you need to think some more.

Find many, many sources of information - then share them with others.   Talk about them - agree, disagree, whatever.  Share ideas and learn.

When we as testers limit what we do by some narrow definition or purpose, every project, every time, what are we really doing is boxing testing into a corner. 

When we do that, we limit what testing is.

When we do THAT we fail to be true knowledge workers.  We fail to think fully, and we walk right into the self-fulfilling prophesy that started this series.  Testing is treated as a commodity.  Many testers have been participants in that disservice.

When we fail to to broaden ourselves, we limit ourselves. 

Broadening Testing

We must broaden ourselves, our profession, our views, our colleagues views, our employers views.  We must engage directly in combating the "just test this" mindset.  We must confront the "anyone can do this attitude" that is so pervasive in so many circles.

If you are reading this, thank you.  I believe that the this is a start.  Reading blogs, papers, articles and anything where people are sharing ideas and thoughts around software testing is a start. 

Then write your own.  Spread the word.  Don't care if you are not an expert.  I'm not an expert.  Most folks I know are not experts.  Some people THINK those folks are experts or authorities, and they simply don't consider themselves as experts. 

They do care about what they do.

You can to.

That makes you an expert. 

If you have a blog on testing, please leave a comment below with how we can find it. Thanks.

On Managers and Mothers and Bush Trimmers

As I'm writing this, it is the evening of Mother's Day in the US.  Because the weather was lovely, much time was spent in the garden this weekend mowing the lawn, trimming bushes, preparing the vegetable garden for the summer. I then took my lady-wife and mother to dinner where we had a lovely meal with nice conversation, a very drinkable bottle of wine and cannoli for the mothers in the party.

It has been a remarkable spring. 

The apple blossoms are done - no surprise there.  This is fairly normal for us.  The pear blossoms are done.  This is unusual.  Lilacs are done - not terribly unusual.  The tree peony are done.  Tulips are done - again not that unusual as they often are.  Its a little odd that the late blooming variety are done as well, but, that is not far from the realm of possibility.  Let's see.  Hmmm.  Oh yeah, iris are in bloom and there are peony ready to bloom.  Those two are unusual for mid-May in Michigan.  July is closer to the expected.

Oh, the stuff that is done?  They all bloomed within a few days of each other.  By mid-April.  That is not only unusual.  It is remarkably unusual.

Right then.  What does this have to do with anything?

On Shrubbery

Well, a few years ago, some friends were over visiting a day or so after I had trimmed the bushes in front of the house.  He (Dan, the male in this married couple, and father of a bright boy, married to the boy's mother)  made a comment, asked a question really, "Who trimmed the bushes?  They look very... zen."

I had.  I tend to do that a couple of times a year, three depending on the particular year and how much the bushes have grown.  You see, left to their own devices, shrubs - there are a couple of good-sized arbor vitae, a healthy juniper and a couple of others that I have no idea what they are.  The thing is, when it comes to trimming bushes, shrubs whatever, some of them can be trimmed into shapes really easily and will do quite well.  Others will struggle, sicken and eventually die.

As a shrub grows,and is untended for some time, it will do what ever it pleases.  It will stretch for light and water and... right you get the idea.  The thing is, if the thing is left alone, it will grow quite... big,  These were quite large the first time I tried to prune them.  How do you prune something that is probably larger than most people have them, and still allow them to be healthy and thrive whilst doing what they are supposed to do?

How does one get the most out of anything, help it develop to its full potential and achieve the goals one sets for it?

Well, with bushes, its pretty easy.  You can trim the recent growth, prune the large branches that are sticking up and neaten up the edges.  Maybe give it a nice round shape.  The thing is, from this point you can direct its growth from this point by trimming given branches one way or another - yet always allowing the bush to be a bush. 

So, this got me thinking.  It is, after all, Mother's Day.  Never having been one you see, how does a Mother guide her children in their development, growth, etc.?  I have my ideas, but, like I said, I'm not a mother - grandpa, yes, dad - well, I've played one now for an awful lot of years.  But, how does one teach young people to grow into, well, mature, positive people?

On Mothers

How does a good mother raise children?  Well, I can talk from observation of how the lady-wife and my mother tried - they focused on getting the best from their kids all the time, encouraging them to try things, if they wanted, and sticking through the commitment after starting.  Backing out after starting when things are hard or unpleasant or, boring, was discouraged.  Firm, yet loving might be a good short description.

My siblings and their spouses are using (or have used) this general approach with their kids.  Other folks we know are trying as well. Finding the balance is a challenge.  Learning what will motivate people and what gets them all excited can be a challenge - as any mother (or dad) with more than one child.  The fact is, one-size-fits-all style approaches simply do not work for raising kids - or bushes for that matter.

Some folks tell us that mothers always will do the right thing for their children.  Maybe in a movie.  I don't know.  There are plenty of examples of mothers who did a terrible job and were amazingly horrible at being mothers.  Let's face it - some people are not cut out to be mothers.  (Same with fathers, but my mind was wandering around on mothers today.)  They may want to be mothers, or think they do, but really, they have not considered what it means to be a mother at all, how much work it is and how long that work will continue.

The lady-wife tells people that becoming a mother is a life-changing event that will continue for the rest of their lives.  Once they become a mother, as long as they are alive they will be a mother.  Its a pity that some who chose to do so are not very good mothers.  I think sometimes people forget what their role is.

This got me thinking.

On Managers

Why do some managers try the one-size-fits-all when it comes to career-development, professional-development and generally assisting their staff to improve and grow?  Why do some people believe that the motivational devices that work for one or two people will work for everyone?  Yes, I know - it is up to the employee to seek out and strengthen their career - it is their career after all.  Still, managers can encourage them and show support to them for learning more and broadening their skill-sets, even if it includes learning concepts that may not be directly applicable to what they are doing right now.   After all, the way technology changes, what is to prevent them from learning something that will be helpful to them, the team and the broader company on the next project or a future project? 

Compared to mothers, managers have it easy.  They can become an "un-manager" by changing jobs, quitting, retiring, getting fired... lots of ways.  I wonder if people who want to be managers before they actually are managers would still want to be a manager after they learn the  reality of how much work it is.  Then again, if becoming an un-manager was as difficult as becoming an un-mother after being a mother (or a manager) I wonder if that would change how badly people want to be managers.  

Still, we have our own bias, don't we?  A fair number of people presume that because they wanted to become a lead and then a manager and then some higher level of boss, that the really good testers want to do the same.  Possibly the really not-so-good testers do as well.  I suspect this is because we see this path (novice >  experienced > really experienced > lead > manager > bigger manager > knight > Earl > King) as the only way to measure success.  Because "moving up" in the organization is what we are told is what we want to do - and some people really DO want to move up - then that is what everyone wants to do, right?

Or are biases and personal views getting in the way.  Mom wanted to take ballet when she was a little girl so darn it, her daughters will take ballet.  They only THINK they want to do soccer or karate.  But that can't be part of the one-size-fits-all thing right?  I wanted to be a manager so Joe must want to be a manager too!  I'll get him going and he can move up instead of being just a tester.  That is not part of the one-size-fits-all thing either.  Right?

So, Managers and Mothers - consider what it is that you want for your people - either staff or children.  Is that what you want or is that what they want?  We can't always get everything we want - I know - there's a song about that, right?

The question boils down to this - are we trying to shape out children and our staff in a way that they can be shaped or are we trying to force them into something they can not be?   Shaping and pruning them to enhance their growth will result in an amazing thing of beauty - a well-formed person.  If we force things they can not support, there is a chance they will wither and never achieve the potential that is theirs.

To all the good mothers in the world, I salute you.  Likewise all the good managers.

Bushes, shrubs and hedges?  My hedge clippers and pruning shears are cleaned and sharpened for the next time I need them. 

So Much Older Then, Or, What Was Old Is New Now

Not so long ago, a significant portion of persons of a certain gender and a certain age range (at least in the US) were completely taken up, head-over-heels, gaga-over or enthralled by a series of novels about, yes, vampires. 

Yes, the un-dead, feasting on the mortals around them.  Living on the fringe of society, moving in and out with grace and ensnaring people with their obvious charms. 

Yup.  Interview With a Vampire was a really popular book and movie franchise.  

Wait. 

You thought I meant the Twilight series?  Really?  My oldest granddaughter (a pre- and early teen when the Twilight books first came out) certainly was enthralled by them.  My lady-wife? nah. Me? right.  Do I LOOK like someone who would be enthralled by them?  Not likely. 

Yet, the lady-wife made an observation one night as we were sitting sipping a glass of wine, and watching the 1979 film Dracula. She said "I think every time a new vampire novel or movie comes out, people who have not read or seen the earlier ones latch onto it as if this was the first time anything like that was written."

I've had some conversations with testers and other software folk recently that have convinced me that the lady-wife's view can apply to software development as much as, well, vampire novels and movies.

Part of this is time and age - Some folks of a certain age have seen the same set of ideas come around two or three times.  Slap a new label on it and standard fare from my first programming gig in the early 1980's is all shiny and new.  Just a new buzzword.  In the meantime, there was another buzz-word label for it maybe 10 or 15 years ago. 

I've seen a fair number of "hot trends" in software design and development come and go and come back and go and... heh - kind of like vampires I guess.  They just WON'T STAY IN THEIR GRAVE!

Maybe that is because the underlying problem they were meant to solve was not solved.  The hot trend that replaced them that was absolutely going to solve the problem, did not solve the problem either.

I think back to how eager I was - how ready to change the software world I was - and how I tried to convince the older, kinda-stodgy folks I worked with that I had this bright and shiny new way of doing things.  One of them would sit back and tell a story from 15 years before.  I'd wonder what THAT had to do with Real MODERN software design and development - I mean, punch cards? Might as well be stone tablets, right?  Ah, the enthusiasm of youth.

As I was thinking about this, over a glass of medicinal single-malt scotch whisky last night following the local tester meeting, I got to wondering if the ideas that were bright and shiny-new for me in the early 1980's were retreads of other ideas.  So I dug out some of my older books - stuff that was on the shelf for some time without being disturbed.  I flipped through some of them and ... gads.  There they were!

I wonder if instead of vampires, these ideas were really closer to the immortals in the movie (not the TV series) Highlander - with Sean Connery playing an Egyptian in the service of King Charles V of Spain... with a Japanese katana. (Yeah, that one.)

Ideas don't die - they can't be killed because they are immortal.  You have to take their heads off with a sharp blade to really get rid of them.  If you don't, they'll go underground for a while, change their identity and then come back.  They are always there if you look carefully.  Most people don't look carefully though.

The reason, as near as I can tell, is that the behavior - the underlying mannerisms and actions - of the humans who are developing software have not really changed since Admiral Hopper's team discovered the first "bug" in the computer.  (I know she was not an Admiral at the time, but, you get the idea.)

Our flawed views impact our flawed behaviors which directly impacts our practices in developing software which directly impacts what we put out and what we make and how the software works and interact with humans and their flaws and imperfections and... you get the idea. 

Maybe when an enthusiastic young software person (designer, developer, tester, analyst of any sort) comes into my office with an earth-shattering idea, I may resist the urge to sit back, sip my coffee, stroke my beard and tell a story from 20 or 25 or ... more years ago that leaves them wondering what anything done in COBOL on an IBM Mainframe has to do with modern software development using ... fill in the blank for whatever technology your shop uses. 

What I have learned is that the technology changes.  It changes very quickly - far faster than I expected 30 years ago.  What has not changed in that time, and seemingly has not changed since the time of, well, ever - is how people make things - software in this case and how they interact with those things and each other. 

For those who have not seen anything like this, let me say quite simply.  The problem with computer software has nothing to do with the computers or the software.  The core problem is the behavior of the human persons around it - those who develop the software, design it, use it. 

It took me a long time to understand this, and I think I am beginning to see that I, and many others, have spent most of our careers trying to solve the wrong problems. 

We have been trying to use technology to address a technology problem.  The problem is not in the technology - it is the behavioral relationship we have (both developing and usiing) that technology.  Until we find a way to address that I expect we'll continue to see bright shiny-new labels slapped on older approaches and techniques.  We will continue to have slick snake-oil sold to bosses as THE SILVER BULLET to solve all their problems.

The fact is, none of those things will work.  We need to fix the underlying problem - what we have been looking at "fixing" are the symptoms.

I think this will be an interesting journey.