Category: Uncategorized

Agile Testing Days 2020 (and 2009)

These are some insights I had today, posted as Tweets:

And last, but certainly not least Miroslava Nikolova made me (re?) post a message on a piece of cardboard that circled around at the Agile Testing Days 2009.

I think it is still valid and covers the spirit of this very conference and the attitude of everyone taking part so well.

Here’s the plain text (and if you know who’s the original author, I would really like to know who they are):

We are a community of professionals. We are dedicated of our own continuing education and take responsibility for our careers. We support each other in learning and advancing our craft. We certify ourselves.

— Unknown author(s?) at the Agile Testing Days 2009

I thank everyone who made this day so great!

Autogenerate Path Visualisations

In the previous blog post I have described how to use GraphViz to describe a graph in a textual format and then generate an image from that.

This time, let’s do one more step and add some code so that the image gets generated automatically when the text file is updated.

For my project I use Guard, a Ruby gem that watches file system changes, and allows to define various reactions. Running unit tests whenever a file is saved is one example.

For my case, I let it generate a new image file, when a GraphViz file is saved. First of all, I installed the needed Ruby gems:

gem install guard guard-shell

With that in place, here’s the Guardfile I use to generate the images:

guard 'shell' do
  watch(/(.*\.gv)$/) { | m |
    dot_file = m[1]
    png_file = "#{File.basename(dot_file, '.*')}.png"
    command = "dot -Tpng -Gdpi=300 -o#{png_file} #{dot_file} && open #{png_file}"
    puts command
    puts `#{command}`

Note: In the code above I had to revert to enter (0xff06) instead of & (0x26) in order to prevent the syntax highlighting feature from turing a & into `&`… 🤷‍♂️

The part watch(/(.*.gv)$/) invokes the following code block when a file that matches the given regular expression changes. I am interested in files that match ‘*.gv’ in the directory that the Guardfile is stored in.

The line dot_file = m[1] extracts the file name from the parameter passed into the block, and uses it to create a _new_ file name for the image file that is going to be created.

Then the shell command is put together, logged, and finally called.

Component of the commandWhat it is/does
dot The command name that
translates the gv file into a PNG image
-TpngSet the output format to ‘png’
-Gdpi=300Set the resolution to 300 dpi
(gives a good resolution for printing)
-o#{png_file} Set the file name for the png file
#{dot_file}The name of the input file
&& open #{png_file}This appends another shell command to open the image file.
(I use this on my Mac to automatically (re-) open the file whenever it’s regenerated.)

In case you would like to experiment with this, I created as a starting point, including an example GraphViz file.

Agile Testing Days 2020

I’m really excited that the Agile Testing Days accepted me as a speaker again. This year I’ll offer two workshops, one of them at two times.

“Get The Most Out Of This Conference” is meant for newcomers to conferences in general. If you haven’t attended a conference before, this is for you. The plan is to have the first one on Monday afternoon (9th, Nov. 2020), and then to have the second go right after the morning keynote on Tuesday morning (10th, Nov. 2020). There’s a teaser video available at vimeo.

Let’s Start Learning Elixir — Together” is the second workshop. It’s two hours of looking into a functional programming language, getting started to learning it. This is scheduled for Wednesday morning. For the Elixir workshop there’s a teaser video, too.

Physics And Testing

At a number of conferences I attended in the past, people connected several fields to software development in general and testing in particular, which (at first) seem unrelated.

Since then, I pondered this for a while (read: more than 4 years). With my background in physics, I see a number of parallels to software testing. This is also a great opportunity to answer a question I get asked frequently: How did you enter software testing, given your background in physics?


Let’s start with a definition for physics:

Physics is an experimental science. Physicists observe the phenomena of nature and try to find patterns that relate these phenomena.

— Young, Freedman. “Sears and Zemansky’s University Physics: With Modern Physics”. Pearson Education.
Also see the wikipedia article on physics.

The patterns that relate those phenomena are the theories (or laws) of physics. They are models that describe an aspect of reality. None of these models is complete, in the sense that it describes everything. There is no one physical theory that explains everything. A nice view of the landscape of physical models is shown in the image by Dominic Walliman (see for details):

The landscape of physical theories, see
Dominic Walliman’s ‘Domain of Science’ video on YouTube

In physics (as in science in general), experimental results and predictions  created by models are compared, in order to find out how a model does not match observed behaviour. This is important: Experiments can only ever invalidate a model, but not generally confirm its correctness.


To me software systems are models, too: Even though they may represent reality closely, a software system is not the thing it represents.
Peter Naur described the relationship between theory building and programming in his paper ‘Programming as Theory Building’ (Microprocessing and Microprogramming 15, 1985, pp. 253-261).


My mental model of software testing is very similar to the one of physics: I see software systems as partial implementations of aspects of a real expected behaviour. In my view testing a system means it and comparing observed results with expectations.
The expectations may come from requirements (written or otherwise), previous experiences with similar systems (i.e. another web application from the same company) or other sources.

There are many approaches to testing, in a similar way to the many approaches to physics. Some of them work good in one area but not so well in another. What kind of testing is done, heavily depends on the kind of the software system: Testing embedded software used in medical devices is drastically different from testing, say, a text editor.


It is interesting to go one step further, from physics to science. The Cambridge Dictionary defines science as

the intellectual and practical activity encompassing the systematic study of the structure and behaviour of the physical and natural world through observation and experiment

With a different wording, this seems to fit software testing as well:

Software testing the intellectual and practical activity encompassing the systematic study of the structure and behaviour of software systems through observation and experiment.

The definition with a different wording

To me, many very basic principles of scions in general and physic in particular apply to software testing, too. And that’s why I think that my physics background is very helpful in software testing.

Now, I interested in this: What is your background and how does it help you in software testing (especially if your background is not in computer science or software engineering)?


%d bloggers like this: