DEWT6 announced: Communicating testing during software development

From Friday 22 January till Sunday 24 January 2016 the sixth annual peer conference of the Dutch Exploratory Workshop on Testing will take place at Hotel Bergse Bossen in Driebergen, the Netherlands. The conference is organized by Joris Meerts as conference chair, Jean-Paul Varwijk as content owner and Ruud Cox and Zeger van Hese as facilitators. The twitter hashtag for this peer conference will be #DEWT6.

The theme of DEWT6 is ‘Communicating testing during software development’. Jean-Paul Varwijk illustrates the theme as follows.

One of the goals of software testing, particularly context-driven software testing, is to supply our stakeholders with information. Often we mention how the type and quality of the information we provide extends beyond the presentation of mere metrics such as pass/fail rates. We believe that this information should enable our stakeholders to make informed and meaningful decisions on whether or not the developed software suits their needs and wants, and lives up to the relevant (quality) standards and expectations.

Much of this information, or at least what is communicated about this information, is directed towards the final stages of development but most exchanges of information happen during development itself. During DEWT6 we would like you to share with us your experiences in communicating about software testing while it is being developed. With whom did you share your test ideas and test results? How did you share it? How was your feedback received? Did it turn out the way you expected? Was it useful?

The peer conferences of the Dutch Exploratory Workshop on Testing are based on the experience reports of the participants. Therefore each participant is asked to prepare an experience report on the conference theme. Participation in this conference is by invitation only.

The DEWT peer conferences are modeled after the Los Altos Workshop on Software Testing (LAWST) and the Software Test Managers Roundtable (STMR). More information about this type of conference can also be found in Paul Holland’s Guide to Peer Conference Facilitation.

Posted in DEWT6 | Tagged , , | Leave a comment

DEWT5 Report

The 5th DEWT peer conference took place January 16-18th at Hotel Bergse Bossen Driebergen, the Netherlands. The central theme was “Test Strategy“.

DEWT5 was attended by Ben Peachey, Daniel Wiersma, Eddy Bruin, Huib Schoots, Ilari Henrik Aegerter, Jackie Frank, Jeanne Hofmans, Jean-Paul Varwijk, Jeroen Mengerink, Joep Schuurkes, Joris Meerts, Maaike Brinkhof, Maaret Pyhäjärvi, Marjana Shammi, Massimo D’Antonio, Pascal Dufour, Peter “Simon” Schrijver, Philip Hoeben, Ray Oei, Richard Bradshaw, Ruud Cox, Ruud Teunissen, Simon Knight and Zeger van Hese.
Helena Jeret-Mäe unfortunately couldn’t make it.

Below is the schedule of the conference, managed in Trello.

DEWT5 Schedule


Maaret Pyhäjärvi wrote some blog posts upfront:

Simon Knight refered to the following articles in The Testing Planet:

The collection of index cards on the DEWT5 Learning Wall.

Collected ‘#DEWT and #DEWT5’ tweets by Richard Bradshaw

DEWT5 Sketchnotes by Zeger van Hese

Not a Conference on Test Strategy by Joris Meerts

(In Response to DEWT5) – What Has a Test Strategy Ever Done for Us? A response to Joris’ post by Colin Cherry

On behalf of all the DEWT’s I’d like to thank the AST for the grant which contributed to the success of this conference.

Posted in DEWT5, Peer conference | Leave a comment

DEWT5 announced

The 5th DEWT peer conference will take place January 16-18th at Hotel Bergse Bossen Driebergen, the Netherlands. The central theme is “Test Strategy“. This version of DEWT will be organized by Philip Hoeben as conference chair, Ruud Cox as content owner and Huib Schoots as facilitator. The twitter hashtag for this peer conference will be #DEWT5.

This conference is for DEWTs and invitees only. Ruud has written the following invitation/call for papers:
At DEWT5, we would like to focus on test strategy, the set of ideas that guide your test design. A test strategy lives throughout the entire lifecycle of a testing project. It includes planning, execution, and reporting, so your experience report could describe any part of a project, or all of it. Some questions to help you focus your experience report:

  • How did the context of your project influence your test strategy? Which factors were taken into account? Which ones were deliberately left out?
  • Did you use a specific method when you created your test strategy? What did work? What didn’t work? How did you know?
  • How did you found out what was important?
  • Did you document your test strategy, and if so in what format?
  • Was your test strategy supported by the decision makers? How about the project team. If you did not document the test strategy, how did you proceed, and how did that work for you?
  • How did your test strategy evolve over time during the project?
  • Did you drop some ideas and pick up others as the test project progressed?
  • Did your approach to test strategy change as the project progressed? Were there any particular challenges associated with test strategy?
  • Was the test strategy successful? Why do you think that? How did you know?

DEWT5 is modelled after the Los Altos Workshop on Software Testing (LAWST) and the Software Test Managers Roundtable (STMR). Information about how those meetings are run can be found at their respective websites at, and Attendees are asked to prepare experience reports about the proposed topic.

So far 25 people have confirmed that they will participate: Ben Peachey, Daniel Wiersma, Eddy Bruin, Helena Jeret-Mäe, Huib Schoots, Ilari Henrik Aegerter, Jackie Frank, Jeanne Hofmans, Jean-Paul Varwijk, Jeroen Mengerink, Joep Schuurkes, Joris Meerts, Maaike Brinkhof, Maaret Pyhäjärvi, Marjana Shammi, Massimo D’Antonio, Pascal Dufour, Peter “Simon” Schrijver, Philip Hoeben, Ray Oei, Richard Bradshaw, Ruud Cox, Ruud Teunissen, Simon Knight, Zeger van Hese.

Posted in DEWT5, Peer conference | Leave a comment

Why I am context-driven – Joep Schuurkes

Why am I context-driven? Because it’s more fun.

That’s all there is to it.

Of course I could argue that becoming context-driven has made me a better tester and I do think it has. Yet it’s not the reason I became a context-driven tester. Besides, how would I prove it made me a better tester?

So no, I am context-driven because it’s more fun. Because it sees testing as an intellectual challenge. Because it allows human uncertainty to be at the core of what it is. Because it tells me that I’m in charge of what I do and how I do it. Because it encourages me to dive in at the deep end of some complex problem, trusting on my skills to get out on top and enjoying every step of the way.
And I am context-driven because there’s a context-driven community filled with people who feel the same way.

To me it boils down to this: what do I want testing to be? Do I want it to be about documents, processes and best practices? Or do I want it to be about skills, wonder and investigation? That’s not a difficult choice: I want the latter.

And now the devil’s advocate may ask: But what if it makes you not a better but a worse tester? In a way I don’t care. Testing based on skills and investigation is the job I fell in love with it. If I couldn’t do that, if I wasn’t allowed to be a context-driven tester, I do not think I would be a tester at all.

Posted in Context-driven testing, Why am I context-driven | Tagged , | 1 Comment

I am context-driven. There is no why – Zeger Van Hese


No, dear DEWTs, I did not misunderstand the assignment. The title of this series (“Why I am context-driven”) was handed to me chiseled in stone, ten commandments-style. The Moses in me chose to rearrange the tablets. I felt that the original title was asking for a justification of my context-driven-ness, as in “Why did you choose to live the context-driven life?”.

I did not choose the context-driven life. The context-driven life chose me.

Wait a second – did I just paraphrase the enlightened philosopher 2Pac in public? The point is – I don’t feel it was a conscious decision on my part. It was in my testing genes all along, waiting for me to discover it. Here are some defining moments and personal epiphanies as I recall them:

Early tester life

I arrived late to the testing party. I worked for a movie distributor specializing in arthouse cinema at first, followed by a brief stint as a COBOL developer. Those were the days! Riding with dinosaurs! Yelling commands at the compiler: “Hey you, move to Working-Storage Section! And you, Compute this, Display that!”.

In 2000, by the time I joined my first test team, I was almost thirty years old.

I was convinced it was going to be a temporary job since I was called in to go help some colleagues who were short of testers in their team. Unlike many of my team members who had chosen the testing career path, I never received any formal testing training. After all, I was only meant to be there for the short term. So while the rest of the team was being introduced to the wonders of “structured testing”, I was trying to figure out what the hell the system under test was trying to tell me – I taught myself to listen. By doing that I was able to unearth problems and loads of useful information. Right then and there I fell in love with the joy of exploration and discovery.

1st great realization:
Exploring software systems makes me feel alive

The theory

The team came back fully trained, armed with jargon and techniques. I wanted to tap into their newly acquired knowledge and listened carefully when they told stories about equivalence class partitioning, all pairs testing and different sorts of code coverage. Wow, those were actual tools of the trade I could use! The more I got to know, the more I started to like this testing thing.

Some of the best practices they took home confused me though, such as the principle to create test scripts upfront. I had just spent a couple of days discovering important problems and I asked myself: would I have found those very issues if I had created all my tests upfront? Best practice or not, the philosophy behind the whole thing seemed flaky. Why would you base your whole verification process on stuff created at a moment when you know so little about what is coming your way? Who defines what’s “best”, anyway?

2nd great realization:
Other people’s preferred methods might not work for me

The practice

A few months of testing turned into a couple of years, and I was lucky enough to work on different product teams across various industries. It wasn’t easy to find time to explore the software as I used to, because most of these teams had a testing methodology in place with lots of procedures, templates and test scripts designed upfront. I ended up doing most of it under the radar: when developing scripts, I found out I was exploring to make them the best I possibly could; when executing scripts, I was exploring on the side because it seemed silly to only stay on predefined paths. It never failed to find important problems. I felt that all of testing was infused with exploration. I thought it was all just common sense. People just looked at me funny.

3rd great realization:
Exploration is at the heart of all things testing

4th great realization:
My common sense is not other people’s common sense

The reality check

When I got the opportunity to lead a team of testers through an important new release, I grabbed it with both hands and welcomed any guidance I could get. People I highly respected advised me to stick to the procedures and templates with this one, as it was a unique pilot that shouldn’t go wrong. They spoke from experience, since “we used this approach in all our projects and it always worked” (emphasis theirs). I thought that was a bold claim (always? for all of them?), but I decided to give it a go.

The results were less than stellar.

The project came gift-wrapped with spectacularly detailed requirements – the user interface specifications document alone was as thick as a phone book. The software was not ready yet, but we used our time well, churning out elaborated scripts like there was no tomorrow. When the software finally arrived, it looked nothing like we had envisioned it. As a result, our scripts turned out to be brittle and trivial. On top of that, the whole team was getting desperate, bored and tired of following scripts while they felt they could do much more valuable work.

5th great realization:
Context eats strategy for breakfast

6th great realization:
If testing is boring, I’m probably doing it wrong

Our project manager asked for pass/fail rates, bug- and test case metrics. I proposed to rather give him an analysis of the most important problems, but he insisted on getting the numbers. Once these numbers got out, people started altering their behavior. It was the first time that I witnessed the counterproductive potential of metrics.

7th great realization:
Not all metrics are useful – some are dangerous

When the project manager wanted extra graphs for his report, I duly delivered. Three weeks later he was asking me to tweak these graphs to make the situation look less dramatic. It became clear that we had different intrests – I assume his targets and reputation were at stake, while I was concerned about my integrity and credibility as a tester. I wanted to help him, but it felt as if every muscle in my body was resisting.

8th great realization:
I value my integrity

The revelation

In 2003, a co-worker approached me with a big grin on his face, saying “Check this – you might like it” as he threw a conference handout on my desk. A whole presentation on something called “exploratory testing”! Was this for real!? Turned out that it was. Even better: it described my favorite part in testing – the part that seemed so natural to me – as a recognized testing approach. It even had a proper name!

I wanted to know more and started reading everything I could get my hands on. This quickly led to Cem Kaner and James Bach, who championed exploratory testing as a sapient approach involving simultaneous test design, test execution and learning. All their work appeared to be rooted in science, and well thought out. And it wasn’t just theoretical thought-exercises either, they actually gave plenty of pointers on how to do exploratory testing well and how to make it more manageable.

They called it a martial art of the mind, scientific thinking in real time. They did not only make it sound cool – they also put effort in dismissing the common criticism of it being unstructured, asserted that it can be as disciplined as any other intellectual activity. When they stated that virtually all testing performed by human testers is exploratory to some degree, I knew I found my tribe.

9th great realization:
I am not weird – other people think alike

The homecoming

It was almost inevitable that I would cross paths with context-driven school of testing. Although that only happened years later, it was a kind of homecoming.

I discovered a vibrant community, a bunch of skeptics that rejected the idea of best practices, didn’t take anything for granted and were serious about studying their craft. They looked outwards, not only inwards, drawing from sociology, psychology, even philosophy (which was music to my ears – it matched my own tendency to look for testing lessons outside the field of testing).

Members of the context-driven school pointed to Thomas Kuhn’s “The Structure of Scientific Revolutions” to explain how it is possible that different groups of people – although they all claim to be studying the same field of practice – are using such radically different ontologies to describe it. The different schools of testing all have different paradigms, different goals and value different things (which in hindsight explained why I sometimes felt so alienated from other testers – and they from me).


Years have passed and although a lot of things around me (and probably inside me as well) have changed, I am still part of that community. It has become my touchstone for new ideas and my first line help desk when struggling with testing problems. It’s peers like this who encourage me to continuously learn and stay on top of my game.

I am aware that there are significant drawbacks to surrounding yourself with too many like minded people, so I try to engage with people who are willing to ask the hard questions and challenge my beliefs, even when they don’t necessarily disagree with me. The good thing is that there are plenty of those to be found in the community, but I constantly remind myself to have an open mind and to keep interacting with people outside of it as well.

That community is by far the most visible (and audible) part of context-driven testing, but it is not the reason why I consider myself a context-driven tester. As I mentioned above, it was not a conscious choice. Rather, it is how I make sense of the testing world around me. I consider it a value system: my personal set of morals, ethics, standards, preferences and world views that constitute my DNA as a tester.

So yes, dear DEWTs. I’m context-driven. It is baked into my system. There is no why.

Posted in Context-driven testing, Why am I context-driven | Tagged , , | Leave a comment

Why I am context-driven – Ray Oei …. I think…..

This is my blog in the series “Why am I Context-driven”. In this series every member of DEWT writes a personal story on why he or she is context-driven.

That is the line the contibutions have started in this series. My first thought was to change that in: “Am I Context-driven?”. Because there are a lot of questions that need to be answered to explain that…
What /is/ Context-driven?
What does it mean to /be/ Context-driven?
What does it mean to be /part of/ the Context-driven community?
What means /the/ in the sentence ‘the Context-driven community’?
What is a community?
What is context?
Is there a reason to write context with a capital?
What is…?

And I could go on for a while.

When I started testing, by accident in a way, there were a lot of questions running through my mind. At my first serious testing challenge it could have looked a bit like this:

How /should/ I be doing /that???
– who decides what is good?
– who’s opinion should I take into account?
– who has the answers?
– what does my manager want from me?
– in what way can I be wrong?
– how am I going to prevent to be wrong?
– what is wrong about being wrong?
– where can I learn to do it right?
– why would I supply that?
– why wouldn’t I supply that?
– what is the problem (here)?
– why would I bother?
– why would anyone bother?
– what is right anyway?
– what is it what I want to say?
– what is it what I mean?
– what is it what I want?
– I don’t want to fail…..
– …….
– what /is/ failing anyway?
– who would care?
– …
– wait, …. do I see a pattern here??????

I have written before what led me to this point: here. And why I started the discussion what led to DEWT (here). So I am not going to re-itereate that.
But that still doesn’t answer any of those questions. Some of the critics (here and here both in Dutch) find most of what we (“what is /we/?” “Who are /we/?”) vague or obvious or not interesting. That is ok. Despite of what some of us (“who is /us/?”) say or seem to imply: there is no ‘best practice’ of being ‘context-driven’. Some of the discussions have culminated in a fight over ‘wrong’ and ‘right’. In essence – I think – it is about ‘following the rules’ versus ‘investigate and see what can be learned’. The latter is something that appeals to me the most, being from a scientific background. So many times questions like: “is it useful?” “What information does that provide?” “To what purpose should I be doing this?” have gone through my mind at some time.

So why write this in the first place? One of the important foundations for this community is to share. Share knowledge. Share experiences. Share thoughts. And discuss them. Learn from them. Change your ideas when information compels you to. Be critical. Accepts that others might be (very) critical. Try to learn from that too. About the craft. About yourself. About the world. And use that in your work.

This community helps me to do that. With people who expect critical thinking. Who don’t provide the “right” answer. Who provoke (which I wouldn’t do that easily). Who get me thinking. Do I agree with all of what is said? Does that really matter? To whom? And sometimes I am doubting whether I am ‘context-driven’. But do I have to be?

I can see why some people have problems with ‘us’. And I think that is something we should learn from. We can be overbearing at times. Know it all’s. Seem to be a closed group. And sometimes it is difficult to separate the message from the person. I should not speak for others. I myself don’t really like being too direct. Or at the front of the stage. It’s uncomfortable, to me. So am I still context-driven then? Are people hesitant to join the community because it feels too much that you can only belong if you are like ‘that’? (“What is /that/ exactly?”). We also need to be self critical. We can (and should!) learn and sharpen our ideas when we are confronted with other opinions. Are we vague? We don’t intend to (no really: we don’t!!) but we are perceived that way sometimes. So we should work on that. Well… no, I should work on that.

I try to learn. I share what I have learned by teaching others for free (here and here). I coach testers for free (here). They learn from me, I hope. And I learn from them. What I do right ánd what I do not so right.
So what does it mean to be context-driven? Can you only be context-driven when you call yourself context-driven? I know a few very good testers who explicitly do not consider themselves to be ‘context-driven’. Are those people less as testers? I don’t think so! /I/ consider them to be a part of the ‘context-driven’ philosophy. They are critical thinkers to start with…

So it might be /that/ that appeals to me the most: ask questions. Investigate. Discuss. Try to find answers with the information you have. Re-investigate. Lean. Learn. Learn…

Posted in Context-driven testing, Why am I context-driven | Tagged , | 2 Comments

Why I am context-driven – Philip Hoeben

This is my blog in the series “Why am I Context-driven”. In this series every member of DEWT writes a personal story on why he or she is context-driven.

A natural phenomenon that appeals to me.

How obvious it may seem, first of all I want to point out that testing is part of a society where it functions. It’s not some form of alienated stand-alone discipline. One can notice a lot of similarities happening in the test world with things happening outside of the test world. It is not surprising that there is such a thing as a context-driven community, because it is a manifestation of what happens in society.

For instance, have a look at this article: It’s about the PISA (Programme for International Student Assessment) tests, the introduction of a standardised curriculum, and the criticism on it. I don’t think I have to elaborate that these debates are also going on within the test world. Just think of the vivid discussions about the value of certifications.

Or have a look at:  Audrey Watters who writes a lot about ed tech on her blog, elaborates inspiringly about the effects of technology in education. When reading her blogs it is not hard to see parallels with the test world. She points out on her blog “Robots and education labor” that education is about gaining skills and not job training and career readiness.

My own take on education and the ‘joy of learning’ is that I want to dive into areas of my own interest, developing my own learning path, shaping my ideas in a way I choose. I don’t have any need to give an answer somebody expects me to give, which can be falsified anyway, as has been demonstrated both within as outside of the test world. It’s much more important to show skills in reasoning behind the answer. The context-driven school emphasizes on showing skills and being able to explain your reasoning.

Solving actual test problems.

I value one model over another when that model gives more insight in a topic. When I started to read about testing, at some point, I realise which model I value most.

Why the context-driven model?

When you want to learn about testing you have to study what testing is about and what happens during testing, because testing only happens when somebody is testing. We have to study this ‘act of testing’. Looking at testing with the stance of a detached observer can give illusory pretensions of what testing is, since only artifacts are the objects of study (test cases, test techniques, test plans, test processes etc.).

You interact with the software by using and manipulating the software as a human being. Your whole history (e.g. knowledge, experiences) is brought to your testing.

Wow, isn’t that great!

The context-driven community focusses on the human aspects of software testing and studies phenomena like interpretation, understanding and observing. By addressing it and showing the importance, you can actually study it.

Improvements in testing

As said before, I value the context-driven model most. I am convinced that in the future problems will rise that cannot be addressed by the context-driven model. As long as I don’t know or have any model for that or as long as a new model is not relevant, I stick to context-driven testing.

Improvements in testing are not related to security, big data, mobile, more or less or less is more automation, TMMi level x or other tech trends. Improvements in testing are about refining or redefining a model that challenge ideas that became common, and fits better in the ever changing society. Context-driven testing, and for example also agile, didn’t come to life because of tech trends, but through a different view on a subject. I don’t think tech trends will help us refine or redefine a model for testing. I believe context-driven testing is currently the only model which redefines and refines software testing. And for the good!

That people thing and the community

Of course there is a community of people saying meaningful things. Those people that are willing to help without presenting a one size fits all solution. I enjoy being with them and like to read their stuff.

It’s a truly inspiring community!

Posted in Context-driven testing, Why am I context-driven | Leave a comment

Why I am context-driven – Simon ‘Peter’ Schrijver

This is my blog in the series “Why am I Context-driven”. In this series every member of DEWT writes a personal story on why he or she is context-driven.

Officially, I started with testing in 1997. Looking back to my career, I can say I started with testing when I started my professional career back in the eighties. All the jobs I did before 1997, I had to deal with some serious test work. I only did not realize I was doing that. That period perhaps made me the tester I’m today. I always look for problem situations, look for situations where things could go wrong, how the system did behave at that moment.
I learned testing from 1997 to 2003 by just using common sense. Next to looking where things are okay, I looked for problem situations. In that period I was working for a large telecom network systems provider and we were testing network systems and network solutions. We always had to introduce errors in the environment and look how the solution reacted, responded. We found some serious problems in these days.

I kept on going with this mindset for all my test assignments with other companies. The time I started as an independent tester, I needed to take care of my own education. I decided to go to conferences. There I came in contact with people like Michael Bolton, James and Jon Bach at STAR East in 2007. What they were talking about got me interested. Perhaps this was the push in the ‘right’ direction.

I got in touch with CDT when I registered for the CAST 2011 conference. This conference was organized James and Jon Bach with the theme “Context Driven Testing” and it was an epic event. Some of the presentations given there were great. Markus Gärtner gave a presentation about self learning that really triggered me to do more with my test career. I was already working on improving my testers skills, but that were certificate focused classes instead of skill training. From the moment I left the conference, I said to my self: “I want to be a context driven tester. What do I need to do?”

I joined Twitter to follow the stories of other testers. I started reading blogs and books. I tried to find means to use CDT at my work. That was not easy sometimes as I worked in an environment with classical trained people focused on processes with pre–scripted test cases and pass/fail graphs. Luckily, the projects I did, I was able focus on what was really important in the context of my stakeholders.

Let me give an example of a project I did some time ago. It was a replacement project. The development team wanted to built software using SCRUM. There was only one strange thing they wanted. They wanted to deliver the software to my acceptance test team in three big deliveries. My reaction to this was as follows:
“If you want to do Scrum as a development approach and you deliver the SW in three big deliveries to me, each containing 8 features (i.e. data streams for billing and fraud systems), why are you doing Scrum? I want for every feature a separate, dedicated delivery plan.”
The next question I got from the project team was, “what is your test plan, how many test cases do you have?” After some discussion I told them, “I have one test case. I want to see that the data stream on the test environment produces the same output compared to the production environment.”
By having this attitude, I convinced my stakeholders I was serving them well.

As a tester I look for solutions which serve my stakeholders. I learn new practices which are useful at that moment risking I will never use them again. That is a risk I’m willing to take.
Further, I share my experiences with people I meet at conferences and/or via my blog.

I like to end with a few lines some of you probably recognize (if you are a Trekkie).

Space, the final frontier
These are the sessions of the context driven tester
Its unchartered missions
To explore undiscovered areas
To seek out for bugs and new information
To boldly test where no one has tested before

I hope you will join me on my journey.

Posted in Context-driven testing, Why am I context-driven | Leave a comment

Why I am context-driven – Joris Meerts

We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.

T.S Eliot – Little Gidding

Any theory that can account for all of the facts is wrong, because some of the facts are always wrong.

Francis Crick

I was introduced to the context-driven community when Shmuel Gershon invited me to a soiree in Copenhagen, during the EuroSTAR conference in 2010. This invitation was based on my work on the history of software testing, the importance and purpose of which I was largely unaware of at that time.

I do not claim to be a context-driven tester. However, I am drawn to view of testing that is entertained by the context-driven community. Currently, there is no other school of thought in software testing that provides the same kind of energy and excitement, willingness to explore and at the same time the willingness to confront ourselves with the conditions and predicaments of our craft.

Software testing is an act of investigation. This is the constant factor in software testing. The reason why we conduct this investigation, the means by which we conduct this investigation and the degree of success of this investigation differs from project to project. From this it follows that there is no single technique, no single approach, that can universally be applied. It also follows that an attempt to apply universally a single approach is bound to diverge constantly from the purpose of the software development effort. Regretfully this means that there are techniques or tools that I mastered and like, but may never apply again. It also means that there are other techniques and tools that I must learn in order to be able to do my next job.

The constant factor from project to project, is to develop an understanding of how to conduct an investigation and how to act in a way that is relevant to the project. This is by far the most difficult part of software testing. Software testers have to develop a sense of awareness and ways of reasoning to assess themselves, their team, the project, the company, the customers and, perhaps, taken to the very extreme, the society in which the software plays a part. Context-driven testing studies the ideas and tools that aid reasoning, observation and experimentation. As far as I am aware, the school of context-driven testing is the only school in software testing that actively pursues the application of these academic areas in software testing.

On the other hand, context-driven testing may very well be a product of its age, just as methodology-driven testing is a product of a firm belief that industrialization and standardization will eventually lead to success in software development. The age in which, in my opinion, the roots of context-driven can be found, spans the 1940s to the 1970s. As far as I have been able to assess, in this age the seeds of developments in rather young scientific disciplines were sown; disciplines that influence software testing today. Parts of systems theory were developed by Kenneth Boulding in the 1950s, cybernetics by Norbert Wiener in the 1940s, information theory by Claude Shannon in the 1940s, game theory by John von Neumann in the 1940s, complexity theory by William Ross Ashby in the 1950s, system dynamics by Jay Forrester in the 1960s and social systems theory by Talcott Parsons in the 1950s. It is my personal feeling that, in order to meaningfully contribute to software development, software testing should study the aforementioned areas first, and only after that start fussing about condensing the outcomes of experiments (‘test cases’) into simplistic binary representations.

There are many other developments in this age, particularly in cognition, language (Chomsky comes to mind), art and anthropology that may prove useful in software testing.

In the Netherlands, whenever there is a discussion of ‘European testing’ versus ‘American testing’, contrasting methodology-driven testing and context-driven testing, I like to jokingly elucidate that actually context-driven testing is fundamentally an Austrian invention. As ‘evidence’ to support my case I use the books Against Method by Paul Feyerabend (1975), General System Theory by Ludwig von Bertalanffy (1968) and the Logik der Forschung by Karl Popper (1935), books that contain ideas that influenced context-driven testing. As you can guess all of these authors were born in Austria.

I should probably mention that I have not read Popper’s book. Naturally, the book is in my library, because I feel that the chapters on falsifiability, empiricism, testability and probability will some day serve me well.

Much of this comes down to an understanding of what software actually is. I feel that software testing as a craft should develop such an understanding, not on the basis of wrought iron processes or convoluted models, but out of a naturalistic investigation, by looking at software as it is. This is the capability that we lost in the past couple of decades. I hope context-driven testing can regain it.

Posted in Context-driven testing, Why am I context-driven | Leave a comment

Why I am context-driven – Jeanne Hofmans

This is the third blog in the series “Why am I Context-driven”. In this series every member of DEWT writes a personal story on why he or she is context-driven.

After graduating from my study in Software Technology I started to work as a tester. The reason? Although I liked to program, I enjoyed designing and testing more. Agile development was not yet a common practice and I knew that solely programming at my desk would not make me happy. I simply loved (and love) talking to other people: discussing strategies and questioning features. As a tester I could do just that. In my opinion testers play a central role in projects. As a tester I would need to communicate with designers, with the business, with developers, with project management, with QA, etcetera. Also I liked the act of testing. When other students had finished their work, I could not resist to ask: may I? After which I tried to ‘break’ their program. So I decided to make testing my career.

Choose a job you love and you will never have to work a day in your life. – Confucius

On the job, working for several clients, I really learned a lot about testing. I saw how some things worked and some things did not. Sometimes paper and processes seemed to prevail over people and skills. That bothered me. For example when a risk analysis had been performed but was not actually used. Why spend time on the risk analysis in that case at all? I experimented with performing risk analyses and the way to implement a risk based strategy. One day I was discussing this with my colleague Ruud Cox. After that in-depth discussion he asked me if I would like to attend DEWT once. So I did.
At DEWT I found a group of people passionate about testing. Discussing all kind of aspects related to testing appealed to me. So I joined DEWT. At DEWT I learned about context driven testing (CDT). I really liked some of the principles of CDT, like the focus on people, skill and also playing with the product.

  • People: Jerry Weinberg’s definition of quality: “Quality is value to some person” clearly indicates the importance of people in quality and testing. Products are made by people and are to be used by people. Thus understanding people and interacting with people, asking questions, makes us better testers.
  • Skill: Several skills are of importance to testers. From general communication skills to being able to use several heuristics and test design techniques (as seen suited!)
  • Play: The ability to play makes us, people, different from a computer. Playing with the product helps us understand the product and find bugs that we otherwise would not find. Playing is also about fun.

Pleasure in the job puts perfection in the work. – Aristotle

Basically all of these are about continuous learning. Learning by reference (discussing with peers and people having other viewpoints and backgrounds), learning by exercising, and learning by reading. Once you are more aware of possibilities and pitfalls, you can make better choices for your testing. As every project is unique, the solution to testing is also unique. And that is why I am a context driven tester.

Posted in Context-driven testing, Why am I context-driven | Leave a comment