Rambling...

I am feeling rather facetious tonight, so if you don't want to bear with pointless diatribe, then don't proceed.

OK....if you've made it this far, then let's start. The other day I happened to be watching a Google video featuring Jon Bach explaining exploratory testing yet again.  <TANGENT>  I must admit that I find it especially sad that after all these years some people still feel compelled to portray exploratory testing as a victim of ignorance, and attempt to extol exploratory testing as the holy grail of software testing. I think we get it. Exploratory testing is performed, it has always been performed (well before the moniker was attached), it will always be performed. It is based on experience, knowledge and skill, the more you explore the more you learn, it is a valuable approach within certain contexts, blah, blah blah. Please...I think folks realize its value, I think they realize they do it, and I think they realize its limitations. It really doesn't matter how much or to whom we pray; the simple fact is that exploratory testing will never achieve the status of divine miracle in the software community. So, can we move on from the "we all do it," and "it is goodness" platitudes. </TANGENT>

I must get back on track (otherwise you will simply consider this as trite ramblings of an old man. Wait...some of you already do think that of some of my posts, yet you still indulge me.  <TANGENT> Isn't it is a mysterious dichotomy of life that attracts some of us to the things with which we disagree or find offensive? </TANGENT> ). Anyway, as I am watching the video Jon is leading a discussion of random tests to try to "break" the triangle program. So, someone suggests inputs that would essentially equate to a straight line. Low and behold the program accepts the inputs and draws a straight line outside the parameters of a box that is supposed to display a visual representation of the triangle type. At this point I begin thinking to myself that the developer of this code was a complete moron (either because he/she didn't know how to calculate inputs for a invalid triangle, or failed to do basic unit testing prior to code check-in), or purposely went out of his/her way to inject such a ridiculously simple defect. Sure, I would certainly execute the test, and if I the program failed as displayed in the video I would probably just start looking for a new job because the project is in real crisis if the developers don't understand how to check for basic triangle types or are too lazy to perform basic unit testing.

Think about it; somewhere between 4th grade and junior high school most of us learn basic plane geometry. So, I am thinking that if someone developing or testing a triangle program doesn't know that inputs of 1, 2, and 3 don't form a valid triangle and those inputs  or inputs of 0, 0, and 0 should (oh, let me go out on a limb here and suggest) perhaps display an error message, then I have to ask myself if I really want this person developing or testing more complex computer systems. Hello...this is just basic plane geometry; it's not hyperbolic geometry or spherical geometry, and it's certainly not trigonometry! I mean seriously, Lexus now has  a car that has the ability to automatically parallel park itself, and last year I had the privilege of meeting some of the developers and testers who worked on this technology. Now, admittedly the technology still has problems, but I am thinking that the folks who worked on that project figured out pretty quickly how to calculate and test for invalid triangle inputs before installing it in a car and taking it out on the road for an exploratory test ride. 

Now, don't jump to conclusions and assume this is an attack against Jon Bach or exploratory testing; because it isn't. In this presentation to Google, Jon does another good job of extolling the virtues of exploratory testing (yet again) and drawing parallels between exploratory testing and the sport of curling. (It's a master orator who can make that connection.) But, for some strange reason my mind focused on the failure illustrated in the video, or should I say the inability of the program to deal with fundamental error handling. Then, I began to speculate and ponder wild thoughts, and I dreamed of a mysterious world in which my imagination never ventured. I began to wonder if many of the testers (outside of the companies I've had the privilege of working for or with) really do have a rash of incompetent developers who were actually working on production level code making such juvenile mistakes over and over again? We all know that developers sometimes are not very proficient at testing and that unit testing doesn't catch all defects, but I have to ask if we would really expect a software company to put a developer with only a 3rd grade education on this problem when many people know that its not until 4th grade that most children typically begin to learn plane geometry?

OK, seriously...I do know (or at least I hope) this defect was purposefully injected to illustrate a point. But, the point was not very clear, because I have to tell you I am not doing exploratory testing when I design functional tests to evaluate proper error handling capabilities of a program given nominal inputs in which a+b<=c, or b+c<=a, or a+c<=b  (assuming valid nominal inputs and not including boundary value analysis) to test for invalid triangle values given the simple requirements outlined by Weinberg's original description of this common testing parable. Or, perhaps the point was simply to demonstrate the fact that sometimes developers make simple errors. Yes, this happens, but I don't really expect too many professional developers to make such apparently cheese-ball type mistakes in the future. But, in the off chance developers do make these types of errors where you work, and you have to test their crap code then at least be comforted by the fact that you probably don't need to improve your technical skills and knowledge too much and you will still have pretty good job security using the "let's try this" approach or 'finger-dancing' on keyboard stage. But, I think with agile development approaches, and emphasis on TDD, unit testing, defect prevention and driving quality upstream finding such simple bugs are going to become rare occurrences. As testers, this means that we are going to have to increase our technical and professional knowledge and skills to be more effective in our role, and which will be essential for success and advancement in the discipline of software testing in the coming years. (Hmmm...maybe this wasn't completely pointless after all. )