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

https://www.import.io/post/8-fantastic-examples-of-data-storytelling/
http://janetgregory.ca/im-right-im-wrong-all-the-time/
http://www.gmgauthier.com/advocacy-observation-and-the-future/
http://thetesteye.com/blog/2011/10/software-testing-storytelling/
http://firstround.com/review/Lessons-from-Pixar-Why-Software-Developers-should-be-Story-Tellers/

http://visible-quality.blogspot.co.uk/2016/06/resurrecting-signature-series-of.html

Ep 31: Tales Of Derring-Do Bad and Good Luck Tales

Or: Duck Tales, Woo-oo
Or: Rubber Duckie, you’re the one

Which children’s tv show to pay homage to? Such a tough choice!

You know the rubber duck debugging thing, right? The idea that you should explain a problem, or some code to an imaginary or otherwise rubber duck on your desk and that forces you to think about the problems, out loud, and explain your thinking and suddenly you realise you’ve missed something and things fall into place, there’s a chorus of angels etc.

I do not have the rubber duck. I have the unfiled bug report. So many bug reports get closed half way through typing when I realise I’m being an idiot, or maybe I should try x first instead to see if the issue isn’t that it doesn’t work, but that it works in a way I wasn’t expecting or needs better help/UX text. These discoveries may well be filed as bugs but, importantly, they’re very different to the bug I was in the middle of filing.

Sometimes I think out what I’ll say to a developer if I go over to ask – I tend to plan out my half of conversations in my head anyway, so I generally have a ‘well, if I do this and this, this doesn’t happen (or does happen)’ and that 1) makes sure I’ve got my steps down – especially if there’s a weird or complex issue (or issue on a complex feature) and 2) makes sure what I’m saying makes sense.

Forcing yourself to formulate your thoughts into full sentences means your brain is getting information in a different way. It’s why you can say something and only realise what you’ve said after you’ve said it. You have to hear the words for your brain to click, as it’s a different way of getting the information. Your brain is great at smoothing over cracks when it’s made the leaps subconsciously.

Typing words out is a similar exercise. You’ve got to slow down to write out the connecting bits your brain doesn’t specify, so you get the information slower, in a different format, and with all the details, even the unnecessary parts (which may turn out to be necessary). I often go through the steps that caused the bug again but stopping to write each step down as I go. Again, this forces me to consider why I’ve done that step and whether that could be the issue rather than the system itself.

The issue with your brain, is that occasionally it lets you get away with your own bullshit, or manufactures bullshit and you end up in a mess. The duck or a similar proxy inanimate object means you can clear it out without having to actually get up or make too much of an arse of yourself.

I prefer to use a computer or mythical brain!developer at start as real people are unpredictable and derail into all sorts of possibly unrelated issues, plus also I am distracting them from what they should be doing, or if they’re in the zone.

Of course, there are times where I do all this and I still have to go over to a dev or file a bug, but at that point I am prepared and can explain/file a good bug so the developers know what’s going on as easily as possible.

Its also good for documenting tests, so the test session has notes about what I’ve done. I often reference the AC in the bug/test session, so it’s laid out in a As then, when this, then this, which is a fairly clear way to write out issues in a cause and effect kind of way.

Ep 17: Risky

Leading on from last week’s show, I want to talk about prioritising and risk assessment. I’ve spoken a little bit before about how I use AC as a base for my testing – that’s the highest priority, then I spread out from there.

I think there’s some merit to timeboxing things off and focusing your time for a tight time period, like 15mins of focused testing and see where you get. This I think is true for security updates that might have an effect on various parts of the site as well (talking from a Drupal point of view, we recently had an update that may have affected some custom work we’d done, so I gave that custom work a test through). As an aside, the ten minute rule for test plans1I think is useful, and I have definitely found that AC take less time to write and review once I’m in that focused mindset, and it cuts the fluff that doesn’t need writing, that can be left to the test sessions.

But how do you prioritise what you test after AC? How do you prioritise bugs when you report them (and defining blocking bugs as opposed to ones that need fixing, but don’t block the story from passing, if you even differentiate them. I try to keep blocking bugs to bugs that I wouldn’t want the work going live with, but that doesn’t always mean the AC isn’t being met. So sometimes that requires a discussion of ‘is this a blocking bug, or a bug we’ll tackle as part of the bug fixing part of the sprint? Should we log it but throw it to the client to prioritise?) Which comes down to:

• Risk of fixing it vs. Risk of keeping it as it is

• Complexity of the bug and fix

• The timings of the project


For example, we work with Drupal, one bug we came across recently had a fix that involved upgrading a module to the dev version. This was the version after the latest stable version of the module, and so there was some risk attached to it; it wasn’t used widely, hadn’t been crowd tested like the stable version had. The site we had the bug on is a large site with lots of users. The bug was relatively small, and had a workaround. We decided to spend some time investigating alternatives, but if we couldn’t easily find an alternative fix within the time we had, we could offer a workaround, and wait until the dev version of the module became the stable release. It just wasn’t worth the risk of upgrading to a potentially unstable module version that could have unknown effects over a large site, that we didn’t have teh time to fully investigate, given we could offer a decent workaround to the client.

On the flip side, a client asked us to spend some time and effort looking into a complex change request – changing how out of hte box functionality worked and looked for them. For us it didn’t seem like a high priority, and was not complex, but not easy, but the client prioritised it, so we did the work, anf the client was happy. We also was able to contribute this back to the community, for other people to use if they found it useful.

Which I guess highlights that there will sometimes be conflicting priorities from a developer and client point of view, and sometimes concessions and compromises have to be made. This does depend on the client, as there will always be some who will think everything is top priority all the time, but sometimes a discussion is needed.

I think conversation is one of the most important things when it comes to prioritising and risk assessment, and I do think I’m getting better at spotting which bug I need to get developer input on before marking it as blocking or not.

And sometimes the conversation ends up like my second anecdote back there, where we ended up contributing to a larger community, and that’s always a good thing.

As an aside, I want to throw a podcast recommendation at you. All through recording this episode, I’ve had the soundtrack to a podcast called Risk!2 In my head. Its the opposite of everything this podcast is. The tagline is: True Tales, Boldly Told, and its “where people tell true stories they never thought they’d dare to share in public”. Its often NSFW or children, but its also funny, or touching, or any other number of things. Its well worth a listen, if you enjoy listening to stories.

Footnote

[1]http://googletesting.blogspot.co.uk/2011/09/10-minute-test-plan.html
[2]http://risk-show.com/

Ep 7: To fight the bug, we must understand the bug

Would you like to know more?

Firstly if you get the reference that the title of this ep is (without googling!), please let me know so I can award you one internet.

Bug reports are an art form. I work with a lot of devs, devs who are good at their jobs and who I have massive amounts of respect for, who I enjoy working with, but, more often than not I’ve no idea what their bug reports are about. Front enders will write bug reports about css elements that are missing, back end devs will write ‘this feature doesn’t work, investigate and fix it’. Which means I have to go and ask what I’m meant to be testing, what the expected functionality should be, where the elements will be applied, things like that. The bug has been put straight in by the dev when they’ve noticed, sometimes before I’ve even had chance to test anything, so I’ve not seen the wrong behaviour, never mind knowing what the right behaviour should be.

So, I want to talk a bit about bug reports, how to write them, how to make them as useful as possible.

So, I find a bug. I double check that I can reproduce it, and I’m not just being an idiot (its more likely than you think!). If it still looks a bug after that I either:

Start writing a bug report if it’s a simple, obvious bug.
Talk to a dev on the project (preferably the dev who did the work I’m testing, but if it’s not obviously related to a feature, the dev I feel will know most about it). The reason I generally try to talk to a dev first is because firstly, dev environments can be a bit weird – features can be switched on or off (sending emails for example, we turn that off on most dev sites and this causes some errors to show), deployments can go weird, things like that. It might be that I just need to clear some caches or similar and the problem will be fixed. Secondly, I might still be being an idiot and not realising, and a second pair of eyes is useful. Lastly, the dev might have some insight into the issue and have some details they want in the bug report. Or they’ll be like ‘Yup, i know what that is, throw it over to me and I’ll fix it’, which if its a bug that’s stopping the story from being passed is a nice way of getting those bugs prioritised.

So, assuming I’ve got to the ‘write a bug report’ step.

Firstly title. I try for short, but sometimes in order to be clear I have to be on the long side. I go for findability over short and pithy. You should be able to figure out roughly what the issue is and what part it affects from the title alone.

Description. More details about user roles it affects, steps to reproduce, expected and actual outcomes. Sometime if the expected behaviour is obvious I won’t put that it, I’ll put ‘we should remove x or something, because sometimes the expected behaviour is obvious and putting it in the ticket sounds really condescending.

Attachments. Screenshots, documents, videos, whatever supporting information I have.

Links. Links to a story or issue if relevant.

Sometimes the bug will be passed to the client or product owner. If it’s a usability issue and we’re unsure how they want the system to work, we’ll pass the bug report over to them and let them feedback on it before any work is carried out.

Decent bug reports are important, and so triaging incoming bugs from product owner becomes an important task. You’ve got to check the bug actually exists and isn’t a user or permissions issue. You’ve got to make sure the description makes sense, and relates to the bug they’re reporting. And then you may need to add to it. Add screenshots, details about reproducing the bug, anything the product owner may have missed. Sometimes this becomes a back and forth with the product owner if the bug report isn’t clear at all. Sometimes you even need to split bug reports up if the report is multiple bugs in one.

Giving devs and testers good bug reports is part of making sure work is carried out efficiently, with minimal re-work/ticket tennis, so I think it’s really important to make sure reports are as detailed and useful as possible.