the testing curve

my learning curve in software testing

Yet Another Testing Model: Value – Information – Processes – Tools

During Let’s Test 2012 some ideas clicked in my mind with the result of yet another testing model:
Value – Information – Processes – Tools.

For me this model really is a culmination of being part of the context-driven testing community. If you have been reading about context-driven testing, I’m sure you’ll be able to spot plenty ideas I stole from others. ;-) So thank you so much to all of you!
Secondly, I have trouble believing I am the first one to come up with this simple model – although a google search didn’t turn up anything. (1) So if any of you know of similar models, please leave a comment!

And now to the actual model. Since you can’t have a model without a drawing, here’s a not so spectacular one:

Value - Information - Processes - Tools

Value is worth, usefulness.
Information is thoughts, ideas, questions, etc.
Processes are everything that happens: thinking, reading, talking, testing, etc.
Tools are stuff. Pen and paper, requirements document, charters, heuristics cheat sheets, etc. And people are also tools (no pun intended) (2).

Ok, now on to a simple example. Let’s take a look at you reading this blog post.
This blog post is a tool, a communication tool. It’s a specific configuration of pixels on a screen that can be interpreted as a set of letters in the Latin alphabet which can be read as a text in the English language.
Which brings us to the process part: you reading and interpreting it. Without you doing this, this blog post is just a set of pixels. Without a process the tool doesn’t do anything.
This process results in you getting information: your interpretation of what I wrote and your ideas, thoughts and questions based on that interpretation.
And hopefully this information is of value to you in some way.
That’s all there is to it!

Let’s continue with an example that actually has something to do with testing: defect management.
The most typical tool of defect management is the bug tracker. It can be an expensive tool, an open source-tool, a set of sticky notes or a list in your head. The processes involved are quite obvious: creating, reading and updating entries. The information (Remember that this information is not what’s in the tool; it’s an interpretation of what’s in the tool.) consists of what the defects is about, its status, who is supposed to something with it, etc. Finally the value is keeping track of the defects: defects should be fixed and/or registered, not forgotten.
However, that’s not the whole story. Keeping track of defects is of value, but we can also see it as a tool. By keeping track of the defects, we can analyse their current status. This gives us information about how the testing is going, how many issues there are with the product, what kind of issues there are and are not, etc. This information is valuable because it allows us to change our test approach if needed.
So as this example illustrates, often it’s possible to build one VIPT pyramid on the other with the value becoming the tool.

One of the most inmportant things to note about this model is that only tools can be actual things, objects. Processes are events; they occur. Some processes are observable; some are not. Information exists only in your mind. And so does value. Of course, you can use the tool of speech in a process of communication to share information about why you find this VIPT model valuable. But all I would get from that is the value of my interpration of what you said. I do not get your information or your value.
Or to put it differently. It’s possible to share a tool: I can give you the requirements document. It’s possible to partly share a process: we can review the requirements document together. It’s possible to share filtered information: you can interpret what I say. It’s possible to share translated value: I can tell you what I find valuable.
So basically, what we care about is value, but all we really ‘have’ are tools. And to get from tools to value, we need to go through processes that generate information. This distance between tools and value can make a life as tester a bit complicated sometimes. This problem is what part two of this post will be about.

Please post any questions or remarks in the comments! I am sure the model and its explanation can use some refining.

— — —

More on VIPT here:
VIPT Intermezzo – Models and the Unix philosophy

VIPT – bottom-up or top-down

VIPT – how to teach software testing

— — —

(1) This may have something to do with me heavily leaning on Kantian epistemology to simplify the model, though. (If you want to learn more about Kantian epistemology, reading Schopenhauer is a good start.)
(2) Of course one should remember Immanuel Kant’s admonition here always to treat people as ends in themselves, never as mere means.

5 responses to “Yet Another Testing Model: Value – Information – Processes – Tools

  1. Pingback: Five Blogs – 11 July 2012 « 5blogs

  2. Neil Thompson July 14, 2012 at 7:44 pm

    I don’t know whether or not you were in my talk at Let’s Test (slides are at ), but I have been thinking along similar lines to you. My model is slightly more complex than yours I’m afraid, and (notably) 3-dimensional! I tried to paste a diagram (png) in here but it looks like that’s not allowed.

    If you had googled “Value Flow ScoreCard” (no reason you would have done that *as such*, of course), you would have found in .That was written (with Mike Smith) for a largely traditional audience but from my perspective at least was trying to build a bridge to context-driven, and exploratory in particular, whether the context was agile or not. Since then I have been on the Problem-Solving Leadership course and attended an AYE conference, and I wanted to integrate my enhanced learnings and outlook into a coherent whole (for myself, at least), integrated with my current worldview. The result, so far, was that Let’s Test 2012 presentation. I’m reasonably pleased to see that googling “value flow” currently brings that in at the top of page 2.

    I aim sometime to produce an animated gif which shows progress starting at the centre from congruence (self, others, context) then flowing out (via the “ScoreCard”) and via systems thinking, then to emergence of new capabilities, all supported by (the 3rd dimension) scientific method underlain by selectable / hybridisable / inventable techniques & tools. That seems to fit your (note 1) Kantian admonition – except that I *start* with the people; the idea is that the benefits then feed back to the people, in a value-adding way (virtuous circles).

    But in my model people are *not* also tools (your note 2), rather they are users / improvers / inventors of tools. I’m not sure if that fits Schopenhauer or not – I would express his pessimistic view the other way round – optimisation (hopefully) never ends.

    I’d be interested in any comments you have, and keeping in touch.


    [Joep’s reply: Hi Neil, thank you for your comment!
    I’m afraid I wasn’t at your talk at Let’s Test. So I checked out the links you posted and the similarities between your Value Flow Scorecard and my model are quite plain to see. (Although you qualifying your full model as “slightly more complex” is a bit of an understatement. ;-)) As per your reference to “Test is dead.” and Scott Barber’s response to that, the testing community needs to have a good story about what value testing can deliver and how we think of doing so. And that story needs a solid foundation, so let’s indeed take all we can use from philosophy of science, psychology, etc. Sometimes I get the impression that most problems in software testing have already been solved; we just need to find it in a field of study that has encountered a similar problem.

    You are probably correct that one of the biggest difference between our models has to do with the ‘people are tools’.
    My model borders on solipsism. There is a world ‘out there’ with objects. One interacts with it. This results in information. So it’s very much a model of a person locked up inside his/her own mind. If there’s a cup of coffee on the table in front of me and I move it (interaction), one could say I changed the state of the world. But that sate of the world as such is not accessible to me, only the information about it through my human faculties of knowledge are accessible to me. So one could argue it’s irrelevant if I changed the state of the world, what matters is that I changed the information I have about the state of the world. In my opinion, this benefits of this simplification outweigh its dangers. (Most solipsists can be cured with a slap in the face: if the world exists only in their head, the just slapped themselves.)
    In that respect your usage of congruence, value flow and systems thinking is a lot more respectful to people. And it allows you to talk about projects and software development as a whole – with people interacting with each other in complex ways.
    I’m not sure what to think of this difference in scope, though. Does the difference matter? If so, how and why? Is it possible to combine the two models in some way? Why would you combine them? As an experiment, to create a hybrid model, …
    Guess I have some more thinking to do. :-D So thank you very much for sharing your insights!]

  3. andersdinsen July 16, 2012 at 12:14 pm

    Hi Joep
    I really like your model, which I think, resembles models of many things. E.g. it could also be a model of the complete product development process.

    There are four things I like about it:

    1. The fact that you put value on top. We’re here to create value. That’s actually an important statement in testing, which is often spoken about as a ‘destructive’ process (I even like to talk about it as such, it’s fun telling people that you “break software” for a living). But we’re here to create value.

    2. That the model can be embedded in a cycle. We create value, and we can convert the perceived value to money which we can use to buy ourselves new things: Tools/objects – food to live from for that matter!

    3. That you’re giving us abstract levels we can use to group “stuff” into: Tools are tools, processes are heuristics and test cases for example, information are bugs, test results etc.

    4. And that these abstractions are “real”: I.e. information are not the words written – you’re talking about the tacit knowledge related to the information stream/string.

    Do you have any good ideas on how to use the model e.g. for understanding testing in new ways or structuring it more efficiently (improving generated value)?


    PS: I laughed my pants off reading your comment about how to cure solipsists! :-D

    [Joep’s reply: Thank you for your comments, especially for no.3! To be honest I hadn’t looked at it that way yet: heuristics, test cases, bug reports and test results are just tools. But it is indeed true that heuristics and test cases have more to do with processes than with information and with bug reports and test results it’s the other way around. Hmm… there might be more to this. Need to think about it.

    And I have a few ideas on how this model can actually help one in testing. More on that in a post I intend to finish tomorrow!]

    • andersdinsen July 17, 2012 at 5:47 am

      Sounds great, I’ll be looking forward to your next post (by the way, being a unix fan, I also liked your other post about simplicity).

      About heuristics being a process or a tool. If you’re teaching me a heuristic, then yes, I have it as a tool, I can apply to my testing. However, if I’m tacitly using a heuristic to find bugs in a product, I’d say the heuristic would be best characterized as a process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s