Ignorance is bliss?

A lot of people seem to believe that you have to know a lot about something before you can test it. This is something that also fuels the idea that someone who knows a system well will be able to test it, even if they don't know the first thing about testing.

I don't believe that this is the case, and certainly in my current role I think there is real value in having someone who knows nothing about the product contribute to the test effort. Here are a couple of reasons why...

Value your confusion

Assuming that you are of around average intelligence (many testers I know are significantly above average in this department), it is a reasonable inference to suggest that if you experience confusion whilst using a piece of software, that some eventual end-users of the software will experience similar difficulties.

So instead of becoming frustrated because you don't understand what the software is or should be doing, you should congratulate yourself. You have identified potential within the software for end users to become confused. And odds are, if end users are confused they will use the software incorrectly and it will not do the job that they want it to do.

It's very easy in testing to become wrapped up in the system itself, and the way it functions. We must remember though, that software is always a means to an end. It is about people and what people want it to do. While having a thorough understanding of the purpose and design of a piece of software can be extremely useful in finding a certain brand of bug, it can also bias our observations.

The user will likely not have such a thorough understanding. They will not necessarily understand the logic that is driving the system behind the scenes. Ultimately, they will be very much outcome focused, and if the system doesn't easily allow them to achieve that outcome then it could be considered a failure.

As such, if you as a tester have a vast amount of knowledge about the system that the user won't have, then you are unable to evaluate the way that the system functions from their point of view. This gives us access to a different type of information about the product, which may be just as useful as that which is informed by a depth of knowledge.

This can be particularly evident when assessing the usability of a piece of software. In the past I was test lead on a project where the interface of the application was particularly difficult. I had been using it for some time so it's quirks had become familiar to me, but when initiating new team members I always enjoyed their insights and reactions and was careful to pay attention to what troubled them about it, and the impacts that this had on what they were doing.

So next time you're testing and feel a bit stuck using the software, don't get down on yourself. Embrace the confusion and respect what it is telling you.

Hunt for knowledge

This is going to sound exceedingly obvious, but another benefit that comes from a certain level of ignorance about your system or the domain it exists in is that you know and accept that you don't know much about it.

This can be incredibly useful because often I think we are all guilty of assuming too much knowledge or expertise in certain areas, or at least not significantly questioning the knowledge that we think we have.

It's easy to settle into a certain comfort zone when you start to feel like you understand something, and that prevents you from then exploring further and perhaps uncovering new and more useful information.

As such, it's important to remember the methods by which we established out initial set of knowledge. Generally, knowledge is accumulated piecemeal from a wide variety of sources. When you are new to a project and you are aware that you know nothing, you hunt for it vociferously - you have to, else you remain ostensibly useless.

As such, you go searching for specific bits of information - the bits you have decided you need in order to make immediate progress. But in the search you uncover a whole wealth of other information. Whether you read a whole document to get to one tidbit, whether you overhear people talking while you're chatting to someone else, or whether the designer you're talking with is incapable of answering just the question you asked, this knowledge is invaluable.

It starts to build a wider picture of the environment you have found yourself in. It contextualises the other pieces of knowledge you already have. Much of it is picked up subconsciously, or at least, you don't understand it until you pick up another piece of information later which suddenly throws light upon its significance.

This happens because you are drastically aware of your lack of knowledge. But once you start to feel a bit more secure in your surroundings, it's easy to tone down the hunt a bit. You're comfortable in your surroundings. The pressure to learn isn't so great. The learning curve pleateaus.

But this discounts the fact that any environment is always changing. That your knowledge might be becoming outdated. Of course, it's impossible and inefficient to maintain the hunt for knowledge at that initial intensity forever. But that doesn't mean you shouldn't remain alert for signs of ignorance.

The moment you recognise that you don't know something, the hunt should start again. It is likely a indicator that something has changed, or that you didn't find something out previously. And again, ignorance in this sense is not a negative - it is impossible to know everything. Instead, ignorance should be welcomed, as it indicates the potential for further learning.

So don't panic if you know nothing...

Truly good testers will never be held back by a lack of domain or system specific knowledge. A lack of this knowledge will only hold you back from identifying some kinds of bugs, and ultimately if you understand your learning processes you'll find them soon enough anyway.

But while we are doing this learning, we should pay attention to our ignorance. It shouldn't be something that we are ashamed of. Instead, be proud of your confusion. Embrace your ignorance and use it to access a different set of information about the product you are working with.

A tester who knows his trade well can come in and immediately start providing their client with valuable information about their product. They do this because they recognise that being a tester is all about information - and information about unknowns can be just as powerful as information about knowns.

Which is precisely why I defy anyone who believes that domain knowledge or experience qualifies someone to be a tester. That is not so. It qualifies a person to evaluate certain facets of a system, but it does not enable them to recognise how their biases impact their evaluation or to identify different sets of information.

So, is ignorance bliss? Not at all. Testing is all about learning. But that shouldn't mean we don't appreciate the value of the journey and what we might find along the way.