Category Archives: A leader ships

Test Creativity, Inc.

Using the book ‘Creativity Inc.’ as a basis for this blog post, I made a mistake. I tried to craft a compelling story, how creativity could be used in every phase of software testing. But the post became a struggle for me. Then I realised that the book was not about creativity or management. It was about leadership. Let me write about it.

Learn, Struggle, and Tell
During one of my workshops about mind mapping I talked with a colleague, who was specialised in project support. She told me, that she already had been taught mind mapping during her master class. She was quite proud about the nice mind map as a deliverable of one master class group project. She described the beautiful details, but I sensed some reluctance to use mind maps for her daily work.

One of my kids had to give a talk. In the US it is called Show and Tell. An object is shown to the class and the pupil tells about it. The teacher of my kid would give a penalty, if no mind map could be shown.

Where’s the fun?

Flow and Tell
What I like about mind maps, is that they are playful in use. I can get in a flow, during which I can add and modify information in a continuous way. I can focus and defocus. With a single delete action I can remove a complete subtree of information.

A mind map makes a TODO list more interactive than a standard checklist. I can make sub tasks and move them around. It shows me, which things need my immediate attention.

This is useful fun for me.

Use and Tell
Years ago I used to work for a consultancy firm. This company had a special program for consultants between projects. One of the workshops was Introduction Mind Mapping, which appealed to me as a knowledge worker. The reasons to attend my workshop were different:

  • “I am curious, what mind mapping is.”
  • “I heard good stories about this workshop.”
  • “It might be useful for my work.”

During the years it became a feel good workshop. I found the right mix between practice and entertaining stories.

In order to maintain the quality of the workshops I was requested to collect filled in evaluation forms. Once I even scored a 10 for the whole workshop on scale from 1 to 10. You guessed right: 10 is perfect. For Dutch people this is quite exceptional. Most of the time I scored 8 or 9, which is good.

The feedback about the use of mind maps after the workshop was quite limited. One consultant used a mind map in a presentation, which I attended.

Another consultant had a long call with me to look at the use of mind maps as a vehicle for knowledge management. And there were a few more.

Show and Provide
There was not enough time to make a test plan. My project manager was quite strict: you have to do your job with the available resources. So I asked my project lead to use a mind map. The reaction was like “Sure, why not?”
I confirmed my request:
“You won’t get [word processor] doc, but a mind map.”
“That’s no problem.” she answered with a smile.

I went back to my computer and made one of the most compact test plans ever. I mailed the plan to her and started playing the theme of Mission Impossible in my head. I succeeded.

Later I heard that the plan was converted to a document. This was not entirely my intention.

Show them & They Tell me
Another time another mind map. This time I presented the test plan mind map to the stakeholders. It was scrutinised and becoming better after each feedback. Weeks later I requested information from a colleague, she answered with:
“I looked to your mind map and […]”.
Just imagine that smile on my face.

A few weeks later I got questions from another colleague. I opened my mind map and talked about the options. It was highly constructive. Test ideas were reframed with new facts and questions. The focus was on the content and not on the form.

There’s No Business like Show Business
There are many people, who already use mind maps like me. So my creativity is not that high. The use of test plans for management is standard in many companies. But the constructive discussion about the tests to be executed was quite unique for me. My test plan mind map was discussed, adjusted, and used to give a direction.

Am I a leader, because people follow me? Maybe they are chatting and not paying real attention. Maybe I am a leader when I tell the right direction in the back of the group. But they might follow another group or be led by some else in the group.

Real leadership is granted and not imposed.

A stoic view on the Circle of Influence

This is a story, which matured over the years. Lingering in my thoughts waiting to be told.
So behold.
(Yes, it is time for a rhyme.)

Circle of Concern
At the end of the workshop Introduction Mind Mapping I told, that I was working on a workshop about The 7 Habits of Highly Effective People. Two young colleagues reacted immediately. All smiles and eagerness.
“I want to come. Where is it?”
This announcement was a typical case of skin in the game. I could not stop now.

I kindly informed the programme committee about my intentions. Also now I had strong reactions: offices were fighting for my workshop. I picked the first office, which had reacted. After the announcement other consult giving colleagues on projects reacted with:
“Are you willing to give the workshop in the evening?”

During my time as a consultant I visited the office regularly between projects. People had finally time to wind down after a busy period. There was also time to study books. The book of Covey was an intriguing one. It was hard to grasp and it was a must read. This was a real dilemma.

The first time I told about my plans. A friend reacted with:
“You are all smiling.”

During the first day of the workshop I introduced the Circle of Concern.
“The Circle of Concern contains things you bother about.”
A compelling example was easily chosen: that very evening a manager might call team members, that they were fired.

Circle of Influence
I also pointed out, that not everyone or everything in the Circle of Concern could be influenced. So I signed a Circle of Influence inside the Circle of Concern.
“Can you call some persons you cannot influence?”
After a suggestion I placed a dot with Manager inside the Circle of Concern, but outside the Circle of Influence. More options were discussed and more dots placed.
Particularly in the Circle of Influence.

On my way home I received a call from my emotional manager:
“I have to call you, because you are fired.”
I protested formally and the call ended.

That very evening I  concerned people by phoning them, that I was fired. Looking back at this period my wife said:
“You were really confident to get a new job.”
Due to the exercise I knew exactly what to do. There was no grief, only determination.

In the days after the dreadful call I was kindly requested to stop all my activities including the workshop 7 Habits of Highly Effective People. Attendees protested to no avail. What I had planned as a viral workshop, was put on hold.

Looking back to this course of circumstances I might challenge the reader to point out a Circle of Concern and a Circle of Influence. There are multiple. What I want to write, is to give a philosophical view of the story.

Stoicism as a Service
I still remember the discussed options in my Circle of Influence. They gave me a direction to move. There were no emotions at that moment.

While writing this article I somehow became emotional. I tried to trace it back to its roots: I was reflecting the emotions of my manager and my co-workers.

Once I heard a family member quoting, that being fired is one of the most emotional things that can happen to people. The actual message of the firing did not influence my emotions. I somehow reflected the negative wave.

Until a week ago I did not give much thought about it. A common thought would be:
“I take this as a grown up. I won’t budge. No cry.”
But then I had no superman feelings at all.

Some people might say that I was past the denial phase. Or was it “Walk your talk”?

I was rational at that moment. Bad thoughts were not bugging me. I had a stoic attitude during those days. I viewed the loss of a job as a broken shoestring. I just needed a new 1.

Is a stoic approach not a bad way of living? A denial of emotions and focusing on the current steps. I once read a book about stoicism and one of the lessons was to shield myself against negative thoughts and let the positive feelings in.

I still remember that great feeling, when my young co-workers were excited about announcement of the workshop 7 Habits of Highly Effective People. Or feel the excitement of my colleagues on projects. Or that warm smile of me, when I heard “You are all smiling.”, when I told my plan to a friend.

Does this Circle of Influence make me bullet proof against bad feelings? No.
During the writing of this blog post I felt the loss of my former manager and the disappointment of my colleagues. As a tester I am still busy to keep my emotions under control. And I think, that it can be useful to show, that I am not pleased with a particular situation.

I am a testing human being, not a testing robot.

a Test Fuga On 2 A Flat Screens – Part 2

A single note might be forgotten; a melody might be engraved in one’s memory.

Words can be compared with music notes. In most cases a single word does not make much sense for a tester. Performance is too vague, good too ambiguous, funny too personal. In my previous blog post I described, how I had gathered useful information and created test ideas using mind maps. Now I had some groups of words, pieces of a melody. Time for music!

Let’s have a look
Now I had a lot of test ideas. The best way to combine them is to use a test charter. The first test charters were not exciting like “Explore the interface by finding the right buttons for the functions”. This sounds silly, but I could not explore, what I could not find.

So what about the two screens as mentioned in the title? During my test I had two computer screens in front of me. On one screen the Application Under Test was shown, on the other screen my Word Processor. With a turn of my head I could switch between the application and my notes.

Let’s make notes
At the start of my test session I noted relevant information like day, time, version, and test database in my document. Sometimes I described actions I had performed. I did not write all my actions, which would slow down the tests or my flow of thoughts. In case of possible bugs I would go back and describe other relevant steps for a proper repro path or reproduction path of the bug. Print screens were also useful to accelerate the note taking.

The programmer had warned me, that it was not possible to schedule the data exchange. So I only tried to look at the buttons. I found a button and clicked on it by accident. (A typical case of an automatic target seeking index finger.) This was a waste of time. But the application was still stable, so I assessed the situation. I had started the ad hoc operation.

I switched to the Windows Explorer. Maybe some traces of my action were still visible. In a subdirectory for temporary files I found interface files, which had been created shortly before. This was a bug: temporary files must be deleted after use. And a great opportunity to dissect the files.

Let’s cover
The structure of the interface files was relatively simple. So I chose a mind map to record the coverage. For every file a branch was added. For every type of record a sub branch was added to the branch of the file. If the record had passed the tests, I placed an OK icon on the branch. Otherwise a NOK icon was placed.

In case of files with many combinations I once used a spreadsheet to describe the coverage.

Let’s debrief
After the first test charter I noticed, that I spent more than the planned 1 hour. On the other hand I had started testing the most important part of the interface, the files. The one hour limit was too short for a good test session, so I extended it to two hours in later test sessions.

Then I updated my mind maps. I used a partial filled circle icon to indicate, how much I had completed the test charter. Furthermore I used similar icons to mark the progression of my test ideas. So one screen contained my mind map and the other screen my document with my notes.

Let’s ask
Whenever I had any questions, I added those to the mind maps. I marked the branches with question mark icons. A question could be like “How many attempts are made to transfer the files?” After I got the answer, I would put it in the mind map, removed the question mark icon, and updated the test charter mind map, if necessary.

During the test I asked the programmer, whether I had to test both the ad hoc service and the scheduled service in depth. He assured me, that the same code was used for both services. This saved me a lot of time. The heuristic Avoid duplication of code had been used.

Let’s update
Every day I would look to the test ideas to be tested. Then I looked to my test charters. I focused on the test charters with the highest product risks. On a daily basis the mind maps were updated with every piece of information and progression was tracked.

In the meantime the option to schedule services for the interface was gradually implemented. I started to add branches in the information mind map to describe the proper steps to start up the services. Because this process changed regularly, I modified my mind map accordingly. I noticed that my fellow testers also were struggling with services. So I put this information next to the mind maps in the knowledge management system.

Let’s use markers
During the tests I used the two markers TODO and BUG in my notes. After BUG a short description of the unwanted situation was given most of the times accompanied by a print screen. TODO was used to mark down situations, which needed further investigation. If I ran out of ideas during a test session, then I searched for TODO. At the end of the session I would file bug reports for situations marked with BUG. Afterwards BUG was replaced by the defect number and short description.

Over time my use of keywords changed. My notes were a chronological list of actions and print screens. New notes were added at the end of the document. Sometimes it was hard to reproduce bugs. So I used hash tags like in Twitter like #DoubleTime. I replaced the marker BUG with my own test tag. At the end of the document I placed #DoubleTime. Then I started to make notes to reproduce the bug. Of course not all strange situations were reproducible. I noted that and marked it with #Remarkable. In the future strange situations could be found by looking for #Remarkable in the content of the files using Windows Explorer.

This system was still awkward. Now I had two places in the file referring to the same strange situation. Then I started to use indent like this:
01-okt   Invalid value shown on screen

15-okt    used 2, 3, and 5. Not reproducible

Let’s look forward

At the end I stored the latest versions of my mind maps in the knowledge management system of my company. Because the files had been created by a non-standard program, I added images of the mind maps as well. This saved some mouse clicks for the interested reader. I also updated the steps to install the services in a proper way.

It was a nice job. I had experienced exploratory testing and learned a lot. Now it is time for me to move on.

Q&A Deployment Plan Meeting Part 2

Facilitator: Thank you for joining in once again. Han Toan has already answered a lot of questions about Deployment Test Meeting over here. These questions were raised after reading his writing about his Deployment Plan Meeting.

Questions are still coming in. I’ve got green cards from numbers 38, 95, and 12. Number 38, you can ask your question.

Attendee number 38: Did you take the communication styles of the attendees in the meeting into account?

Speaker: During the preparation of the meeting I sent a concept version of the Deployment Plan to all the attendees. So the techies could study all actions and make notes on it.

The project leaders also brought their hard copy. They used it to note down important actions. I would not be surprised, that it was also used for time tracking: will all actions be discussed during the meeting? There were also managers carrying small notebooks.

One of the biggest advantages of the beamer was, that changes were shown. Next to verbal clarifications.


Facilitator: I’ve got green cards from numbers 95, and 12, and 23. Number 95, you can ask your question.

Attendee number 95: A Deployment Plan looks like a scripted test case. People say, that there is no need to make a test case, if it is used once. So why the hassle?

Speaker: I consider the Deployment Plan as a checklist of ordered and dependent actions. Still people might consider it as a time consuming artifact or test case.

Due to the complexity of the system and the number of involved parties it is handy to have some kind of script ready for use. Weeks before the deployment there was enough time to think things over.

Let’s assume I have the idea to have a dinner with my team. There are practical things like the location and time period. But there are also other things to take into account: is the food not too hot by the use of peppers? Or is vegetarian food available? If this is the first time, then it takes some time to arrange it.


Facilitator: I’ve got green cards from numbers 12 and 23. Number 12, you can ask your question.

Attendee number 12: At the beginning of the meeting I would start with introductions. I missed that part in your story.

Speaker: To me it is a logical step, so I skipped it in my writing. But I agree with you, that a round of introductions is needed. I think, that it is good to realise, that you work with human beings with needs and feelings.


Facilitator: Number 23

Attendee number 23: Were enough technical people attending?

Speaker: It was a prerequisite for the meeting. Technical actions had to be discussed. A manager can be helpful, but a techie knows the implications.

To be frank with you, I have to add, that one system administrator was not present. I talked with him about all relevant actions for him. Then I got the assurance, that I could call him during the meeting.


Facilitator: A yellow card from number 38.

Attendee number 38: Were all involved managers involved?

Speaker: Yes, they were. It was relevant to get fast approval for additional actions. During the meeting a techie could look at his manager for approval.


Facilitator: At the moment there are no more questions on the stack. This is your last chance. Okay. I see number 2. Number 7 and number 9. Number 2.

Attendee number 2: What was your Lesson Learned from this meeting?

Speaker: During the meeting I also updated the Deployment Plan myself. This way costed me a lot of energy, because I also wanted to see, how people reacted. The next time I let someone else update the Deployment Plan.


Facilitator: Number 7.

Attendee number 7: Why do you share this story?

Speaker: For me it was a logical step to set up a meeting and be a chairman. It looked effortless to lead this process. It was not completely the case. What is important, that I want to share the steps and actions I took.


Facilitator: Number 2.

Attendee number 2: Why do you share this QA?

Speaker: This is my way to exercise answering questions. It is a quite thorough one, because it can strengthen my story. Sometimes I use the answers, the next time I tell my story.

Furthermore it shows, how K-cards can be used.


Facilitator: There are no more cards on the stack. I hope you had some refreshing blog posts about a deployment plan and a meeting. Next time there will a blog post about more technical stuff.

Have a nice day (and fruitful Deployment Plan Meeting:).


Q&A Deployment Plan Meeting

Facilitator:  Thank you reading “In Case Of Emergeny Press 1“.  I’ve got green cards from numbers 95, 27, 38, and 23. Number 95, you can ask your question.

Attendee number 95: Did you consider Inspection according to Gilb and Graham?

Speaker: I am familiar with the Inspection according to Gilb and Graham. Frankly I did not consider this method. The question should be rephrased as
“Would you choose Inspection according to Gilb and Graham?”.
Looking backwards it is too far fetched. The people should receive proper training and there was just a block of few hours. Another disturbing element is mentioning the most biggest issues first. This can lead to a lot browsing forward and backward through the deployment plan. This can be quite disturbing.


Facilitator: Number 27, you can ask your question.

Attendee number 27: What was your role in the project?

Speaker: My role was a test coordinator.

Facilitator: I’ve got a yellow card from number 68. Number 68.

Attendee number 68: Why did you call for this meeting? It is not your task.

Speaker: I thought, that it was important. The next step is to make things happen: I planned in the meeting and I became the chairman.


Facilitator: There are no more yellow cards for this question on the stack. So we move on the next green card. Number 38.

Attendee number 38: Did the suppliers provide any deployment plans?

Speaker: All the suppliers provided deployment plans.

Attendee no 38: This looks like a time consuming operation. Was there any reluctance?

Speaker: One supplier did not see the benefits at first. Then he made a Deployment Plan after some talking.


Facilitator: At the moment I’ve got one green card from number 23. Number 23.

Attendee no 23: why did you need a deployment plan?

Speaker: I asked my test team the same question. One of the testers told me, that experience taught, that these plans were necessary. A few months before I personally witnessed a rollback.

Facilitator: we have a red card. Number 3.

Attendee no 3: What is a rollback?

Speaker: A rollback is, when the backup is restored. In this particular case also the old system was reinstalled.

Facilitator: we have a yellow card. Is it about the rollback? Okay. Number 17 go ahead.

Attendee no 17: Do you need to test it? The system, which was rolled back.

Speaker: Of course


Facilitator: There are no more yellow cards on the stack. I’ve got green cards from 54, 65, and 78. So number 54, you can ask your question.

Attendee no 54: Which format did you use for the Deployment Plan?

Speaker: I asked and got permission from one of the suppliers to use their Deployment Plan as a starting point. The advantage was, that it was familiar to the employees of this supplier.


Facilitator: I’ve got green cards from 65 and 78. So number 65.

Attendee no 65: Why do you call it an emergency? Nobody got hurt.

Speaker: How do you call a situation with a person cutting someone’s tent? And what would happen, if this person is caught in the act?
How do you call a situation with a system, which cannot be used right after the deployment?

Attendee no 65: [nods]


Facilitator: I’ve got green cards from numbers 78, 95 and 24. Number 78, you can ask your question.

Attendee no 78: Looking at your technical background it seems easy to be a chairman. Do you know everything?

Speaker: I do not know everything. I cannot know everything.

Attendee no 78: Did you not feel vulnerable?

Speaker: At certain points of the meeting I was vulnerable. Quite vulnerable. But I was also confident, that we could make a deployment plan as a group. Sometimes I had to ask for support and I got it.


Facilitator: No yellow cards. Number 95.

Attendee no 95: So technical knowledge and experience are not necessary?

Speaker: The important thing is to have a safe environment. A place, where people can voice their thoughts.
In order to discuss all actions I chose a business way of meeting. Please stick to facts. And we’re all here to accomplish something like a group.
I watched for body language. If I was not sure, then I stated the action, looked to the person and became silent.


Facilitator: I’ve got green cards from numbers 24, 38, and 23. Number 24, you can ask your question.

Attendee no 24: You added a new blog category: A leader ships. Did you ship? A Deployment Plan is just an artifact.

Speaker: I once read something along the line like System must solve the problem. If the deployment is bad, even the best system cannot solve a problem.


Facilitator: I’ve got green cards from numbers 38 and 23. Number 38, you can ask your question.

Attendee no 38: What have juggling and testing in common? You are talking about a hobby and job. These are two separate things for me.

Speaker: I have question in return: would you please summarise both stories in 4 words?

Attendee no 38: What about: good planning withstands emergency.

Speaker: So you plan the emergency?

Attendee no 38: I need some What If Scenarios, if things go wrong.

Speaker: So you want to make a scenario for every possible situation like overloaded network, a comet paying a visit, etcetera. There are a lot of scenarios to ponder upon. I suggest: Plan to anticipate emergency. In this case: complete rollback.

[To be continued here.]

In Case Of Emergency Press 1

Speaker: Welcome to my writing “In Case Of Emergency Press 1”. My name is Han Toan Lim. I want to share some stories with you.

Facilitator: There is an opportunity to ask questions using K-cards. More information can be found here.

Speaker: In the weeks after the Dutch Juggling Convention in 1992 a new story circulated in the Dutch juggling community. During the Public Show some people had paid an undesirable visit to the camping site. There were no guards.
“Right after the convention I would be camping. The convention [in Delft] looked like a good rehearsal, then someone made some cuts in my tent.”, a juggler told me with a bit of disappointment.
Another juggler was really upset:
“They took my knife from my tent.”
Somehow this unwanted visit was not anticipated. Over the years the story was shared less and less, but it still stung me.

Now it is time for a flash forward. Several projects were weeks from the deployment. I had pressed for a meeting and finally my project manager had agreed. During the preparation of this meeting I had merged 3 Deployment Plans of the three systems on the same day. I had still doubts about the completeness of this resulting plan. All suppliers and other involved parties of the client were present. I was the chairman.

I began with stating the goal of the meeting: everyone should know, what and when they should do in order to deploy 3 systems on the same day. On the screen I showed a gantt chart made in a spreadsheet program. It was an updated version of the team lead of system administration. The time blocks for the deployments of each system was shown. Other time blocks were for preparation and wrap ups. Then it was time to go one level deeper. On the screen the latest version of the Deployment Plan was shown by me in a spreadsheet. The first activities took me some time to let the attendees make themselves familiar with the structure of the plan.

Facilitator: We’ve got a red card.
Attendee 95: What do you mean with “make themselves familiar” with the Deployment Plan?
Speaker: The Deployment Plan was a big table in a spreadsheet. So the size could distract the reader. So I first explained the heading from left to right. Then I went slowly through the first action. So the attendees could listen or read the information with enough time for reflection. Does this answer your question?
Attendee 95: Yes
Facilitator: I see no more red cards. So you can continue.

Speaker: The following pattern arised. I read the action aloud and made sure, that the person, who was assigned the task, fully understood the task. I questioned or let it questioned in different ways:

  • Do you really understand this action?
  • Are other actions needed?
  • Are the actions planned in the right order?

I preferred, that other participants voiced their thoughts. This was beneficial for the group interaction. It was not my one man show after all.

Let me focus on one particular action, restoring the backup. If the deployment would be stopped, then a rollback of the old systems had to take place. So a backup should be restored. But it takes a while to make a good one. To be more precisely one working day. So people had to be instructed, that the systems could only be used for retrieving information and not for storing new information. Some of these actions had not been planned in.

Because no abstract actions had to be discussed, it was relatively easy to describe the specific actions. If there was agreement about the action, then I immediately updated the deployment plan on the screen. If the description of the action was still ambiguous, then people had the opportunity to clarify it.

Then came the part of the failed deployment. Some attendees were reluctant to talk about it. There might be different reasons: the actual steps for a successful deployment were discussed in depth, so they probably would not be needed. Another guess of mine was, that after 2 hours of meeting people were tired.

Afterwards I got the compliment: “You did well.”

This writing I would like to end with a Lesson Used. So time for a flashback.

In 2002 I went to one of the organisers of the Dutch Juggling Convention in Amsterdam. He told me:
“I’ve got some flowers for you.”
Before I could digest the information, he continued with:
“Right after the Public Show we asked the volunteer coordinators on stage. We called Nienke [and gave her flowers].”
Then I said:
“The other volunteer coordinator is Han Toan Lim. He is not here. He’s watching the camping site.”
He waited a moment.
“They gave you the biggest round of applause.”
At that moment I was just relieved, that no bad things had taken place at the convention’s camping site.

I thank for your attention.

Facilitator: You can ask questions using this form. I have already 4 green cards.

[To be continued here.]