Posted September 20, 2013
The 8th annual Conference for the Association for Software Testing was held in Madison, WI this past August. I admit that I’m biased when I say that this has always been one of my favorite testing conferences. I was very much involved in creating, molding, and managing the conference for its first 5 years & served as volunteer staff for the remaining CASTs I attended… except for this year. This year was different. This year I was tasked with delivering the closing keynote with my friend Rob Sabourin. Our topic was “Lessons Learned at CAST 2013” and we challenged ourselves to limit our keynote to lessons that we learned individually, not lessons that others learned. What this meant was that—instead of spending the conference at the registration desk, or managing audio/visual equipment, or coordinating food with the venue, during most of the actual conference program—I was committed to participating in as much of the program as possible.
Needless to say, I was looking through a very different lens this year. Being freed from my usual responsibilities of care taking other attendees, I was able to fully participate in the programs and seek out my own lessons. And I realized some things:
- CAST isn’t “just” a conference. CAST is also an annual reunion for an oddly close knit & passionate community (oddly, in that almost all of the 50-ish% first time attendees were so well integrated by lunch on the first day, that an outsider would have thought the entire group was friends “reunited”.
- Testers really are quite social (at least with other testers) and they really enjoy spending time with other citizens of “Testerland.”
- CAST is just one of many passionate communities within the whole of Testerland.
- Testerland is less like a unified body than an archipelago of “islands of misfit toys.” Testers have no professional society, no degree programs, no widely accepted standards boards, and no “basic training.” The only “homes” we have are the communities we build for ourselves.
- Many of these communities in Testerland don’t get along with one another.
Yes that’s right, testers are cliquish. There are cliques related to different industries, appropriate degrees of pre-planning, percent of automated vs. manual tests, whether testers should have strong programming skills, agile or waterfall, advisor or gatekeeper, certification or aptitude… the list goes on and on. Worse still, many of these cliques (and/or prominent members thereof) have a nasty habit of taking the ugliest of their debates “to the streets.” And yet, testers wonder why it is that we so frequently “get no respect” in the software industry? Could it possibly have something to do with the fact that what most folks *see* of “Testerland” is testers not showing respect for (or outright disrespecting) other testers? Might it be the case that non-testers would respect both testing and testers more if they observed *us* treating one another with more respect?
Now, don’t get me wrong, I’m not saying that testers should stop debating… that is, after all, how many of us learn best. It’s also one of the ways that testing advances, by challenging one another to be even better. But differences of opinion (even polarizing ones) need not create cliques and bitter battles better suited for TV sitcoms than the center-stage of professional environments. And yes, I know I’m guilty of participating in some of those bitter battles – some with better justification than others – but I fully acknowledge that whether I was right or wrong, and whether or not something positive came out of those battles, the battles did damage to both Testerland and to outsider’s opinion of the value and professionalism of the citizens of Testerland.
I personally most closely align with the sub-community of Testerland that follows the 7 principles of “Context-Driven Testing.” CAST, the AST and several other communities within Testerland are publicly or privately aligned with the “Context-Driven School” as it is called. For those of you who are not familiar with them, below are the 7 Context-Driven principles:
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
As it turns out, the Context-Driven community has been—more or less since it came into existence—at the center of much of the bitter divisiveness in Testerland. A few years ago, I attempted to quell the fires a bit by blogging about “What Being Context-Driven Means to Me,” believing that much of the bitterness was related to some kind of misunderstanding about what Context-Driven actually was. It didn’t help…at least not much.
Here’s what I don’t get. What is it about these 7 principles that makes Context-Driven arguably the *most* divisive of all of the communities in Testerland? Maybe it has something to do with the ongoing confusion between Testing and Quality Assurance (QA). For the record, it is my opinion that the 7 items above would make a lousy set of core principles for QA, but QA as a term has been so amazingly miss-applied in software (as opposed to the non-software industries the term originated from) that it’s difficult to know what anyone actually means when they say “QA” anymore. Is it the fact that, even though software testing is at best only 60 years old, folks want “best practices?” Even though after over 7,000 years, the field of Accounting has only recently achieved “Generally Accepted Practices.” Is it something else? I don’t know. But I do know that:
- Testers seem to enjoy affiliating both socially and professionally with like-minded testers.
- Testers like to debate (We are natural skeptics after all. That’s part of what makes us good at our jobs!)
- Tester communities seem to have a propensity for debating, often violently, with other testing communities – publicly.
- Testerland is damaged when the ugly aspects of our in-fighting goes public.
- All this divisiveness contributes to the advancement of testing being diminished, the quality of software suffering, and universal reduction in respect for both testers and testing.
Personally, I hope we will realize that our community will never become more than what it is while our energy seems to be focused on civil wars. I hope that with that realization, the civil wars come to an end—but not the passionate, yet professionally acceptable debates. I hope that we can find that we actually have some things in common, and that those things are more unifying than are differences are divisive. I hope we can learn to accept differences within our community (at least to the degree those differences are based on context, experience, and value to our stakeholders).
But mostly, I just hope that the cliques and the infighting don’t end up destroying both fun and professionally fulfilling aspects of our…testing sure is a whole lot less fun when there’s no one left to tell my tester jokes to.