YAKKING UP HAIRBALLS

Disgorging the Contents of the Blog Fodder File



To supply some New Year’s entertainment, I thought I’d disgorge the contents of my Blog Fodder file (just the last few weeks); none of these were so incendiary they moved me to write an entire blog on the topic, but all of them caught my attention for one reason or another. I attributed the comments to the author wherever possible; the thoughts that went through my head at the time appear under the statement in italics….



"did a wonderful talk about testing against requirements. I’m so glad he avoided the common tropes about the importance of “testable” requirements (he offered “Scheja’s Law” which is “any requirement that can be implemented can also be tested”). I also happen to know he’s a gifted leader of exploratory testers. He works through Sogeti for a client I cannot name– apparently because that client does not want to publicly admit they do ET. Oh when will they learn?" (James Bach)

I’m very familiar with Sogeti; I’d imagine part of the reason for the reticence is that Sogeti has their “own” methodology – TPI – and I’d put it right up there with RUP (my least favorite methodology) in terms of heavy process. It’s unlikely they’d want to ascribe to (some other) methodology in public. I’d also like to say, however, that if you’ve got the money and the time, Sogeti can produce a quality product.

And on the “when will they learn” comment; when will anyone learn? The term “exploratory testing” is poison to some businesses; I’ve used the techniques and never used that term to describe testing strategy. Everyone is willing to use “agile” testing technique; however, the word “exploratory” immediately makes the concept harder to sell. I’m not really in love with any particular word. Except, maybe, for “heinous” and “vile”. I’m fond of those two…


"At least half the testing speakers at Oredev were Context-Driven folks or sympathetic to CDT. So, I’m pleased. We’re taking over the world with our gospel of “It’s okay to solve problems instead of following gospel.” "(James Bach)

Sorry, but my staff (all 42 of them) joyfully leap on any mistakes I make and I’m going to follow suit. What was said here is that "our gospel" is better than their gospel. Unless your gospel was inscribed on stone tablets by God, which would be surprising considering the CP’s distaste for standards, I think I’ll cling to my pagan ways.

"I have been all around Sweden in the past few weeks. It’s clear that there is a lot of interest in Rapid Testing and the whole exploratory approach. No wonder, with the economy tanking… bring on real testers and let the script-heavy factory approach to testing die its natural and long-deserved death. "(James Bach)

There you have it. Everyone who doesn’t do exploratory testing is a Fake Tester. LOL. I’d love to see what would happen if you tried to get those “real testers” to operate in some of the state, federal, banking, or insurance assignments I’ve handled. The reason for all that hard-hat work is because it’s the only way those agencies can operate, due to auditing, accountability, and their inability/unwillingness to cooperate or talk to each other – even if their desks are located right next to each other - unless it’s mandated. Process-heavy red tape environments usually evolved that way because it solved some problems that couldn’t be solved any other way.

"I wouldn’t believe myself until saw this really happening. Testers keep writing detailed test cases up-front with the primary goal to justify the time they spend early on the project. And right they are (are they?). At least they believe so. Managers see evidence that testers have red and understood..." (Ainars)

Well, I personally still don’t believe it. In fact, I think Ainars made it up. To be honest, my immediate reaction was “bullshit”.

"Concepts like "right" and "wrong" requirements "before design can begin" assume that:(1) The customer can speak with one voice,(2) The customer can know what he wants without first seeing an example,(3) The customer never changes his mind,(4) The market never changes: The "right" requirements last week, last month, or next year are all the same.(5) Design and Requirements are two separate and distinct processes that do not feed each other. That is to say, it is not possible, or at least not desirable, to innovate on the specification with interesting design ideas. (For example: "The spec says do A,B,C,D which might take a year. But just A,B,C we could do in two months. Can we do just A,B,C, deliver it, and see if we need D at all?")Now let me ask: for any given project you are working on, are statements one through five actually true? " (Matt Heusser)

How about "right at the moment"? Or “as close as we can make it, working with the customers we have available, based on what the market is at the moment, with a Really Good change control process”? Some of these issues are for PMs, not testers. They can’t influence project methodology – they need to play whatever hand they’re dealt. Requirements are freaking important; whether they change daily, or they don’t change at all. Otherwise, you have development staff working on the wrong things and the testing staff trying to “guess” at what is, or is not, an anomaly. It’s also time-consuming and expensive to never arrive at “what is this beast?”.

"1. a ScrumMaster course two weeks ago (is that Agile or agile?) and came away with a lot more than just Scrum. What intrigued me was the whole concept of acountability and the commitment of the team. It finally clicked, that this is exactly what processes and monster-documents-from-hell destroy (see the whole Waterfall process mess). They take away the accountability and the sense of belonging to a piece of work. "(Oliver)

Project methodology has nothing to do with accountability and commitment of the team. You can have an Agile project that stinks and you can have a Waterfall project that stinks. You can have success with either one as well. I believe it is communication, the Project Manager, and the caliber of the team that makes the difference.

"will be shocked when people make claims (what I call as "popular perceptions") about software testing such as “all testing should be documented, test cases are important for performing testing, test cases must be traceable to requirements, you cannot test without specifications, tester’s role is to find bugs, testing assures quality of the product, testing needs to be more process oriented than person dependent etc. I can say that those who are not shocked by such claims have not understood about software testing that relies on human elements (thinking, questioning, observations etc)."(Shrini Kulkarni)

How do you share your thoughts, questions, and observations with others? Through communication. Documentation is one form of communication, often used in environments that have problems with verbal communications, those that need to communicate those ideas to people who are geographically located in distant parts, people who will come after them when they are gone, assessors/auditors responsible for ensuring the (public, end users, customers) got what was contracted for, or that certain federal/state/country regulations were met.

I am not “shocked” by such claims; I understand them, even when I don’t necessarily enjoy every aspect of such environments.

Perhaps this is why Agile works so much better than Waterfall. By imposing numerous (arbitrary) deadlines mid-project, it forces prioritization. (Steve Rowe)

I really liked this statement and not because I necessarily agree with all of it. Project management techniques, which are what Agile and Waterfall represent, don’t mean squat to me. I can perform equally well in either environment and I train my staff to be able to do the same. What I liked about it was the idea of imposing numerous (arbitrary) deadlines mid-project to force prioritization. That concept would work equally well using any type of project methodology.


So that’s it for 2008 and thank you all for an interesting, thought-provoking, and entertaining year!!!