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.


Acceptable Weaknesses

Everybody has strengths and weaknesses. You are likely to be working in a job that suits your strengths, however that doesn’t mean you won’t be required to test something that seriously challenges your weaknesses. Weaknesses tend to fall into the acceptable and the unacceptable categories. Categories that subtly change depending on your company. Maybe when you’re with friends it’s unacceptable not to be able to name all the Number 1 hits from the music charts in the 90s. A skill that is unlikely to matter at work.

Unacceptable weaknesses are more of a challenge. People take it as a given that you can spot a bug in spelling or grammar but very few job interviews test for this.  

I once tested a Polish language system. I don’t speak a word of Polish but this was an acceptable weakness. The testing role I was performing didn’t require me to actually read Polish, I was a functional tester in a team which also had a native Polish speaker to test the copy. Don’t be mistaken into thinking that my testing didn’t involve checking any of the system text. I couldn’t read the text but by deliberately ignoring it, thinking that it wasn’t my job, I would have perhaps missed several places where English had been mistakenly used instead of Polish. Maybe I would have even missed the screen layout problems caused by words being longer, or breaking in different places, to English.

The same system required me to test a financial product through its complete life-cycle. My background is not in financial services and so I hit upon an unacceptable weakness. Only by reading up on the financial product, and by talking to experts in the company could I gain enough understanding to be confident in testing the system. My lack of knowledge required that far more time and effort was expended to make sure all test plans were accurate. Exploratory testing was useful for trying to break the system but I was lacking the knowledge to allow me to test the system functionality without a scripted test plan.

Not all weaknesses are as obvious as this one. Consider for a moment how competent you believe you are in usability testing of websites. Most people consider themselves to have a reasonably good understanding of what makes a website easy and enjoyable to use. However there is a fascinating cognitive bias called The Dunning-Kruger Effect which states that incompetent people overestimate their abilities whereas competent people underestimate theirs. The great challenge is correctly identifying which side you stand on. It seems plausible that someone who hasn’t studied the complexities of usability will consider the problem to be far simpler than a UX expert who knows the subject in-depth.

The Dunning-Kruger Effect makes identifying weaknesses problematic. It is likely that if you are truly weak at an area then you will overestimate your abilities. You’ll be testing using knowledge that you don’t have. On the flip side you might be more competent that you realise but the Dunning-Kruger Effect will have you underestimating you abilities and probably conceding to ‘experts’ when in fact you should be challenging their opinions.

Either way you’re likely to be testing with an incomplete set of information.

So what can you do? The easy answer is to be aware. Question your assumptions and those of people around you. Always ask questions no matter how certain you are of the answer.

The hard answer is to address those (perceived) weaknesses. Get some training, read some books, do whatever it takes to learn enough about the subject to allow you to question subject experts, and ultimately software, with confidence.