1 of 3: Eurostar Testconference 2012 – Lessons learned and to learn...

I’ve been to the Eurostar 2012 test conference in Amsterdam (November 2012). There were so many presentations about lots of subjects. If I would try to learn from all those wonderful ideas I would certainly get lost in this overload of information. But as Alan Page said in his keynote, ideas come from other ideas, so I will let that be a guidance.

So in the end these blog posts leads to:
-    some ideas to put on my self-study list
-    a list of books to read (or to put on my everlasting book pile).
-    some ideas I can use immediately in my daily practice as a tester.

So what did I learn?

The keynote of Alan Page was about ideas and innovation. I combined some learning from Alan Page and the workshop I followed on the third day: Beyond Testing, by Marcus Gärtner.

What is innovation? To solve the ‘right’ problem. But one should know what the problem is and then you should follow it up by questioning the problem: Is it really a problem, maybe there is a problem behind the problem, what is the real cause of the problem?

Furthermore: Always check if the problem still exists. Is there a bigger problem here than what we acknowledge until now. Defocus on what is perceived and try to see the bigger issue behind it.

One way to start solving issues and create some ideas is drawing up a a cause-effect diagram: What are the different aspects that influence each other, are these positive or negative influences. Do they increase the problem or are there any positive side effects we can think of? How can we change the negative relations between activities to get out of this downward spiral.

Cause-effect diagram, drawn by M. Gärtner in workshop

The binary disease

Am I on my way to complete health from the binary disease? Richard Edgren did a talk about some diseases we have as testers. The binary disease is one of them: Reporting test results in the form of pass/fail lists. Because real life isn’t that black and white, it is actually very strange to report test results in this binary way of “passed” and “failed” test cases.

In my current job I had discussions with the project managers about test reports I created. Instead of a big list of OK and Not OK they only wanted the most important defects, and no red blinking Not OK signs.

But only reporting on blocking issues wouldn’t give the overall picture, I still wanted more in the reports, but was not sure what to do about it in this context. Eventually it was a defect report combined with mentioning possible risks for going into production. Now I should study reporting more by checking those various blogs that are written about this. There are some blogs going on about visualizing testing and testing results, so that would be something to check out. Richard also mentioned a great exercise that I’m going to use: Stop where you are while working in a project and explain the status of the project in 30 seconds.

I connected the Richard talk with the Alan Richardson (aka Evil Tester) talk later on with the subject of using other words to describe testing, not using the standard words we all learn during ISTQB or TMap courses and trainings. Use words that fit the customer in a better way.

For example: system testing is an official standard, but in practice could mean something completely different from organization to organization. So instead of trying to use certain words from testing standards and methods , use the words that best describe the situation for a certain organization, project, software product. On what system testing really means for example, simply communicate and discuss with the people that are dealing with that kind of testing.

End of part 1 of 3