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.


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.