Ep 53: You have no control who lives who dies who tells your story

Thiiings: I have 3 potential interviews coming up for the podcast and I am excited! More details when I get them. I am panicking about Testbash Manchester as I said I’d do a practice talk at the local Drupal User group in August and lols I’ve not even written the thing yet. Ministry of Test is doing a series of webinars, facilitated by Maaret Pyhäjärvi, which I’ve asked to take part in, so I need that topic as well.

Sooo, I want to talk about storytelling.

I’ve always been fascinated by stories. I was a reader as a child, I got lost in words more often than anything else. I read the fifth Harry Potter book the night before my Physics GCSE, staying up until the early hours because the alternative – not reading it – was unthinkable). I always thought it was some kind of magic, storytelling. Later, hearing stories became my obsession, through Ted talks, podcasts, and conference talks, and it’s still my obsession now.

Stories keep you engrossed, invite you on a journey. You’re not just telling someone something, you’re informing them, showing them, bringing them with you on something.

When I started hearing about testers as storytellers I sat up, and paid attention. I don’t have the imagination to write fiction – I’ve tried and I can’t hold a plot with two hands and a bucket, but writing has always brought me joy, and I am always trying to write and speak better, tell my own stories in a way that’s useful and engrossing.

And I realised, as I was reading about storytelling in testing and software development just how much space there is for storytelling in our work. I knew and had used personas before; and how this persona interacts with a product. What I hadn’t thought about is how writing bugs reports is storytelling.

Part of a tester’s job is to advocate for bugs. We report the bugs and in our reports are the whys and hows of raising them, and why we think they should be fixed. Sometimes this is nothing major – this doesn’t work at all, or doesn’t work in this environment. Sometimes it’s a bit more nuanced, “I would expect this here” “I shouldn’t see this because of this reason” and getting the details across fully and in a compelling way is important, because it will get the bug across to people who are in charge of fixing or scheduling the fix.

Sometimes it’s not a bug as much as it’s something that’s not been thought of, or something has been missed, and you need to explain why we need to include the change you’re asking for. Stories can help advocate for things.

So how can we make our stories compelling? First it needs to have a structure: a beginning, a middle, and end. This person went to here and did this and this happened. This is what we thought was going to happen, this is what should happen, this is what we need to happen, and this is why we think this should happen.

Tell the report to someone. This is one reason I’m inclined to talk to developers first when it comes to an awkward bug, or a bug that’s not obvious. I can talk through things and get a feel for what details are needed. If I can’t, or it doesn’t make sense to, I’ll write the bug out in bullet points, with an introduction and end to structure the bug. I make the title relevant (no puns in ticket titles, no matter how tempting. I save all my puns for you, listeners <3), and I make sure I include a desired resolution. Never leave a story on a cliffhanger, people will hate you. A pox on bug reports that are literally ‘the menu doesn’t work’.

Choose your evidence – annotate and refer to the images, videos, numbers you include, don’t just include them without explaining (this is something I am guilty of a lot). Otherwise it’s just decoration and something making the ticket bigger.

Exposition is allowed, and is preferred to a light touch when it comes to details. At the same time, we’re not Charles Dickens and none of us are being paid by the word (this was not actually true, but I like the idea of it). Choose your details wisely.

Write first, then edit before sending it to a developer. Choose what details make sense when you review the entire report.

When the bug comes back to you, detail the resolution – say x was done, or on reflection, y was done because of reasons a, b, c. Finish the story, close the loop. Start again.

We should tell clients more stories. Instead of saying ‘this will do x and y, say, this will allow you/your customers to do x and y, but not a, or b.” or, “we chose to implement this because of these advantages.”

And we should listen and help clients form their own stories. Point out plot holes, and suggest how to tighten the plot up. Offer different opinions, viewpoints, and expertise (you’d send a novel to a copy editor before printing, right?). Help them guide their clients or users or stakeholders through the journey of the site or the app, and make that journey part of a story. When something becomes part of your story it becomes something you care about, and engage with, which is important when it comes to developing successful software. Speak in a common language, and make sure the goal is the same on all sides.

Your user story statement should in fact tell people the story of the feature. As this person, this character, I want to do this thing to reach this goal. Break with the format if needed, but make sure the story elements are there.

Practice. I really like internal sprint walkthroughs. These happen prior to the sprint demo to the client, and it means that the team as a whole gets to look at the work we’ve done. We take each feature ticket, and demo how we meet that criteria. It’s practice for one; the lead dev can find the most sensible way to demo the entire sprint (to tell the story of the sprint, maybe?). It gives the team a chance to review progress as a whole, and make sure everything fits together well.

Hell, storytelling could be a good way of substituting metrics for useful data. Metrics don’t tell you much of anything, but you can at least supplement them with words. X% of stories were rejected with bugs, this is because of x, y, and z, is much better than x% of stories were rejected. Even better would be ‘we had issues with a few stories because of these reasons’, and then move forward, but that doesn’t fit into a graph nicely.

There’s a million things I haven’t done – I’ve not spoken about what happens when the story is taken out of your hands, or talking to people you don’t work with (interviewers, other testers, people who aren’t techy), but I wanted to focus on the sprint cycle.

The whole agile process it an exercise in storytelling, and I think we need to get better at telling them, and about helping other people develop them. Stories are fundamental to human nature – humans are rooted in narrative; we form lives and memories around stories, There’s no reason we can’t continue this in software development, and bring a bit more of the human into the software.

Further reading



Ep 49: Leading the Witness

Firstly, an announcement: LTATB is moving to fortnightly episodes. I need to level up my content game, and I can’t do that in weekly slots, so there will be an episode every two weeks. The next episode will be on 19th May.

People are really bad at telling you what they want. Really bad. They think they know, but I guarantee you they don’t. And it’s not because they’re stupid, if anything, it’s because they know their business and processes really well. Or, they know their business and processes as they stand really well. Translating that to a new system can be difficult to do.

How well do you know your commute to work? Or how to cook your favourite meal? Or the layout of your phone screen or desktop. The things you use all the time, you know what you’re doing well enough that you may not even think about every little step. You may not even realise if you’re doing something slightly (or not so slightly) inefficiently. Or, you may realise, but there’s a reason for it (I occasionally walk a longer way to/from work because it’s prettier and there’s more chance of seeing dogs being walked, for example).

Or, another way, changing computers. You get a new or different computer, and you start transferring/re-downloading files and programs. How many times after that initial set up do you realise you’re missing a program? I’ve had a week go by easily before realising there is something missing.

These little things are going to be the things that actually turn out to be really integral to a system. The stuff that isn’t the main points (browser of choice, or the pasta in a lasagna) but the stuff that just makes everything smoother (setting up key shortcuts, or adding basil or oregano). Technically you can get away without them, but it makes things just a little harder, or less great, and the people using the system will miss it and be less willing to engage with what you’ve built. So, how do you figure these things out? Ideally, you watch people interact with the system as it stands, and have a play yourself. I spoke last week about inheriting legacy systems, and some of those techniques apply here.

Another way of doing this is going through user journeys with the product owner and team.

People are really good at telling you what they don’t want. There’s gets a point in a discussion about a system where you can kind of tell that the client isn’t sure what part you’re not getting, so I’ll go through my assumption of the user journey. Suddenly, when I get to the bit I’m pretty sure I’m wrong on, they’ll re-engage and point out where my assumptions are wrong. Its easier to go ‘no, not like that’ then it is go to ‘this and this, and then this, except, shit, I missed a step here’.

However, this assumes that you’re wording things in the right way. Leading the witness is when a lawyer asks a leading question; or a question that puts words into the witness’ mouth. In this line of work, it could be as simple as assuming something and phrasing it as ‘and then you do x’ as opposed to ‘and after that, what happens? X? Or something else?’. The idea is you prompt them, but not fill in the gaps for them. In a situation where maybe people are feeling tired after a long meeting, or a bit nervous, or overwhelmed by techspeak, something like that could be just agreed to, and so you want to balance between making it go smoothly and easily and telling clients what they are going to get. We’ve implemented some things that on the surface of them make no sense, but for the context we’re working with, make perfect sense. You wouldn’t ever do it for a public facing site, but for the internal processes of the client, it made sense). And we’ve worked on a few government/public funded or charity sites, and their processes are larger than anything we can do or effect change, so we have to make them fit the system we build, not try to get them to change their processes for the new system.

The best and smoothest projects I’ve ever worked on are where the whole team has that understanding; we’re the experts in the tech side, but the PO knows their team and users better than we do, and so they say ‘we have this need, maybe we can have this?’ and we go either ‘sure’ or’ yes, maybe, but how about this?’ and then it works amazingly well.

Further Reading


Ep 47 – Beyond Unreasonable Doubt

As I said last week, I’m going to talk about unreasonable doubt.

‘Unreasonable’ doubt (for these purposes) is when you doubt your own abilities wrongly – imposter syndrome, or under estimating your own abilities, maybe due to inexperience.

Sometimes this can be a good thing; doubt about a skillset you have can be a motivator to learn more and become better, but it can be detrimental; holding you back when you have no need to doubt your abilities.

I think you can tell the difference between the two – imposter syndrome is a lot more anxiety inducing than being inexperienced is. If I don’t feel confidence in a specific area, it feels like a weakness (even if I’m not actually deficient in that area), but a specific weakness. Imposter syndrome is a much more overwhelming anxiety, one that is much more diffuse; its not an area or two that can be pinpointed, its everything you are and do in your professional world.

I want to talk about a few different strategies for tackling these kind of doubts.

I’m going to start with being new, or inexperienced.

I read a brilliant blog post this week about being ‘a dumb girl in computer science’. It’s really good – it’s about just saying loudly ‘I don’t understand’ and people coming together to help each other out.

Asking questions is really important! And yeah, sometimes it does feel like showing weakness, but everyone’s been where you are, and a lot of us still are – the world of testing is huge (and I think this applies to all spheres of professional life), and you can’t know everything and all things.

So question things. You may get corrected, in fact, through your career you probably will get corrected. Firstly, try to step back when someone corrects you. Assuming they’re not being a cockwomble about it, they’re helping you out. Also, don’t be afraid to question their corrections. They might be wrong? Both of you could be wrong? Start a discussion, go somewhere with it.

You could try focusing. This is something I’m having issues settling on. I’m very much like a magpie in that I’ll go ‘ooh, shiny’ and go over there for a bit, then get bored and never actually sit down and focus on anything (like this podcast!). You may find, if you focus on one or two areas that interest you, and settle on those, becoming more knowledgeable, keeping upto date, you can carve a place for yourself, and feel a bit more grounded and ‘deserving’ of your place in your professional world.

While some of these may help to lessen your imposter syndrome, there are some steps you can take help tackle imposter syndrome specifically.

Talking about it is a key step (yes, it does feel like you’re fishing for compliments, but sharing experience is important). This is a thing that a lot of people suffer from, and so you’ll get a sense of solidarity and knowledge that it’s not just you. It will help.

Studying is sometimes recommended, and while professional and personal development is important, if the motivation is to combat imposter syndrome, you’re gonna get worse, because there is always a lot of stuff you don’t know, but that doesn’t make you a fraud, it just makes you human. However, if you’re aware of a deficiency in a part of your skillset, or something you want to get better at, it’s good to build on these, and it might make your foundation solid and help you find your place.

Share. Tweet, blog, vlog, podcast. Sharing has so many pros – it’s good for you, and good for others. Talking to others will help you structure your information, and will let you realise how much you do know about a thing. Share what you know, and, what you’ve discovered, what you succeeded and failed at. People will listen, and interact, and bring you into the community. Don’t want to maintain your own blog etc? Comment on other people’s’! Retweet, become a curator of awesome, because you’ll be reading this stuff anyway, you may as well share.

Comparisons will kill you slowly, they will. You have no idea what people are choosing to trade off when they do all these extra-curricular things, you just see them fly about doing talks and running events and holding down a job and they’re probably an awesome friend who sends you random texts once a week to see how you are, and has the neatest house in the world but maybe that person leaves toast sweat on their kitchen counter. They drink milk straight out of the carton. And they have a secret love for Sex in the City 2. You see the point I am making here, yes? Most importantly, they probably feel the same way as you when they think about themselves.

Therapy and drugs. I’ve spoken before about my clinical anxiety, and it may be that you need some professional help. Imposter Syndrome could be a symptom of some larger issues. Get help, reach out, if you need to. People will help you, and needing help is not something to be ashamed of. A therapist is a great impartial ear, and nothing deflates your jerk brain like having to justify it out loud. Practice kindness to yourself and others.

This isn’t a comprehensive guide to overcoming doubt. This shit is hard, and it’s hard to maintain, and some of it won’t work. I’ve taken a fairly lighthearted approach to this, but don’t mistake that for me making light of this. I know it’s hard, and I deal with it on a regular basis. If you need to talk, reach out, whether it’s to me, or to the community, or a loved one, or a professional. (Incidentally, would people find an episode on how to respond if people reach out to you useful?)

Further Reading:

Ep 42: Always Look on the Bright Side of Life

Okay so on the day this comes out I will be travelling down to testbash, armed with y mic, laptop, business cards, and stickers! I am so excited, I’ll be bouncing throughout the 4 hour train journey down. I’ve also never been to Brighton before, so I’m hoping to get some walking on the beach and exploration done. Still hoping to get some field recording done, so come find me! I’ll be the short, wide-eyed girl with dark purple hair and will be wearing a geeky shirt.

I like to think I’m pretty good at pointing out the positive of the work I test, and the people I work with as well as logging bugs or pointing out issues. I always feel that passing a story isn’t as good as logging a bug is bad if that makes sense? Passing a bug happens without fanfare unless I make fanfare. And I don’t want fanfare for every story passed – sometimes there are small ones that are routine, so that would take away from the larger work, but when something has been tricky, or when it works particularly well, or is something truly custom, then I’ll praise the work that’s been done.

I’ll also mention passing stories as well as bugs in the scrum and flag up anything particularly good there.

In fact, generally I try to put good points forward first, and this is because I know if I don’t I’ll get distracted by bugs and other things and end up just not vocalising these compliments, and I want to be positive, because no one likes being told only the bad things.

This is a thing I learned when I proof read fiction for a friend of mine – I’d get so lost in the things I’d picked up that I wouldn’t say what I liked, and that was not the best way to give feedback. So I try to start with the good.

I also don’t want to be overbearing and condescending, but even a ‘looks good, not seeing any obvious bugs’ is enough. I’m so used to that look or fear/resignation on devs faces when I walk over that sometimes it’s nice to meet that with: ‘no, this looks good I just need to ask a question’.

And sometimes the devs compliment me! Just last week I was giving a status update and mentioned a small bug I’d found and the dev who’d done the work said ‘Ah, didn’t think of that – good catch’. And it’s a good feeling, and part of being a good team. You’re working together, not against each other.

Ep 13: I Love Docs, I’ve Always Loved Docs

GIF from Jupiter Ascdending. Dialog: I love dogs, I've always loved dogs

The title is a reference to Jupiter Ascending, the wonderfully fun and ridiculous Wachowski film. I highly recommend it!

Lets talk about something else I really enjoy at work: documentation. This was a episode I had in the back of my head but after an interesting twitter conversation I decided to move this up the schedule.

Writing documentation is often left as an after thought, not enough time given to compile and write out good documentation. And even when it’s written, making sure it’s kept up to date is something else that’s often neglected. Or someone sets up a wiki or a confluence and there’s no real maintainer or editor and documentation is piecemeal, and a bit crap. It’s much harder to go and fix someone else’s bad docs than to write your own, I think?

Documentation is important, whether it be for contributing to an open source project, internal documentation, or user documentation. Good documentation is even more important – documentation that is not helpful or usable is probably worse than not having anything at all because confusing a user with bad documentation is going to frustrate them more than having nothing to read and them just learning as they go along or googling for the answers.

So, what goes into good documentation? That’s quite a big question, with lots of different things to take into account, but I’m going to give a brief overview of the basics here.

I think the main things to consider are:-

  • Purpose
  • Assumed knowledge
  • Format
  • Formatting

Each of these have their own considerations:


Fairly obvious, everything needs a purpose. If you don’t know why you’re writing docs, you can’t write then effectively.

You need to figure out who, what, where, when, and why?

This will inform pretty much all the next steps and decisions made.

Users require different knowledge and language to devs, and different users may require different knowledge depending on how they interact with the system. Are there different user roles and permissions? Are there dependencies?

Assumed Knowledge

If your docs are aimed at developers then you can assume certain bits of knowledge about coding or using libraries or apis; or you can possibly assume the devs will be able to google/ask for assistance for parts of the docs.

For user docs other than domain knowledge, what can you assume? I prefer not to assume anything – it’s easier to skim what you know that not find what you don’t know. But you may be able to assume some knowledge of the system, it’s a decision to be made before you start writing.

Format and Formatting

Electronic means easier to update, centralised, and can be more accessible. On the other hand, you need to consider who updates it, how to update it, version control, etc.

Hard copies can be inaccessible to users who are visually impaired, hard to update and review, copies are not centralised.

This can be anything from layout; following user journeys.

Formatting can be anything from using screenshots, bulleted lists, annotations, alt text.


Keep it short and informative. I have a biochemistry degree, and one of the assignments that sticks in my head was writing a precis. We were given an article from a scientific journal, and we had to summarise it in under 1000 words. The original paper is around 4500 words. It was hard, deciding what was really needed to convey the contents and meaning of the paper, and what could be cut without changing the context of the paper. Thankfully it wasn’t a write up of an experiment or research; that would’ve been even harder to summarise while keeping the overall results on findings of the paper correct. I’ve got a link to the paper and the precis here, if anyone’s interested. I’ve read the precis, and I’d like to think my writing has got better since then, there’s definitely choices I’d make just to the way I’ve written things there, even without me re-reading the original paper.

That’s a tangent, but my point is that summarising and shortening things is a skill, one that needs to be practised. Writing itself is a skill that can really only be honed by practising and this is as true for technical and factual writing as it is for fictional writing (though the methodology and skillset is different). You’ve just got to keep writing, whenever you can.

Finally, go read this, its brilliant: http://stevelosh.com/blog/2013/09/teach-dont-tell/

Ep 8: Rage Against the QA

This week I talk to Mike Bell, Drupal Dev, friend, and colleague about the relationship between QA, Dev, and Client.

We talk about how QAs and Devs think differently, reporting bugs to devs, writing AC, and the affect of planetary movements on testing. I also try and fail to remember the term Galumphing and James Bach, the name of the person who coined it.

Mike Bell can be found on Mike Bell, and will be talking at PHPNW15 this year. He’s previously spoken at NWDUG and various Drupal Camps.

In between recording this episode and posting it, its been announced that Mike will be talking as part of a keynote at DrupalCamp Barcelona! Read more about his talk here: https://events.drupal.org/barcelona2015/sessions/mental-health-and-open-source