value of practices, but it will at least provide more data to inform those debates.
Context-driven testers believe test process is about tradeoffs. They see test process in terms of problems and possible solutions. If that is true, then there are no “best practices.” Instead, the best we have is guidance that can fail, what we call “heuristic.” Therefore, if you know only one way to do something, or imply that there can be only one good way to test, expect an argument.
Toward a Real Dialogue
In his book The Five Dysfunctions of a Team, Patrick Lencioni details five specific problems. The behavior of context-driven testers is directed at addressing three of these dysfunctions in particular: fear of conflict, which creates artificial harmony and stifles real change; lack of commitment, which leads to people disengaging instead of openly disagreeing; and avoidance of accountability, which leads to people ducking the responsibility to call peers on counterproductive behavior and produces low standards.
Context-driven testers hope to advance the practice of software testing, avoiding dysfunction by fighting about language and ideas and exposing shallow agreement and making their ideas explicit with actual examples. This is what they bring to testing, and what they believe to be valuable. If you can keep that in mind when tempers flare, things might just go a little better.
As a context-driven tester, myself, I invite you to tell me I'm wrong. Have you had an experience working with testers from different schools? Did your experience conflict with my advice? Tell your story. Do you have a different idea about dealing with differences and conflicts in testing culture? Make your case. Or, if you agree or have something to add to my model or my advice, say so.
This article is my part of the conversation. The comments? That’s up to you.