Author: Stephan

About Stephan

I'm a self-employed software tester. I test and write software, listen to music and go hiking — sometimes simultaneously. Prior to this was a physicist and oceanographer, among other things.

A Year of ‘Explore’

At the end of last year, I decided I would not make any new year’s resolutions in favour of selecting a ‘word of the year’, see the blog post from early 2013. I picked the word ‘explore for 2013 and since the year is (nearly) over, it’s time to look back and see how it worked out.

The Black Box Software Testing Courses

At the time of this writing there are four BBST (Black Box Software Testing) courses the Association for Software Testing offers:

  1. Foundations
  2. Test Design
  3. Bug Advocacy
  4. Instructors

I took the first three of them in the first half of 2013, and the last one in October. And while I do recommend taking these courses, I have to say that I needed a good amount of time to work through all the material, labs & exercises. Especially the ‘Test Design’ course offered a phenomenal amount of material.

I totally recommend these courses to everyone working in software testing and software development in general.


For a while now, I try to go to two conferences each year, a programmer conference as well as a tester conference. I used to recommend this to my fellow ‘programming tester colleagues’, but now I’ve also started to recommend it to the ‘testing programmers’ as well. While I focus on software testing, I find it useful to know a bit about programming, too.

I hoped to be able to go to the EuRuKo (European Ruby Conference) in Athens, Greece in summer. In the end it didn’t work out as planned and I couldn’t go. However, I gave my ticket away and received two post cards in return. Thank you, you know who you are.

In September I attended the BARUCO, the ‘Barcelona Ruby Conference’ in Spain, and in October I went to the Agile Testing Days in Potsdam, Germany. At both conferences I gave short presentations about testing and the two values of software. Furthermore, at the Agile Testing Days I had the pleasure to assist Lisa Crispin and Janet Gregory at the  beginning of their keynote presentation:

A remark: The BBST Instructors course and the Agile Testing Days overlapped a bit. If you can, I suggest to avoid a commitment like that. Although it did work for me (in the end), this is a way of exploring, I’ll avoid in the future.


Early this year, I wanted to try some rather short software testing projects and joined uTest (now renamed to be Applause), where I worked on several apps for mobile devices as well as OS X. Given my background with longer running projects, having just a few days for testing was a refreshing experience. I also joined a project using Calabash to automate testing (well, checking actually) on Android devices.

In late June I joined a new longer running project using a whole bunch of technologies I’ve heard about before, but which were new to me – Another way to explore! So now I work in a project using MongoDB, VarnishPuppet and Vagrant. All of them are really interesting technologies, and the team doesn’t stop there: Every now and then we take a day to, well, explore new ways that may improve our work.


It’s been a very exciting and busy year and I am convinced that picking a ‘word of the year’ instead of making new year’s resolutions made a big difference. Instead of a plan, I felt I had some guidance that helped in deciding what to do (and what not to do in some cases). I will pick a word of the year for 2014 as well and if you also pick one, or if you already had one for 2013, why not write a short comment whether (or not) it helped you and in which way?

Testing And The Two Values of Software

The Two Values of Software

Sure enough: If your team’s software fails to provide value now (or in the near future), something’s gone badly wrong. You don’t like your software project to end up similar to this, right?

Smoking Remainders
Smoking remainders of a ‘Biikebrennen’ — don’t let your project end like this.

As Alistair Cockburn explained in “Agile Software Development” software development can be seen as a game played in rounds — and most teams prefer to stay in the game for many rounds.

To me it’s interesting (and a bit worrying) that most of the testing techniques and approaches are focussed on whether the current version of our software…

  1. is in fact the right software and
  2. if it works correctly.

In other words, testing focusses on validation and verification, it concentrates on a relatively short period of time: the next release.

Now, Uncle Bob Martin presented the idea of the primary and secondary value of software in episode 9 (‘The Single Responsibility Principle’) of his CleanCoders video series. He presents the secondary value first (which most people believe to be more important): ‘The secondary value of software is its behavior.’ He also explains the primary, more important value as: ‘The ability of software to tolerate and facilitate such ongoing change is the primary value of software. The primary value of software is that it’s soft.’

In Alistair Cockburn’s description the order is reversed (see Agile Software Development, 2nd edition p. 37 ff), but in my opinion the order isn’t always that important: I am worried that testing doesn’t consider one of the two values of software.

To my experience, essentially all projects focus on current or near-future behaviour of software, but rarely actively work to keep the software ready to deal with future requirements. I understand that YAGNI (You ain’t gonna need it) may play a role here. But mind you: YAGNI mostly applies to actually implemented features that are not needed. It may also be valid in order to prevent going overboard with too much abstraction and flexibility. In the end, you always need to find a balance between following and ignoring the SOLID principles (a good part of the Clean Coders videos covers this in detail).

Concerning the 1st value of software (according to Uncle Bob Martin), I’m convinced that testing needs to answer questions like this:

  • Is “the ability of software to tolerate and facilitate such ongoing change” a job purely for programmers?
  • Can software testers contribute to the primary value? Should they?
    • If yes, is this part of the job or should we keep out of this business?
    • How can we as testers contribute?
  • Can other disciplines help?

What do you think? Is this topic important for testing? Should we treat it in the way Michael Bolton advises testers with respect to “Quality Assurance Business” (spoiler alert/hint: He advises us to stay out of it)?

I personally think testers should get involved: A tester is somebody who knows that things can be different, as Jerry Weinberg says.

Also, I definitely want my clients, as well as their clients, to be happy with the software I help to develop, not only today, but also in the future, even when most original developers of a software system have left the team or company.

When your project (or product life cycle) comes to an end it should stay in your memory not like the smoking remainders of a fire, but with the bright colours of a great sunset.

Bright Sunset
Bright Sunset

Tools for Testing — 1

I recently took the excellent Black Box Software Testing Foundation Course offered by the AST (Association for Software Testing).

The course came with a lot of extra material in addition to the primary deck of slides & videos: Articles published by a number of people, blog posts, exam guides. I used Papers, which helps to organise, well, papers. It manages meta information about the papers, such as publishing date, title and authors etc. and allows highlighting text, adding notes and more. I also liked using the iPad version of the program (there’s a way to sync your library on your computer and iPad), because I don’t always work at my desk.

The other tool I found useful is GraphViz, an extremely powerful program to describe and draw graphs. The graphs are described in a text file (there’s a complete language that describes graphs, but for many purposes you’ll only need a small set).

digraph example_path {
graph [ dpi = 150 ];
 rankdir = LR;
 fontname="DejaVu Sans";
 fontsize = 20;
 node[shape=circle,fontname="DejaVu Sans"];

 1 -> 2 -> 5 -> 6 -> 7;
 2 -> 4 -> 5;
 2 -> 3 -> 4;
 3 -> 6;
 6 -> 2;
 label = "\nBranches & Loops";

GraphViz comes with a command line tool dot. If in the same directory as the file that holds the description above, one can use

dot -Tpng file_name_here -O

to generate a 150 dpi PNG file, which looks like this:

An Example Path
An Example Path

GraphViz can create much more complex images (see the GraphViz Gallery for examples), however I find just a short text file and a simple terminal command covers a lot of ground and there’s no need to create ‘hand made’ images anymore.

Both programs Papers and GraphViz are available for Windows, OX S and the iPad/iPhone (GraphViz is called Instaviz on the iOS devices).

What non-typical tools do you use in testing?

Anthropomorphism And Dehumanisation In Testing — How Does It Affect Us?

Where it began

I find it interesting to keep track of where and when I run into new information relevant to software testing. This time it was an article in a German magazine for dog owners (issue 6 2012, to be precise). The topic was anthropomorphising dogs. And I think digging deeper into anthropomorphism can help us understand software development and testing better.

What is anthropomorphism?

This is the definition of anthropomorphism given on Wikipedia:

Anthropomorphism or personification is any attribution of human characteristics (or characteristics assumed to belong only to humans) to other animals, non-living things, phenomena, material states, objects or abstract concepts, such as organisations, governments, spirits or deities. (

Why is it worth thinking about?

The German magazine article mentioned Adam Waytz as the author of a study and that way I found “Social Cognition Unbound: Insights Into Anthropomorphism and Dehumanization” by Waytz et al. (citation see end of this article).

The authors of the paper (details see below) say that “computers … can seem to have minds of their own” and mention that people “…curse at unresponsive computers…” (at least I have). If similar situations happened to you, maybe while testing software, then anthropomorphism affects your work.

I’m convinced that this topic requires more than a single post. This post is an introduction to the topic.

A brief summary of the paper

The authors discuss reasons for anthropomorphism as well as dehumanization and present three “primary factors——elicited agent knowledge, sociality motivation, and effectance motivation” which determine whether someone is likely to anthropomorphise or not.

Let’s look at the three factors:

Elicited Agent Knowledge
Anthropocentric knowledge is accessible and/or applicable.
Social Motivation
This is the need to be accepted, part of society and to connect to others.
Effectance Motivation
The motivation derived from understanding, explaining and (being able to) change or influence the environment.

Some ways this affects software testing

I will not go into much detail in this introductory post, but will instead list some of the behaviours that can be explained through this model:

  1. Effectance motivation and scripted testing
    I will not add to the discussion of the pros and cons of scripted testing, but instead introduce a possible explanation why testing and testers are not well respected in environments where scripted testing is used.
    When a rather strict execution of scripted test cases is demanded, the testers can’t influence their environment much. It’s about following scripts, manually operating the system under test and checking whether given conditions are met or not. In some cases changing scripts is not allowed, just following them. To others this looks like manually executing source code, something a computer is much more suited for. In other words: Testers work like computers, they’re perceived less human-like than they are.
    That way effectance motivation is inhibited, leading to dehumanising of the testers (at least to a certain degree).
  2. Test versus development teams—and what they perceive of each other
    I’ve worked in an environment where testers and developers were separate from each other. The most important communication was though the artefacts we were exchanging: Installed software on the test system, defect reports in a bug tracking system and may be the source code.
    We couldn’t see each other as the humans we are, it was (mostly) artefacts, the ‘other side’ didn’t even look remotely human. Thus neither side felt much respect for each other.
  3. System complexity
    The tester assumes the system is more complex than it is or has an intention that’s not there.
    Software systems, at least today, do not have a human intent. If a system under test is subject to anthropomorphism the tester assumes the system is more complex (or complicated) than it actually is and therefore puts more effort into testing. This can lead to new ways of testing or new test ideas and therefore improve the testing.

Leaving thoughts

This post introduced the idea that anthropomorphism affects software testing and described some of the effects. As mentioned above, I think there’s much more to discover for testing, so stay tuned for more posts about the topic!

Do you have examples of anthropomorphism in software testing? Please share them.

Cited paper

Waytz, Adam, N. Epley and J. T. Cacioppo. 2010. Social cognition unbound: Psychological insights into anthropomorphism and dehumanization. Current Directions in Psychological Science. 19: 58-62.


%d bloggers like this: