Why Do We Test?

There have been a lot of recent talks and articles regarding the whole “Is Test/Testing Dead?”  Jon Bach gave a great keynote at STPCon in New Orleans last week regarding this.  “Testing isn’t dead,” he said, “but Bad Testing should probably die.”  Overall, testing as a practice, as a skill, seems to be on the decline as the actual activity is being done by just about anybody. 

But can just anybody test?

It depends.

I fall back on that response a lot, sorry, but it’s useful.  In this case, it depends on what you’re testing. 

A better question is can anybody test software?

No.  I personally don’t think so.  It takes someone with a good analytical mindset, technical knowledge, and an innate drive to find things out to be a really good software tester.  Again, that’s just my personal opinion based on my 15 years of software testing and working with a wide range of testers, developers, support engineers, and technologists.  Overall, I think some testers lose sight of the basic question, which I’ve conveniently put in the title of the post.

Why Do We Test?

A good interview question I’ve used in the past (along with my famous “How do you know when you’re done testing?”) I’ve heard many answers in response.

“To see if the software works”

This is a completely valid, logical response; also, the one that I hear the most.  Essentially, yes, we are confirming that the software works.  But isn’t there more to it?

“To prove the developers wrong”

I chuckled at this one especially because I’ve heard it on more than one occasion.  I’m not a fan of the adversarial tester versus developer mentality.  I try to squash it whenever I come across it in fact.  I like to think that we all have the common goal of delivering quality software to the client and should behave as such.

“Because it’s my job”

This one was an actual response from an interview I gave.  I had to quickly check to see if the candidate was in fact a two dimensional cardboard cutout.  If you’re just testing because you were told too, how well are you going to do your job? How inventive will you be in your testing? Going through the motions of testing is not time well spent at all.      

Ultimately, we test to learn something about the software that we don’t already know the answer to; to confirm or disprove something about the software that we think or had heard about. 

We test to learn.

The point of each and every test that we run on software should be to learn something about it.  Not just if it works, but how it works.  What happens when we expose the software to specific conditions?  How many users at one time will break it? Slow it down? Can I bypass the password protection? Will it run on my Mac just like it runs on Windows? Does the website look better on Internet Explorer than Google Chrome? Perform better on FireFox?

Endless amounts of questions can be answered by our testing.  And with each test, we learn something more about the software.  Sometimes, we learn things we weren’t even looking or testing for but we take the knowledge the test delivers to us and use it to create more tests.

At least we should be

Is Testing Dead? Are we doing our part to kill bad testing?

Ask yourself, for each test that you run, what have I learned from this test?  Did I learn anything new about the software?  Is this test telling me something that no other test is telling me?

If you have a suite of tests that tell you nothing about the software, ask yourself, Why am I running this test if I learn nothing about the software when I run it?

If you have questions about the software and you have no tests that give you the answers you’re looking for, ask yourself;

Why haven’t I written those tests yet?