In a recent blog post, Paul Gerard wants to reject the idea of schools of software testing as defined by Bret here. To me, this means that he belongs to a school of thought that suggests that there shouldn’t be schools of thought about software testing. That’s different from my school of thought, so I guess we’re in different schools of thought, at least on that issue.
Paul argues that “no one wants to be part of a school”. That’s clearly false, since many people seem to identify themselves as members of the context-driven school. (If it makes Paul feel better to call it the context-driven community, that’s fine with me.) I think, maybe, that Paul means no one wants to be tagged as a member of a school against his or her will, or by someone else. That’s fair enough; it’s okay not to want that. But understand that it’s going to happen anyway, one way or another, any time that anyone wants to be reasonable about disagreements in thinking and approaches. An alternative is to say that people are wrong, or crazy, or idiots. I prefer to suggest that they’re in a different school of thought from mine, and for convenience I might label that school of thought when there are two or more people in it. Boris Beizer has called our community “the touchy-feely school”. Actually, I believe we’re more like the “thinky-valuey” school, but Boris can call us whatever he likes without it really bothering me. He’s not of my school, after all.
Paul’s second objection is that that the four (five) schools are stereotypes that don’t align with reality. Well, they are if you choose to take them literally. But Bret’s classification scheme is a model. All models are wrong, but some are useful. And models can be modified. Maybe there are many more schools of thought in testing than Bret describes. Maybe there are only two—context-driven and not. Different people may have different models. On the whole I’ve found Bret’s model useful in describing the approaches some people might choose and the choices some people might make in a given context. If it helps, you could turn them into adjectives without labelling people: “That’s a factory-school approach” or “That’s quality-police thinking.” There are certainly schools of software development; Agile and non-Agile, at least. There are schools of belief. Are there not schools of software testing?
Apparently there are. Paul notes in his post that he got together with a group of “testing friends” who agreed that practices from each of the schools might be appropriate some of the time. Note that it was a group of his testing friends who agreed. Are there people in the world who think differently about testing from Paul and his friends? What would happen if he were to have this chat with a bunch of people who disagreed with him about choosing practices? He says, “Call us the ‘some of the time school’, or maybe the ‘appropriate’ school or maybe, the ‘it depends on the context’ school. Whatever. We choose to adopt appropriate practices depending on our context.” That sounds like he wants to be a member of the context-driven school, and not some other. Yet Paul has also proposed axioms, universal premises about testing that apply in all contexts—which to me is not a very context-driven thing to propose. So what will we do about that? Well, we’ll talk it out like colleagues and he’ll drop the idea, or we’ll agree to divide into different schools of thought that one or the other of us might choose to label. Either conclusion would be okay.
In a different post, Paul says “If I believe ‘high process’ approaches have their place in some projects – does that preclude me being context-driven?” No; that’s of the essence of context-driven thinking. He says “But a continuing theme of these schools discussions is that high-formality approaches are the result of crooked thinking.” That’s not the way I see it; the belief that high-formality approaches are universally appropriate is the result of crooked thinking, just as the belief that they’re universally inappropriate would be too. That’s part of what the context-driven school is all about; rejecting the notion of practices that are universally best, in favour of adopting and adapting ideas from other schools of thought. Want to be a good context-driven thinker and have some fun with this? Consider at least three contexts in which context-driven thinking would be a bad idea.
Back to the more recent post. Paul claims that “NO ONE ACTUALLY behaves the way that the hackneyed stereotypes would have you believe…. The schools don’t work because the proposed stereotypes do not align with the behaviours of people in real projects.” Well, I’ve been to a large number of places, all around the world, and I observe that Paul is incorrect. There are people who claim that you can’t test, ever, without complete, consistent, unambiguous requirements and a detailed written test plan, and that you’re morally deficient if you try it. There are people who believe that completely automated unit and acceptance tests are the be-all and end-all of good testing—”the Holy Grail”, as appeared on one mailing list lately. There are some people who claim that testers should be the gatekeepers of quality. There are some people—academics, mostly—who believe that programs can be proven correct, and for whom questions about value are off the table. There are people who believe that “maturity” means “doing the same things the same way every time” instead of “being able to adapt your process and your practices reasonably and responsibly to changing context.”
You’ve seen some of these people speaking at conferences, Paul, and on occasion I’ve seen you challenge them. You don’t belong to their schools, nor they to yours.