12

One of the more interesting dichotomies for testing is the contrast between trying to get standardisation across individual testers vs. applying context driven techniques that allow testers to apply the appropriate testing method to the context in which they are testing.

Does anyone have any advice on how to encourage and educate about context driven testing?

I am concerned that I don't want to introduce the concept and have it descend into a situation like "Agile" development which has become an often misused term to mean "no process at all and everyone just does what they feel like".

Pierre.Vriens
  • 145
  • 1
  • 1
  • 11
Bruce McLeod
  • 9,750
  • 5
  • 33
  • 73
  • Hi Bruce, can you please elaborate on what you mean by "get standardization across individual testers?" I have been in the industry for more than 2 decades and I have never heard of an effort to get testers to standardize on a set of techniques or approach all testing projects from a singular perspective. – Bj Rollison Aug 23 '11 at 15:23
  • I hear you about "Agile"! I sincerely hope what I'm living right now is just a phase in getting to real Agile - or even something moderately close to it. Favoriting this, because I definitely want to learn more about context-driven testing. – Kate Paulk Aug 23 '11 at 19:01
  • @BJ Conceptually by "trying to get standardisation across individual testers" I mean having a wide range of testers across an organisation be able to apply varying approaches, ideas and tools yet still talk a common language and have some consistency in the way they all approach testing. e.g. A severity 1 bug and unit testing means the same thing to everyone. – Bruce McLeod Aug 24 '11 at 08:40
  • @Bruce, this seems to imply that people who call themselves "context-driven testers" and who work in the same organization don't have common jargon for describing sev 1 bugs, or understanding what a unit test is. – Bj Rollison Aug 24 '11 at 15:59
  • @BJ that is not the intent ... I meant to contrast a whole heap of testers & non testers who make up their own meanings and don't have a common language. Just as one example. – Bruce McLeod Aug 24 '11 at 20:43
  • It's tricky; one never knows for sure when a common language is truly spoken and heard in common. You could publish a glossary, for example, but can you be sure that someone has read it? If they've read it, do any two people understand it in the same way? If you want to address this issue, continuous conversation and astute observation would seem, to me, to be very important. Collins' Tacit and Explicit Knowledge suggests that repetition is important to transmit "strings"; variation is important to transmit meaning. – Michael Bolton Sep 06 '11 at 20:17
  • Isn't this the same across all disciplines? You need guidelines to prevent people from reinventing the wheel with every new task, but you need to give workers latitude to get the job done without inventing a slightly different wheel for every different task. That's why experienced workers and skilled managers are so important: they can strike the balance between creating new wheels and using old ones. Now if only they could give us better metaphors than wheels... – corsiKa Aug 28 '12 at 14:20

3 Answers3

9

You might try these things.

  • encourage people to think about the last time they consulted a testing standard or a canned process document and found it even remotely important, helpful, and useful
  • ask people if they would use the same approaches to testing a medical device, vs. a game, vs. a financial institution, vs. an online dating service
  • ask people whether they would use the same communication style with a folksy, friendly programmer and a very capable but brusque prima donna
  • point people to http://www.context-driven-testing.com, and question the principles for yourself, and encourage others to question them too. Note the explications that follow the principles.
  • have people go through the BBST's foundations and bug advocacy courses, which work on some of the issues you raise in depth.
  • In all of this, it starts with you sharpening your own recognition and understanding-- your own study.

---Michael B.

Michael Bolton
  • 224
  • 1
  • 2
1

In response to BJ Rollison:

To name but a few attempts to get something that I'd call "standardization across individual testers":

http://softwaretestingstandard.org/ http://www.tmap.net/Home/ http://www.tmmifoundation.org/ http://istqb.org/display/ISTQB/Home

---Michael B.

Michael Bolton
  • 224
  • 1
  • 2
  • That's interesting because your perspective on standarization seems to be different than Bruce's. Besides, these things don't attempt to create standardization across "testers" as much as standardization among some testing processes. – Bj Rollison Aug 24 '11 at 09:01
  • 1
    In fact they create neither, but they sometimes successfully create the illusion of one or the other. – Michael Bolton Aug 29 '11 at 10:17
  • Perhaps not, but often someone's perception is their reality. So the percieved value that some orgs get from standardizing on jargon such as "unit tests" is of more value than having everyone argue whether or not equivalence partitioning or creating logical groupings is a figment of someone's imagination. – Bj Rollison Aug 30 '11 at 02:41
  • Oh, I agree with that. In that context, perception is reality. But let's not make the mistake of complying with the idea that that has anything to do with testing. That, as Feynman would have put it, is simple public relations.

    Have you had a look at Harry Collins' Tacit and Explicit Knowledge yet?

     – Michael Bolton Sep 06 '11 at 20:10
0

The education process depends upon the individual. For some testers, it will suffice to point them at a stack of web pages, refer them to a book, or send them to a course.

For others testers, the best approach may be to spend a day (or a week) testing with them: let them drive, but give them suggestions on what to try, and take the time to explain your motivations. This requires a time investment, and you need the right rapport: the teacher needs to be patient, a good communicator, and aware of their thought processes, and the student needs to be patient, inquisitive, and open to learning from the teacher. In the right circumstances, this can be a powerful and productive technique. (I once taught a young developer how to debug this way. It was one of the more gratifying moments of my career.)