Saturday, November 18, 2017

Don't Knock It

They were chuckling at me when I came back from the kitchen next to the meeting room. They were grinning and smirking at each other because they'd heard me laugh out loud and knew that I was the only person in there.

So I felt compelled to explain that I was laughing because I value highly in testers the ability to find more than one way to look at any given situation. Stated drily like that, it  doesn't sound worthy of a solo guffaw does it? But what I actually said went a bit like this ...

You know that scene in The Lord Of The Rings where they're trying to get into a mine? There's a clue phrase in Elvish above the door that Gandalf translates as "Speak, friend, and enter" but then he can't remember what the password is. Eventually he sees an alternative interpretation, "Say friend and enter", and they get in.

Well, I was in the kitchen looking at the door to the car park and there's a sticker on it which I'm sure I must've read before ...

... but this time I thought is that door calling me a knob?

Thursday, November 16, 2017

Respond to the Context

Sometimes a phrase just lights up the room when it's spoken.

I encountered one today. One of my team was debriefing us, giving her analysis of our answers to her survey of our experiences of the team pairing experiment that she ran.

I say it lit up the room, but really for me it was writ large in fireworks, sounding a fanfare, and flying loop-the-loops. Here it is:
Respond to the context.
I'll just leave it there for you. And also this.

Wednesday, November 8, 2017

NoSQL for Us

Unfortunately, last night's Cambridge Tester Meetup talk about database unit testing was cancelled due to speaker illness. No problem! We had Lean Coffee instead. Here's a few aggregated comments and questions from the group discussion.

How do you deal with internal conflicts?

  • Give overt, verbal appreciation to the other person and their perspective.
  • Be humble.
  • Leave your ego behind.
  • Conflict is healthier than the alternative. 
  • Conflict betrays a lack of common understanding.
  • I seek conflict.
  • Conflict of personality or of ideas?
  • I want to squeeze out ambiguity and lack of clarity.
  • A stand-up row can be acceptable to achieve that. (Even if it isn't the first thing I'll try.)
  • Some people avoid conflict because they feel they won't win the argument.
  • What is the source of the conflict? That makes a difference.
  • Try to keep discussion to facts; objective not subjective; technical not personal.
  • Try to get to know each other as people.
  • Try to build team spirit.
  • Change your language for different people.
  • Make yourself likeable.
  • Be assertive. That is, be calm, direct and equal.

What does Agile mean to you?

  • The Agile Manifesto is about software engineering and not about other processes.
  • Agile is a good term for marketing to upper management.
  • Extreme Programming is not a good term for marketing to upper management.
  • Agile is for projects where we don't know what we want.
  • It's for when we want to do the right thing but don't know how.
  • It's about early feedback.
  • It's about collaboration.
  • It's about being responsive.
  • Anything-by-the-book is never good.
  • "Painting by numbers doesn't teach you how to paint".
  • Most teams have 30% of their members who don't know what they're doing.
  • I'm a fan of Agile but not a fan of Scrum.
  • Teams at my work mostly use Kanban.
  • It's about knowing things will change and not going overboard on planning.

TDD Difficulty

  • So many people talk about TDD but why is it so hard to get it into use?
  • I like it and my boss likes it, but in five years we've never moved to it.
  • Why?
  • Perhaps it's too big a change for our team.
  • Perhaps no-one wants to make the effort to change it.
  • BDD is a better approach.
  • Is TDD better as personal preference than mandated practice?
  • It only matters that there are tests at the end.
  • Has anyone tried to measure the pros/cons of doing it?
  • Some people think TDD is an overhead; work without benefit.
  • TDD is about design rather than tests.
  • Is TDD really about capturing intent?

How are you using Docker in Testing?

  • To avoid having to deal with dependencies.
  • For installation testing; it's easy to get a known, repeatable environment.
  • Interested in trying to containerise test cases so that we can give something to developers to just run to see an issue.
  • Virtual machines are an unnecessary overhead much of the time.
  • Docker makes it easier to exploit all of the CPU on a host.
  • Docker is no help for kernel development and testing (if you need to use variant kernels.)
  • My team haven't found a use for it.

Wednesday, November 1, 2017

A (Definition of) Testing Story

I'm speaking on the Storytelling track at UKSTAR 2018. In eight minutes I'm going to explain how I arrived at my own definition of testing, why I bothered, and what I do with it now I've got it. 

You can find some of the background in these posts:
and I made a kind of sketchnote video thing to promote it too:

If you still want to come after all that, get 10% off, on me:

See you there I hope.

Saturday, October 28, 2017

Quality != Quality

Anne-Marie Charrett delivered a beta version of her Testbash Manchester keynote at the Cambridge Tester meetup this week. Her core message was that quality and testing are not the same thing:
  • there are non-testing aspects of software development that contribute to product quality
  • there are non-product aspects of quality which should be considered in software development.

A theme of the talk was that customer benefit could be threatened by the second of these, by factors such as code hygiene, speed of delivery, and time to recover after a failure in production. Testers, and others in software development, were urged to reframe their view of quality to encompass these kinds of activities. A Venn diagram represented it like this:

Interesting, but it didn't quite hang together for me. I slept on it.

In the morning, I found myself thinking that what Anne-Marie was trying to visualise really had two notions of quality, and they were not the same. Perhaps she could move from a two-way to a three-way relationship between product quality (features, performance, usability and so on), production quality (for the non-product stuff around producing the software), and customer benefit. (Although I prefer business value rather than customer benefit because the business might prefer things that don't give value to the customer at some times.)

Here's how I've tried to sketch that:

The sweet spot is work that improves the way the software is produced, improves the software and adds value for the business. For example, changing from a product implemented in two languages to a product implemented in a single language could enhance in-product consistency and performance, simplify toolchains, and reduce IDE licensing costs.

But the tripartite division gives other potentially interesting intersections too. There's the traditional new feature which drives an increase in sales (product quality/business value) and then there's situations like moving from weekly to daily drops of a core component to internal teams which removes wasted time on their side (production quality/business value).

Anne-Marie asked for feedback on her talk so I pinged her a few notes along with a sketch of my idea and she incorporated some of it into the keynote.

Which is gratifying and all that but while my model might be considered an iterative improvement on hers, it's not short of its own quirks. The intersection I haven't mentioned yet (production quality/product quality) could be encountered when ancient build servers are replaced, enabling newer libraries to be used in the product, but adding (at least, at that time) no value.

The caveat, at that time, is interesting because it reflects the idea that there's a granularity effect at play. The example just given, at a certain temporal granularity, adds no value. But once new features that build on the new library are implemented, value is added. Zoom out to a wider time perspective and the action of updating the build server can sit in the sweet spot.

There's other ways in which this model is fuzzy: in a continuous deployment world, the boundary in the pipeline between the product and the production of the product becomes harder to define. Also, there's no good way to represent stuff that's actively detrimental to business value.

And there's ways in which our viewpoint (biased to the technical) can distort the relative importance of our interests too. Remember that business value can be generated without any involvement of the development staff: dropping the price of the product might drive sales and increase overall revenue.

Your perspective on the model alters the value of the model. Quality may not be whatever you think it is. Stay humble.
Images: Nick Pass and Dan Billing (via Twitter)

Edit: This post blew up a bit on Hacker News. The views expressed there on what quality is or isn't, the ease with which quality can be achieved, and the notions of quality as subjective or objective distinction are interesting to see. Anne-Marie used Weinberg's definition of quality in her talk and I recently wrestled with that in In Two Minds.

Monday, October 23, 2017

Where Did All The Women Go?

I took my daughters to the We're Here. Hi! Let's Play pop-up exhibition about women in computer gaming that's running as part of Where Did All The Women Go? One display board caught my eye:
Research shows that women play games just as much as men do. This fact is often dismissed using the argument that women don't play 'proper' games.
A stereotype has emerged that women mostly play 'casual' titles, like puzzlers and tile-matching games, that shouldn't count in this research — but who gets to decide what gaming is?
All forms of media have this problem: film buffs disparage blockbusters and literary critics dismiss genre fiction. The difference with gaming is that both sides are becoming gendered. Men are seen as the serious gamers and women as 'causals' with lower skill and investment in the medium. These attitudes risk excluding female players and preventing new ideas from flourishing in the industry.
That situation is unlikely to be a surprise to many of us, and it's echoed in the wider tech industry:
“Women were turned off computing in the 80s,” [Prof Dame Wendy Hall] says. “Computers were sold as toys for the boys. Somehow that cultural stigma has stuck in the west in a way that we can’t get rid of and it’s just getting worse. The skills gap is going to get huge.”
My kids have been to the Centre for Computing History before, and they like it for its own sake. But I wanted them to see the exhibition and to use it to reinforce the message that they should feel able to play any game, or try a technical career, if they want to, in spite of social conventions, peer pressure, discrimination, the weight of history, or anything else that might contrive to hold them back.

They're young, so I didn't try to ram anything down their throats. We had fun making pixel art, playing Tempest and marvelling at ET in a Sinclair C5, and in between we watched a video about an amazing all-women professional gaming team, thought a little about the imagery around us and in the games they play on their tablet PCs, and I told them about Karen Spärck Jones, one of the women featured in the exhibition. Karen was in the same research group as me at the Computer Lab, a pioneer in Computational Linguistics, and often quoted as saying "computing is too important to be left to men".

Tuesday, October 17, 2017

Testing Thinking, Anyone?

At Quality Jam London 2017 I was introduced to the term design thinking. It sounded interesting. I  looked it up when I got home, spoke to Rog, our UX specialist at work, and read a couple of references that he provided. Jared Spool's Shh! Don’t Tell Them There’s No Magic In Design Thinking was particularly intriguing:
For decades, I’ve needed to do what every seasoned design professional has found themselves doing: explaining why design is more than just making something pretty. When I’ve worked with other designers, they get it. 
But once someone who isn’t a designer — someone who is a layperson — is introduced into the mix, I’ve found I need to convince them that design isn’t only about making the thing pretty. That’s it’s about solving problems. That’s it’s about end-to-end solutions. 
The phrase design thinking changed all that. To a layperson, it was completely new. While it was made up of words they thought they knew, the combination was novel. “Design thinking? What’s that?”
Adding the word ‘thinking’ to ‘design’ was a brilliant move. David Kelley and Tim Brown, the founders of IDEO who popularized the term, were smart to take advantage of the unfamiliarity of the phrase.
To those of us who’ve been doing this for a long time, design thinking doesn’t mean anything new. But it also doesn’t mean ‘make it pretty.’ And that’s why it works.

At Quality Jam London 2017 I listened to Tony Bruce talking about manual testing. From my notes:
in Manual Testing is Dead. Long Live Manual Testing, [Bruce] called for testers to set the expectations of the people that they interact with. The term "manual testing" undersells what testing is, or can be, with its connotations of manual labour, unthinking monotony, apparent separation from (woo! sexy!) automation and the historical association with scripted test cases.
So he might refer to using questions, experiments, exploration, engagement, surveys, investigation, tools (which includes woo! sexy! automation), spending time thinking, iterating, and adjusting to new data. And he'll report on what he found, but not necessarily what he produced ... It's all testing, and it's on testers to explain and demonstrate how and why and what value it delivers.

Words are more than just a collection of letters on a page or vibrations in the air. Words are powerful and subtle and important. Words have emotional effects and social impacts, and they'll differ for different listeners (connoisseurs and consumers, for instance) and at different times. Words come with baggage and consequences, some of which will align with the speaker's intent, and some of which will not. Words can be freedom and words can be prison.

But blah blah semantics whatever. Testing Thinking, anyone?