Talking vs Communicating

It's easy to conflate talking with communication. Sure, most of the time I would suggest that when people are talking, people are communicating. But the opposite isn't necessarily true. A lack of talking does not necessarily mean there's a lack of communication, or a lack of collaboration. We should be aware of this when making observations about people and the teams they work in.

Phased vs Threaded Testing

There have been many attempts to model different approaches to software testing. You'll be familiar with many of them: exploratory vs scripted; traditional vs agile; testing vs checking; standards-driven vs context-driven; and many more.

There’s another spectrum I’d like to introduce that I’ve derived value from using: Phased testing vs. threaded testing.

Lies, Damn Lies, and Traceability Matrices

Beware the Traceability Matrix. It deceives and misleads.

An Anecdote and a (small) Editorial - The man who opened the door to testing for me

I worry about posting this. I'm worried I'm going to be told to 'check my privilege'. I'm worried I'm going to be told my perspective isn't important. But to add a positive experience isn't to deny that bad experiences happen. I also don't like getting involved in Twitter dramas, but as an opinionated observer, I find their pull irresistible at times. Especially when they involve people I consider to be friends.

There are anecdotes of people leaving the testing field because of James Bach. I'm not denying this has happened. But if we're collecting anecdotes, I'd like to add mine.

An Anecdote

Towards the end of 2009, I had been testing for about two years and I had no public profile. The kind of testing I was doing I would describe now as 'exploratory testing in an agile environment.' I didn't know those words back then though. Describing what I did with the words I knew back I would say "I was doing ad hoc testing in an unstructured environment". I had done ISTQB, gone to local meetups, and interacted with other testers who worked for big corporations. They talked about things like "requirements" and "test scripts" and "traceability matrices". I'd lie in bed at night worrying about what a fraud I was being. You see, I was doing things like "talking to the developers" and "asking them what the most important things to test were." When I was done, I'd report back to them. Not in a test case management tool; I'd walk to their desk and talk to them. Sometimes I'd be as formal as writing an email, or a two-page summary document. I tried testing 'properly' once, but it didn't make much sense to me. I was obviously just not 'getting it' which added to my anxiety.

The STANZ (Software Testing Australia New Zealand) Conference 2009 came around and I begged my employer to go as I was desperate to learn how to 'do testing properly'. One of the speakers was James Bach. Oh he's an expert in the field! His talk was called "Becoming a Software Testing Expert".

Perfect.

In his talk, he talked about "The Tester's Mindset". There was lots of talk about thinking critically, on how to identify threats to value, establishing context. It was immensely useful, and really helped give structure to what I was doing, and let me think critically about my testing and how to improve it.

But it still didn't scratch the itch I had.

So I plucked up the courage to ask him a question after his talk.

"I really enjoyed your talk, and it talked a lot about the kind of testing I'm doing, but, umm.... what if I want to learn how to do testing by the book?"

"Why would you want to do testing by the book?" he boomed back in his American accent. "The book is wrong!"

"I wrote a book about testing, and noone ever checked to see if I knew what I was talking about."

He continued talking to me, right through the break time. The next session was about to start, so he started rummaging through his bag. He said "It looks like we've got to go..." He found what it was he was looking for. "But here, you should read this book. You can have it."

"Exploring Science" by David Klahr. The book James gave me as a faceless attendee at a conference in a remote part of the world

The words "The book is wrong" was the key that opened the software testing door to me. Being gifted a book as a nobody by a gargantuan in the industry was what pushed me through it.

Since then, I've interacted with James countless times:

I've engaged in coaching sessions with him, which he volunteers his time to give (http://www.satisfice.com/blog/archives/393).

The first time I spent one-on-one time in person with him was when he volunteered his time to help Brian Osman set up and be content owner of the first Kiwi Workshop on Software Testing.

The first time I collaborated with James was when he volunteered to co-write an article for Testing Trapeze magazine, and I offered to co-write with him.


These were all 'nice' things for him to do. They came from a place of authenticity.

James can be difficult to interact with, because he doesn't pretend to be nice. I find him intimidating. I have to think carefully about what I say around him. I have to be careful with my ideas. If I say something, I have to defend and justify it. But that's ok. That's who James is, and that's the deal I make when I engage with him. Through this all, I have learnt courage. I have learnt how to be my own biggest critic. Yes, I also suffered from baby tiger syndrome, but I also learnt and grew from that too.

In short, interacting with James is difficult, but worthwhile and I owe much of my career and success so far to James Bach.

That's the anecdote to add to the pile.

A (small) Editorial

I don't think James is a bad person. I don't think James is a malicious person. I do think James is unusual in that he values integrity over manners; honesty over niceness.

I said in the anecdote that I owe much of my career and success so far to James Bach. I think most of the people who would read this have benefited from the work James has done directly, or indirectly, consciously, or not. In fact, I can't imagine what the testing profession would look like if not for his influence on it.

But James is double edged sword, and it frustrates me when I read about people being hurt by his blade, when they don't seem to deserve it. I don't know what to do about that - his sharpness has helped so many; his contribution to the industry immeasurable. But his sharpness has undeniably hurt some people that probably didn't deserve to get hurt. Dulling the blade or sheathing the sword means losing a lot.

Embracing diversity means challenging what is 'usual' and working out how to work with 'unusual'. If we strive to embrace diversity, then we should acknowledge diversity of personality, and diversity of temperaments, and work out how to work with that.

Lean Testing in theory and practice

This article was originally published in an earlier form on the Assurity Consulting website

There are many different definitions of software testing, and many views on what responsible testing looks like in our industry.  How you view the role of a tester informs what practices and artifacts you believe are valuable.

Resources relating to "That's not the map I had in mind"

Resources for "That's not the map I had in mind"

I expect that these diagrams will evolve and grow over time which is why I have included them here for comment. This list will grow over time.

Xmind file for taxonomic hierarchy: XMind file

JPG file for taxonomic hierarchy: Image

 Downloadable examples of various testing models coming soon

WeTest Weekend Workshops 2014 theme: Evolve

This last weekend (29/11/2014), we had our second WeTest Weekend Workshops 2014. The theme was "Evolve".