Software Testers Don’t Break Code – or Do They

(Update: As the blog text came at 6 AM, it seems only appropriate to wake up at 4:30 AM to update the post. I fixed some inconsistencies, rewrote phrases and clarified my own point of view in the subject.)

***
Short description around the discussion before I go to rephrase what I wrote earlier. This all started from a semi-joke from my side to Erik Davis. I thought it's funny to say I am a tester who sometimes break code. I had the intention behind that I also write code sometimes. As the discussion didn't stop there, I thought first to write how to defend "testers break code" but while writing it all collapsed in my mind. This is why the original post was really confusing and my replies to the comments about it. I tried to keep the body of the original post here so there still can be apparent mistakes. I'd be glad to hear about those.
***

I have discussed about this topic a few times, but I never gave it much of a thought. I did think different aspects on a slightly superficial level, however, as I didn't write about those sides, I decided finally today at 6 AM it's time to update my blog. This won't be an exhaustive research on the subject, but it's intended to show how I think about the topic (and how I see discussion around it) currently. My thinking will change the more I dig into this.

When I talk about testers in this case, I talk about people who mainly do software testing. I don't include for example programmers and managers in the definition of a software tester, even if they would do testing. I can include them in the definition if testing is what they get paid for and they are continuously trying to improve their skills as a software tester. But I think in this case their title should be a tester or so.

Next logical step would be to think what is breaking. For looking into different meanings of that word, I used The Free Dictionary by Farlex. I won't go copy/pasting the text here, please just take a glance and see how many ways there are to use that word. I take a few snippets that I think apply nicely for software world:

1. To force or make a way through; puncture or penetrate => break into software /  crack it
2. To find an opening or flaw in => bug
3. To render useless or inoperative => pretty major bug
4. Go down, crash => software breaks during a test / over a period of time

In this respect, it does indeed /seem/ like testers would break software. This sounds counter-intuitive? Yes, definitely I have the same thought. (As I didn't find any better translations, I leave it here from the dictionary point of view. In my opinion, breaking would imply making the code unusable/working wrong.) But on the other hand, as these are used as arguments by some people, let's look into what they say: "If we have software running and by our actions it becomes useless, who actually broke it? Sure, the code was not resistant to *all* possible use cases, but please, show me an application that is."

There are many levels of breaking, one could argue to us. "There is the misuse, happy flow and how ever people want to call ways to use an application." This doesn't really add content to the topic. The definition of breaking is not subject to different ways to use an application. In my opinion, we can’t have in a long time, if ever, applications that handle every possible scenario without “bugs”. However, when we find those, we don't break the code, we find ways to expose threats to the value of the application.

There are two other points of view I still want to write about. I used some definitions of breaking above, but what if we say "testers receive the code broken"? Now this changes the discussion closer to existentialism, where many thorough deductions seem to end. The argument we would hear could be: "Let's say we have a light bulb, drop it on the floor and it shatters to pieces. Did we receive the light already broken or who/what broke it? One could say we broke it, one blames the manufacturing company, someone the engineers or faulty machinery. And there are always those who said the ground brake it with a devilish co-operation with gravity. Damn you Newton - why you just didn't eat your apples!"

In reality, software is not like a physical object that breaks by dropping it on the ground. Software breaks because there are problems with the code - and sometimes it seems to break because of problems in the infrastructure. If you hear analogies with breaking physical objects, changes are the discussion needs to change focus from "what is breaking" into "what is software" before the first question can be answered.

The second point is about how we actually use these words. I hear this really often and sometimes fall into it myself. Language is not static; it's constantly evolving to many directions. It's different if we write or say aloud the words. It's a lot different if we shout or whisper. For these reasons I don't consider it always that important what words people use if we know what they mean. (And obviously, we need to ask them about this if we are not "sure"; and even then in some cases.) But this is not the case with people such as scientists and engineers; they need to be accurate with their wordings. Beware of arguments that back up on interpretations!

I want to note here I prefer saying “I like to find ways how the application/system seems to reveal a threat to the value of the product” (shorter version: I like to see stuff break) or something in those lines. In other words, I prefer telling I want to /find/ something that I /believe/ is a threat to /some/ value. (As value is a relationship, I understand my “important” findings are not valuable to all stakeholders.) I don't like talking about breaking code or code being broken. However, I like breaking *things*.