A day at Test Automation Day 2011

On June 23rd 2011 I was in the position to attend the Test Automation Day 2011 as an advantage since Squerist, the company I work for, was the founding partner of this event. In my profession I started with automated testing although I like to think more how test processes can contribute value to an organization I still have a weak spot for automated testing. This made me curious about what to expect.

I attended in the afternoon due to other obligations. This leaves me to the experiences of other people. I entered the exhibition area just before lunch and noticed the crowd entering the room. Normally I recognize some people from past conferences, now I saw new faces with one thing similar: passion for their profession.
I talked with a few of them and they heard new interesting stuff how certain tools might fit into their business. They got already some value back for attending. Others heard more or less the same story. Isn't it always this way.

I attended 3 keynotes: From Martin Gijssen (De kracht van open source testtools), to Mark Fewster (Experience Driven Test Automation) and Scott Barber
(Automating Performance Tests: Tips to Maximize Value and Minimize Effort)

Somehow I missed another presentation in the middle. instead I had a great talk with others.

What I remembered about the presentation was that Martin was able to speak about open source tools without making a judgment what we should do. In generally it depends, sometimes open source tools are good to use, sometimes not. Personally I expected more information how, when and the pitfalls instead focusing on a framework. Though some introduction was needed and if time is valuable you cannot tell the whole story. What left was the importance of a framework, a test architecture and key-word driven testing is still kept alive.

About Mark Fewster: I like this guy, If you sit far behind in the room and you don't have the full picture he has some similarity with David Letterman only in his best days. (hope he is not offended by this. I enjoyed listening and watching to him) With passion and wit he stood there convincing about the experiences he collected about test automation. Based on this he shared us his future. One of the things in his future was the maturity of tools supporting test techniques. I think he might be right, there will be coming more tools than ever.
I think another road in the future is the need for focus of tools on the human aspects.

So I think we have here 2 paths: 1 path of tools which will support more techniques and move towards the developer to build the scripts for testing and other tools which will support the "keyusers" to tell in what they want to do or did with testing.
What the future will bring, we will never know. At least he triggered me to look forward to his book in which he collected the experiences of others.

The last keynote was provided by Scott Barber, I never saw him before. Wow, he is an artist, how he sells his story. He got me all the way. Although it was mainly focused on performance testing, he sold me the idea that it is quite different then functional testing. More complex. And perhaps equally fun :-)
During the time he gave us 10 tips for free to focus on while setting up your performance test. I think they also are generally usable for all the test we perform

Top 10 performance test tips by Scott Barber on Twitter
10 data design
9 variance
8 object orientation
7 Iteration/agile
6 Error detection
5 Human validation
4 Model production
3 Reverse validation
2 Tool driven design
1 value first

For details about his tips, just contact him. I'm still looking forward for his presentation as the information was to much to write down. And he has some story to tell. (Afterwards I spoke with him and he is willing to tell you about his experiences)

Some of the eye-openers/lessons I remembered:
1. Performance testing is for developers, let them help you,
2. provide information about performance on continue basis, not only as a big bang
3. Think about the release management, test management and infrastructure before you start measuring performance
4. Also in performance testing, numbers doesn't say much. Perhaps start presenting you measurements with the happy faces and sad faces.
5. Although I was not directly involved with performance testing, in the past indirectly I learned some items and were involved with some performance issues too.


I think this conference was a good one, for a first time I think they can be proud of it. A lot of information was shared, good presentations (and some less) were given. They missed the short break after the 2 keynotes and between the "business cases". Now there was less room to share experiences of the presentations. As all conferences, you hear some old wine in new bags or what is it called. I strongly believe in the skill to learn from the information you get and read between the lines.
I had some good fun that day and was surprised. It triggered my thoughts and extended some perceptions/views and ideas.

Reflection of a day at DEWT

DEWT peer conference: A fact
On June 11th 2011 the first #DEWT peer conference was held. For passionate testers attended by passionate tester and challenged by the same testers. The intention of this day was to share information about topics we have chosen in a previous DEWT meeting with the understanding it interest us and might help us understanding better and become better testers.
Next to sharing information it was also an opportunity to practise some skills like presentation and teaching. Or what about sharing ideas to work on them.

The evening before
Actually, it started already the evening before. In an informal setting, more informal then on the 11th we sat down at the bar and immediately the spirit was already there. The spirit of supporting and challenging each other, tell about their experiences and how we might continue.

This was just at the beginning of the evening, there was much fun from sharing experience stories, judging the music, talking about artists and how lucky we are the have open minds able to learn what is testing all about.

The day it happened
At 9 o'clock sharp we started.....with waiting when the last persons would show up. And after 10 minutes the great happening was opened by Ruud Cox, appointed chairmen for the first part of the day. On a previous meeting of DEWT we decided to support this day with 2 chairmen (Also Jeanne Hofmans) to restrict our ideas and thoughts. Based on the same session we came up with the following program (except the lightning talks, those were defined during this day)

On todays program where the following topics:
§ Opening presentation on Artful Testing by Zeger van Hese
§ Transpection by Michael Bolton
§ Lightning talks by:
Jeroen Rosink: Testing Pyramid
Huib Schoots: The power of knowing nothing
Zeger van Hesse: Bader Meinhoff-phenomenon:
§ RST and SBTM in The Netherlands by Ray Oei
§ Credibility (the quality of being trusted and believed) introduction by Ruud Cox

Each performance had its own perspective and story, you had to be there if you had the chance.
I shall not recapitulate everything instead let me tell you some of the lessons I learned

Some Lessons Learned
When Zeger told about art and artist he made the relationship with testing. What I liked is that he sees testing as and art though we are not the artist. Testers can be seen more in the role of an art critic. And an art critic should know about all the variants of art.
Should he?
This triggered me thinking about the tester, should he also be aware about all the variants of testing? Perhaps at a certain moment. At least what he knows about testing must be told with confidence en compared to the truth.

I think if you keep shouting something is bad, that noise will no longer leave your room. If you tell the story and you are capable to make that story accepted then you gained reliability. This means you have to be able to explain in certain details what your test was all about....You have to be able to tell and explain the art of the software.

Another challenging topic was supported by Michael Bolton and was about transpection.

What I remember about the definition was Transpection: "An idea in head to explore which gives the person the opportunity to probe/play with the idea without influenced too much"

Valuable information about this topic can be found on:
Transpective Dialogs for Learning
by James Bach
Blog: Transpection and the Three Elements of Checking by Michel Bolton
Blog: Transpection and the Three Elements of Checking by Michael Bolton

He challenged us to use transpection to investigate the meaning of it. it made us think. Some investigated the internet to find more information, or examples. Together with Jean-Paul we did our own mind exploring to see how we would see the boundaries of transpection.

What I learned about transpection it is already done by persons like Plato...it is a good way to gain information or guide persons to learn/gain insights. Not everything is a transpection, pub talk can be rather not. It has a beginning and an ending although you never know which direction it goes. Though it starts with a main subject.

I think transpections can change over the time. With this I mean:
- you are the person who held the transpection and challenge the other
- you are the person who is challenged
- During the initial transpection, in which you are challenging your idea, you leave space for the other for a moment of transpection. perhaps you get it back later on?

Some questions I still have:
What is the option to step out of a transpection?
How can you step out without minimizing the result for the other?( Rude behaviour might distract and loose focus on the results)
Can the main subject be changed? How is this done/monitored?
When do you have a transpection and when did you loose the transpection?

These are some questions I have to look further and learn about myself.

The Lightning talks
The first talk was provided by Huib Schoots. He explained the idea of the power of knowing nothing. I think he is onto something. Though I know a bit about this :-)
It reminded me about the concept by general Rumsfeld: about known-knowns onto the unknown-unkowns.
If there is some power behind the information we don't know I think it can be worth to investigate what we don't know and always be aware of it.

I was also chalenged to held a talk. This gave me the opportunity to challenge an idea. While expressing the concept I was triggered to continue thinking about it. What was my idea? The main concept is that testers start as junior and grow up as senior. Only there is not much space for seniors so if you want to survive, you ahve to be good at what you are. This reminded my about a story by Adam Coucher: The most important stakeholder are you!

Or what Cem Kaner ask us: do we want to be commodity (a banana)Exploratory Test Automation: Investment Modeling as an Example by Cem kaner or do we challenge ourselves and learn?

In my opionion if you want to stay in business you have to create to ability to learn and not only to remember. You have to be aware that you can't rely on what you have done in the past or which certificates you collected. You have to be aware and think what you want to be.

During the lightning talk MB chalenged me: about the "You" and the "Why" he was right. Who am I to tell you what to do!!!

Zeger spoke about the Bader-meinhof-phenomenon. If I'm correct it is about the situation, when you noticed something strongly you suddently see it all around you. Imagine you have a new car, before you never noticed those beautifull cars, and now it is all around you. Imagine what this can do with bugs. You never were aware of this type of bugs and now: HELP!!!!

The thing I don't like is the title of this phenomenon, it has some negative feeling. Im certain there are other sources from psychology which explains more in detail from another perspective about it. I know that something similar is also explained by Oliver Sacks in The Man Who Mistook His Wife for a Hat
In one of the chapters he explains about a situation where after learning about it he saw similar symtoms all over the city by people.

Somehow we made it to lunch and deserved also a great walk through the woods next to the hotel.

RST in The Netherlands

After getting back some final tutorials were given by Ray Oei who explained about the lessons he learned implementing RST at 3 companies. It was sometimes hard as we still live in "TMap-country" There was some sound who explained that if TMap is asked we might call it TMap.

This idea I reject. Why call it something which doesn't work in the essence because when we ask testers about it they too often exlpain that it is not done as written therefore intended. They made there own twist..When asking them about it it is far from TMap. They use some templates, they use some techniques, they use some something and at least: it is al planned and those planned are nto telling what you actually did.

What I believe is: if you found you own way to make testing happen, don't lean on a name to sell it. By selling it under a name like TMap or ISTQB you support the believe it actually works. So it is sold more often. Perhaps it works for you, what I believe in is in honesty. Borrowing good things or bad things from a concept which leads to your succes doesn't make the concept be a succes.

Ray remined me why I suport RST because it chalenge you to think out of the box, it helps you to guide your thoughts, it leaves space to make it work for you!

Are you credible?

After the RST the final presentation was provided by Ruud about credibility of a tester. he is onto something, we testers should be aware about our credibility more often. When it is gone it is hard to gain back. Perhaps we should copy his action and create our own card or "buy" it from Ruud

copyright about the photo: at Zeger van Hesse/ copyright of the actual object (style-card): at Ruud Cox

STYLE


• Safety language


• Two ears one mouth


• Yes but


• Lighten up a little


• Empathy

With this final tutorial we closed the day in STYLE and went out for a dinner and reflect on the day and share some mysteries and parrots ;-)

Afteral it was a great day.

See also
DEWT
Zeger van Hesse
Jean-Paul Varwijk

How can I work when you build a fence around it?

Protection of your work
Last week while I was busy with one of my hobbies "geocaching" I found beside the treasure another particular thing. As on the photo below you see a mailbox only how can the postman deliver his work?

You might pass by this situation and laugh about it and continue what you are doing. The same you can do with this posting. You also might think what can be learned from this? is this a bug? Can it bugging me? Or bugging someone else? In certain situations I try to reflect on these situations towards testing. I believe that in every thing/situation there is something to learn from and which can help you define your mind set about testing.

A mailbox as trigger for questioning
So what did this picture triggered me: translate mailbox as you test object...it is a box that you want to see what you can do with it, what value it can give you, what you can tell about it, perhaps you want to take a look inside.

Currently there is a fence between you and the mailbox. How would you translate the fence. In my opinion anything which stands behind you and what you want to do. This can be procedures, a process, no resources just use your imagination.

The situation here reveals more information. Only you have to make assumptions, and some people claim making assumptions is a bad thing for testers. I like to play with assumptions to see if there is valuable information behind those assumptions. For this situation I raise the assumption that this mailbox was of use for someone at some time for some period. I'm onlyy a person who found about this situation when there was a fence. Perhaps this was not always the case. This is an assumption. In my opinion the value of the object changed over time. Only it is the value I can give based on my current observations and knowledge. I might tell this mailbox cannot be used anymore, big deal, the postman should take postcards back to the station.

Change of process
For the postmen it might disturb the process as he was ask to deliver, by taking back it is not taking back his postcards; it are the receivers postcards, and now there is no line of communication with the receiver. The package cannot be delivered and there is no solid way to communicate about the changed situation. The owner was not available. The fence is stopping him to do his job.

Another assumption here is that someone else placed the fence for some reasons we don't understand, yet? That other person used his process to place the fence without bothering other process which affects his action. In organizations there are also those people/roles. Therefore this can also be translated testing.

Other processes affects testing

How often are we testers bothered with other processes which stopped us doing our job? Our job is testing, asking questions to the software and more. How often are we busy to find information why processes/procedures which are defined to help us obviously to test better? Making the quality of the process visible instead of making the quality visible of the product. We use our energy on other "important" things than using it for testing. I learned that often we are busy with "valuable" metrics to control processes instead of collecting information to tell the story about the product. Value time is lost.

Help us with testing

Instead of focus only on processes try to focus on testing. Sure there is always other processes which affects our work. Let those processes help us. Only make sure you don't build your fence around our job!