Teaching = Learning

This week I sent 2 proposals for the Spring Event to TestNet, the Dutch Special Interest Group in Software Testing. One was for a presentation for 3 quarters of an hour, the other one for a workshop of 1 and a 1/2 hour. The process of writing proposals was time consuming and intense. My proposals will be rated and then ranked against the other proposals. Finally I will be notified, whether I have a speaker slot.

In 1992 I went to my first Dutch Juggling Convention. I was thrilled; I would be performing in the Public Show. It had taken me months to acquire the Blow Off Your Socks level of juggling. (I still dropped my juggling prop though.) The first part of the convention was a long warming up for my act.

On the first day I walked in the gym. I noticed a few people juggling, but a big white paper sheet drew my attention. It was a table. On one side time slots were mentioned, on the other workshop areas. 2 or 3 workshops had been filled in.  A marker was hanging on a string.

I am still amused, how simple it is to book a workshop for myself on a juggling convention. No rating, no ranking. Just write down my name, juggling prop, and level. Or one name and two nouns. (The only exception I experienced is an International Juggling Association convention, but that is another story.)

There are many possible reasons, why I signed up to give a workshop. I only wanted to share knowledge about juggling. My favourite juggling prop is the devilstick. Wouldn’t it be great, if there were more good jugglers with a devilstick? So this workshop was not planned. A coincidence to happen.

If there is a huge juggling convention which cannot be ignored by a mainstream juggler, then it is the European one. My first European Juggling Convention was in Leeds. This time I came fully prepared. I had rehearsed two workshops for devilsticking in English, which definitely differs from my native language Dutch. The schedule of each workshop I had written down and memorised. And the tricks and combinations were still evolving during my preparations. The most difficult part was to locate the workshop schedule. You still remember that big white thing on the wall attached to a marker. I had planned two workshops, but gave a total of 3 workshops. Good response can be a nudge in the right direction.

Looking back I notice exciting patterns:

  • Determine the biggest step people can take and still follow me.
    [Blank faces.]
  • Discover and share new tricks and combinations, because attendees love them.
    “Did you write a book?”

The most important thing I learned was to observe the attendees. A struggle with the devilstick triggered the reaction: I had either been unclear or combined too many movements. So their struggle became my struggle. By dissecting my juggling tricks for my workshop pupils I learned more than I imagined. I determined the elementary movements to make more combinations.

Once a young woman was impressed by my flurry of movements of the devilstick. Then a man remarked dryly: “He is just combining a few little tricks.”

Let’s go back to testing. It is my way to earn my living after all. In one consultancy company I had to earn my place as a teacher or workshop leader. I spoke with several colleagues about test courses. Yes, they were looking for new teachers. My pitch was: “I have more than 15 year of experience with giving workshops in juggling.”

In the meantime I started to teach mind mapping to my colleagues. The whole process of dissection repeated for me: why do you add branches clockwise? What is a fast way to make a mind map? A lot of questions, which bothered the attendees. I learned to mind map according to the rules, but also using mind map programs working around their restrictions.
BTW I wrote this post using a mind map program while commuting. I moved and added branches to make this a compelling story. Hopefully.

My pitch became: “I have experience with teaching mind maps to colleagues in our company. These are my scores from their feedback.”

Once I had a funny insight to illustrate testing Virtual Reality with juggling. I had one brilliant test idea to start with. My colleagues were supportive and a Bit sceptic (with a capital B). To everyone’s surprise my proposal was accepted in 2008. The preparation gave me lots of energy and inspiration. What is a good test idea and why? Let me break it down for you and show it to you with Real Life juggling.

Then I noticed that there were more people willing to speak than available speaker slots in a test conference. As you might have guessed: I did not speak at many test conferences.

I started to miss the thoughts in my head breaking down my testing examples and improving them. So I began to experiment on my work, but that was not enough.

Why not start a blog and write about mind mapping, SFDIPOT, and 2 screens?  Wouldn’t it be great, if there are more good testers? So this blog post was not planned. A coincidence to happen.

 

An Oracle, Two Systems, And Four Situations

On September 26, 2015 Justin Rohrman ‏tweeted:
“Anyone know of the origin of the word ‘Oracle’ in software testing? Who started using it, what other words were used prior, …”

I answered with:

  • in the past in the Greek city of Delphi there was a special person you could ask question: Oracle.
  • The answer was sometimes cryptic. When the Persians invaded Greece, the answer was to hide behind
  • wooden doors. There was a smart man, who interpreted the answer right. He advised to build
  • a fleet of wooden ships, which beat the Persian fleet.

An oracle is a source of information, which I can use during testing. It can be used to determine, whether the observed situation is right. Right?

A dialogue from a movie with John Cleese about choosing a direction (while driving a car):
“Right?”
“Right?!”
“Left?”
“Left!”

Are you sure?

“Hey, I think I found a bug.”
“Okay. Tell me about it.” The other tester requested me.
I told as objective as possible my observations and my conclusion.
“Did you look in the previous version?”

Some systems are so complex. A fast way to sift possible bugs was to look at the system used in production. Of course afterwards it was always possible to read the specs or ask the PO, Product Owner.

One tester was able to pinpoint the version, where a bug was introduced, within minutes. He had the latest versions of the system available.

So I learned,

  • how to install more  than 5 different releases on my PC.
  • how to rollback a release including the database.
  • how to prepare the proper database and configuration for testing.

Where did you see it?

During the test I noticed, that the test version showed status information, which was not shown in the release in production. I asked other testers, who noticed the same. So my test environment was OK. There was still a doubt, whether the customers would miss the information.

The most simple way was to ask help from the help desk.

In the afternoon a blond woman was standing at my door post:
“You are right. The situation occurs in production.”
It was time to make a bug report.

Just don’t let it happen again

“I have not enough information to test the issue.” I complained.
“Did you test in the previous version?”, another tester remarked.
“No.”
“If you reproduce the steps from the issue, then you notice, what will go wrong. The issue has been solved, if the observed situation does not occur.”

During one project I had to test a system with service desk agents and PR colleagues. There were issues to be tested. I did not have time to make test cases for them.  If I let the testers test on their own, there was a chance  that they would check, whether only the bug was removed. I needed information about similar situations and connected cases.

I opened an issue in the defect registration system and read the description. “I would test this …” Then I wrote down the test ideas in the comment. Before the test I gave some instructions to the testers:
“In the comment situations are described, which must be tested. If you are ready, write in a comment, what you did. Then you assign the issue to me.”

After the start of the test the issues came back to me. I looked at the feedback. Sometimes I realised, that more situations had to be tested. Then I added them to the comment of the issue and assigned it back. The nicest thing, that happened, was that extra test ideas were added by the other testers.

Did you have a good look at it?

During the regression test I had to test the export and import function. I had two systems installed with different databases. The only things, what I did, were export data to a file and import the file in the other system.

I had two screens, so it was easy to compare the data: I placed the systems on different screens. If there was a difference between the source and target system, then I made a print screen. The picture contained images of both screens. Hey look mom! With one finger!

Next stop was my word processor, where I pasted the image. Then I used the keyword BUG followed with a small description. Sometimes I analysed the data file to pinpoint the source of the strange situation. If the file was wrong, then the source system might have some glitches. Otherwise it was the target system.

During the stand up I mentioned, that I had found a number of particular situations. This resulted in a session, during which I spoke with a programmer. The following pattern was repeated:

  • Search for “BUG”.
  • Resize the image to show the differences between the systems.
  • If necessary, look in the file.
  • Determine, whether it was a bug.

During the bug removal phase I got two kinds of feedback from the programmer: it was fixed or it cannot be fixed. The latter surprised me, but a study of the specifications changed my view. The format of the file did not support all types of information. There were semantic limitations. Something like: country is not supported, so this cannot be exchanged.