Top 3 New Skills from TestBash Manchester 2016

Third in a series of posts summing up my thoughts on the Ministry of Testing’s latest success.

Note: The summaries below are based on my takeaways from the discussions, and are not necessarily representative of either the original intent or meaning of their authors! I only offer my perspective on what I heard, so my apologies if anyone feels misquoted. With that said…

3. Sketchnoting

The conference opened with the very engaging, very experienced James Bach, someone I’ve been aware of for about as long as I’ve been a tester. His insights have helped me before, and seeing him in the flesh for the first time I was doing my best impression of a diligent student, scrawling down snippets and key themes of his presentation on managing social and critical distance in testing. It was all going well, until I looked over my first complete sheet of notes and it struck me – they were useless!

Um… what?

A whole load of waffle, a few detached ideas and themes, but otherwise a real waste of effort. If I had spent a little longer listening and less frantically transcribing, I may have crystallised my own personal takeaways in a few more concise (and more complete) statements. And then I looked around, and saw everyone else doing something different.

Various people could be seen scribbling away with coloured pencils, highlighters, felt tips and many others chose to draw out their reactions to the papers being presented, rather than a blank wall of scribbled handwriting. The notes were oddly beautiful, akin to mind maps or other brainstorming techniques, full of personal connections and imagery meaningful only to the author.

I feel like I’m arriving very late to this particular party, but something which seems de rigueur at software conferences is the mysterious art of sketchnoting.

Sketchnotes are purposeful doodling while listening to something interesting. Sketchnotes don’t require high drawing skills, but do require a skill to visually synthesize and summarize via shapes, connectors, and text. Sketchnotes are as much a method of note taking as they are a form of creative expression.

From Mike Rohde’s The Sketchnote Workbook:

Friends in the sketchnoting community constantly share how they use sketchnotes to document processes, plan projects, and capture ideas in books, movies, TV shows, and sporting events.

Craighton Berman at Core77 does a nice job of describing sketchnotes as:

Through the use of images, text, and diagrams, these notes take advantage of the “visual thinker” mind’s penchant for make sense of—and understanding—information with pictures.

From SketchnoteArmy

Now, I’m a largely verbal thinker. By background is in English Literature and Philosophy, I write poetry and I’m a real devotee of the written word. But the reality is, sketchnoting seems to offer something I don’t have in my arsenal, and even if I decide it’s not for me, I want to take it for a spin! So, in the weeks ahead, I’m going to be learning the dark art for myself.

Below are some of the most promising resources I’ve identified so far. I look forward to giving an update on this in the weeks to come!

From The Sketchnote Handbook

Sketch note resources:
Sketchnotes 101: The Basics of Visual Note-taking
How To Get Started With Sketchnotes
Sketchnoting in Education (great list of resources)

2. Using The Dark Side

Iain Bright was on to a winner in his talk on The Psychology of Asking Questions, comparing testers to Jedi, and testing to using the Force. Who wouldn’t want to be a lightsaber-wielding warrior, against the forces of evil in the galaxy? Evidently most of the testers in the room agreed.

But the Force represents a balance, between the light and the dark. By only ever using one approach – that of positivity and harmony – we fail to acknowledge the “power of the dark side”.

A tester’s main tool is not a crystal-cored laser sword (although admittedly that would be useful in some estimation sessions) – it is the humble question. By asking the right questions, we stimulate thought, encourage fresh perspectives, and develop our own understanding.

Below is an excerpt from Iain Bright’s article on Testing Huddle:

After a bit of research, I found three ‘real-life’ psychological techniques which we probably use but at an instinctive level:

• Why Not: when refused, ask “Why Not….?” This should only be asked after you have asked yourself “Why?” and you are clear in your objectives.
• Foot in the door: start off small and build up.
• Door in the face: make a large request then follow up with a smaller request if the first is refused.

From Psychology of Asking Questions

Whilst my main takeaway from the whole conference was Kim Knup’s excellent points around positivity (combined with Stephen Mounsey’s discussion of styles of listening), there is also something to be said for actively engaging in “dark side” activities – that is, proving something is brittle, be that code, an idea, an approach, a design. Considering this I was reminded of James Bach’s example of the Challenger Shuttle safety committee, who failed to speak up, thereby failing to execute their role. People died because those who were entrusted to do their job were too “light side” to rock the boat.

Testers: Rock the boat! Rattle the cage! Dissent! Disagree! Shout from the top of your lungs “I’m as mad as hell, and I’m not gonna take this anymore!!”

Maybe not that last one. But remember that friction at work is not always bad, and is often a sign people are doing their jobs properly. In my workplace we have a culture of “robust conversations”. These look a lot like arguments to outsiders, the main difference being we are all friends again at the end. That honesty, friction and – let’s face it – brutality lets us get a lot done without a lot of wasted time. It is a lean approach to interaction and in my experience many testers would benefit from a better understanding that speaking up, speaking out and saying “hell no!” is something required in the role.

Dark side resources:
Psychology of Asking Questions
Ritual Dissent (a dark side workshop)
10 Ways to Protect Yourself from NLP Mind Control (amusingly crackpot, but gives a nice “defence against the dark arts” primer with dark side tecniques implied throughout)

1. System Monitoring

Gwen Diagram’s sweary, surreal and superb spin through the wonderful world of what I’d have considered infrastructure considerations was a great eye-opener to some of the tools I’ve been missing out on as a tester. Whilst I’ve recently dabbled with performance testing (via JMeter) for the first time, other than that system performance bottlenecks, release strategies and the more techy system tools have remained in the hands of developers.

Gwen put an end to that with one simple sentence:

Monitoring is a form of testing.

This seems obvious when you put it that way, doesn’t it? I mean… what’s testing about? Providing information about the state, performance and functionality of a system. Discovering what works and what doesn’t, making observations about the quality of what’s there. There are so many definitions of the purpose of testing but whatever school of thought you subscribe to, it seems pretty clear monitoring is a very closely linked activity.

So why have so few testers traditionally looked into the infrastructural level? The answer seems fairly obvious: many testers are not technical, and as such the “stuff behind the code” seems obscure by several dimensions. If we can’t read code, we can’t work out configuration problems… right?

The reality is, modern tools like New Relic and Kibana make the arcane business of interpreting esoteric data strings something anyone can do – often at a glance. A view of the least performant screens in your app? A breakdown of your user base by browser? Why wouldn’t these things be of vital importance to a tester, someone who understands the importance of context in all scenarios?

A great start in this has been talking to my dev team, and a quick chat with the infrastructure guys. Whilst they had some suggestions for the “most relevant” screens for my purposes, those were of varying relevance – a better idea is to put on your explorer’s hat and go for a wander through the various types of data available (ideally with a dev nearby to confirm or deny any technical assumptions you make along the way).

I’m new to this and I don’t pretend to have a great grasp of it yet; however this is a real gap in my CV as a tester and one I’m relishing the opportunity to plug.

System Monitoring resources:
Zen and the Art of System Monitoring
Some of the stuff New Relic can do for Testers
Build impactful Test Automation dashboards using ELK stack