5 Questions With Simon Morley

Regular readers will now be tired of my Lessons Learned From Reffing Posts so back to my 5 Questions Series and Simon Morley - a Yorkshireman now living and working in Sweden and author of The Testers Headache

1) What's your background and how did a Yorky end up in Sweden?

I started out wanting to be a diplomat - which was probably a really bad career choice as I was one of the least diplomatic people around - at that time! 

So I tried applied mathematics(!), doing a stint in underwater defense research. The fall of the Berlin wall saw the end of that career (reduction in defense research - the cold-war dividend and all that). But, the very intelligent people I worked with at the time said some of the next big technological challenges were in telecommunications. And so I "drifted" into telecoms and started out as a trainee tester at a Swedish company - it was the guys interviewing me that spotted that I could be a tester - so I guess I owe a lot to them (actually my boss was a mathematician, having studied the same course at the same college…)

Ending up in Sweden? Well there's more space, the wildlife is wilder (literally), the nature is cool AND it loves me (at least there are all sorts of things biting me for my blood), the winter sports are more wintry, and... oh yeah, my better-half is Swedish - so I'd been coming here for a number of years before deciding to settle down here. 

2) Is there any difference between the test culture in England and Sweden?

There are many different levels to that question! I've worked in several different countries, and sometimes the testing culture is a function of the country culture, sometimes the company, sometimes the project structure, but usually a mix of all three.

Whilst in England I worked for a Japanese company - which had Japanese high expectations, had imported an American results-orientation and were encasing that in a British work attitude -> and we were combining work from English, French and Portuguese teams -> there were mismatches on so many different levels. The testers and test teams were caught between a cultural rock and an organisational hard place. 

That was very educational for me and I started noticing differences between company, country and organizational cultures more and more - and distinguishing them from "testers" - testers were part of the system, but not THE system. 

In Sweden there is much more a feeling of egalité - equality where anyone can talk to anyone - the hierarchy is not there in the same way (I think a BBC article recently described it as Jante's Law, but I'm not completely convinced about that.) Most things are more open, on the table and up for discussion. 

This is great for feedback and challenging of ideas. Ironically there can be a reticence in Swedes - but not always, and that's not a problem if you understand it. But once people know each other the idea that everyone is more-or-less equal means ideas can flood out - and be challenged. It means the results can be clever and well-thought-through.

3) Your blog is called The Testers Headache - what's giving you a headache at the moment and have you tried aspirin?

Haha!

The blog name comes from a deal of frustration that I had seen in testers over the years (and myself) - part of this was about being powerless in organizations - sometimes gatekeepers, sometimes scapegoats, sometimes put into impossible situations. So I wanted to start writing to help distill my thoughts and even get different views on that from anyone that might want to comment/discuss.

It's an attempt to isolate the tester in an organizational or cultural problem - and look at both aspects. With my science background, I tend to take a systems view of situations and from a number of angles - sometimes tangential! This helps me learn! Whenever I meet new testers (or ones I haven't met before) I usually ask what they have been writing and where I can read it - and if they haven't started a blog, well now is a good time - you'll have at least one reader!

Some time ago I did a monthly blog post called the "Carnival of Testers" - this was both an attempt to point out interesting reads and, occasionally, lift someone up and say, "here's a new writer/blogger… go and read what they say and give feedback" - I still read a lot of blogs, but don't have the time to compile a list anymore  - although I make an effort now and then - I did 2 compilations last year -> (1) to promote "Let's Test" (a wonderful test conference), and (2) to jot down some thoughts about Ola Hyltén (a wonderful person that also knew about testing)

So, the blog (which in itself is partly its own aspirin), is an attempt to re-frame testing as an intellectual activity - at least for testers that want respect, and for organizations that want good testing and good work. It's partly an attempt to illustrate the complexity with good testing and how powerful (and not powerless) it can be - and using that it can contribute massively to good software development… 

4) What advice would you give to a new tester - or someone thinking of becoming a tester?

I meet new/newish testers now and then and I usually want to know why they want to test, what is it that drives them. If they think that testing is difficult to do well, want to study it and get better at it, then I try to find how they want to improve. Anyone wanting to improve usually has a drive or a reason or a main interest. Sometimes it's about tapping into them - doesn't mean I can help, but I can help them understand where they are in the bigger picture. 

That sounds "fluffy" but it boils down to: "Do you want to understand what you're doing?" -> "Do you want to get better at, for example, observation?" -> "Ok, tell me where you use observation - the good, the bad and the ugly….." And then explore observation - pitfalls and good examples. 

Sometimes, people think they can't do something or have never done something, but sometimes they just don't know how to recognize it, and then it's about giving a helping hand. If, and only if, they want help…

I recently held a peer conference where I work and people were stopping me and saying they wanted to come but didn't have any experience to talk about. On 2 occasions after chatting with them for 5 minutes I "noticed" something that they could talk about - and that would be a good report. So, sometimes it's really just helping people "notice" things.

So, advice I would give to a new tester - pair up, chat with or reach out to an "experienced tester" - maybe online or in person - if they're any good they'll usually be glad to help (maybe you have to arrange a time first.) Have a discussion - and maybe challenge the experienced tester to find something that you can (1) improve on, or, (2) learn - something that you didn't know about before. Then ask the experienced tester to give you a challenge - either with something you've learnt/improved

For someone thinking about testing or software development I'd say: 

Creating software is both a creative and subjective art. Matching the software to what someone might want is really difficult on so many levels - (1) The customer might not know what they really want; this creates many problems trying to understand that… (2) They might not have any pre-conceived ideas how to know that what they get is what they want; this makes understanding if what is being developed comes near to what is wanted more tricky (3) You may work in an environment (team, project, company) that doesn't understand these limitations; which makes doing the work more difficult

So, if working with trying to figure out what a customer might/might not want (when there's probably no crystal clear answer), figuring out how a development team turns those wishes into software (when there might be implementation discrepancies due to misunderstanding, mistakes, omissions, etc; and all of these might not be knowable or observable), figuring out how to create experiments (which may well be imperfect) to gather information (which may be incomplete or incorrect) about a system (software + environment + human emotions and foibles) that may be imperfectly described and subject to change and then talk about all of those issues and findings in a coherent way… - if all of this sounds challenging and something that you can make a real contribution to, then take up the challenge of doing good, nay excellent, testing.

Note, to do good testing you will need to understand the human element (to some extent) in this system, understand how to observe systems (with people and other artifacts), understand how to distinguish rhetoric from substantive evidence, design experiments, understand the limitations of what you know about the system and what you can know and then communicate about that in a way that's understandable to someone that probably has not studied this whole system in as much detail as you. 

You'll be a cross between an investigative journalist, scientist, part-sociologist and part-psychologist.

You can make a contribution because this system of interaction is not "off-the-shelf" and so the techniques, lessons and ways in which to approach such systems are not predictable - you can help by adding to the corpus of knowledge that makes working in such systems better. This might be finding traps and good experiences to avoid them or it might be finding new techniques with certain types of systems.

5) What books are you reading at the moment and why?

Oh, quite a lot - I usually have quite a few on the go. The current top of the stack:

"How to be an explorer of the world" (Smith) - a great book to get you to look at the world around in a new way. It's a really good book for practicing observation and note taking!

"Intuition Pumps and Other Tools for Thinking" (Dennet) - Just started this - I've been intrigued by Daniel Dennet since seeing a TED talk some time ago and then seeing some recent interviews - he has an "evolutionary" bent to thinking - something I wondered about wrt testing some time ago and think I might investigate more.

"NASA Space Shuttle Program Tacit Knowledge Capture Project: Oral Histories from Twenty Program Officials and Managers, Challenger and Columbia Accident Insights and Lessons Learned" - I'm intrigued by the program to make tacit knowledge explicit in NASA - it's connected to a recent post I made about peer conferencing -> that the dialogue and discussion of any topic /can/ get to the core issues and links in to other work (by Bo Göranzon) about dialogue seminars to uncover hidden knowledge.

"Experiential Learning" (Weinberg) - I've experienced this type of learning in several forms (I now recognize them in retrospect after reading about the techniques) and understand how powerful this learning type is and want to get better at it.

"Psychology of Intelligence Analysis" (Heuer) - I started reading this about a year ago and returned to it recently. This was a textbook in the CIA for how they gather and analyze masses of information, trying to understand their own biases that may occur and so how to make better decisions - actually this is very similar to testers gathering masses of different information and trying to work with that. The CIA have been years ahead in terms of applying cognitive studies and applying to their work. They recognized that most of their techniques are heuristic in nature. I want to use a sister book of this (a trade craft primer) and do a mapping to software testing -> that's an ongoing pet project.

"Protocol Analysis - Verbal Reports as Data" (Simon, Ericsson) - I discovered this recently (actually referenced from another document on intelligence analysis (Intelligence Analysis: Behavioral and Social Scientific Foundations)) - really interesting - it backs up how difficult it is to get to the "truth" - their thesis has ideas on the power of verbal information. Still working through it - but interesting so far.