Conferences – to go or to not (let them) go….


Every third quarter of the year a small discussion starts in our office. The subject of discussion is

 “Are any of our testers going to attend a conference, and if so how many and who?”

Generally the discussion tends to lean more to the how many then to if any testers are going. So in the past years on average four to six testers attended for example EuroSTAR and the Dutch Testing Conference. The question who was going to a conference solved itself most of the times. The number of testers wanting and able to go did usually not exceed the number of places available.

Cost and return

Having attended several conferences myself I know that the result of attending can be very rewarding. Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network.

Conferences, especially when they are abroad, are however rather costly given that you easily spent between 1500 to 2500 euros per person. This might not be much more than a three or four-day course, but then again it is a conference and not a course. And this seems to create the need to sell the attendance of a conference to management. So my question to you the reader is:

What do you,

or rather what does your manager,

see as valid justification to attend a conference?

I would like to ask you to participate in a small inquiry and leave your justifications as a comment.

To start a few I thought of myself:

    • As a reward or bonus
    • To expand the attendees knowledge
    • To expand the organizations knowledge letting the attendee convey what she has learned (How?)
    • There is no justification it is money waisted as the organization never sees any return

What’s in a name – Part 1, I am an engineer

Ever since I started software testing I was surprised by the different names the test functions have ranging from say “Software Development Engineer in Test” to just “Tester”. At the time I did not pay much attention to this as testing to me seemed to be similar regardless of the title you have while doing it. Some time later however, after  listening to Stephen R. Covey’s 7 habits, I was reminded of these different titles. Covey mentions, in the Paradigm chapter, the shifts in paradigm that can come with a change in the title you carry. At that time my idea that all software testers basically performed the same activity had also changed and the subject of the title by which you test intermittently came back to my mind. And now some years later I have found both time and inspiration to use it as subject for a number of posts. In this small series of posts I will, start to, shape a model  of my perception that the title by which you perform your testing activities has consequences on how you and others perceive and approach your work in software testing.

This first post in the model relates to the origin of the computer itself.

The first computers were mostly a product of scientists, civil engineers (like Leibniz, Babbage, Atanasoff or Zuse), and others building more or less programmable hardware attempting to both solve and speed up the solution of calculations. The application specific machines that emerged out of this eventually not only calculated based on their physical configuration but also based on data and settings fed into them.

The design, implementation and modification of this data known as software eventually was, and still is, seen as an engineering activity known as Software Engineering. (The origin of the term is linked to a NATO report  in 1968)

This part of the model then represents the engineering paradigm.

In the engineering paradigm testing is seen as a specialisation or a sub-discipline of software engineering. In this paradigm software test engineers see themselves closely related to software engineering and by doing so favorably like to share the perception that they perform based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering. Like their counterparts their focus lies first and foremost on the functional correctness of the software engineering product, the code. The code itself and it’s syntax or grammar (patterns, coding practices, etc.) is however mostly left to the developers or programmers.

The software test engineers responsibility is to check whether or not the software:

  • Works; does the software or section of software work once installed
  • Contains all functionality; checking that all functionality that is described in the specifications is present
  • Is functionally correct; does the function do what is described in the specification of that function

For a lot of people then, whether or not involved in software development or even if involved in software testing themselves, the following thus describes what testing is about:

Verify that it works and is built as specified.

Obviously software testing has evolved since the early days of building computers using switches, relays and vacuum tubes. The consistent use of the engineer part in titles for software testing however signifies, in my opinion,  the implicit focus on the correctness and completeness of the software built rather than more user or quality attribute orientated views.