Over the course of the Let’s Test conference in Runö, Sweden, I noticed a problem with context-driven testing. In the past one or two months this turned into two problems I see with context-driven testing. I finally decided to put them out there for further discussion. I hope a lot of you don’t agree with me – and I hope a lot of you folks speak up.
Systemic effects
The most pressing issue I have starts with the systemic effect. I will phrase this as arrogantly as I can. The term “context-driven testing” – for me – includes the notion that we are driven by the context, and the context of our situation is the only way we can think of as we should be handling now. We are testing alongside our context, right? What could be wrong about that?
This interpretation of “context-driven testing” ignores pretty much a central point about context:
The context includes the tester.
Our behavior leads to changes in the system that we call “context”. This is a variation of the Chinese proverb: “When you point your finger to another person, look where the other three fingers are pointing to.” By acting based on “the context”, we influence “the context”, we change “the context”, thereby we will drive “the context” to another status, to another “context” that will change our behavior. To put it clearly: Stating “I as a tester am only driven by the context of the people around me” is foolish, short-sighted, and ignores the systemic effect that our own actions have to the situation, the context of our project.
If we do a poor job of testing, this will influence the stakeholders and project managers around us to lead to different actions upon us. If we do a decent job testing for the stakeholders’ expected results, this context might drive us into different follow-up actions. But rejecting the premise that we as testers influence that context, and are only driven by it, is rejecting the systemic effect that we bring to the party. We neglect the effects that we make upon the project, thereby we will miss a large part of “the context” that we claim that drives us. Ouch!
But there is more to it.
Victim behavior
Victim behavior? What’s that? Unfortunately we have to dive into transactional analysis for this. According to the theory behind the Karpman drama triangle we play a game here. A game with roles as the persecutor, the victim and the rescuer. Huh? What’s that?
People play games at work and while interacting with each other. The Karpman drama triangle puts three roles into context, and I see them a lot. The persecutor is the one evil figure. It’s the devil in the Holy Book, it’s Al Kaida in Western News Reporting, it’s the programmer and the project manager in modern programming (I made this third one up).
As a tester, now, we are victims of this situation. We are helpless there just as the US is helpless against Al Kaida, the German soccer team is helpless against the Spains or Balotelli, and the only hope against the devil is the belief in God. We testers are the victims of the situation, the victims of the context, that became our persecutor. I hope by now you notice how this is an extension to the first point that I made with the ignorance about the systemic effect.
Now, in the triangle, there is someone who rescues us victim testers that are persecuted by the evil context.By playing the role of the victim, we are seeking for the rescuer, whoever that might be. I won’t hypothesize on this; you’re a thinking tester; I think you can make up your mind about who your rescuer could be on your own.
Now, here is my call: Stop being a tester that claims to be “driven by context” as a false victim behavior. You are influencing the same “context” by your behavior, and you might find yourself seeking a rescuer that will not hear you.
I agree with most of the context-driven literature, most of the context-driven teachings, heck, I even claim to teach context-driven testing to others. And I think the name is at least misleading in these two particular points that I described. We are not victims as testers, and we are active actors within the context that we claim that influences us. Deal with it. Now.
Markus
You raise some important points, and I feel that it is important for us to test the boundaries of how we define context driven testing.
I’ve been toying with the change problem – and by extension the victim problem – for a while now, in fact, Michael Bolton and I were exchanging tweets on the subject last night. Of course we are part of our context, nor are we passive observers – we are actors in our own contexts.
The principles of context driven testing, or more accurately the commentary to the same, may state that there is “no room for advocacy”, but this relates to advocating any favored practice. Similarly, the commentary also states that “we do the best with what we get”, but where does it state that you have no control over what you ask for? Nowhere. Is there anything wrong with asking for something that would improve testability? Is there anything wrong with asking for clarification on the design? Of course not. If you don’t ask, you don’t get.
We CAN, we DO, indeed we CANNOT AVOID changing our contexts. We do not meekly accept the hand that context deals us. But what sets us apart from best practice testers is that it is the needs of context that motivates us, not our own self interest or preferences.
Regards
Iain
Hmm, interesting post Markus. I’d like to ask you a question before commenting too much…
How often have you seen testers that don’t include themselves as part the context? When thinking about context I always include myself. As a tester you impact the context a great deal… your experience, your passion, your abilities, etc. all come into play when looking at the context. I find it strange that many others wouldn’t do this… hence my question.
I’m a firm believer that being a victim is a choice… I have more recently seen myself as a rescuer. A rescuer that saves projects by providing valuable information when required.
I need more form you on these two points. Are you generalising? Have you seen this happening the majority of the time? Provide us some more context (pun very much intended). ;0)
David, I don’t think you really want to portray yourself as a Rescuer in the Karpman sense. We strive to be driven by the needs of context rather than the needs of our egos – Iain
My first reaction to this is that the needs of our egos form part of the context, whether we like it or not…
I have more, but think it may be the length of a post rather than a comment reply. Either way it will come soon. ;0)
Thanks guys for sparking another path of learning for me… :0)
http://martialtester.wordpress.com/2012/07/05/karpmans-drama-triangle/
Sorry, just to clarify… I mean that having a victim mentality at work is a choice, not being a victim is a choice.
I wasn’t at the “Let’s Test” conference, so I can only react remotely to ideas that come from it. I am sure that I am missing some context.
But in terms of what I see here (and so much of what I see on twitter), I am saddened but I guess not shocked that there are doctrinal disputes over the meanings of pronouncements in the context-driven principles. Look, these principles are not perfectly worded. They were not written by deities. They rest on what I still think are good ideas, but it is easy to give the words too much importance. When conferences spring up that advertise themselves as “If it’s not context-driven, you can’t do it here,” I worry that we are encouraging a level of zealotry that will include, among other problems, arguments that pit common sense against a literal interpretation of some words.
Some of my words on context-driven-testing.com seem to be playing a role in this dispute, so let me argue for the common sense side of them. OF COURSE the tester is part of the context. And OF COURSE the tester should suggest ideas or practices that s/he thinks it would be helpful and appropriate to suggest. I am not sure how someone can read past the underlying humanistic emphasis of the context-driven principles to reach a conclusion that would alienate a tester from the quality of her work.
We have many ways to improve a project, and as a general rule, it is good to improve things. And as a general rule, testers will question whatever they feel like questioning and thus come up with lots of different ideas for improving lots of different aspects of the project. As a general rule, I think that’s a good thing too.
But on projects that we don’t own and don’t manage, and that are not designed to serve our needs, the nature of the improvement we can generally achieve is incremental. And the effort to improve its atmosphere and its practices can be overdone to the extent that they weaken the project with distraction, dissension or recrimination, killing the project’s atmosphere and productivity. I think that’s a bad thing.
There is a contrary view that is more assertive. That view encourages testers to think we have a moral or professional responsibility to hijack the project and insist on our favorite best practices or insist against our favorite worst practices, and to label anyone who disagrees with us as unethical. I used to see this as a mark of the “standards” advocates, but I think see it among some people who label themselves context-driven today. In either case, I think it is destructive. In response to either kind of zealot, I say no, we start from the project’s context, we start from an acceptance that a project can be legitimate and its management can be legitimate even if they do things in ways that we don’t like (subject to some limits, of course).
As I see it, my responsibility is to serve the project and its stakeholders, in ways that advance their goals for the project, and if I can’t focus on that and do that well, I shouldn’t be on that project. As I see it, to serve that project well, I have to understand how my work fits within that project’s goals and practices and how to meld my work with them constructively. I start from the context, I operate within the context, I become part of the context, but on most projects, I play a relatively small part in creating and evolving that context. Mainly, I adapt.
— Cem Kaner
Cem,
Doctinal dispute? In the same way that discussing different interpretations of requirements can be valuable, don’t we stand to gain as testers by understanding alternate interpretations? Even by clearing out the sillier ones? We’re testers after all, and we can’t help but test context-driven testing.
As to our role (or otherwise) as change agents: our role is to serve yet often our customers impose barriers to us doing so. When do we let those constraints go? When do we seek merely to illuminate them? When do we refuse them, and look to work with customers whose values align more closely with our own? When do we challenge our OWN beliefs about those constraints and entertain the thought that WE might be wrong (much of the time I hope). These are funadamentally difficult questions and that there are a range of opinions is unsurprising. But again, I think that dialogue is healthy.
Iain
Yes, the tester is part of the context. A context-driven tester is trying to understand that and all the rest, so that he can be useful in that context.
Regarding ethics. I agree with Cem and it’s wrong to call people unethical because you disagree with them. Instead, I hope people in our community will oppose actual unethical behavior (such as counting test cases when the test case count cannot possibly be used in a productive way, and also leaving loaded guns around toddlers) when in good conscience and consideration we believe that it is unethical. We must also have the courage to talk about ethics and wrestle with them even when people might label us as “zealots” for doing so.
I also agree with Cem that there is a danger of zealotry in any situation where people care to do great work or care to avoid great harm. So let’s do our best to maintain collegiality and amity even when it’s hard. And let’s talk about these issues and let’s moderate ourselves with reason and humanity. No one has done more than Cem to stand for this, in our industry.
— James
Too bad there is no way to edit these things in place. There are two typos, above:
1) “also not leaving” should “also leaving”
2) “conscious” should be “conscience”
I edited it for you.
Grouping counting test cases with leaving loaded guns by toddlers? Come on man…