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 Delegate Report about TestNet Spring Event 2016

There are some main stream test events, which I cannot ignore. I just need to be there. Enter TestNet Spring Event 2016.

The Dutch Special interest Group in Software Testing, TestNet, had another free congress for his members: workshops, lectures, meals, etc. from 9 am to 10 pm. All for a yearly contribution under 90 Euro, which also includes an Autumn Event, peer meetings, and a congress with sponsored workshops. Did I mention the working parties?
It’s not cheap, it’s good.

Disclosure: I confess that I was a board member of this SIG, your honour.

5 lifehacks in a beginning scrum team

Eric van der Marck was called a first time speaker, who took his listeners with him on his journey through the scrum world. He talked his encounters with end users. He started to walk like a cowboy: “They are wearing a can of pepper spray and a gun.”

In order to illustrate his points he had nice examples with lots of interactions with the attendees. Pairing was useful even with different roles. He asked a programmer during a review about the code. He knew that he would ask irrelevant questions. And still there were some moments of hesitation and insight from the programmer’s side.

He also worked for a Police project. The agents needed a handheld device, which could be used in a simple way. My first reaction was unbelief, until he explained the context. If an agent talks to a possibly dangerous person, he /she wants to watch the person all the time. The same with a victim.

Eric had a preference for good documentation. Not only for the dreaded audit, but also for helping team members. An attendee asked why the documentation was not in the code. Eric responded that the documentation was also used by end users. Then he described the reaction of an agent looking at code.
“The moment I show him code I lose him. [Silence of 3 seconds]
They are smart. [Silence of 1 second]
In other way.”

With all kind of tools available he described, what happened, when test cases are attached to Jira tickets.
“For a regression test you have to browse through all these tickets.”
A rather unpleasant task indeed.
He advocated Confluence for test case administration and Gliffy, an add on for Confluence, to make process flows in order to track the test coverage.

Eric ended the story with coaching. How to make people better scrum members.

Agile Testing Survival Guide

Ingo Philip is an employee of a test tool supplier. I groaned inside. I was sitting in the front row and suppressed my urge to flee to another session. Ingo promised, that he would not mention his company again. I relaxed a bit.

Ingo remarked that there were redundant test cases. The basic cause is user stories, which might have overlapping acceptance criteria. These had corresponding test cases in turn. So he suggested to consider functionality grouped test cases. While blogging I started to miss a process flow test or data flow test.

Next he suggested to look at patterns in the past. Risk analysis was a helpful tool. For each feature good risk coverage should be obtained during testing. In an example some features had risk coverage of 50 %. Nice for statistics, but pretty abstract for me. Then I added all risk coverages of the features and got a result over 100%.

That was the moment to raise my arm for a clarification. Ingo noticed me and delayed the question to the Q & A section.

Heading towards the wall he described how test cases could be weighted using information from the past. He turned the steering wheel a bit by pointing out that deviations could not be predicted. Then unexpectedly he mentioned Exploratory Testing as a good supplement for test cases. ET could address unseen or other risks than test cases. Just missed the wall by a few nanometres.

In the last part of the talk Ingo described a case about a regression test: test case reduction using the previously described method including the risk coverage, automatic test data generation, automated tests in several forms and frequencies. I recognised a pattern of another talk: determine a small set, which can be used for a fastback feedback, and distribute the tests over several servers to reduce the execution time.

At the end I finally got a chance to ask about risk coverage. I picked up factors like frequency and potential damage, then the facilitator stopped the explanation. Ingo gave me an invitation to go to the booth for more information. But I came for the talk. His talk.

So
time to leave the premises. A few things to mulch about. Or blog about.