Tuesday, July 10, 2018

Test Driving a Scoda


Jessica Bane presented her Scope Discovery and Alignment meeting format at last week's Cambridge Tester Meetup. As the name suggests, its function is for a team to develop a shared understanding of the reason that work is being requested, what is expected to be included, and what is not expected to be included.

The structure involves collaboration on a statement that represents the mission and a breakdown of project factors (such as risks, questions, in/out of scope, resources) using tools familiar to many teams these days, a Kanban-like board and post-its. But the format is flexible and intended to service the key thing: making space for a productive conversation about the why and what, leaving the team free to go away and get on with the how.

After the talk, a brief workshop gave us a chance to kick the tyres of the approach. The group I was in were asked to organise a baby shower for our product owner's wife and, after aligning ourselves first on what a baby shower even was, we were able to  generate proposals, questions, and ideas that were quickly distributed on our board for the PO to begin addressing.

There's clear overlap with other planning processes, and several people noted similarities to Scrum ceremonies and the sprint goal. As with all such things, getting the right people together, at a time when they are in a mood to engage, and keeping discussion at a high-enough level are likely to be limiting factors on the utility of Scoda. Jessica and her colleagues from Displaylink were very positive on that point, saying that careful meeting scheduling, the structure, and the familiarity of the tools really helps.

Thursday, June 28, 2018

I am Awesome


I am awesome! I must be, because Matthew Syed told me I am in his book. I bought it for my daughter, to help her to see how awesome she is, and Matthew said it was true. Then my wife read it and apparently she's awesome too.

Matthew is promiscuous in his assertions of awesomeness. That's because he believes that everyone can be awesome at almost anything, and in You Are Awesome he explains, in simple terms, how:

People who are great at things have always practised really hard. Always.

People you think are naturals look that way because all their practice has made their skill second nature.

To be awesome you should practice, too.

And cultivate a growth mindset, accepting that you can learn, and change, and challenge yourself to do more.

Oh yes, and be prepared to fail along the way.

But take positives from those failures. Each one contains a suggestion for improvement.

And strive for those improvements, particularly continuous micro-improvements.

Focus most on the things that contribute most to achieving your goal.

It will be hard, but you should grit your teeth and just start.

Because you won't get to where you want to go without starting.

And you can get there, because you are awesome, Matthew says. Just like me.
Image: Amazon

Monday, June 11, 2018

Traitment Options


"Mastering the twelve traits that trap us." That's the subtitle of The Coach's Casebook by Geoff Watts and Kim Morgan, and the traits in question include impostor syndrome, fierce independence, and perfectionism. Varied as they are, they share a few characteristics: they can become problematic for some of those who have them, they have potential upsides, and the authors believe that most people will experience some sense of at least one of them.

There are, I estimate, about ... erm ... ten trillion books on coaching out there but a few nice touches set this one apart from others that I've seen. The first is the chapter structures: each starts with a case study of a composite character (based on Watts and Morgan's experience) suffering from one of the traits, is followed by a set of exercises that might be used for others with that trait, and ends with an interview with someone famous who is said to exhibit the trait, and sometimes harnessing it to their advantage.

Looking through these three lenses permits different aspects of the problem and possible approaches to become apparent. In the case study it was often the personal interactions that I found interesting: when the coach was silent, or chose to ask or not a particular question, or when (as in the case of Richard, who suffered from "ostrich syndrome") to be provocative. The coaching techniques and questions are what they are, useful to have in the back pocket, although I would have liked to have had suggestions on directions to take depending on the results. The interviews present the perspective of someone who has lived with a trait and frequently offer evidence that it can be overcome or put to good use, in moderation.

The second nice touch is the coaching of the coach (the term used is supervision) in the case studies. In these sessions, the coach gets an independent perspective on, and is sometimes challenged about, their interactions with the client. In these sections the uncertainty, biases, and fallibility of the coach is laid bare. Coaches can use coaches.

The final piece that helps this book to stand out is a summary matrix at the end which collects all of the approaches suggested during the book and cross-references them against the traits. Many techniques have value in multiple situations and the authors have done well to avoid repeating themselves across the chapters.

I have a few minor quibbles: I might question whether the twelve traits are indeed traits (even the authors admit that the chapter on coping with loss is an outlier), or that these are the traits that trap us rather than some that could do at some times, and I would have liked to have had discussion of ways to arrive at, or confirm, the coach's "diagnosis" of a given trait. I also would love the case studies to show some alternative paths for the same client and, given that they are fictionalised, to perhaps also show the interactions from the perspective of the client.

But these are relatively minor for me. I think this book will be a useful reference, I've already used bits of it, and I've ordered a copy for my team.
Image: Amazon

Wednesday, May 23, 2018

Cambridge Lean Coffee


This month's Lean Coffee was hosted by Linguamatics. Here's some brief, aggregated comments and questions on topics covered by the group I was in.

As a developer, how can I make a tester's job easier?

  • Lots of good communication.
  • Tell us about the test coverage you already have.
  • Tell us what it would be useful for you to know.
  • Tell us what you would not like to see in the application.
  • Tell us what is logged, where, why, when.
  • Tell us what the log messages mean.
  • Tell us how you think it's supposed to work.
  • Show us how you think it's supposed to work.
  • Give us feedback on our testing - what's helping, what isn't.
  • Offer to demonstrate what you've done.
  • Say what you think are the risky areas, and why.
  • Say what was hard to get right, and why.
  • Recognise that we're not there to try and beat or show you up.
  • Help us find our unknown unknowns by sharing with us 

How can we help you, as a developer?

  • Give good repro steps in your reports.
  • Help me to understand the ambiguous requirements.
  • Ask your questions, they really do help.
  • Don't accuse.
  • Have specific details of the issues you observed.
  • Understand that developers can feel defensive of their work.
  • Tell me when you see something good, or something that works.

How do you avoid or mitigate biases?

  • Look back and review what you did, critically.
  • Check your assumptions or assertions.
  • Ask a developer.
  • Externalise your assumptions.
  • Peer review.
  • Rubber ducking.
  • Write (but don't send) and email to someone who might know. (Like rubber ducking)
  • Do something else for a bit and come back.
  • Be aware of the kinds of biases there are and then you can check for them.
  • Rule of three helps to generate perspectives.
  • Write down what you did, as this prompts thoughts about it.
  • Compare what you did to something else you could have done.
  • Remember to say "my assumption is" or "but perhaps that's my bias" out loud.

Should all testers know a programming language and, if so, which one?

  • It can help, e.g. to review code changes.
  • It can help with other aspects of testing, e.g. data generation.
  • Which language? Shell, because it's almost always just there. 
  • I like python.
  • Should is a strong verb. Understanding the need would help to answer.
  • Testers shouldn't feel forced to learn a programming language
  • ... but they should understand the risks of not (e.g. in recruitment, or by lacking a powerful tool)
  • It helps with software development jobs generally.
  • So does other technical knowledge, e.g. of HTTP.
  • Reading a language helps in testing.
  • There's an analogy to speaking English in a foreign country - it helps to have a bit of the local language.
  • Enables more empathy with the developer - probably less of the "we'll just fix that" mentality.
  • When recruiting, I don't care about the language.
  • It's best when there's support and a community to help learn programming.

What testing tool would you like to be able to wave a magic wand and just invent?

  • A universal standard for test case management and reporting software.
  • A tool to create a visual map of product architecture which can be overlaid with code changes, all aspects of testing, recent issues.
  • ... and also predict new issues!
  • Something that can reliably map specification items to test cases, and show what needs to be changed when the spec changes.
  • A reliable, stable GUI testing tool.
  • Something that puts a team straight into the sweet spot of great communication, talking directly, working with each other.
  • A Babel fish that means that the listener understands exactly what was meant by the speaker.

Do you bring questions to Lean Coffee or make them up when you're here?

  • Both.
  • I think about them in the shower.
  • I try to come with one then make some up.
  • I take notes during the month, then try to remember them on the way.
  • I think on the way in.
  • Would some kind of a board, perhaps Trello, be useful to store them between meet ups?
  • Perhaps it'd lead to discussion in Trello?
  • Perhaps people would come prepared with arguments for the issues they'd seen on Trello.
  • Topics might be stale by the time the meetup comes around.
  • Spontaneous is good!
  • Person-to-person is good!
  • Paper and pencil mean you think differently

Wednesday, May 16, 2018

UX or Ex-Users


It seems like yonks ago that I stumbled across Steve Krug's book Rocket Surgery Made Easy and loved it, so I eagerly took the chance to see him talk at the Cambridge Usability Group in a double-header with Andy Morris.

In the first half, Andy talked about how Onshape try to engage and empower and delight and retain users while at the same time gathering data that the company can use in their design and support efforts. In the second half, Steve reprised some of the key points on usability testing from Rocket Surgery.

Tuesday, May 15, 2018

You Are Not Alone


Abstracta's recent review of Hiccupps for their 75 Best Software Testing Blogs list says "James [shares] learnings from events and fun sketchnotes he makes."  Learnings here are from this week's Cambridge Tester meetup at Linguamatics  and, while the notes might be fun, the subject matter is less so.

First up, Chris Kelly previewed his Testbash Dublin talk, The Anxious Tester, a story of how his anxiety has affected his work as a tester and some suggestions for fellow sufferers, those around them, and those they work for.


That was followed by a video of The Fraud Squad where Claire Reckless presented background material on impostor syndrome, talked about her personal experience of it, and gave advice for supporting oneself  or others when the unfounded fear of being found out hits.

These are timely topics during Mental Health Awareness Week, and it's worth noting that the speakers shared a recommendation for anyone experiencing difficulties: remember that you are not alone.

Sunday, May 13, 2018

Tomorrow Never Nose

At CEWT #3, back in October 2016, I presented a definition of testing I had been toying with, a definition which later became this:
Testing is the pursuit of relevant incongruity
After hearing me out, one of the participants asked a strong, strong question: did I think my definition of testing could also define something else? I love this. It's a way to test the explanatory power of the proposal. On the day, I think I said that I thought it could also be a description of science.

Yesterday, I read a review of The Happy Brain by Dean Burnett in which Katy Guest said:
He rattles through studies, building a picture of what exactly tickles the human brain and why ... Laughter, it turns out, may originate among the temporal, occipital and parietal lobes, whose role is to "detect and resolve incongruity".
Bzzzzzttttt!!!!!  Arrooogggaaa!!!!  Honk! Honk! And with a jolt of recognition, I realised only 18 months after the fact, that I would also say my definition could describe joking.

I get a rush from finding unexpected connections in unexpected places and this is a particularly intense high because at EuroSTAR 2015 I aligned testing with joking (and science) by appealing to the similarity of the aha! and haha! moments and an incongruity theory of humour.

But so what? Well, for me, this episode is a nice self-reminder that conclusions are relative. What you think you know is contingent on variables including you, the context, the data, and the time. Like me, on this occasion, you might not see even what's right under your nose until tomorrow, or perhaps never.
Image: Recordmecca