Software Testing

Book Review - Crucial Conversations by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler

It has been quite a while since a book has had such an impact on how I look at communications. The book offers a treasure trove of techniques to navigate tricky conversations. I first read this some time ago and have been through twice now as it feels important to really understand the contents.

The authors define crucial conversations as those pivotal moments when opinions clash, emotions surge, and outcomes are important. The book helps with ideas on how to navigate such conversations.  At the heart of the book lies the notion of creating a safe environment for candid discussions. Respectful communication, paired with active listening, emerges as the basis of successful communication. It covers those difficult topics and how to approach them in a balanced way, taking emotions into account. It discusses how conversations involve sharing perspectives, seeking comprehension, and fostering a collaborative atmosphere.

Another key message is that effective communication happens when both parties contribute to and draw from a common pool of understanding. Misunderstandings often arise when this isn’t there. The book underscores the importance of maintaining safety and mutual purpose during conversations. Establishing common ground and shared goals forms the bedrock of fruitful discourse. The book's principles can be extended to group dynamics and improving how you handle crucial conversations can yield improved team cohesion and decision-making.

Normally I’d say who I think would benefit most from reading a book but in this case I’d say that I can’t think of anyone who wouldn’t benefit from a better understanding of what motivates us and others in conversation. 

Reflections from TestBash Brighton –Testing as a Team

Reflections from TestBash Brighton –Testing as a Team

During my time at TestBash Brighton possibly the most common subject to pop up was related to group testing activities.  Be that mobbing, bug bashes or whole team test days built into the process.  Maaike Brinkhof in her talk, ‘Exploratory Testing with the Team, a Journey Worth Taking’ explained how they undertook ‘Team Test Sessions’ before they released. 

This is the story of our first foray into testing as a team.

Reflections from TestBash Brighton - Testing is?

For my talk at TestBash Brighton Essentials (see ref below for slides and more) one of the things I covered was what I believe testing is. Over the last 6-months or so I have been mentoring a new tester on their journey and to start that journey, I had to explain what testing is.

There are a many, many attempts to explain testing and I even referenced one of my favourite descriptions in my presentation.

Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous.

James Bach

Over time, the more I looked at how different people went to great lengths to explain the craft, the techniques, the mind set and from other perspectives. I though, there must be a simpler way of beginning the conversation as it is my opinion that when trying to explain what ‘testing is…’ we do ourselves a disservice and answer instead, ‘what testers do…’ or a close variation.

My belief is when we do this, we confuse ourselves and others and we would really help our craft and each other if we simply said;

Testing is part of risk mitigation for the product or system.

Now I know that might sound overly simplistic when we are sometimes put in the position of defending our profession and craft. But, we should follow up with;

And we do that by…

This way, when we talk about critical thinking, observation, problem identification and solving; explain why automation helps but isn’t a solution in of itself; offer advice about bias, empathy and inclusion; offer opinions on observability and testability and ask unexpected questions from the, ‘but that would never happen’ category, there would be a clear concept that all these things help us identify and reduce risk for the product or system we are helping develop.

I would be really happy to hear others opinions on this way of thinking. Please let me know in the comments or follow up on Twitter @CricketRulz

Refs:

https://www.ministryoftesting.com/events/testbash-essentials-brighton-2019

https://www.slideshare.net/adystokes/test-all-the-things-with-the-periodic-table-140052297

Talk link to be added later, may be Pro or attendees only, to be confirmed

I See No Bugs / The Fresh Prince of Testing

In November I did a presentation at Leeds Tester Gathering with the slides available here;  (https://www.slideshare.net/adystokes/2017-11-leeds-tester-gathering-i-see-no-bugs) The talk was about how a test manager back in 2005 pitted testers and developers against each other but using the measure of bugs.  They were good for testers and bad for developers.  This lead to arguments about features, not in the requirements etc. etc.  Basically a rant about attitude, human communication and language that lead to me stop finding bugs and instead just describe behaviour.  For anyone who has seen my version of Rudyard Kipling’s famous poem ‘If’ written as if he were a tester you may already know I sometimes do strange things with others great work.  

For the gathering I was hoping to have a version of the Fresh Prince of Bel Air theme tune to close but I simply didn’t finish it in time.  So here in it’s glory is my version of the theme telling the tale of my belief that as an entity ‘bugs’ have no intrinsic value, are divisive and a hindrance to collaboration.  Controversial I know but that’s what I feel.  There’s a link at the end if you want to have a go singing it! 

The Fresh Prince of Testing

This is the story all about how
My life got flipped turned upside down
And I’d like to take a minute just sit right there
I’ll tell you why I don’t find bugs because there’s no value there

In West Yorkshire born and raised
Finding bugs was how I spent most of my days
Chilling out, maxing, relaxing all cool
Executing scripts as a general rule
When a test manager who was up to no good
Started making trouble in my neighbourhood
I was measured on bugs and the Devs were too
I could tell pretty quickly that we were all screwed

I whistled for a dev and when they came near
I told them about bugs but it was like they didn’t hear
I wish I could say arguments were rare
But they were like mansions in the town of Bel Air

I pulled my hair out in chunks and the Devs did too
All we did was argue and the quality blew
Then I said eureka about bugs I don’t care
I’ll just describe the behaviour that I see there

So the arguments stopped and the quality grew
The manager left coz he didn’t know what to do
Thanks for taking a minute and sitting right there
Now you know why I don’t find bugs
And why my boss doesn’t care. 


Instrumental if you want to sing along! 
https://www.youtube.com/watch?v=_sh2zSencBc

Fresh Prince of Bel Air theme song (short version from the TV opening)
https://www.youtube.com/watch?v=3qHA366oRMs