You didn’t upset me! That’s just the way I talk! I was, am, talking and thinking out loud. However, I will try to think/write clearly now…

Firstly, I was not attacking you for describing yourself as a tester. The way I entered this discussion was similar to how one might float into a discussion round a coffee machine. So please don’t see this as an attack. That was not my intention.

Secondly, I have nothing against labeling. What I was kicking back against was reactive thinking and false oppositions. I like to challenge what people say because I want to get to the heart of the matter. I work really hard to bring people out of their roles. Roles and responsibilities can hinder a development effort because it gives a hiding place to people who don’t care or who are to afraid to step out of their comfort zone.

Thirdly, I never said one couldn’t describe themselves in relation to another or describe another person. I said I didn’t like it when one used a reference to me as a way to define themselves. Maybe an example can help.

If you and I were pitching for some work, you might say “I have worked in all kinds of areas of software development but I focus mainly on testing, my colleague here has done the same but he tends to focus on quality assurance�. This is a definition, based on each other, and some what grounded in reality.

However, if you were to say “Jamie is a developer and doesn’t like to break things, but only build them, therefore, we make a good team because I will make sure his stuff isn’t rubbish�. This is a definition based on assumptions I think are false. Assumptions such as developers don’t break things. This second description feels more like my role as a developer being mis-represented to satisfy the tester’s definition of what testers and developers do.

This is why I kick back against “tester vs. developer� discussions.

In summary, are labels bad? No, not really, we live in a semi-solid world were practical things like roles and names help keep things moving. Can you, or anyone, describe themselves in terms of another? Yes, you can do what you like! Would it bother me? No, it wouldn’t as long we don’t mis-represent someone else in order to fulfill or support a false assumption. Can you talk about these things without upsetting me? Of course you can, although upsetting me should not even concern you. I wasn’t actually upset, I was merely pointing out that if someone, not you because I know you a little bit, comes up to me with a ridiculously false argument they are using to hide behind, then I may get upset.

When I was a novice programmer I had to content with things like this: 1) I suggest to the testers that I can do some unit testing before I deliver the code and I get told “you develop, we test. End of discussion� 2) I suggest to management that we can go to the pub, to do team building, and I get told “you develop, we manage. End of discussion�. Do you see why I kick a little bit against strong role definition?

Hope this makes sense tester buddy.

Jamie the developer.

[James' Reply: Cool. This clarifies things nicely for me. Thanks, man.] 

There is nothing wrong with giving yourself a label in order to communicate what you do. I also communicate things about myself. Definitions range from kick-arse developer to trouble shooter to sex god to Jedi Knight. It depends what day it is. Without labels, of some kind, we do indeed run the risk of practical things going wrong.

Where I draw the line is when people, testers, priests, developers, who ever, start re-packaging what I do to fulfill their definitions, their co-dependent needs. Screw them. Screw them all to hell and back. Over-simplifying the world around us to suite our mental laziness is, to me, unacceptable. When I hear things like “tester vs. programmer� or “manager vs. developer� I tend to get angry or just shut off to this ridiculous two-dimensional thinking.

It’s not that simple. I wish it where. These are cloudy days we are living in. But, I choose the fear and doubt over a lie. When I hear someone say “testers take things apart and developers build things� I tend to think “fuck you�.

PS – no disrespect to Chris’ post is intended, I use that sentence only as an example. Regards, Jamie.

By the way, would anyone hire me if I described my self as a “Creator of Useful and New Technologies�? What if I just used the acronym? Hope you are well, Jamie.

[James' Reply: Okay, so you are concerned about people assigning you to a category, with associated attributes, rather than just speaking for themselves? If so, a puzzle I have about that is how do I talk about myself in relation to other people, if I have studied and developed further in a particular direction than other people?

Let me reverse it. I am a programmer. By this I mean that I am comfortable programming and that I write software casually, as I need to. It's not a big deal for me to write a tool to process a log file or manipulate a spreadsheet. It's just part of my normal work. Additionally, I have worked as a production programmer, long ago. I've been programming a long time. Nobody is going to convince me I'm not a real programmer. And still, there are many many programmers in the world who have developed their skills beyond the level where I have found it convenient to develop mine. As I like to put it, I am a real programmer, but not an artisan programmer. Now, by your protocol, I am allowed to say that about myself, but is it true that you are not allowed to say that about me? Something seems wrong about that. I think you should be able to point out that you have studied a skill to a degree I have not.

I believe that's what the tester vs. developer dialectic is all about: people making distinctions among themselves based on what they do in relation to what other people don't do so much. Is there a way to talk about that without upsetting you? If so, can you tell me how?]

Chris writes “Programmers tend to be constructive souls and would probably have been more interested in erector sets. Testers have to be curious about how things work and bold enough to poke around and destroy things without regard for the consequences.�
And he then says “The ultimate danger of the “All Testers Must Be Programmers� school is that it will reduce testing to merely a science and take all the art out of it�.
James makes the observation that science is ultimately a human endeavor, and of course it is. Thus, testing and development are human endeavors and are thus highly scientific and the best people are usually very creative and have great imaginations. Why is science, even by us scientists, down-graded to algorithmic thinking? This is a very wrong label and a result of ego driven reactive thinking.
My tuppence worth on the programmer/tester divide, that testers are curious and programmers are builders is this: I reject it outright and whole heartedly. We are all thinkers, problem solvers. I, although labeled a developer or methodologist, consider myself to be a problem solver. My main problem, that I solve daily, is how to create bug-free software. If that means me thinking about how best to motivate my team to carry out test-driven-development, I will. If that means thinking about exploratory testing, I will. If it means me creatively juggling figures and chatting up the finance people so I can get the money to get someone like James in to train my testers, I will.
So, ultimately, we are all doing the same thing. When you create boundaries you create co-dependent relationships. Then testers are defined by programmers and vice versa. Managers are defined by their team. The conflicts start… when creating this divide you are solving the problem at the level of abstraction it was created. This won’t work.
The reason the waterfall is still so popular is because it provides boundaries for us to work within. These boundaries are false, a phantom. When discussing testers and programmers as separate entities a false opposition is created. The same occurs when we polarize scientists and artists. Philosophers and theologians.
We only do this to satisfy our insatiable egos. “I am tester� we want to shout. Or, “I am a scientist, I don’t care for arty farty things�. The truth is, there is no separation, and that is what we have to come to terms with as an industry.

Whew, you opened up a can of worms today James. Jamie.

PS – Chris, as a child I: took things apart; played with lego; enjoyed soap operas; went to church, and served on the alter; loved science; loved language; programmed; played rugby; boxed; read science fiction; and held my eyes open when I sneezed just to see if they’d fall out. What job does that qualify me for?

[James' Reply: I appreciate and sympathize with your concern, Jamie. Indeed there is a falseness to the boundaries and oppositions we create. Maybe a better word than false would be "artificial"-- it's an artifice, and we may create too much of an artifice, at times.

I think of myself as a tester, put TESTER on my immigration paperwork, and distinguish myself from a programmer, because I think it's a helpful distinction-- generally speaking. It says something about my focus. It's a message to others about how I prefer to deal with the world. I have studied the craft of testing pretty intensively and reinvented that craft for myself, so it feels meaningful to say I'm a tester. I feel that I am a tester more than I am other things. I'm an ordinary father, chessplayer, programmer, pilot, American, etc., but I'm an interesting tester.

If we shun conventional self-descriptions, a danger lurks. If for instance, I called myself a neo-pragmatic motivational philosopher who helps knowledge workers live in an inter-subjective world and be better skeptics (after Pyhrro and Hume) and better empirical investigators of ephemeral phenomena, would anyone ever hire me? I tend to doubt it.]

Which brings me to what I believe is your point, if I understand you correctly:

If you create a repeatable test, then you will never test outside the bounds or space of your test and test procedure, and therefore stand a great possiblity of missing many more bugs and unreasonable results (using your term for unexpected).

This may seem counter-intuitive to the reasons for having formal test procedures, but nonetheless, you will probably save a boatload on not producing such detailed test documents and at the same time find more unreasonable results.

Kind regards,

David
Aberdeen, MD

(I do care when people fib about having a qualification; that has nothing to do with their qualifications but everything to do with their integrity.)

The ultimate danger of the “All Testers Must Be Programmers” school is that it will reduce testing to merely a science and take all the art out of it. Context-driven testing will be replaced by a mechanical method that is guaranteed to cross all the t’s and dot all the i’s and give “certainty” to the entire process. It will drive those who were never really interested in programming out of the industry. It will also ensure that the same type of outlook (the programmer’s/constructor’s outlook) which guided the author of the program will also guide the tester of it. That will mean even more of the complicated, over-egged software we’re coming to see from Microsoft, Google, and others. None of the testers will challenge the assumptions of the programmers, as they will make the same assumptions.

[James' Reply: I agree with your sentiment Chris, but I wish you wouldn't say that about science. The technocrats pushing testers-as-programmers don't know what real science is. They also don't understand engineering, in my view, although they seem to love that word. If you take the humanities out of science and engineering, you also take most of its power away. Science is a human process-- an artistic process, if you like.] 

I agree that testing and programming skills are distinct, but I’m sure there exist passionate, skilled testers who also have programming skills.

[James' Reply: Of course they exist. I am one of them. I would present myself as prototypical. I started as a video game programmer, and worked in the Borland C++ team in the early 90's.

However, anyone who really studies testing as applied epistemology knows that our education and temperament strongly influences our sensitivities. A tester's job is to be sensitive to things, so a wise test manager will construct a test team with a variety of backgrounds and encourage them to test in a variety of ways. When I was a young test manager, I too believed that all testers should be programmers like me. Experience beat me out of that point of view, and I now see it as an infantile notion. My excuse is that I was in my twenties when I believed it-- you can't hold someone fully responsible for what goofball things they believed in their twenties.

If you look at the work of BJ Rollison, you'll see a sort of caricature of the hostility I'm talking about. I suspect his point of view is on the extreme end, and that perhaps he is not taken very seriously in Microsoft. But Rollison is known for his bombast on the conference circuit, promoting the idea that testing should be treated as engineering and then talking as if engineers are people who turn little cranks on little formulaic test techniques instead of being broadly educated and encouraged to think deeply and systemically. If Rollison were just a bit better educated, he might possibly have learned from Semiotics and from Structuralism in general that one's categories and working tools condition the kinds of things one thinks and notices. We must have humility about how our ideas and methods screen us from seeing the world as others may see it. This is vital to excellent testing.

Rollison believes that it isn't necessary to study things like Semiotics and, say, post-modern Critical Theory, to be an excellent tester. Well, Critical Theory teaches that this is one way that we humans attempt to dominate each other-- by telling each other not to learn certain things.

More directly, my brother Jonathan was a tester at Microsoft three different times in four groups. He is one of the finest test managers I know. Jonathan tells me he thinks he could not get a job at Microsoft today, because he's not a programmer.

I'm also in contact with another test manager at Microsoft who's respected in my community. She tells me that cult of All Testers Must Program is becoming rather oppressive.

I have spoken with several people at Google who tell me the same basic story.

That's why it should not surprise us that the software coming out of these companies is wonderfully capable, and yet geared for power-users and technical people like me. Meanwhile, my wife is able to use a tiny fraction of the capabilities of Microsoft software. Her views on usability are not represented in modern software technology, and she gets by because I'm her personal computer geek.]

So, according to you, what should be the bench mark to judge the efficiency of a good (or rather “skilled”) tester ?

[James' Reply: Testers are not engines or equations, so I don't think there is any point in assessing general efficiency. I'm not even sure what that would mean. Instead I would give a tester a problem and evaluate the efficiency or effectiveness of his answer with respect to that particular problem. From that I would decide if the tester was worth trying out on a project.] 

[James' Reply: I have a new favorite book called The Philosopher's Toolkit, by Peter Fosl. This is a wonderful and thoroughly readable breakdown of philosophical techniques. I am considered writing a series of articles on applying the techniques to testing. For critical thinking, I suggest Tools for Critical Thinking, by Levy.] 

Unfortunately, we do have people at interviewing and recruiting positions who (themselves don’t know what it takes to be a good tester) think that certifications are required as common grounds or benchmark for the job (a “not so good” benchmark). Reason: our interviewing techniques for interviewing and hiring methodologies have not matured. Those interviewers who understand what it takes to be a good tester, would NOT ask (insist) for certifications. If some like James, Cem or Michael Bolton, were to do the interview, I am sure such questions about certifications.

Also, please note that certification is not equal to qualification. In my view you get qualified at something by practicing not by mere getting certified. I think James is clearly making this distinction.

It is the problem about people at both levels (interviewers and interviewees) not knowing skills required to be a tester (or a good tester).

Shrini

[James' Reply: Qualification means a lot to me, that's why I work hard to be qualified. In any case, I reject the premise of your questions. Some people use silly reasons to hire other people. I can't control that.] 

I don’t think that James stated in the interview that he is against all certifications.
His actual statement was:

“I don’t know of any tester certification program that is worthy of respect.”

I would not compare a doctor to a tester either. Whenever I go to a doctor (and I rarely do) the first question I get to answer is “and what is your problem sir?”. In a lot of cases I get a prescription to treat just the symptoms (the failures) not the cause (the fault). When the medication is an antibiotic it basically does not really care what the real cause of the problem is. ( it just kills a variety of things - good and bad).

I am not so sure if “a structured way to approach teaching” is the best way to approach teaching. Just today I had a conversation with my friends. We discussed the school system here in the USA and how that affects our kids’ education (our kids attend elementary school). It seems that teachers are limited in their teaching approaches, and need to comply to the ‘teaching structure’ defined by the school district.
I find this structured approach rather disturbing.

I also have a degree in computer science obtained in a ’structured school’. I am sure that my parents will tell me “look where that brought you!”. What I’ll never know is where I would have been if throughout my education the emphasis would have been more geared towards ‘critical thinking’.

[James' Reply: Please read my blog entry titled "Against Certification". That lays out the arguments. I have a high professional standard. I believe the certification programs now available for testers are making a mockery of high standards. I think that's a problem.

Maybe you don't need someone to teach you how to think. But if you want to think for a living, and you are a man of ambition, then you better learn to think somehow. Personally, I've been learning to think for years. I'm pretty good at it now. But I want to be better. If I wish to be a fantastic tester, I NEED to think better. Think of it this way. If you win that city chess championship, that's fine, but if you want to be an international grandmaster, you have more training to do. Same with testing.

Regarding doctors, my wife and I hired illegal midwives to help her through the labor when my son was born. We did our research and I certified the midwives myself by interviewing them about emergency procedures. Actually, my feeling was that I would deliver my own son, but in the end that was not practical (my wife didn't want me to let go of her), so they did it.] 

Many are stunned. Many are realizing that good testing is a skilled activity.

However, I believe that many in QA are attempting to prove that it is a skilled activity in the wrong way: through one-school-view certification programs. In my opinion, this is the opposite of showing that good testing is a skilled activity. Instead of teaching people to test, such programs teach people to be robots and subscribe to a single set of term definitions and processes. Instead of saying “learn to think, learn to be a skeptic, learn to consider what might go wrong”, these programs teach people to follow a process instead of thinking for themselves.

If testers can be turned into robots, then why not automate or outsource them all?

And I agree with you the 3 challenges of testing, and add the task of unify concepts, terms, language.

Anyhow good thing is though late but everybody is waking to the fact .