Build Quality In

Build Quality In

I’m excited to announce that Songkick‘s experience of moving to Continuous Deployment will be included in the forthcoming book “Build Quality In” edited by Steve Smith and Matthew Skelton.

The book, available on Leanpub aims to gather together experiences, lessons learnt, and the highs and lows of building quality in. I’ll be contributing my experience of moving to continuous deployment and in particular taking a look at the impact the change had on testing and quality at Songkick.

Step away from the book

Do you ever feel like you’re overwhelmed by all the things that you need to learn? Everyday you hear of a great new technique or receive a new book recommendation. What do you mean you haven’t read “Thinking Fast, Thinking Slow”? Next you’ll be saying you haven’t read Milton, or Proust.

Years ago most people were taught by rote. The system appeared to work well, certainly at least some people did come away with a broad bed of knowledge. More recently it seems that a shift has taken place. Some, but probably not enough, kids are learning for themselves. This approach isn’t entirely new, in 1907 the first Montessori school opened, allowing children to learn through play. More recently unschooling has gained popularity, allowing kids to have the space to think for themselves and guide their own learning. These kids are likely to be far better equipped for the world around them because they are curious and used to working out what the answer is, and why.

Now consider your own education. Why do you read all those books? Are you genuinely interested in what they have to say? Do they provide a particular answer that you have been seeking? Or are you reading them simply because you feel you should? If it’s the latter then step away from the book. Learn because you are genuinely curious and you will remember the lesson for far longer than if you plug away at a book just to be able to say you’ve read it.

James Bach does a great job of explaining how he learns in his book “The Secrets of a Buccaneer Scholar“. Actively seeking connections between your knowledge can be an effective way to build understanding, and seems to be a method that ties in with this article which explores the physical side of how we learn. Successful learners are people who find a passion and then chase it. Don’t allow yourself to be overwhelmed, or constrained by what other people are saying and doing.

Ask your own questions and seek your own answers.

Book Recommendations

On Friday I asked the Twitterverse to recommend books about process change. I was hoping to find 2-3 good titles which I could give away during my Agile Cambridge Tutorial. As always the great mix of people on Twitter didn’t disappoint. Here is the full list of recommendations:

Fish, and Fish! Sticks were recommended by Erik Brickarp

Understanding Organisations was recommended by Graham Bleach

Quality Software Management: Vol 4: Anticipating Change was recommended by Michael Bolton

Peopleware: Productive Projects and Teams was recommended by Helena Jeret-Mäe

Bob Marshall linked to his fascinating blog post on Homogeneous Mindsets.

Have you read any of the recommended books? Would you recommend any others?

It’s All in the Mindset

I recently started reading ‘Proust was a Neuroscientist’ by Jonah Lehrer, so far it has been an extremely interesting and thought provoking book, I’ll probably write a proper review once I finish it but in the meantime I wanted to explore one particular thought.

In the chapter where he writes about how Auguste Escoffier invented veal stock they come across an interesting phenomena. Your mindset determines what you taste. Serve identical wines in a cheap bottle and in an expensive bottle and nearly all tasters will think that the wine in the expensive bottle tastes better. The tasters are not lying. The brain expects the wine to taste better and so when the tastes are interpreted by the subjective brain they are judged to be better.

I started thinking about how mindset affects testing. We all know that developers tend not to make good testers because they expect the system to work. They either subconsciously don’t stress the system or in some cases become blind to the errors.  It seems that testers can be caught out in the same way. Everything from past experiences to your current happiness will affect what you see and how you judge something.

It’s normal to expect that experienced testers who have a wealth of previous bug discoveries will carry out the best testing. In fact I often find that totally new testers, with their entirely fresh mindset, can uncover some incredible bugs.

Perhaps the only way to deal with this is to embrace it. Structure your testing sessions so that you deliberately set your mindset. In the first session go in expecting everything to work. Embrace your user and confirm the main user actions can be performed. Later adopt a negative mindset and expect everything to be broken. Try to see things from the point of view of a blind person, or a colour blind person. How about if you’re in a rush and need to complete a task quickly? Each time you set your mindset to something different your brain will start seeing, and interrupting things differently.