A few shorter testing books for the 30 day testing challenge

Thought I'd whip up a few recs for shorter testing books for the 30 Day Testing Challenge, which kicks off with buying a book on testing to read by day 30. Please add your own suggestions in the comments! 

http://www.ministryoftesting.com/2016/06/30-day-testing-challenge/

The Little Black Book of Test Design by Rikard Edgren

29 pages not including bibliography.

Packs in a lot of ideas despite its size. Well worth reading for inspiration and an insight into how a very experienced and skilled tester thinks about designing tests, and really at this size, you have no excuse not to.

Explore It! by Elizabeth Hendrickson

186 pages

In my opinion, this is _the_ exploratory testing book. If you have never read a book about software testing, then buy this. Hendrickson starts by presenting a really nice way to create charters for your exploration, moves on into observation, modelling the product you're working with, and finishes up with descriptions of exploration in context, demonstrating how broadly you can apply the techniques you learn in this book. Well written and engaging throughout. 

50 quick ideas to improve your tests by Gojko Adzic, David Evans, Tom Roden 

198 pages

This is a lovely browsing book - lots of neat ideas, each one covered in 2-4 pages. It's aimed at cross-functional teams, and assumes you are using user stories, and delivering in iterations - if you're not working in that environment then you may find some value, but a lot is likely to be difficult for you to apply. Ideas range across how to work more effectively together, to designing better checks, testability, and managing large automated test suites. 

Perfect Software, and Other Illusions about Testing by Gerald Weinberg

182 pages

This is the ideal book to get ​_other_​ people to read. Like your CTO. It explains some of the common myths and misconceptions people have about what testing can achieve. A good antidote for addicts of Magic Testing Pixie Dust (i.e. those who believe sprinkling a bit of testing pixie dust on at the end will magically fix a broken project.) That doesn't mean you won't enjoy reading it yourself, but it's one you'll want to share.

Edited to add:

Remaining relevant and employable in a changing world by Rob Lambert
166 pages

This is about taking control of your career - how to find good jobs, demonstrate your skills effectively in an interview, join testing communities and network. 

You can't learn to [ ] by reading a book

Triggered by this tweet and following conversation: https://twitter.com/TestSideStory/status/432453407673446401

I commented: "Learning happens during reflection as well as action. Reading can be both." But then I ran out of space to explain in a tweet what I meant.

Here's my example:

When I was learning to fly a glider, I spent a LOT of time flying in circles. (Why? Because I was thermalling, or trying to - which means that you're trying to find, centre in, and stay in an invisible, moving column of rising air, which, by the way, has sinking air on the outside, and to do that you need to fly in fairly precise circles, and also have a good mental picture of where you think the thermal is now, that you keep adjusting to new data). I kept finding myself out of the nice thermal, sinking fast and hunting around to try to find it again, for reasons that were entirely mystifying to me.

Eventually I sat down with the books, and read up on the theory. One point I noticed was the comment that your turning circle was going to be larger if you were flying faster. I worked out and drew circles to scale for the aircraft I was learning in, for different speeds. Huh. Quite a lot of difference. In fairness, my instructor had pointed out a number of times that my somewhat ropey speed control was making things harder. I think he might even have drawn a few circles. But until I'd struggled with it in practice, re-read the theory, and then worked out a few examples myself, the penny didn't really drop. The next time I went flying, I still had difficulty controlling my speed, but now I felt I had a good grasp on the effect it was having, and it seemed to be easier for me to picture mentally what I might need to do to recover and find the centre of the thermal again.

After that, I got better, and my thermalling skills are something that instructors have always complimented (even when they were being very negative about the rest of the flight!).

So, where did I learn to thermal? While I was up in the air? Down on the ground reading a book? A bit of both? Or is that the wrong question?

I think it would also be wrong to assume that the action only happened in the air, and the reflection only on the ground. Reading a book can be a very active process, whether that be externally visible (calculating and drawing diagrams), or internally questioning, cross-checking, and rebuilding your own mental models as you read.

The State of Testing

Do you know where the testing profession is heading? Do you know how testers' salaries vary across different locations worldwide? What are the main challenges faced by testers around the world, and what does their professional environment look like?

It's not hard to find people who think they know the answer to the above. And some of them are pretty confident about that. But actual hard data - well...that's not so easy to find.

Which is why I was delighted to hear (via TESTHEAD) that Joel Montvelisky and Tea Time with Testers are planning a survey, but in order to get as many responses as possible, they need to spread the word.

Here's where you can sign up: http://qablog.practitest.com/state-of-testing/

Can you get your colleagues to do the survey too?

The "boring" thing...

The "boring" thing comes up on a regular basis. So often, that I think we testers often buy into it ourselves, and start saying things like "you need to be able to tolerate some boring stuff" about testing.

Erm - you mean like any job, right? Like you know, if you want to learn programming, or play the violin, or calculus, there's a certain amount of work you just have to do. So why do we allow people, including ourselves, to make out like a high tolerance for boredom is some kind of beneficial personality trait in testers specifically?

I think that's a very, very, dangerous path. Because, apart from making us look like button pushing dullards - It's. Just. Wrong.

(I happen to have a pretty low boredom threshold myself - which is part of the reason I stayed with testing - so you might detect a certain degree of self-serving bias here but IT'S MY BLOG DAMMIT. So I'll forge right ahead with telling you why my personality weakness is, naturally, a secret strength.)

Frankly, I use a sense of boredom as a very important warning flag when testing. It may mean a variety of different things, from "you are trying to do something a small shell script would do better" to "this workflow is both tedious and difficult to get right without several tries: this is useful feedback that I should be providing" to "could the reason I'm bored out of my skull be that I actually know the task I'm doing right now is pointless and ineffective? Perhaps I should do something about that."

I hope you can see where I'm going here.

I don't think it benefits our testing, ourselves, or our profession to accept the "boring" label. I wrote this post in response to an aside in an interesting post (that I'm still digesting) by Liz Keogh.

I commented as follows (first indented bit is Liz's words):

" Testers are very happy to do the same thing over and over again, with minor tweaks. Their patience amazes and inspires me, even if they are utterly evil."

Very interesting and useful post, but I had to jump in on this one: I am a tester. Doing the sane thing over and over with minor tweaks doesn't make me happy, it makes me very unhappy. I have an extremely low boredom threshold. As do many good testers. So I wouldn't call it patience, so much as crazy levels of stubborness when I think I've caught a sniff of something. Finding out something new or interesting isn't boring. I think the distinction is very important, because if what non-testers see is "testers like doing boring stuff" then they start feeling it's okay to dump boring stuff on them (and bad stuff ensues, like demotivated testers, loss of trust in the team, etc). Whereas the truth may be more that "this tester has got their teeth into something potentially interesting to them - even if it looks boring to you from the outside, your judgment of what looks interesting to someone else isn't as reliable as theirs".

 I clearly didn't get it right, as she didn't quite get my point. I hope I'll have explained well enough in the follow-up comment, but don't really want to hijack her comments for an aside.

Eventually, I hope I'll strike on a better way of explaining it. How do you explain it? Or do you genuinely believe that your chosen profession is actually meant to have more boring bits than other professions?

After the conference...

I arrived back from the conference late last night - such a good conference, thought inspiring sessions, hope inspiring talks, lots of new ideas to work on, and best of all - lots of great conversations with new people, and catching up with others I don't see as often as I'd like.

I sat on the plane home last night just trying to capture all of the things I'd like to do now after the conference - too many to share before my son wakes up! So instead, I'm thinking about how to tackle that long long list. I've already started to mark some ideas as ones which can wait until a suitable moment, and ones that I should work on soon. Realistically I know I probably won't get to many of the former (many are interesting, but not currently very relevant), but I should reread the list in a few months and see if any have now become more relevant.

The items that are just about following up on references to interesting books and tools to explore are fairly easy to implement. What's going to be harder is deciding: what do I want to change? What do I want to implement? And here, I confess to not taking my own advice - in my session I asked participants to make a commitment to some action to take on their return, because it's too easy to go home and think "I will do that tomorrow", and tomorrow never comes. I didn't do the same myself - to be fair, I was kinda busy focusing on the session. I wrote some down on the way home, but I now have to think about how I can achieve them.

Of course, there is one big advantage - if I find that in a few weeks time I am still trying to figure it out, then I can take it back to the people who attended my session to ask for some help, advice, or moral support. Because the lovely people at Eurostar will be creating a new site, with a discussion forum area that we're going to be able to use to share stories and discuss. This is a new thing for me after a conference, being able to , and I'm really looking forward to it.

Once I'm a little clearer about what the main priorities for me are, I'm probably going to revive an old approach I tried a few years ago, and create a personal review plan - sounds very formal, but it's actually very simple. I pick 4 main personal goals I want to work on that year - I write out a sentence explaining each one at the top. And then I create a short table for the next month, and one for after that. As I think of specific activities that will contribute to those goals, or as I realise what I've done this week fits in with that - I add them to the list. (As an example, if my goal is to become a better facilitator of meetings, I might practice, by offering to facilitate a meeting, or I might read Sam Kaner's fantastic Facilitator's Guide to Participatory Decision making.)

I go back to the document every now and then and look at what I've been doing. Often I realise that actually, I achieved a lot this month even if I feel like I didn't do much because I'm disappointed about not getting a couple of things I'd hoped for done. Sometimes I realise I haven't done much at all - if it's because life is just busy right now, that's fine - or maybe it prompts me to push myself to pick one small thing off the list and get it done now.

I also tend to colour code the list according to the goals (that's a good incentive to only pick a small number!) - if I see my list is all green, and no yellows for months, maybe I better go back to that. Or maybe, it isn't as important to me as I thought.

This structured approach isn't something I do often. At the time I started doing it, I felt quite down about my career, and it helped me to see I was actually making quite a lot more progress than I thought I was. At this time, life is pretty busy with a small child and work, so I think it may help me to use the limited personal time I have wisely - it's pretty tempting to just read blogs and Twitter, and while those are a great source of ideas, inspiration, and conversation, if I don't actually go off and do anything as a result, it's not a good use of time.

It may sound like - hey, well I do that at work anyway. Why should I do it just for me? Well, I'll leave you with this quote:

Everybody's self employed, whether they realise it or not. Via @imccowatt #esconfs #UnboxedTester @TesterAB

— Simon Knight (@sjpknight) November 6, 2013

Off to Eurostar again

Packing today for my third visit to the Eurostar software testing conference - this time in Gothenburg.

The first time I went was in 2008, in The Hague - I'd won a free ticket at SIGIST, and my company kindly agreed to pay for my travel. To my manager's surprise. Though he was even more surprised when I said that if they couldn't find budget for me to travel there, I'd pay my own way, but could they give me the leave? He almost fell off his chair, and spluttered something along the lines of "I knew you were interested in testing but...". And then recovered himself enough to request that I get him a particular kind of cheese while I was in the Netherlands. :)

It was a pretty mind blowing experience for me. Before SIGIST, I had never been to any conferences, and I was a bit afraid that everybody else at "Europe's #1 Testing Event" would be a test manager, consultant, or some other kind of big expert and that I would really stand out as a mere humble tester. I wasn't actually 100% certain I was even supposed to be there. I felt I had to explain that I was there almost by accident.

Those doubts vanished fairly soon. I arrived there interested in testing. I went home obsessive about testing and plunged right into the testing community, eager to find out whatever I could. I attended whatever meetups or conferences I could manage, but Eurostar again was out of my budget, and that of the teams I worked with. Then someone pointed out that one way to get to a conference - is to speak at a conference. I discovered Manchester Eurostar in 2011 had a minitrack of short talks to encourage first time speakers.  I applied with a lot of help and feedback from Stephen Allott and Rob Lambert on my submission - and got accepted!

And now I'm attending my third Eurostar. It looks like a fantastic programme - given that I'm doing a track session, this is both a good thing and a bad thing. I hope at least a few people come to my session, but I've got some stiff competition!