Do your best with what you get

A while back, I wrote a short response post to one of Huib Schoot’s blog posts on the difference between a mindset tentatively labeled “adaptability” and that of the context-driven tester. I submitted (as did Huib) that the thinking behind the label adaptability was very different from how context-driven testers think.

This post is about addressing another misunderstanding about context-driven testing that I’ve come to fear is worryingly common, namely the notion that for one reason or another, context-driven testers are incompatible with so called “agile testing”. If I were to address all potential sources for such a misunderstanding, this post would turn into a short book, so for now I’ll only focus on the misunderstanding that “context-driven testers work in an exclusively reactive fashion”.

I was reminded of this when I was reading Sigge Birgisson’s blog a couple of days ago. Sigge has recently published a nice series of comparative posts where he compares Agile Testing to a series of other perspectives on testing. The series is not complete yet (I think) and there are hints of a concluding post down the line, but there’s quite a lot of material to go through already. In particular, Sigge’s comparison with context-driven testing has proved thought provoking and has spawned quite a lot of discussion already, which is of course lovely to see. (Way to go, Sigge.)

One of the things discussed refers back to part of the commentary on the context-driven-testing.com website where the the guiding principles of the context-driven school is published in its original form.

At two points in the commentary following the principles, there is a statement that says that: “Ultimately, context-driven testing is about doing the best we can with what we get.” To me, there’s nothing strange or controversial with that commentary, but it can evidently be misinterpreted to include an implicit call to “accept the status quo” or “work only reactively, not proactively”. If that was true, then context-driven testers would indeed not work well in agile context. Fortunately, this is not the case. Of course, I didn’t write the commentary, but let me explain what interpretation I would propose makes more sense.

The “doing the best you can with what you get” commentary is meant to help illustrate one of the most basic context-driven principles: Context is what drives our selection of tools (or approaches, frameworks, process, techniques, etc.). We don’t force the context to comply to our favorite tools. If we enter a context with poorly written requirements, then no competent tester, regardless of label or affiliation, would say: “I can’t do any testing until I get proper requirements”. Instead, we’d do the best we can, given the situation we’re in.  Or put another way, instead of treating every problem as a nails just because you happen to love your hammer, examine the problem and try to find a reasonable way to either (1) solve the problem or (2) find a way to work around the problem until you are able to solve it. Use the WWMD heuristic: What Would MacGyver Do?

Depending on the rest of the context, in our “poor requirements” example that could include executing a couple of survey sessions, having yet another chat with the product owner or customer representatives, talking to other developers, go out hunting for other requirement sources than what we’ve been given (requirements document ≪ requirements!) or performing some claims testing… Basically whatever you need to do in order to deliver valuable information back to your team or your stakeholders. And naturally, we also work in parallel to try to improve the situation, together with our team. After all, what other alternative is there? (Apart from leaving the situation altogether and finding a new job.)

If I were to try to come to any sort of conclusion with this rambling, I would say that identifying yourself as a context-driven tester doesn’t say anything about how active a participant you will be in working with continuous improvement activities in the workplace, or whether you will just accept things as they are or work tirelessly to change them for the better. Neither does it say anything about your feelings about proactive testing activities. In fact, specific practices is not even something that the context-driven principles address. (Because they are principles! The value of any practice depends on its context!) Nevertheless, constantly trying to make a difference in the workplace, trying to get a testing perspective involved as early as possible in a project and striving to make the place we work in more harmonious and effective, is something I think everybody I know advocates, regardless of labels or affiliations.

All in in, while the context-driven community traditionally employs a somewhat different emphasis and/or perspective on testing than the agile community tend to do, they’re not incompatible. And although it has nothing to do with context-driven principles, the last thing a context-driven tester would object to is continuous improvement or proactive thinking about testing and checking.

If you think differently, then please do challenge me: Name a testing practice thought of as traditionally “agile” that a context-driven driven tester would reject out of hand, or even be unjustifiably suspicious against, and tell me why you think that is. If nothing else it should make for a good discussion.

3 Responses to Do your best with what you get

  1. Hi Johan

    thanks for this post. I too read Sigge’s post and that statement stood out to me too.

    Here’s how I look at it. When I go to test, I understand and negotiate the givens. (James Bach’s Context Driven Planning http://www.satisfice.com/tools/satisfice-cm.pdf )

    Sometimes I work with the constraints I’ve got. For example, if the requirements are poor and I have no recourse to address that, I test with this constraint. I’ll try and source information elsewhere, but I recognise this is a constraint.

    I might also recognise a test environment constraint that I’m unwilling to accept. For example, perhaps I dont have the right equipment to create a test environment, to the point where I dont feel I can test adequately. Here I’m going to negotiate and ‘drive’ the context. I’m prepared to ‘fight’ for more equipment, other wise I feel I cant do my job.

    So sometimes I accept the constraint sometimes I ‘drive’ the context. As with all testing its a matter of judgement.

    • Hi Anne-Marie,

      Good point. That we need to assess and sometimes negotiate constraints is an important thing to point out. It’s definitely part of “doing the best we can with what we get” (the givens). It might also be one of those things that get misunderstood when talking about context-driven testing, because negotiating givens would by definition work to change the context, while just accepting it (the context) with all its constraints as… constraints, could be seen as being truly “driven” by the context. I hope that doesn’t sound like a good idea to anyone though.

      Like you say, it’s a matter of judgement. Trying to draw a line between what constitutes a good or bad kind of “context-jiggling” would probably be more or less impossible, but it’s of course possible to point out a fair number of heuristic principles.

      We’ll always need to explain the trade-offs to stakeholder and/or downright protest unreasonable conditions or stupidity with reasonable arguments. The important thing is to remember to keep the project’s needs in mind, rather than our personal preferences. If we do that, we’ll probably be alright, and we’ll be serving our stakeholders instead of our own interests.

  2. Pingback: Five Blogs – 22 January 2013 « 5blogs

Leave a Reply

Your email address will not be published. Required fields are marked *