Thursday, January 15, 2015

On The King's Speech and Testing

I was sitting 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.




Monday, January 12, 2015

On Conferences and Differences and Speaking

I've been watching a lot of discussion the last year or so on conferences - particularly in the realm of software conferences. Whether it be Approach, or Methodology or more niche areas like Agile, Lean, specific development styles - or, my favorite - Testing.

Wow. That was a long run-on sentence. That is what happens when I type what I am thinking and not worrying about format too much. I'll try and do better the rest of this post.

While looking at how people perceive conferences and ideas and sharing and learning, I often wonder what people are looking for in a conference. I know what I am looking for. I suspect there are others with similar criteria. There are also people who decide about going to a conference on totally other decision points.

I get that. Not everyone thinks in a similar vein as I do. It would make my day-job a lot easier if they did.  However, I suspect it would be quite boring (as in, not stimulating in any significant way) and I probably would not learn much.

For me, a conference counts as a something I am interested in going to if, in looking at the program and reading the abstracts, I can say "This is something I am interested in and a) I want to learn something about it; b) I want to get different insights on this topic; c) I want to see how this speaker approaches something I am familiar with, but I don't necessarily agree with."

There are other things - but those are the big ones. Some of those other things are - do I know any of the presenters? As in, have I met them? Engaged in conversation? Exchanged emails? Maybe I've read some of their writings.

The thing is, I am fairly certain that a fair number of people don't use the same measures. I know some who look to see where the conference is. Some folks are more interested in the activities around the conference more than the conference itself.

Well, if asked directly not, but... well - if the conference is at a famous resort, are they drawing people for the content or for the non-conference activities? Now, in fairness, there is usually very good content at some of these. Others? Well, for me, there is not anything in the program as a draw.

What makes me different from still others, is that I don't really need to look for people who look, and sound, and think like me.

Because the majority of speakers at the majority of conferences look a lot like me: Male. Caucasian.

I get it. I really do.

Other folks, I'm not so sure that they get it. I also am not so sure that they see a problem with that.

I am working on a conference this year.  I am the Conference Chair for CAST - the Conference of the Association for Software Testing.  This year it will be held in downtown, Grand Rapids, Michigan. Where I live. The venue is nice. A conference center hotel that emerged out of a historic hotel - one of the grand old-style ones that have become rare in the US. The nice thing being downtown, there are loads of activities, events and nightlife within walking distance.

I am working with a group of people who are working hard on putting together the best program they can. Ummm - I don't get a vote on the track talks and workshops.

They are building that part of the program from the proposals that are submitted by people. Testers, Developers. Other software professionals and - maybe students and people who are interested in software and testing.

The thing is, if you are a person who is looking to see speakers who look like you at this or any other conference, there is nothing my colleagues and I or our counterparts at other conferences can do if people do not submit proposals.  I can reach out to individuals and encourage them to submit proposals. The members of the program committee can encourage people to submit proposals.

But people must submit proposals. 

If you want to see more women speaking, or more people of color speaking or more - whatever.

Submit your proposal.  I'd be very happy if you submitted a proposal for CAST. 

But - Submit your proposal.

Thank you. Other people will be happy you did.

Submit your proposal.   Today.