My selection for the TestNet Autumn event


Each year TestNet, the Dutch society for testers, organizes a spring event and an autumn event. The event is a single days conference with the morning reserved for workshops and the afternoon and the evening reserved for two key notes and parallel tracks. On Wednesday 14 October, the autumn event takes places. Its theme is ‘Trends in Testing’. Most of the presentations are in Dutch and therefore the descriptions of the sessions may not make a lot of sense to those who do not understand Dutch, but I am going to try and describe some of them, together with my personal selection for this conference.

The conference attracts more than five hundred visitors! Part of its attraction must be that the program is varied, the venue is excellent, and the admission price is zero euros if you’re a member of TestNet. TestNet membership costs next to nothing, so basically you get two big conferences for free each year. There is no reason why you, as a professional tester, would not show up at these conferences, other than personal circumstances.

As I said the theme of the autumn event is ‘Trends in Testing’. Let’s have a quick look how this theme is reflected in the presentations. Besides the key notes there are four presentations about test automation, two about performance testing, two about security, one about big data and one about the internet of things and that’s just about it for the buzz words. The other presentations are about the selection of test data, about roles in testing, about information ethics (nice find Nathalie!), about operational intelligence, about handling functional specifications in a more efficient way, and one (only one?) about exploratory testing. For a conference theme that could easily end up facilitating a buzz word bingo, it turned out pretty well.

From the four track sessions I selected the sessions that I am going to attend. The first one is ‘Subset: Less is more’ by Marten Bakker. I do not know the speaker, but I am drawn to the topics of his talk. Marten is going to talk about test data management and the creation of subsets of data. From personal experience I know that testers easily focus on functional specifications and easily lose sight of test data. In my current project there is almost complete ignorance of test data. This, of course, is very bad, but when one deals with large sets of data and a large variety of data, it can be become quite intimidating to handle this with some form of elegance. I hope Marten has some good suggestions.

The second track session that I am going to attend is ‘Panacea – A test framework for all’ by Adonis Stanislas Sheeban. Again, I do not know the speaker. The talk is about test automation, specifically about the tools Protractor and Cucumber. I heard of these tools, but never worked with them, and I am taking this chance to get to know a little bit more about them.

The track session that I am really looking forward to is ‘Google naar fouten met operational intelligence’ (Google for errors using operational intelligence) by Albert Witteveen. Albert is going to talk about complex, linked systems and how to check if these systems are functioning correctly. In my current project, and in the one before that, I’ve been digging through databases and logs quite a lot, in order to establish how well the system is functioning or to find out the root cause of a defect. This can be a tedious and yet very difficult, time-consuming job. Albert envisions software that can do the gathering of relevant data for us and that make this data easily accessible. I am sure such tools can save a lot of time. I tried my hand at building a log analyzer once and loved doing that. So in this talk I am also going to look for opportunities for self development.

The last track session that I want to visit is ‘Trifolium Repens: de nieuwe testbasis voor Agile en Waterval testen’ Trifolium Repens: the new test basis for Agile and waterfall testing) by Rudi Niemeijer. I am not entirely sure what Rudi is going to talk about. I think he is going to introduce a method to reduce overhead (functional specifications) by combining the strong points of the tester and the developer. At the very least he is going to have to explain why he uses a plant (white clover) as a metaphor. I am looking forward to his explanation.

I do not know if any of the sessions that I am going actually describe trends in testing. I hope they do.

Communication Between the Hominids


How do we build the theories that describe what we think testing is? How do we evaluate them?

Five minutes into a presentation I attended at the Dutch TestNet Spring Event, the speaker recklessly confronted the audience with the following phrase.

communication between the disciplines

For me that was a clear call to run for the exit. The title of the talk was Test Improvement is Something You Do in the Workplace and I attended it hoping that I would learn a thing or two from hearing another tester’s perspective on how to improve testing. The phrase ‘communication between the discplines’ however, ignited my fear that this talk was not going to be about humans. When the speaker announced that we would do an excercise and consequently checklists were handed out, I was dead sure.

Later in the evening I reflected on my moment of frustration and on why the word ‘discipline’ startled me. If you quickly substitute ‘the discplines’ with ‘the people on the project’, which is probably what you did already without even noticing it, then there is nothing wrong with that phrase. But we should notice ‘communication between the disciplines’ actually means something different.

According to my Oxford Paperback Dictionary & Thesaurus a discipline is a branch of academic study. A discipline has a field of study, is likely to have a paradigm and will have ways of doing research. Here is a taxonomy of academic disciplines (PDF).

The concept ‘discipline’ is an abstraction, and the use of the word discipline to indicate people doing different tasks on a software project is indicative of a particular point of view. It shows how a theory of software testing choses to identify and classify entities in its realm. In this case it is a theory that is based on the use of ‘discipline’  as a classification mechanism. ‘Discipline’, in this theory, serves a mechanism that abstracts from the realm of software testing exactly those aspects that serve a purpose to the theory. Exclusively, or most preferably, the elements that form the concept of a discpline, are those that lend ultimate support to this theory of software testing.

This means that this particular theory of software testing decides to regard the humans doing particular tasks in a software project not from the perspective of them being human, but from the perspective of them working in a profession that originates from an academic field of study. The theory states that the latter perspective is by far more useful; it accounts for the phenomena that occur when doing testing in an excessively superior way.

I was inclined to dismiss this point of view right away. But I think further investigation is warranted. If this theory speaks of ‘disciplines’ rather than ‘people’ then there should be in the literature relating to this theory an examination of the disciplines that interact with software testing, and for each of these disciplines a clarification of how aspects of the discipline are relevant to the theory and how other perspectives are not. I’m assuming there are case studies or field studies too.

As of yet, however, I have been unable to find solid evidence that the ‘disciplines’ perspective trumps the ‘human’ perspective when it comes to communicating with other people on the project. Since conclusive evidence is lacking,  the speaker in the presentation mentioned above would be required to at least add a disclaimer to his ‘disciplines’ perspective and inform his audience that he is using a highly contestable abstraction. As you can guess, he did not say a word about it and I reacted too slowly to question his reasoning. Frankly, I was too infuriated.

In my current project I have five software developers. In theory their work is the subject of investigation of the following academic field of study.

Physical Sciences and Mathematics: Computer Sciences: Software Engineering

When this team creates software there are discussions on almost every aspect of software engineering. There are different points of view on what should be in the definition of done, how we should write our unit tests, how far refactoring should go, what should be documented where, what should be in code comments, what should be in scope for the acceptance tests, what tooling we should use, how we set up test automation, what should be the level of detail of our use cases, how we set up test environments and what purpose they should serve, how we set up data and how we should deal with incidents and interruptions. Behind each of these considerations there is a whealth of rationales, most of them probably not based on mathematical calculations, but on human emotions.

According to the ‘disciplines’ perspective I should be communicating with each of developers alike, as members of an academic field of study. In practice this will probably get me blank stares across the board. The thing that will help me in my communication with my fellow units is to know that they have very valid human reasons or sentiments to act in a certain kind of way. To make progress (to improve) is to appeal to these sentiments.

From this experience and a couple of others, I would say a typical software development workplace contains mostly hominidae of the genus homo. If we are looking to improve our testing, perhaps we should therefore start ‘communicating between the humans’ and concentrate our precious resources and intellect on the study of aspects of human behavior in software development, as did Gerald Weinberg, Tom DeMarco and Timothy Lister, and Alistair Cockburn.