Last week I went to Hamburg for the first German Agile Testing and Exploratory Workshop (GATE).

The event took place in Hamburg and it was my first trip there. The city seems like a nice place, where everything gives the impression of cleanness and organized work. If you want to try something excentric, Reeperbahn at night is the place to be. Therefore, you can select what you consider suitable for you.

The workshop had a few participants, Meike Mertsch, Markus Gärtner, Maik Nogens , Christian Baumann and myself, but it turn out to be a really productive and interesting meeting. Some of the initial topics were more developed than others, turning the discussion to focus on only some aspects ,and thus, causing other topics to be left out, but for some other time. It was a really good stimulation of the brain.

In some workplaces and most corporations you are just limited. When you have the chance to do a little bit more and add a personal touch to your work, something happens and you end up being busy with other secondary tasks. Meetings and workshops are a great opportunity for the testers, in this case, to come with new ideas and more important, have their ideas put into practice.

Therefore, I thank Markus and Meike’s company it-agile GmbH for making the event possible, by letting us use their space, and because I had the chance to meet interesting people in the beautiful city of Hamburg.

Markus’ session with the dice game, done by Michael Bolton and James Bach particularly comes to my mind as I have to admit that I didn’t really recognize the pattern instantly, even if it was the same James practice with me more than an year ago. And then I thought that my solution was expressed mostly by numbers and it could have been represented in a visual way. Thus, I realized visual memory is stronger than memorizing numbers.

You can check Markus blog post on it for more information, blog to which I couldn’t add too much myself.

Maik had a nice story in which he described the notion of “Charity Testing”, a term that he coined. Basically, if you want to learn for yourself, the best approach is to use it in a specific context, by finding projects that are done to help the community, as a volunteer tester. Although maybe “volunteer” is not the exact word.

Meike played a lot with stickers and kanban. I personally took from this a sketch idea for future implementations as puzzles or even ways to write an article.

I also tried my beta picture puzzle exercise, but turned out to be a bad idea not to mention that it was not complete. Of course everyone in the room was a tester and my app was thoroughly analyzed and broken. It got a set of bugs that I wasn’t aware of, but will try to fix it.

The topics presented were interesting, but what was really great it was the way the whole workshop went and ideas changed.

It will be harder probably to keep the same spirit of sharing among larger number of participants, as in large crowds you have lesser time and tend to self-censor yourself about what can be said or not. But, I would gladly participate to a second workshop next year.

As I said, the subjects and topics were good, but what really matter was the way we shared the ideas. If there is a job where one can have this constant environment of sharing ideas and come up with better solutions every day, I would really like to have the chance to experience this once again. I realize, however, it is hard to find such a thing.

I attended the Weekend Testing Americas no 18, where James Bach was the invited facilitator.

The mission had the purpose of doing  self-training activities related to Weekend Testing chapters.

Basically each participant had to edit this document Charters-How-To with the scope of improving it.

More details on http://weekendtesting.com

Another session was this Saturday, actually sessions (+WT and WTA). Its very good considering there were basically 6h for those willingly to join.

Even that I proposed the mission and got to play a little before the actual meeting, I think I got more knowledge about boundary testing and limits.

Everything will differ for a product and environment, but in this context I saw:

-a chat message goes through many locations. As we assumed (read the transcript) it will be probably be an Xml record at one point, then maybe a db record. Depending how the data stream is sent, we will probably have another set of limits.

-in testing limits we can actually do (without even trying)  security testing or Pen testing. So we should be also careful from the legal points of view.

-the boundary depends on the input. An alpha numeric char differs from another char. An example used were kanji (Japanese) chars (“Petteri Lyytinen: I tried to paste a text string that is 32768 kanji characters” ..”only showed the two dots”)

-anything too big is truncated (or should be truncated in some situations) and the process of truncation can be different in some cases, some unexpected

-some parts cannot be tested easily (or in the required time interval) like the history containing large messages

-tools help – this time we used one available, but in other cases tools need to be built up

Thanks to the participants:

Anna Baik, Ben Simo, David Vydra, Kristjan Uba, Lalitkumar Bhamare, Michael Larsen, Narasimha Reddy, Nitin Purswani, Petteri Lyytinen, Santhosh S Tuppad and Eusebiu Blindu (as host)

Over the past two weeks I hosted the European Chapter of WeekendTesting. The two missions were EWT39 – Optical Recognition and EWT40-Mission impossible.

The first question someone would ask is “Why?” Well, because a Weekend Testing session can provide several nice stuff that usually is not present (or not in the same way) as in a real job:

-you can just not participate (but this “free will” increases the chances of enjoying it and get something productive from it)

-usually there are simple applications to understand for all – and from this what remains is the way to develop an approach to test it

-its a way to spend time (maybe not the best, but not the worst)

-you can risk with stuff you cannot risk at work – like following the curiosity for an approach

-get others to know you (usually the after reports include mentions to your name – website links if you are easy to be found )

and many other stuff

Anyone is welcomed to participate and this is possible by:

- Looking on the WeekendTesting website, usually the announcements are here for the new sessions

- adding on Skype the username  “europetesters” in your list

- sending an email at europetesters@googlemail.com

- following @europetesters on twitter

In medicine and journalism there are these models, these principles that are a guidance to the practitioner.  For example doctors have the Hippocratic Oath which is an oath historically taken  swearing to practice medicine ethically.

According to The Elements of Journalism, a book by Bill Kovach and Tom Rosenstiel, there are nine elements of journalism.

So I though of proposing myself a similar set for testing:

1. Testing’s first obligation is to show the truth.

This means to take off the veil of fake certainty that everything works. Also to validate any assumptions claiming there is nothing that reduces the value of the product.

2. Its first loyalty is to the client(s).

Here the clients can be users,  stakeholders,  managers. Its important to know who are the clients in the first place.

3. The essence of testing is questioning a product in order to evaluate it.

This is actually inspired from the definition that James Bach gives to testing.

4. The testers must maintain an independence from the people that give them the info.

For example the data gathered from a developer should not be trusted 100 percent. People will give you what they think or what they assume is right.

5. The testers should inform based on their analysis and thought.

This means they should not just take the info they receive and jump to use it to inform others. If initial information is false,  it will result in more disinformation.

6. The information provided by testers should be also reviewed.

This means a bug can be set invalid, or the reports should be reviewed by someone else.

7. The information about the product to test should be significant, interesting and relevant.

Testing should consider risk areas, priority based on circumstances, context and the  information should be useful.

8. The information provided should be comprehensive and proportional.

This means to inform the client right to the point, also in an acceptable format. No one will read a 100 pages report when its not needed.

9. Testers should be allowed to exercise their personal conscience.

This means the approach should be left for testers to decide  and have a relative independence.