There is no one perfect thing

In this talk from Malcolm Gladwell, he discusses some interesting points about choice and the search for the one perfect solution.

Again, I can't help but think about certification and how we are trying to find a one size fits all approach to learning.

When I watch this I also think about why we often have problems when we ask customers what they want. Do they really know what they want? Are these things they want easy to articulate? Maybe a collaborative specification workshop with examples is what we need?

It's an old talk but a valuable one.

[youtube http://www.youtube.com/watch?v=iIiAAhUeR6Y?wmode=transparent]

Good topic.

The Paradox of Choice

During my Agile Testing Days presentation I suggested that taking away lots of process and leaving the team players to make all decisions can be as restrictive to creativity as defining every little process, due to the fact the team will suffer “option paralysis”.

 

That is when the team has so many choices that they make none, or the one they do make makes them feel disatisfied and longing for making a different decision. The first time I encountered the idea was in the excellent book : The Paradox of Choice.

 

Here’s the author Barry Schwartz at Ted Talks.:

[youtube http://www.youtube.com/watch?v=VO6XEQIsCoM?wmode=transparent]

 

For testers we are often faced with a dizzying array of test combinations. Our products are often stuffed with countless features few people will use and our day to day lives are becoming confusing through a multiple choice of directions and things to do. Maybe it’s time to stepo back, break things down in to small chunks and tackle one thing at a time? Maybe.

Purdue Creativity Test – #agiletd

As part of my Agile Testing Days presentation I did a quick Purdue creativity test.

I asked each person in the audience to draw the person next to them. They had around 30 seconds to complete the picture.

At the end of the task I asked them to show the person they had drawn the picture and as expected there were lots of “I’m so sorry”, “my drawing ability isn’t great”, “I can’t draw”.

The point of exercises like this are to show how we self edit ourselves and apologise for our creative ideas and output.

And so it’s crucial to ensure we have environments that encourage people to feel safe and relaxed about sharing creative ideas and output. Sometimes these parts of the idea they “self edit” that never get aired are the best solutions, the best ideas, the best output – we may never know. It’s important we get these self edited parts out in the open by providing safe and trusted environment.

I collected some of the drawings from the very talented audience and here they are…in all their glory.

I’d suggest you try exercises like this within your teams. They can be a powerful way of seeing how relaxed and trusting your environments are. They are also a good laugh 🙂

Enjoy.

Less is more

As a keen writer and communications fan I spend a lot of time looking at how I (or we) can improve our communication and one of the best techniques is to remove the bits of communication that people skip.

In the world of writing this means removing the sentences, words or entire chapters that you *think* or *know* people will skip. With my own writing this is a very subjective process. I don't know which bits to remove but I do know I self edit my work quite heavily.

It's like using twitter. It's amazing how you can still get your point across in a few characters. It's a good practice to get in to. Brevity of writing is a good thing.

Much of my writing gets drastically chopped down but no doubt there are still huge amounts of it that are what I call "fluff".

And it's important to realise that this idea of fine tuning can be incredibly valuable in our testing world too.

Let's take a test case. One of the typical ones with plenty of steps and lots of detail. This is not uncommon, there are loads of teams still using highly scripted tests. In fact, I'd go so far as to say it's the "norm"

There are several audiences for these test cases and if you are dishing these out to people simply ticking the boxes then the more detail the better. The fact that this approach is insane, wasteful and insulting to these testers is something best left to another blog post.

But give your scripted tests to a software tester and observe. Ask them for feedback too on the overall effectiveness of the test case. Here is what I believe you will find:

  • They will not follow the test case step by step
  • They will read the whole test case in advance to get the gist of it, to formulate an idea about the intentions of the test case
  • They will often make extra notes or areas to concentrate/focus on
  • They will often re-read this test case a few times to truly understand the intentions or expectations and to double check any missing prerequisites or knowledge
  • They will draw on all of their domain knowledge and experience
  • They will perform the testing but not as a step by step process. Instead they will tend to complete the whole test and revisit the test case to tick all of the boxes after, just to check they got everything asked for in the right way.
  • They will probably explore or diverge slightly from the test, but no so far that they don't fulfill the intentions
  • They will mark the test case with edits, suggestions, ideas and improvements.
  • They will probably suggest several new test ideas too
  • They will note down observations which in turn often get fedback to the test case
  • But most importantly they will not be guided by a step by step process

These are just my own observations but I encourage you to study your own work and that of your colleagues. I suspect you will see the same thing.

And here's the point. Don't include the unneccessary, the verbose, the irrelevant, the obvious, the waste or the *skipped* detail. In ommiting this "fluff" you will probably end up with what I call "Guidance Level Tests" (it's an old post on my old blog but the sentiment remains the same).

If testers are skipping sentences, ideas or sections because they are not needed or irrelevant or verbose – get rid of them. In the end you'll end up with a checklist to guide, not a document to steer. And this moves the thinking to the tester running the test. And this is a powerful thing.

Alternative Paths for Self-Education in Software Testing > Markus Gärtner #agiletd

P1050311-1000

I can't believe I managed to beat Markus Gartner with a blog post from the wonderful Agile Testing Days conference here in Berlin. Oh wait a minute, that's because he's talking….and here's my blog post of his talk Alternative Paths for Self-Education in Software Testing.

Who Is In Charge of your learning?

Markus introduced his topic and asked the question

Who is in charge of your career?

Your boss, your employer, your family, your school teachers….nope…..you. Yes, just you.

Markus then made a very pertinent point "If you find yourself unemployed in a years time, things you do now will all be contributing to you being employed quickly again."

Markus suggested you could start by:

Creating blog or personal journal
Sign up to a community like the Software Testing Club, Weekend Testing, Coding Dojos
Markus also suggested that testers should start to learn how to program in languages like Ruby or Python or Groovy.

Markus explained that the brain has two sides: The Left and right sided brain.
Left – Hypothesis (books, Rapid Software Testing, Black Box software testing, Bucaanner Scholer)
Right – Synthesis (Black box software testing, Testing Dojos, Challenges, Weekend Testers, Miagi-Do School)

Markus then suggested some Books to read
Cem Kaner – Testing Computer Software
Lee Copeland – A Practitioners Guide To Software Test Design
Cem Kaner, James Bacj, Brett Pettichord – Lessons Learned in Software Testing

Markus then suggested the Rapid Software Testing course by Michael Bolton. "4th day free" Michael added in 🙂

Markus also explained that there is a wealth of excellent material on the AST website. Most of the content for The Black Box Testing is provided content by Cem Kaner and James Bach. Markus suggested this is an excellent selection of courses and there are about 60 videos to learn from as well as slides and other information. There were a wealth of topics introduced as being available in the AST course material including Bug Advocacy and various Testing Techniques.

Markus then introduced The Buccanner Scholar and suggested that there are lots of learning heuristics contained within the book. It's the story of James Bach and his approach to learning. Markus introduced some heuristics like 'SACKED SCOWS', 'Long Leashed Heuristics', 'Obsess and Forget' and 'Procrastinate and Push'

Testing Challenges – challenges to and by the Testing Community are very valuable ways of learning more about your craft.

Testing Dojos – Collaboration, Safe Environment, Deliberate Practice. Normally a mission with a challenge which allows the testers to practice their testing and learning. There can sometimes be observers or facilitators. Sometimes it is done using pair testing.

Weekend Testing – A few hours at the weekend where there is a charter or mission and the group work towards how to test it. It's a great opportunity to learn about the assumptions we make and the traps we can fall in to.

Miagi-Do School of Software Testing – A school founded my Matt Heusser. It's a non-commercial, zero profit school of learning where people can improve skills, learn from others and share knowledge. There is a belt system where people move through the belt ranks, like a martial arts.

Markus concluded that no-one is in charge of your testing other than you.

There are different styles, Feedback, Hypothesis and Synthesis.

Stuart Reid > KeyNote > Agile Testing Days – More video snippets #agiletd

Some more videos of Stuart Reid’s Keynote at Agile Testing Days. The most anticipated talk of the day…controversial talk, but not enough time left for questions……

Not sure about the sound quality (as not had chance to listen back yet), let me know if it’s really bad.

Not the whole talk, but snippets of stuff. Some interesting statements.

 

P1050300.mp4
Watch on Posterous

P1050305.mp4
Watch on Posterous

P1050308.mp4
Watch on Posterous

 

Lost in translation – a lesson learned at a hot dog stand – #agiletd

Image from : http://www.flickr.com/photos/bunchofpants/2946843497/sizes/z/in/photostream/

It seems there is inspiration for learning all around us. I’ve just got back to my room after a walk around the local area here at Agile Testing Days in Berlin. The location is excellent, despite being a distance from the airport, and the local area is just lovely. Lots of fabulous buildings and shops and tree lined streets. I’d left my memory card back in the laptop otherwise I’d have included some photos.

I’m one of these tourists that loves to sample the local food. I don’t see the point in being abroad and eating English food. It’s not like we’re known for our culinary delights anyway. So I decided to stop off at a wiener stand by the side of the road.

What followed can only be described as a “Lost in Translation” moment.

Me: Hallo

Vendor : Hallo. (Something else which I suspect was “what can I get you”, but cannot be sure as my German is very very bad)

Me: I’d like what the locals eat please.

Vendor: Ok.

He then proceeded to create the most creative looking “hot-dog” I’ve ever seen. His face told a thousand horrors as he randomly put bits of various stuff from the fridge in a tiny bread roll. He looked like a scientist trying different flavour combinations, each one accompanied by a frown and a suggestion that this might not taste so good.

With a look of sheer panic he placed the largest weiner I’ve ever seen in the tiny roll. Then added Ketchup and Mustard. Some more stuff from the fridge. He rolled his eyes, raised his eye brows and gave off more non-verbal clues that he really wasn’t sure about this thing.

 

It seems my request for something authentic and local had been Lost in Translation and since my German was so embarassingly bad neither of us had really got a good deal out of this.

He leaned over the counter and said:

“hmmm. I guess this is a German Hotdog” His eyes told a chilling truth though. Here was a man who’d created something he’d no doubtedly have nightmares about. I could see in his eyes that he was gutted. I too was apprehensive of this “German hot-dog”.

 

As it happens it was delicious but I suspect, not very authentic. The locals in the cafe were all incredibly amused by my lunch too. I think one or two took pity on me as they offered me kitchen roll and laughed heartily with (at?) me. They’d seen this epic failure on my behalf to communicate my requirements clearly and seen the resulting meal. I’d done everything I preach against doing. I’d failed to communicate my intentions clearly.

If only I had have brought a German Phrase book with me things could have been very different.

 

And so I learned a valuable lesson here today. Even with the best intentions in the world, communication breakdown is a reality and both parties can be dissatisfied with the final product. I should have learned some German for my trip or at least given the vendor something more substantial to go on.

 

This happens in the work place too, even when there is a common cultural language in use. Ideas and concepts get lost in a fog of misunderstanding and assumptions.

 

I think next time I venture out to taste the local cuisine I shall take a phrase book with me and try to clearly articulate my intentions in more detail. I can still see the vendors face now (who I learned was called Alios….I think). But I also tried to let him know how delicious it was, because it truly was amazing. And despite the fact his non-verbal communication suggested otherwise, I can’t help wonder whether he’ll add it to his menu as “The German Hotdog”.