Skip to content

Hiccupps - James Thomas
Syndicate content
James Thomas
Updated: 8 hours 57 min ago

Make The Dirt Pay

Fri, 05/22/2015 - 15:14
Sometimes, perhaps when you're under time pressure and on a mission and in a part of the product you're not familiar with, you bump into issue after issue after issue trying to get to the thing you just have to get tested right now.

Maybe you looked at the doc, but really you only skimmed it because your boss was on your back, a pain in the neck, giving you a headache and tapping his wrist.

Maybe you noticed there was a warning in the log file, but it looked a bit internal and you dismissed it because some output was produced and the product manager is standing in the doorway editing her MS Project plan and tutting heavily.

Maybe you hopefully copied the conventions of other commands in the config file, or just plain guessed at the syntax for the bits you added, because the end of the sprint is tomorrow and the Scrum Master's definition of done is all about the done and less about the definition.

Maybe you asked somebody else, an expert, who had just the knowledge you need, but because you were in a hurry and they're also overloaded, you ended up with a shallow understanding and now their words of wisdom are just wisps of what-the? So you're reduced to feverishly trying random inputs hoping to defeat Probability and somehow magic up the answer the project wants even though by now even if you miraculously happened upon it you probably wouldn't be able to tell.

... Deep breath ...

Congratulations! You have arrived at a rare and privileged position: you are now your user.

Users generally don't know your product inside out. Frankly, most users wouldn't use your product at all if they could get what they need with less effort, hassle, expense or whatever resource is most important to them.

Many users don't pay attention to doc, or warning flags or the messages in the warnings that they don't understand or take time to learn how to do the stuff they don't need often. They just want the result. And they usually need it now, or earlier.

You are seeing the dirt that your users see, for the kinds of reasons your users see it. And that dirt is pay dirt. So don't just sigh and consign that nightmare to the brain bin when you get to the end of your task. Try to make the most of it by using your experiences to help to find ways to make the product better, and ensure that your product continues to be the one that gives your users their result in a timely fashion at the right cost for them.
Categories: Blogs

Personal Development

Sun, 04/26/2015 - 12:07
Here's a couple of personal, experience-based, posts by developers that I came across recently and really like:While Warne is up front about the fact that he's talking heuristics, Sanford doesn't explicitly say but is thinking that way too ("should probably always be"). In both cases the suggestions they make include general team-working advice for those working in software.Image:
Categories: Blogs

Book Notes

Sun, 04/12/2015 - 11:10
I've had a good run of reading in the first three months this year and I thought I'd try to summarise it  by picking out one or two thoughts on each book.

Becoming a Technical Leader, Gerald M. Weinberg 

I'm not a vain or pretentious kind of chap, but I did enjoy discovering that leadership is all about moi. That is Motivation, Opportunity and Ideas.  A good technical leader will look to supply these things in the right measures at the right times for their teams; a great technical leader will look at themselves to see which of these is their weakest and find ways to work at improving it.

What Did You Say? The Art of Giving and Receiving Feedback, Charles N. Seashore, Edith W. Seashore, Gerald M. Weinberg

Before I started regular 1-1s with my test team last year, I cast around for ideas and found a series of Manager Tools podcasts which, despite being much longer than it needed to be, I liked a great deal. A few months in, I was looking for ways grow my own capacity in delivering feedback. One quote from What Did You Say? hits the spot:
Don’t concentrate on giving feedback; concentrate on being congruent–responding to the other person, to yourself, and to the here-and-now situation. Don’t go around hunting for opportunities to give feedback, because feedback is effective only when the need arises naturally out of congruent interactions.And just last week I came across No Magic Words  which aligns really well with the notion (and I hope practice) of 1-1 that I have arrived at.

Are Your Lights On? Donald C. Gause, Gerald M. Weinberg

Weinberg has a knack for pithy yet panoptic definitions. You're undoubtedly familiar with the widely-quoted definition of quality and in this book he provides another:
A problem is a difference between things as desired and thing as perceived.Both desire and perception are up for grabs in any resolution of the problem.

You'll often see an iceberg metaphor being employed to illustrate limited visibility of some bounded-but-extent-unknown larger issue. Reading Weinberg for me is like taking that iceberg and picking off a snowflake from the top. It's easy to behold, even easy to hold, easy to comprehend at the high level but as you begin to think about it, deeper and denser than you imagined. In fact, as you look more closely you realise that that snowflake is itself an iceberg and, actually, it's icebergs all the way down.

The Gift of Time, Fiona Charles (ed.)

This collection of essays is a tribute to (and 75th birthday present for) Weinberg and is strongly influenced by his teachings. Michael Bolton's It's All Relative considers the way in which Weinberg frequently casts his analyses in terms of relationships - as in the problem definition above - and derives from it a generalisation which he calls the relative rule:
 A description of something intangible as "X" really means "X, to some person at some time"This gives us more variables to play with in any situation and so an approach to some problem might be to look at it from different time perspective or the viewpoint of a different person. He references a 1980s lecture by Jonathan Miller in which the ability of humour to alter perceptions of a scenario was proposed. A joke's punchline often hinges on revealing that what you thought you knew, or expected, was wrong.

Which lead me to ...

Laughing Matters, John Durant and Jonathan Miller (eds.)

Another collection of essays, the first of which is by Miller himself and covers the kind of ground that Bolton mentions. The copy I ordered arrived with perfect timing as I was preparing my proposal for EuroSTAR 2015, entitled Your Testing is a Joke, and dealing with the analogy I see between joking and testing. Try this short extract:
In all procedures of life there are rules of thumb which enable us to go on to 'automatic pilot' ... We depend on the existence of these categories in order to go about our everyday business. Jokes allow us to stand back from these rules and inspect them.Yes. Yes. Yes. And testing too.

Agile Product Management with Scrum, Roman Pichler

The test team at Linguamatics services three different development teams working in different ways. Most recently, our Solutions team has started using Scrum and the SolDev Manager lent me this book. It didn't tell me much I hadn't already picked up from other reading, but it is clear, concise and readable for non-developers.

The Signal and The Noise, Nate Silver

One the Dev Manager lent me. In very roughly the same kind of area as Nicholas Taleb and dense, like Weinberg, although without the latter's easy style, this book was occasionally hard-going (for me) but worth persevering with. Each chapter is effectively self-contained so you can easily skip to the next chunk.

Silver tells a great story about Gary Kasparov and the chess computer Deep Blue in a series of high-profile matches in the late 1980s. In one game, the computer made an unexpected move which Kasparov noted and took time to analyse afterwards.

The only explanation he could come up with was that the move was motivated by a strategy that suggested Deep Blue was capable of looking ahead more than 20 moves.  This was unheard of and placed the computer at a significant advantage if true. Unfortunately for Kasparov, he subsequently acted as if it were true - attributing ability and chess wisdom to the software which adversely affected how he played against it - while in fact it was simply a bug.

Lauren Ipsum, Carlos Bueno

I was turned onto this one by a Testhead blog post. It's an Alice-like story about a girl who finds herself in a strange land populated by strange characters with strange ideas. The ideas come from computer science, although they are not presented that way in the story, and the characters include Hugh Rustic (oh yes, and there's plenty of other puns) who says, of the problem of buying tomatoes from the market:
 ... to find the best tomato, you'd have to compare them all, right? ... don't waste your time looking for the best tomato when there are plenty that are Good Enough.I read it to my seven year-old daughter who loved it. We had some conceptually deep but still fun and fantastical discussions on the back of it and played with some Logo apps - the book features "poems" which are really Logo-style programs. I've now lent it to my mate to read to his son.

More Secrets of Consulting, Gerald M. Weinberg

Although I talked about Weinberg's writing in terms of icebergs earlier, this book is more like a tornado. It's a whirlwind of rules, parables, anecdotes and insight tied together by the concept of a Wisdom Box, or a toolkit for consultants. Here's one rule:
When a triangle separates you from your data, choose the hypotenuse.For example, if X says that Y thinks something, and you care what Y thinks. Confirm Y's position with Y before proceeding.
Agile Testing, Lisa Crispin, Janet Gregory

Which I've borrowed from one of my team on her recommendation but only just started.
Image: and the sites I've linked to for each book.
Categories: Blogs

Who'd've Guest?

Tue, 04/07/2015 - 21:48
I was flattered to be asked to contribute articles to The Testing Planet and the uTest blog recently. Here's what I gave them:
  • Not Sure About Uncertainty: thoughts on known/unknowns, quantifiable and unquantifiable risks, testing models incorporating them and their relationship to risk-based testing.
  • Make Like a Tester: thoughts for testers starting a new job, with butter, elephants, Stephen Hawking and a sponge.
Categories: Blogs