Are you an Independent Tester?

March, the time of TestBash Brighton. As always it was a pleasure to return to Brighton and catch up with some of the smartest, friendliest, and most inspirational testers.

The final talk of the day was from Nicola Owen. Her story was about moving from being a tester in a large organisation to being the only tester in a company. She talked of the challenges and benefits that came from being a sole tester.

Nicola’s talk made me ponder the role of a tester. Often we struggle to gain recognition in teams and companies. Testers are frequently the ones who get forgotten about when teams are thanked, or team lunches are organised. Is that really because we’re so forgettable? Does the sheer number of developers make testers invisible?

I believe that testers can, and should, be seen as a beacon of expertise throughout the company. Testers have so much knowledge about the product, the users, and the project risks. Every tester should know exactly when the project deadline is, who the customer is, and what the project goals are. Hopefully they also know the technology stack being used, the experience-level of the developers, and have a deep understanding of every step of the development and release process.

Knowledge is power. Testers don’t have to be technical. The ability to write code doesn’t have to be a measure of how good a tester you are. If you work with good developers then it probably doesn’t matter if you know how to configure a web server, or submit a binary to Google. What does matter is being able to initiate, and contribute to important conversations.

Talking about a problem out loud triggers your brain to think about things in a different way. For this reason many developers use the “Rubber duck debugging” technique to find issues in their code. Talking things through, even with just a rubber duck, can make you realise that you’re missing something, or spot an obvious problem in the design. If a rubber duck can bring this much value to a developer just imagine what a creative, and knowledgeable tester can bring to the conversation.

Whether you work in a small team or a large team you should take responsibility for your own role. A bigger team doesn’t mean you get to take less responsibility.

Behave as you would if you were the only tester around. Ask questions, and make notes, connect the information people give you and turn it into knowledge. If you come across a casual group conversation then get involved. Kitchens are a great place to spend time. Tell people your ideas and ask for their input. Not only will you learn some interesting, and possibly useful things, but you’ll also meet some new people. Don’t under-estimate the power of being well-connected within a company.

Your own experience is worth more than a thousand books. Reflect, search, and understand how your actions impact the team. At the same time read widely, watch talks, and engage with people outside of your organisation. Compare your experiences with others. What can you learn?

Always have an opinion about everything – even if you don’t always share it. Learning to question things, to spot the areas that could have been better will help you become better. Do this with your own work and with others’. When you read an article, or a book, question what it is telling you. How does your own experience differ?

Independent testers are resilient and self-supporting. They have the knowledge and skills to be able to excel as a sole tester in a company but they also have the knowledge and skills to make a larger test team a powerhouse. So don’t look around you and use your team size as a measure of how good a tester you need to be. Look around you and see the opportunities that are open to you. Now grab them.

The TestBash videos are now available over at The Dojo.

Thoughts from TestBash 2015

I’ve just returned from the fourth TestBash conference. Each year it grows, getting better and better every time. A packed out conference (10 speakers!) and many social events make it easy to catch up with old friends, and make new ones too.

I kicked things off with the social event on Thursday evening. Sadly I hadn’t been able to attend the workshops during the day but there were plenty of people singing their praises over drinks. I had a whirlwind of catching up, beers, and a little bit of 99secondtalk prep with my fellow Weekend Tester facilitators Neil Studd and Dan Billing.

After just a few hours sleep, something of a tradition at testing conferences, it was run time! Once again there was a fantastic pre-conference run along the seafront. I love starting the day with a run, this year was an especially beautiful morning and we had a good turnout despite the early start. One of my favourite parts of the run is having 10 minutes or so to just chat with fellow testers completely uninterrupted. We run and we chat. Then we all dash off to try and get ready in time for Leancoffeebacon.

The conference itself had a fantastic line-up. Michael Bolton gave a predictably solid talk on language. A great reminder to actually say what you mean. Ian McCowatt was up next with a great talk on Bug Detection. He gave me the push I needed to pick up Harry Collin’s “Tacit and Explicit” book. I was also reminded of the importance of re-reading books. It’s so easy to get caught up in the endless of book list that sometimes I forget how much you can get from a book on the second, or even third reading.

There were great talks from Martin Hynie, Matt Heusser, and Stephen Janaway. There is still plenty of digesting of the ideas but it was fascinating to hear Martin’s experiences of the job title ‘Tester” actually limiting tester’s ability to get involved in projects. Stephen Janaway had some really interesting ideas in his talk “Why I Lost My Job As a Test Manager and What I Learnt As a Result”, the coaching menu was particularly interesting to me. I can see something like that being very useful on my team.

Vern Richards, and Richard Bradshaw both gave thought-provoking talks. Richard’s story of moving into automation only to find that he had “automated too many things” was really good. So many teams have the goal to automate everything. it was interesting to hear what happens if you actually succeed in doing so.

Sally Goble and Jon Hare-Winton demonstrated that it is possible to do a good double act. Maaret’s talk ” Quality doesn’t belong with the tester!” was a really resonating experience report. Being the only tester on a team is challenging and Maaret shared lots of ways that she tackled it. I really liked that she had talked to her team of developers about how they wanted to define testing. So often it seems testers want to name everything and tell developers how it should be done but developers do testing too, it’s just different.

Karen Johnson wrapped up the day (well apart form the 99second talks!) with a really engaging talk on asking questions. There were so many great ideas in this talk, and a number of interesting book references too.

All in all I have watched so many brilliant talks from engaging, interesting people. I have a list of new books to read and lots of thinking to do. I’ve come away from TestBash having seen so many friends. I’ve got a list of names of my new friends in my pocket and I feel inspired to get stuck in to some testing!

Thanks, Rosie and all of the TestBash speakers and organisers. It was an absolute blast. See you next year!

DevOps with Testers

Last week I spoke at QCon London about Songkick’s experience of moving to Continuous Delivery. You can download the slides, or watch the longer version of this talk on the LondonCD Meetup’s Vimeo channel.

My talk was part of the DevOps and Continuous Delivery track hosted by Eoin Woods. QCon videos of all the talks should be available soon.

One particularly interesting talk was by Steve Thair on ‘DevOps and the need for speed‘. Previously I thought DevOps was about developers and Ops people collaborating to enable faster software delivery. Steve’s definition went much further and ended up being closer to how I think about Continuous Delivery.

Steve defined DevOps as a model that “encompasses a product-centric view across the entire product life-cycle (from inception to retirement) and recognises the value in close collaboration, experimentation and rapid feedback.” He emphasised that the business and testers should be engaging in the collaboration just as much as developers and ops people.

An interesting distinction between Steve’s DevOps definition and Dave Farley’s Continuous Delivery definition focused on the definition of ‘Done’. Continuous Delivery is defined as being about “making businesses more experimental through the early and continuous release of valuable software”. It appears to be complete once the release is out in production. DevOps adds an important final step of evaluating how much value the release is actually adding once it’s in the hands of users.

I love Steve’s definition of DevOps but unfortunately think this term is sadly restricting. I doubt business people or testers will feel included in something called ‘DevOps’. Even more confusingly I believe there are both devs and ops people who do believe ‘DevOps’ only covers devs and ops.

Even re-defining Continuous Delivery to extend beyond the release doesn’t really help the situation. We’re trying to create a process that keeps the software in a state where by it can be released whenever the business wants it to be. Obviously there are some questions around why the business would suddenly decide to release with little notice and whether we should support that or not. Leaving this aside I think Continuous Delivery is a positive way of working to remove unexpected delays to releases.Any process that encourages collaboration and stress-free releases should be given strong consideration in my book.

A name is always just a name but in the case of improving processes and making sure all roles are covered I think it becomes pretty important. We need to hear everyone’s voice as we attempt to fix software development.The concepts being discussed are important and will affect us all. I personally feel that neither the ‘DevOps’ or ‘Continuous Delivery’ terms are quite right for describing an attempt to engage with all stakeholders and release timely, and functioning software to end-users. Regardless of this I believe everyone involved in software design, development and releases should be involved in deciding the best way to fix the software industry.

What do you think? Are you a Continuous Delivery or DevOps fan?

Let’s Test 2014 – Reflections

This time last year I had just spent a painful week watching the Let’s Test attendees tweet their way through a seemingly amazing week. I decided that I would make sure I didn’t miss out this year.

Now having returned home and taking a few days to catch up on sleep and digest the many many conversations I can honestly say that buying a ticket to Let’s Test was one of my better decisions in life.

As James Bach said before the event this is a conferring conference. The talks and workshops were interesting and useful but definitely less polished that at typical conferences. Everybody seemed to be attending the event to meet people and share ideas rather than because there was a particular talk that drew them there.

The conversations that took place during the conference were invaluable. I’m going to be digesting all the brilliant ideas and suggestions for some time. Expect blog posts on more specific topics to appear over the coming months.

For now I thank Henrik, Johan, and Ola for creating such a fantastic experience and thank all the people who I shared this great conference with.

I’ll leave you with a few photos.

Tim Lister opens the conference with his Keynote

The Sketchnoting workshop gets serious with Ilari and beer.

Just a regular start to Tuesday.


Michael protects a (covered) bowl of bacon from some hungry testers.

Learning skills that have no real application in life.