Why Do We Test?

I’ve posted a short post about this on my LinkedIn, but why not write about it a bit more here. Why do we test? I think there can be a lot of reasons, I’ll list a few.

To find out where we are

First what comes to mind is that when testing, we want to find out where we are. Different people have different mental models of the product, of what it does or doesn’t do, how it does it, etc. Testing is then performed to find out more about how the reality looks like.

Because we don’t like surprises

A poorly tested product increases the chances that there’ll be surprises, usually not positive ones, later on. I think it’s far better to be surprised when there’s still time to change things, than putting ourselves under pressure when a customer finds a bug in production.

Because we don’t want our customers to do our job

Customers can obviously help with some testing, for example during beta testing. That can be useful. I’d, however, not rely on this as the primary means of getting feedback about the product. People are not that good at sharing feedback, hunting for problems in a product, or reporting those problems. All these reasons decrease the chances that we’ll even get the feedback.

It is a responsible thing to do

Perhaps not a reason for everyone, but I personally like to do things because I feel it’s the right thing to do. Testing software seems like the right thing to do.

There might be more reasons, no doubt about that. Perhaps I’m not aware of something right now. In that case, I’ll update my article later.

Before wrapping up, let’s see some reasons why we don’t test.

To break the product

I actually get a tiny bit offended when someone suggest I like breaking software. No. I’m actually not that evil. I like when our products work and are highly desired by our customers. I get a product, I test it, and I share what I’ve found. Nowhere in this is anything about me changing the product in order to break it.

To increase quality

I guess this will be controversial to many (it was on LinkedIn in the past :)). First of all, quality is a complex thing, it’s likely something else to different people at different times. I think the best assessment of quality is having meaningful conversations and feedback loops with our customers. Anyway, I also say that testing itself doesn’t increase quality. Because testing doesn’t change the product. Development does. We test to find where we stand, then if we are not happy with that, we do more development to change things for the better.

Some might say this is a play of words. Perhaps. But if you want me to increase quality, then I need to be a developer as well. And likely even someone who decides what the team will be doing, which is usually someone who holds the budget.

To ensure or assure quality

Another controversial one :) Again, there’s the problem with quality in the first place. Then I don’t think that ensuring something in a complex environment with a complex product is possible. That would mean to try every scenario, change every variable (not in the programming sense), test with every possible customer, etc. That is not feasible. I like to say something along the lines: “I can’t find more (meaningful) problems now” instead. That speaks about myself so I can take responsibility for this, but I certainly cannot take responsibility for ensuring quality.

Having said that, QA does not stand for Quality Assurance in my understanding. More like Quality Assistance, or Quality Assessment. The problem is that Quality Assurance is so commonly used that almost no one uses those other terms.

That’s it for today. This is my understanding of testing how I see it now. It might be interesting to revisit this article one day; predicting future is difficult, so who knows if I perhaps change my mind later.