There’s a difference between complicated vocabulary that helps and complicated vocabulary that doesn’t help. A problem with a lot of complicated testing vocabulary is that it has been preserved from criticism by its promoters. It’s allowed to grow like mold in a closed jar. This is because that terminology is actually a marketing and sales tool, not a problem-solving tool. The people doing those certification programs make deals with each other of the form “if you accept my technique into the syllabus then I’ll accept yours.” Such “techniques” are often rather free of content.

There is a lot to say and a lot to study about testing. Testing is not simple if you want to become *very* good at it. I feature exercises in my classes that routinely trap people who believe all they have to do is glance at a program and every important bug will reveal itself. The jargon you complain about is mostly a cover for people who know nothing about testing and wish to continue to know nothing. But some obscure sounding vocabulary serves a useful purpose. To discover whether jargon is empty, you have to question it.

Years ago at PNSQC I saw you give a presentation on back-of-the-napkin state-based testing that demonstrates my point. You can say you were doing something simple, but I saw layers of discernment; heuristics aplenty. I had to walk out of your presentation, before you finished, because I GOT TOO EXCITED TO SIT STILL. I had never seen anyone do in a presentation what you were doing. It inspired me to re-analyze some of my own testing behavior to draw out new subtleties. Now I do the same sort of things in my teaching– but I wouldn’t call it simple, except in the sense that I am helping people to develop skills that everyone already has SOME of, before they ever come to me.

I don’t remember every lesson learned in high school, but this one has stuck with me:

My instructor demonstrated that an object that is taller than it is wide is susceptible to toppling. It lives in a heightened state of potential energy almost BEGGING for equilibrium. Nature revealed that ascending to lofty heights without a solid foundation can be disasterous - or at least disorienting.

I feel like my foundation has been widened having read your post; with the added benefit of a significant loss of my recent heady disorientations. Thanks for providing me with a re-intro to software testing.

I completely agree with everything that you said in this post except few statements that appear to dilute or simplify “testing” . I think, if you read your post without these sentences all of it still read fine - main message of the post still very much in tact.

1) “Testing, quite frankly, should not be that hard. And if it is that hard, something is wrong.”

I would not call testing as simple or hard. I don’t approach testing in that “binary” way. I can only say you got to learn the stuff, learn, practice, speak, listen, observe, collaborate, read, write, argue and so on. Some of this you do using “simple” vocabulary and some of it using “complex”.

Testing as intellectually engaging, technical/empirical investigative, questioning activity could be (mostly is) a complex activity - at least something that anyone with only “real” knowledge of testing can do. I agree that there are developers who can do (few) things that testers can do but there are indeed some tasks where “real” testers excel.

I understand and fully support your crusade against “Jargons world of software testing” - it does not help the cause and existence of testing community. As James suggested, proponents of complicated terminology or”Jargon” based testing kept is shielded from scrutiny and criticism.

2) “Testing activities are too crucial to the success of a software development effort to be left solely in the hands of “certified test experts.” — What if you omit the word(s) “certified”.

Would you be comfortable if success of a software development effort to be left solely in the hands of “test experts”?

4) “good software testing is actually quite simple”
Simple in what? To learn or explain, perform or communicate?

While hitting hard at “Jargon” based software testing experts, you also appear to give the impression that “testing” is “everyone’s job” (as quality) and seem to dilute the importance and role of testing in software world – you might want to clarify. Don’t you think that you can hit at these jargon creators without diluting the role of testing?

Shrini Kulkarni
http://shrinik.blogspot.com

I can accept the idea that anyone can help test the product. I think if you turn testing over to test experts (for certification) then they will automatically enroll other people in helping to test– because part of testing expertise is to appreciate the value of other minds.

But any time I see testing done routinely by people who refuse to study how to do it well, or who are oblivious to the notion that there’s anything particular worth learning about testing, I expect to find great gaping holes in the test strategy. I expect to find people succeeding, if they succeed, by luck and the low standards of their customers. That’s why I’m a little troubled when someone says “testing is simple”, especially someone as skilled at it as Elisabeth is.

If everyone in the world were deaf, there would be no important difference between playing guitar and playing “air guitar”. A problem we have in testing is that so many people are deaf to it. Bad testing looks exactly the same to them as good testing.

“(for certification)” should have been “(forget certification)”

oops

I agree with Elizabeth, I think it’s more of a question of whether someone is both curious and cognitively self-aware. Certification of testers in some areas (like medical device software) can be both necessary, because the knowledge of the subject matter is crucial to understanding what to test, and useful, because the test goals are very specific (i.e. - don’t kill the patient, and if possible, keep them alive), versus an app for wider distribution, where things like interface bugs have a much bigger impact on its quality value, and a less specialized person can provide valuable feedback.

Indeed, any application with “Beta testers” is inherently being tested by “anyone”, with the set of anyone defined as the set of potential users of a product. At this level, testing is a “simple” matter of exploring and clearly communicating the application experience, which almost anyone CAN do, even if they do not. Also, done well, it should be FUN and INTERESTING, which may be why many people “choose” to be deaf to it - they may have only had “bad” testing experiences.

Also, many “Good” testers can engage in “bad” testing, due to mood, or observation bias, or fatigue, or any number of cognitive errors (See “How Doctors Think” for a really cool, interesting examination of these phenomena). Sometimes lots of experience works against a tester, at least in the short run.

I respectfully disagree with Elisabeth on this matter. I have been a Software Tester for 10 years now, ever since I graduated college. I had no knowledge on any technical terms regarding QA up until 3 years ago! Put it this way, there are QA personnel in our group that don’t even know what White Box Testing means! They are professional in how they work and interact with the developers, however, they do not have, and are not interested, in learning any “jargon” regarding QA! As I have been learning more about the QA field these last few years, it has broaden my vision, it has opened my eyes and can see further down the horizon.

My main point here is that knowing all this “jargon” can build a foundation, a structure, in your mind that you can access, at will, whenever the need arises! You start building mental notes, mental patterns that allow you to anticipate possible problems with software. Instead of TESTING something, you now have the knowledge and confidence to EXAMINE it. I don’t understand why this article is so hostile towards these terms, towards this jargon, when all it has done for my professional life is enhance it. I’m beginning to teach the QA group in my department all about these things. I’m trying to put into their heads that it’s not just TESTING this, it’s about understanding the WHOLE concept of QA an applying it to a software! How can you apply a QA concept into an application without knowing the technical jargon?!?!

It makes me think that this is all relative. Simple jargon to you guys might mean a whole suite of complicated terms to my co-workers!! This article is too general to be taken as right or wrong. It is of a natural essence that specialized terminology and jargon will be REQUIRED in order to elevate the significance of QA and its involvement! Software is becoming much too complex to have over-simplified terminology for QA! Just as everything else, you need to learn in strides and in levels. Someone with expertise in the JARGON and PROCEDURES of QA will be much more efficient than someone with no knowledge of the fundamental concepts within the QA field. I disagree that certification of QA is unnecessary. We have to learn how to tame the beast. Any and every tool that we can have at our disposal will work for us! Field-related jargon and terminology provides the infrastructure that we need as QA experts to tame the beast!

I felt the original post was aimed at the mis-use of jargon, as expanded upon by James Bach. Any jargon serves to provide quicker mental access to ideas and concepts than the typical line that refers to an idea. Jargon is great for my use, it’s great for two closely working testers. But I think the field is maybe a little too immature to allow quick communication between testers in the global arena. A hammer is great for hitting nails hard, but it can also be used to kill people. I don’t think hammers should be out-lawed, and likewise jargon has it’s place. The problem is when it serves to shield ignorance or promote a sense of cheap professionalism. I’m new to the field, and certainly not a skilled tester. However I consider my own abilities to be of value to my company (well I do get paid every month…) enough that I don’t fear for my job. (note I’ve resisted cross thread blogging! see:Diluting the tester role)

All said, and in agreement of less jargon being a positive step. It does make me a little cross, when a developer says AUT ?? Autumn?? Autistic?? completely ignoring context and explanation. So in defense of a little jargon slipping into project reports - Semi-precious red jewl on a rail-way line.