Sunday, April 26, 2015

Community & Conferencing & CAST 2015, part 1

Let us begin with the definition of "community" in the Oxford Dictionary.

Community: com·mu·ni·ty /kəˈmyo͞onədē/ noun
1. a group of people living in the same place or having a particular characteristic in common;
2. a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals;


There are many, many people who talk about community in one form or other. When they talk about a community of testers, I tilt my head a bit and listen (or read) perhaps a bit more carefully than I do other times. I suspect it is because I am curious about what they mean and how they intend to use the phrase.

I admit that sometimes, particularly when it is someone with whom I have fundamental disagreement in areas of testing, I listen because I am suspicious of their motives. That may be a failing on my part. Or, it may be that I tend to think carefully and critically about certain things.  Among those things are words and how they are used.

My education included teachers from Catholic Religious Orders, Dominican, Franciscan and one Jesuit. Thinking carefully and how words get used was a hallmark of my education. Perhaps that is why when the first time I read There are good practices in context, but there are no best practices." my reaction was something of "Of course. Why is this revolutionary to some people?"

It seems that idea, perhaps more than any other single idea, is rather off-putting to some people. I understand the retort that such terms as "best practices" are misleading and lazy and disingenuous. I also understand the charges that people are selling snake oil as solutions to testing problems without actually understanding what those testing problems are.

I've written before about the idea of "best practices" and shall not repeat my argument here.

When I first read that idea, which is one of the Principles of the Context-Driven School of testing, it seemed I found a group of people with whom I join in that part of a community of testers. For some time, I have been working closer and closer with people. Some of them I agree with. Some I disagree with. The vast majority of them, I respect greatly.
In 2010 I went to my first CAST conference.  I found a large number of people who had inquisitive minds who were willing to talk and debate and discuss well into the early hours.

Every CAST I have attended and participated in since have born that out.

The fact is, some people do not like having their ideas challenged. Others thrive on it. Some people look at direct questions as an attack, sometimes personal ones intended for them them. (I expect that happens when people wrap so much of their own self identity with their work and ideas.) Some folks look at it as an opportunity to better understand something.

Some people, when their ideas are challenged, crumple up in a ball. Others attack the challenger. Others attack the right of the challenger to have a contrary opinion and voice them - IN PUBLIC.

If you have never attended or participated in CAST before. This might be a good opportunity to find out what it can be like hanging out with thinking people who are not willing to take everything, or anything, said from a podium at face value. A significant portion of each session - including keynotes - is dedicated to "open season" - where people in the audience can ask questions in a moderated, facilitated format.

I've been working with some really talented and dedicated people on this year's CAST. I think it will be worth your while to check it out. You can see more information on the conference here. There is a link to register from the same page.

The schedule is being announced later this week. It is going to be good, if I do say so myself.

Monday, March 23, 2015

On Spring, Gardening, Apple Pie and Defocusing

Too Much Fun

I've had an absolutely crazy couple of weeks. Way too much to do in too short of a period of time. Along with that, there has been too many things that are "absolutely top priority."  You know how that is - where there is a stack of "absolutely can not wait items."

Not just work stuff - but life stuff.  Home and family stuff that needs to be addressed. People who need help with something. All of this is important, right? All of it takes energy.

In the mean time, there is stuff that seems, well, maybe too big to handle on your own? Problems that don't seem to have a solution?

Maybe you never had that issue. Maybe you never had a problem like that.

Spring 

Ah well - Winter seems to be gone, in my neighborhood anyway. Most of the snow has melted. There are some very large piles of snow that are hanging around - and even they are a shadow of what they were a month or so ago.

It has been warm all week. Now, "warm" is relative. I do live in Michigan. (Today we reached the scorching high temperature of 48F/8C.)

The result is, I could spend time working in the garden on Saturday. Gardening is a wonderful thing. No, really. Saturday, I cleaned up the last of the Christmas decorations that were in the front garden.

Well, these were fake poinsettias set in garden pots in the front yard, that had, around Christmas time, small, lighted trees on them. There was 1 one each side of the front steps. The small, lighted trees and the garland came down some time ago. I also took down the red led "mini-lights" that were on the weeping cherry tree in the front garden.

The lights are kind of fun. The last several years we've wrapped lights up the stem and onto branches of the tree. When they are lighted at night, the tree looks like a red palm tree.  Oh. We also wrap green lights around the tree. The green lights go on the tree first, then the red lights.

The red lights are turned on just before Christmas. They stay on until after Valentine's Day. My habit is to unplug the red lights and turn on the green lights on March 1 - St. David's Day. They stay on until sometime after St. Patrick's Day.

They need to come down shortly after that most years, because as the weather warms, the flowers in the garden begin awakening and the weeping cherry begins to bud out.  We need to get the lights off the tree before that gets going full steam. So, the red lights came down Saturday. I left the green lights on for now. They may come down tomorrow.

Gardening 

After putting the lights and fake flowers away, I got out the rake and gently raked around the plants in the front garden. The daffodils and other flowers beginning to poke out, if not blooming, were exposed from their layer of leaves that covered the garden all winter.

Scooping up those leaves is a very satisfying thing. Really. They are bagged up and the plants were exposed - and, to be perfectly frank. The garden looks really nice after this - in an early spring sort of way.

Working in the garden this time of year gives a certain level of satisfaction that may not be there at other times. The ground, as it awakens from its winter sleep, has a healthy scent of strength, growth and new life.

Clearing away the collected leaves and various bits of... stuff, that settled over the winter reveals new growth and a promise of beauty in a matter of weeks. Mind you, there is a certain beauty of the garden as it is.

It no longer looks as a wild, abandoned place. Instead, it looks like a place where the growing things can be seen for what they are and the promise that they have for beauty later in the year.

It is funny how satisfying a few minutes work can be. Obvious results and a sense of completion that often is missing in software. Sure. We can say we "finished" a project, but mostly we see evidence around that "finish."  We don't actually see the results.

Seeing results is pretty cool. That is why I like gardening.

Another reason is, you can do it and completely relax your mind.  There is no reason whatsoever to engage in deep thoughts on what is to be done or how - you just do it. And it is done. And it is a pleasure to look at.

Apple Pie

It is an excellent way to get something tangible done and free the mind. The thing is, sometimes the best thing you can do when you have a pile of work that "must get done," is to work on something unrelated. It helps clear the brain and rest the mind - even while working on something else.

Do you remember Men In Black? The movies with Will Smith and Tommy Lee Jones playing Agents in an unnamed, extra-governmental agency dealing with aliens? The third movie in the collection featured Will Smith going back in time to help a young Tommy Lee Jones deal with an evil alien before he can kill Tommy Lee Jones?

At one point, they wander into a diner for pie - well, because grand-daddy talked about the power of pie. Some debate, hemming and hawing - and -

Apple pie - with a slice of cheese on it.

And Will Smith's character goes off on how he always orders that and... the light goes on. The odd comment made earlier suddenly makes sense.

And there is a classic example of the point - Defocusing.

Stepping away from the problem at hand to work on something else. The mind is freed from what it has been mired in. While working on another problem, the solution sometimes (often) presents itself.

Why? In my case, it is because I let go and worked on something "mindless." This activity allows me to let off steam and mentally relax and let go.

This gives me two results.

One, a task I need to do gets done (like, work in the garden).
Two, in the midst of raking and pulling and cleaning, I find the answer I had been struggling to find while I was "working" on it.

I don't know if it will work work for everyone. I  just know it works for me - and a lot of people I know.










Saturday, March 21, 2015

On Needs, Wants and Being Told What to Do

Brace yourself. 

This is a bit of a rant.

For most of my 30+ years in software development, many of them have been working with companies where software is made to support their primary business. It might be Insurance or Manufacturing or Sales or Distribution & Transportation - but many of these companies, the people using the software don't pay for it. They really don't have an option. To do their jobs, they need to use whatever stuff they get from IT.

If this does not describe the type of organization you are working in, you might want to skip this. Of course, if you have worked in an organization like this, or might possibly work in an organization like this, or perhaps you're curious what has me so worked up - please read on. Thanks.

Sometimes IT people annoy me. Of course, sometimes Internal Business folks annoy me, too.

How often have we heard or heard about IT/software development folks, telling people in business units what they need from the software to do their jobs?  After all - the IT folks know what the computer systems do and can do and so they are the experts.

Sorry.

The accounting and finance courses I had in school, longer ago than I want to admit, while it helped me work through and understand journal entries and balance sheets and other basic finance and accountancy stuff - These do not give me enough understanding to tell the Chief Financial Officer or Company Treasurer or whatever, what they need from the software their staff uses in order to make good, informed decisions.

I can, however, discuss with them the intent they have for using new or changed software. I can discuss the gain they hope to achieve from said software. I can listen and take into consideration what their desire for the end product should look like.

When I am working on making software do something, I can do something else to help the people who need this for their jobs.

I will do my level best to make software and work with the team making the software, that fills the needs and purpose described and discussed.

When possible, I will do my level best to have it work as they wanted.

However - that is not a promise.

Instead, I will do my best to fill their need first.

I've learned that IT people see their "wants" as "needs" (rather like the "business" folks they make software for.)  Cool features or functionality are cool. They are pleasing to design and implement. Do the help the people they are intended to help? Sometimes, sure. Of course. Other times? I've seen too much time and effort put into something that business functional experts truly do not care about.

And what of the "Business" experts? 

The people who use the software every day to do their jobs. The people who make use of the results of that work, every day, to do their jobs. The "decision makers"  looking at reports or summaries or dashboards produced and built by IT - What about them?

Do these people understand the business rules the software is intended to follow? Do they understand what the software is intended to do and why? Do they understand the purpose of what it does now and what the change will be?

Do they understand or know this without asking IT folks for help?

When they do, can the IT folks help them without looking at the code?

Have people abdicated their responsibility and put others in place as their proxies?

Now, if these things sound familiar in your organization, is it any surprise that your software has problems?

None of us really like it when people with no clue what we need tell us what we should do next.

Do the people who are supposed to:
  • Understand the purpose behind the changes;
  • Understand the business rules that to be followed;
  • Understand the why behind these things;
Who is to blame for IT telling people what the changes will be and what the software will do?

Someone has to decide what it will do. I suggest it be someone who knows what the purpose and needs are.

Sunday, March 15, 2015

On Tradition, Tribal Knowledge and "Everyone Knows..."

Interesting story I heard on NPR a couple of years ago. (Oh, for those not in the US, NPR is a privately and publicly funded non-profit organization that serves as a national syndicator for some 900 public radio stations in the U.S., often associated with universities or other forms of learning.)  The story was around Holiday Traditions.

While the gist was the Winter holidays, Christmas, Hanukkuh, New Year's, etc., they talked about other Holidays as well. The guests being interviewed mentioned how family "traditions" are really, on average, a generation old. People associate doing something for a given Holiday if their family, when they were children, did that thing for the same Holiday. In turn, their children will associate doing what ever their family does for Holidays as "Traditional."

Whilst I was still actively competing in pipe bands and teaching workshops for drumming in pipe bands, I remember a panel discussion with a group of pipers and drummers from the US, Canada, Ireland and Scotland. We were talking about styles of drumming and interpreting music.

We got pulled in two significant directions, both of which I found fascinating and I wish I could have been in a place to take notes. We talked on how things can influence our interpretation of music and how we approach music. We talked about how jazz had influenced great drummers in the pipe band world from the 1940's and 50's. We talked about how emigration from Ireland and Scotland had brought musicians to the US and Canada and how they had taught people what they had learned.

The result was many people and pipe bands in the US and Canada tended to inherit an understanding that was, at best, behind the curve of leaders in the world of pipe band were by the 1960's and 70's. The Legion and Community pipe bands in North America tended to get taught "this is how we did it in..." one of the regiments in the British Army.

This got latched on to as "traditional."  The people they taught said the same thing to others they in turn taught.

I remember teaching a band that intended to begin competing some basic technique for bass and tenor drumming. There was a fair amount of resistance because I was teaching them stuff that was "wrong." Their argument was "This is how the British Army does it." I asked which regiment - then pulled out video tapes of the Edinburgh Tattoo, massed Pipes and Drums of the Scottish Division beating retreat and the Scots Guards Trooping the Colours. None of the tenor drummers did anything remotely similar to what they were doing.

Tradition had shifted. Memories had failed as the knowledge was passed on.

Working with some testers a while back there was a problem. The parameters used to run the job they needed run to verify some changes made way up-stream in the process did not seem to be working.

I asked them what they were seeing.  They were pretty confused. The people who had worked on this same set of parameters had given them instructions around what to do.  Essentially, they needed to change the date in the command line and "that is all."

Except it wasn't "all."

The job, the one that had not changed at all, was failing on a bad parameter. It wasn't running "correctly," it simply wasn't running. Nothing was being processed. The people who had run it the last couple of times were looking at it. They were asking the people who had run it before them. They were looking at the notes and instructions.

They looked to see if "something had changed" that would prevent it from running. They looked at the configuration. The "unhelpful" error message gave them no information or guidance. Then, after several days of fits and starts, a light went on.

"Look. This says {blah blah blah} and has a period inside the quotes. What if we add a period?"

SHAZAM! POOF! A MIRACLE HAPPENED!

The combination of "everyone knows how to do this" and half-remembered meaning and importance of one thong effectively slowed work on this by several calendar days. Instead of sailing through as most people expected, we got hung up on people trusting to half remembered information because the entire team, except for the folks doing this the first time, knew exactly what needed to be done. The entire team knew that "all you had to do was..."

The entire team knew about the documentation. They knew the intent. They knew the "tradition."

They did not remember why.

Ya want an example of this, "tribal knowledge" in a "fun" vein? Go watch "The Lone Ranger" - the one with Johnny Depp as Tonto. All the weird stuff Tonto is telling the Ranger. All the stuff that makes people, including the Ranger, go "huh? what?"

Then, as the Ranger is sitting with the Comanche Elders and says something Tonto had told him. They look at each other and ask "Who told you this?"

The "tribal knowledge" the Ranger got from Tonto was ... accurate only for Tonto's interpretation and world view. No one else had that vision or interpretation. To everyone one else, it was not merely wrong.  It was nonsense.

When you are sharing tribal knowledge with other people, how certain are you that you are sharing it accurately? How certain are you that the "why" is being understood?

Is the information you are sharing with other people on testing knowledge, wrong or nonsense?

Saturday, March 7, 2015

What My Dogs Taught Me about Permanence

People who know me, or have seen some of my presentations on testing in an Agile environment, have seen pictures of the cats who live in the house with my me and my dear lady-wife.  People who know me, or my lady-wife, a bit better know that we prefer dogs. The cats started to move in a couple of years after our last dog, Rosie, went to Rottweiler-Heaven.

Rosie was a wonderful critter and companion. She would mind the grandkids when they were sleeping. If there was high tension or a chance of what seemed to be violence, she would walk in between the people involved and nudge them away from each other until things calmed down. She weighed 100 pounds and had the strength to move most people, even if they don't really want to move. Slapping was not permitted when she was around.

Anyway. Rosie was a rescue. She came to us when she was not quite two years old. We suspect that part of the "issue" was that this cute little ball of puppy fun turned into a very VERY large dog in short order. The problem was, she was still mostly puppy.  Translated - there was a lot of work to do with her, so she would behave in ways that were acceptable, even when we were not home.

We spent a lot of time working with her, training her to act in certain ways. Like, staying out of the garden, both vegetables and flowers. And staying off the furniture. It took a bit to convince her that simply because food, like vegetables draining in a colander, about to go on the dinner table, was NOT fair game, even if she could reach it easily.

There was the time we came home from a Christmas Party and found that the plates of cookies and bars and treats on the dining table had been disturbed, slightly. Looking around, we realized one plate was missing - a paper plate full of cookies my sister had made. These were cookies my paternal grandmother used to make, only for Christmas. Wonderful stuff.

They also smelled differently than any of the other cookies and treats that were set out, waiting for our grandkids to come over that evening.

We found Rosie, and the plate... and the plastic-wrap covering, in the crate she used as a dog-bed (it really was a dog crate for big dogs. her blankets and toys were in there. It was her safe haven - her "lair." So, here was the plastic wrap in front of the crate. The paper plate was in the crate -

Crumbs were everywhere. Apparently, she really enjoyed those cookies. Ah well.

As I was saying, it took a while to train her and get her so she'd be able to please as much as she wanted to.

By the time she was 8 or 9 or so, she knew the boundaries of the yard where she could go, and not. She knew what games were allowed - the type of play - and what were not. We could "call" her by simply whispering her name. Where ever she was, she came at a trot. If we called twice - she ran to us.

We could look at her and she knew what was going on - she'd go stand by her leash to go for a walk. Or, she'd go to the back door so she could go outside with us. 

She never did like rain. One time, about this time, we had several days of rain - never seemed to stop. She disliked rain enough where she would not go outside to "do her business" because of it. As we were into the second day of rain, and she had still not gone to "do her business" - I got a large umbrella and took her outside.

She was wary of the idea of being outside when it was raining - then she realized that I was outside - AND NOT GETTING WET!  HOW COOL WAS THAT!?!? So, she went out, I held the umbrella over her - and she was much happier after that.

Rottweilers are not long-lived animals. About the time she turned 9, her hips began to hurt. She could not play in the same way she always liked to. We put rubber-backed rugs around for her to lie down on and be comfortable (the house has hardwood floors, no carpeting in most of the rooms.) We gave her different food, food for "old, senior dogs." We found some supplements to give her that helped with her joint pain.

When the grandkids came over, she played like she was 3 again. But then she spent the next several days hurting as a result. We changed her "lair" - checked with the vet and put in a heating pad for cold nights, under her blanket of course.

By the time she was 10 or so, she could walk into the room and look at us and tilt her head in a given way and let us know what she wanted. She rarely barked. We took her on shorter walks. Her muzzle was all white now, not the black it was when she was young.

When she was 11, she quickly went downhill. Slower. She had a hard time getting up and down steps. Then she developed a large lump. Quickly.

We took her to the vet to be tested, but we knew what was going on. She always liked going to the Vet. She always like "going bye-bye in the car." So, he took a sample from the lump and sent it off to a lab. Before we had an answer we knew it was time for her to go on.  That last trip to the vet she had a really hard time getting into the van. She whimpered for the first time as we helped her in.

When we got there, she looked up and got out (getting down was easier than up.)  We walked in and she nuzzled us, leaned against us, as she always did. We went in with her as she drifted off to sleep that last time. We got home and hung up her collar and leash, put her food and water dishes in the sink to be washed and put away.

We sat down in the living room feeling very sad.  My lady-wife said "The problem with dogs is, once they are perfect for the family and perfectly trained, you need to start getting ready to say good-bye. Because they don't live nearly as long as we do. Just as they get to be perfectly trained, it is time for them to go away and leave us."

Last July, I started a new phase in my adventure in testing.

I went to work for a company that was looking for someone to help improve their testing. They were looking for an experienced person who could guide and coach them in how they could do testing better.

In the interview process, the people I met seemed to "get it." They knew they needed help. They knew the company needed help. They knew they did not have the experience or understanding of testing to get beyond very simple, basic ideas. 

One of the had the title "Quality Architect" - meaning he was not a tester. He never claimed to be. He, like I am, is a member of ASQ - the American Society for Quality. He was a process hound - but not a model hound.  The idea of "best practices" in software was "not a best practice" in his description. There are good ideas, but none of them work all the time.

One was a Manager of Application Services. He had a bunch of diverse groups reporting to him. I was struck that this was a bit like the "Island of Misfit Toys." People with skills that were needed by the organization but did not fit in with a single project development team - or in a tool specific team.

We talked. There was common ground we could work on. There were some differences in views, mostly related to experiences. 

I took the gig. It has been a lot of work. (Maybe you noticed how my blog has been less active lately?) It has been good though. My immediate team has been willing to embrace some new ideas and carry them out into the broader community. The Manager has embraced ideas that he initially found challenging - and in talking about them and working through what they could look like at this company, he became a champion to other Managers and Directors.

We built a good working relationship. Quickly. He even came to the local tester meetup on a fairly regular basis.

During the interview process, in the "describe the company and your experiences" discussion, he said he had been there for ... a long time. His role had changed. He had taken on greater responsibilities and challenges. Then he said "The only way I can see myself leaving here is if {Large International Organization Not Known for Software} had an opening I could fill."

That company did. He applied - interviewed - accepted the position.

Just as he was "perfectly trained" - he left. Friday, yesterday, was his last day at the company.

He "moved on." Of course, this was for a new job opportunity and not a "moved on" like Rosie did (or Hilde-beast before her... or Honz before her...) Still he's going on an adventure. Relocation - New City - New State - New Company.

Good luck Brian - Enjoy the new adventure!

I still think my tweet yesterday applies...
"Didja ever notice that Managers are a bit like dogs -
get them perfectly trained & it is time for them to go away?"

Tuesday, February 3, 2015

On The Easy Way and the Fallacy of the Simple

I've forgotten which of the several books by Jerry Weinberg I first read this in. The gist of the lesson is that when a proposed solution starts "All you have to do is..." it is a safe bet that this "solution" is almost certainly not going to be the solution that is needed.

It's funny how that works.

How many times has some expert walked in and told you, or your boss or someone "important" that "The answer to your problem is {blah}? That clearly the best way to handle the situation is to... blah blah blah blah blah..." Followed by something where it looks a bit like they expect you to accept that 1+2 = Magenta.

Yeah.

It is kind of like "We need to test this stuff but it is hard and complex and figuring our the data relationships and how values interact with . So, we'll just pull data from production and that will be good enough."

Now, I've mentioned that very idea in articles from time to time, and given presentations on how that can be done in integration testing and other forms. In a nutshell, there is no "just" about it.

If you are looking for a shortcut to figuring out test data - this is an OK place to start. But it is not the end.  Except some folks it might be the end.  That is too bad. Frankly, I think it's a huge mistake to think it's the end, but I could be oversimplifying it.

The issue isn't about the data. The issue is more subtle than that.

Where I see that to be the case is generally where people don't understand the system they are supposed to be experts in.

(OK, Context alert - I understand some folks will say "But, Pete, not everyone gets a chance to learn about the system they are supposed to test." I understand, really, and I rarely see those folks being the ones who have the assertions made about "Just use production data..." for testing. OK? So, consider this a "your mileage may vary" disclaimer...)


Ummm, yeah. That is kind of brutal. It also tends to be what I see time and again.

Why? It's complicated.

Well, duh - unless you are working on a piece of software with 1 possible value for the 1 variable in the software, it gets complicated quickly. Frankly, even then it can get complicated. Software is complicated.

Get over it!

OK. Whew. Sorry. Let me try again.

What can we do to make it a little less complicated?

We can look at variables in question - like the possible values that will send the software down different paths. If we have specific conditions we want to exercise or recreate, what does it take to make that happen? What combinations of values do we need?

Maybe some basic data analysis to start? What are the range of values for the variables? What combinations lead to what paths?

We can check the business rules, right? Maybe have coffee with the people who actually use the software? Maybe spend some time sitting with them and seeing how they do the things we're trying to figure out how to test, right?

Maybe we can evaluate logic within the existing code to see what it does - and see what the changes might do, right?

Pretty straight forward, isn't it? So why do so many people punt and say "We'll just run some transactions from production through?" 

Data and transactions "from production" might be a start. Then look at the transactions that are weird - that cause problems, or odd behavior,in the wild. Of course, I've found that chatting with the people using the system on a regular basis can give us insight as to what these types of transactions are.

Doing that might give more information than sitting with them and chatting about what they do.  I've found that asking "what makes things go pear-shaped?" Ummm - maybe "What kinds of things do you run into once in a while - maybe every 6 months or once a year - that takes intervention by  someone?" It could be something odd or something really, really, common, but with something that makes it uncommon.

Having a coffee with them, or buying them a bagel and a coffee - might get a little extra help in finding information. It might get the experts to spend a little time with you working through the problem transactions. It might get you some really deep insights into how people actually use the software.

I find that to be valuable on many levels.

So, what about the people who find this too hard? The folks who are always surprised when there are problems even after "it was tested?"

Maybe because they "are busy"? Maybe because there is a pile of stuff to do and do all those other things take time and get in the way? I'm not sure. Maybe all these things.

Maybe coffee or a cigarette was more important.

Simply put, figuring things out takes time and right bloody hard work. If it was easy, anyone could do it. If it was easy, they would not need to pay someone to do it. 

Of course, I could be wrong. I could be making things more complicated in testing than I need to. I might be uncharitable to the people who don't go through the effort I suggest might be a good idea.

What I do know is that many of the systems people "test" with the "all you have to do is..." approach, tend to have issues that get in the way of people actually using the software.  Of course, it may not be their fault. After all, they used data from production to test it. Is it their fault that the data from production did not cause the problems other data from production caused?

Sorry about shouting earlier. I'll go have a tea and calm down a bit. I get a little upset when people put out rubbish as if it is a revelation from beyond...

Thursday, January 15, 2015

On The King's Speech and Testing

I was sitting with the lady-wife watching "The King's Speech" earlier this week. Did you ever see the film "The King's Speech"? Its an interesting study. The thing is, most people watching it saw it as a study in how one man, a Prince who would be eventually be King, even though he really did not want to be and had an elder brother, the heir, who was tied up in interesting "relationships" with people that were simply, inappropriate... the whole abdication thing in 1936.

Most people who see the film take away a story of a triumph of will on the part of the man who became King George VI, with the assistance of the speech therapist, of course.

As a tester, I noticed one distinct thing, early on - Albert (not yet George) and his wife, Elizabeth, pay a visit to the speech therapist (Lionel Logue). After a brief, unsuccessful visit with Albert alone, this second visit consisted of Albert and Elizabeth telling Logue, in effect, how they wanted him to do his job.

It was interesting, because he had been asking questions that made Bertie/Albert (not yet George) uncomfortable. Stuff where Bertie/Albert did not understand the purpose of the questions. When Logue explained that there was possibly information he needed to help Bertie/Albert within the answers.  Except Bertie and Elizabeth would have nothing to do with such, flim-flam unimportant silliness.

They wanted him to fix the physical problem of his stammer.

Ummm, Right.

How many times does someone, a PM or a BA or whatever, come in and demand that we, as testers, do something that will not serve the needs of the project, team or company - and tell us to do what we are told - and that is our job. So just do it.

So, we should just do it their way. Right?

Clearly, we should focus on finding bugs. Unless we should focus on making "sure the software works".  We should focus in ensuring confidence. 

We should focus on ALL of these things.

CODSWALLOP.

We might do those things, on some projects, in some contexts, when they are the right thing to do. Here, by "right" I mean within a reasonable professional code of ethics. Of course, it might boil don to "keeping your job" but that has never really held much sway for me - at least not in the last 15 or 20 years or so.

So, how to approach or respond someone who is telling us what we should be doing, with no real expertise or experience within their argument, other than "I'm your customer and this is what I want"?

I am reminded of the philosopher-poet who wrote:
You can't always get what you want
But if you try sometimes you just might find
You get what you need

What is Wanted vs What is Needed

Loads of people confuse wants and needs. There really is a difference, no matter what the marketing folks will tell you.  The hard part in sorting out what is needed from what is wanted is that, well, it is hard.

Really hard.

There is the noise/buzz/clamour that they "need it NOW!" Then there is the voice in the back of the head that says "something does not quite feel right; something is out of sorts."

So, how do we do that? The apparently easy way is, we tell them "that won't work."  Of course, I'm not sure that works either.

The apparently not quite as easy way is to say "Well, I'm not sure that will work, and here are my concerns..."

The thing that is wanted from us, as testers, is the one where we say "OK! I'll do precisely that!" Which will make the requester/demander go away happy, at first. Odds are, they'll be back not so happy, but that won't be for a while so that is just fine for now. We can figure out something to tell them later.  Not today.

The option that Logue used was simple. "OK, we'll do it that way." He then proceeded to do "physical exercises" and "training" to deal with the stammer - knowing that the chances of it working were... ummm... improbable.

In the process of working through these exercises, they conversed. They talked. At one point it became clear that Bertie was actually left-handed, but had been trained to act right-handed. This led Logue to comment that this was not uncommon. There were questions posed as "interesting ideas" that Bertie answered, simply because he was relaxed. His guard was down - and did not seem to mind.

In the end - Bertie came to rely on Logue - even apologizing for being a jerk. Well, not quite in those words, but well, it was the gist.

In the end Logue did what was needed - by being willing to help. Oh, and letting Bertie and Elizabeth know he wanted to help - and being willing to "do what they wanted" until it became clear that was not working.

And Testers?

We can push back, gently. We can offer help. We can set the conditions. We must also know what to push back against. We must know why.

I'm not sure if I can do what Logue did - at least on a regular basis. I've tried, with various levels of success. Some folks were OK with that. Other folks wanted something like "that and only that" - do precisely that one thing, exactly what they said.

I have a hard time with that, particularly when they can't answer basic questions around the intent of the software.

Granted, working as a consultant or contractor, you may have a bit of leeway that an "employee" may not have, at least on the surface.

Know how you can contribute, then do so.  Or not.

You may not get a CVO out of it, but I expect you'll be able to sleep at night.