Category Archives: Business

An Inspired Evening

Every company has its own way to engage with his users. Some years ago,  my team members and I spent an evening with the users.

The invitation

One day I received a mail asking for volunteers. It was for a special session. I was curious, so I asked the other testers about it.
“The backlog contains a lot of tickets. So, once in a while user representatives will choose items they want to be solved.”

It was difficult for me to imagine how things would evolve. The other tester continued with: “The programmers will program the solution on that very evening.”

There was no need for extensive documentation and discussion. It was about asking and making it work. Because this sounded agile to me, I volunteered as a tester.

The preparation

In the following weeks the team for the session slowly began to form. There were 3 programmers. An analyst also joined. People with different skill sets were on board.

Welcome in the club.

The selection of the tickets was a balancing act. On one hand a ticket should add real value to the users. On the other hand, it should not take too much time to solve it. The outcome of the session would be a set of solved tickets, which annoyed the users for a long time.

As expected, the users sent a big list to the product owner. In turn he sent the tickets to the programmers. Another selection took place.

During the days before the session, I heard the words “Too big” in different volumes. I interpreted “Too big” in a normal tone as “Solving this ticket will cost a big deal of the session.”. A shouted “Too big” sounded to me like “We need more than 1 session.”.

The meal

The evening started with a meal. Users recognised some developers. There was some small talk.

The session

After the meal we moved to a room with a big table for the laptops. On one wall a big screen was attached.

The problem

The first Jira ticket was shown on a big screen. This was not the application they were looking for. I noticed that the users were disturbed. Imagine your problem described in an unfamiliar form. It was a wall of text. This was not a good start.

A user representative also saw the confused look on the faces of her colleagues and started to talk. Everyone started to look at her instead of that screen with all that text.

She started with “You know that window with …”. People began to nod, while she continued to describe the window and the functions. “Now the problem is, that …”, she continued. Annoyance could be felt, when she described the details.

Then she told: “It would be great, if …” followed by a solution. Her peers showed appreciation for the proposal. She ended with: “Other things to take into account, are …” followed by domain knowledge and their way of working.

She told a first-hand user story. Nothing was lost in translation. There is no shorter path to a user than the shortcut I just described.

The clarification

The single male programmer stepped forward: “I take this one.”

“Can you plug me in?”, he asked. Someone connected his laptop to the big screen. The users saw a familiar window. This was the application they were looking for.

The programmer continued: “So you want the buttons on this window?” Users nodded their heads. The mouse pointer moved to two different locations: “I can place a button here. And here. It will look similar like …”

“this screen”. The programmer was now showing another window on the big screen. “Here are the buttons placed on similar locations.” This sounded good enough for the users.

The laptop of the programmer was disconnected and the next Jira ticket was shown.

The queue

This time the user representative scanned the text in a few seconds and started to talk about the problem, a possible solution, and other relevant information.

Then the first female programmer asked the second female programmer: “Shall I take this one?”
“Yes”
Another round of questions and answers followed. Then she started to program.

Rinse and repeat

Then it was the turn of the user representative and the second female programmer to repeat all the steps for the next Jira ticket.

The wait

It was silent in the room. Three programmers were ticking on their laptops. The other people were quiet.

Once in a while a programmer would ask some questions:
“You wanted to order things.”
A nod followed.
“Is the order ascending?”
“Yes, that would be handy.”

And the silence started again.

The demo

After a while the male programmer said: “I want to show something.” His laptop was connected to the big screen. “On the window I added the buttons.”, while pointing them with the mouse pointer.

“If I do this, …”, he pushed a button, “then this happens.” He told how the buttons interacted with the window.

The 6 users started to ask questions. Some of them were answered by a small demonstration of the application. This was the fix they were looking for.

The business analyst and I were also looking from other perspectives:

  • What is the consequence of the shown information?
  • What happens, if …?

After all the questions were answered, the programmer was available for the next ticket.

The stack

During the evening the stack of tickets slowly decreased. Three different user stories were taken care of at the same time.

The closing

Towards the end of the session the tickets were chosen were with more care: could it be fixed before the end of the session?

I think I can make it.

At the end there was a positive buzz in the air. An evening of working after a complete workday had tired the participants of the session. Afterwards people talked a little before going home.

The follow up

It was a productive evening. The programmers had solved some annoying problems for the users. These were the fixes they were looking for.

The programmers had worked in a development environment, so the fixes were not available on the workplace of the users the next day. The code had to be merged with the code for the next release. Then standard tests and regression test had to be executed by the testers.

The context

It is tempting to compare Jira tickets with low hanging fruit. Is it interesting to invite 6 users for a few hours in an evening to see a development team picking 1 apple?

Strawberries are hanging lower than apples: are 100 strawberries more worthwhile than 100 apples? There are also different strawberries: are green strawberries more worthwhile than red strawberries?

In this company the time to fix the ticket and the value of the ticket were used for the selection of the tickets. These factors might be different for another company.

Later I shared this experience with different companies, but it was not applicable.

Your mileage may vary.

Can we scale down the tests? Part 2

Sometimes you have a harmonica with the wrong scale. It is hard to scale it down.  A simple solution is to buy harmonicas in all scales. It will cost time and money, but it might save the day.

If a manager walks into your cubicle with a suggestion to scale down tests, then it is time to get the big picture before the decision to skip tests. Let’s go back to George.

Quality is an option

At eleven o’ clock in the morning George joined the meeting of the software testers. Cynthia was not looking very happy.
“What’s wrong with you, Cynthia?”, George asked.
“Management decided to skip the user acceptance test for the navigation system to save time.”, Cynthia answered.
“Did you point out the consequences?”
“Of course the interface can really be improved.”
“Can you prove it?”
“Sure.”
“OK, let’s call the PO for his opinion.”

John joined the meeting of the software testers.
“Hi Cynthia, this is supposed to be a tester only meeting.”
“You are welcome.” Cynthia reassured him. “We won’t bite you.”
“Would you give me a permission to let the other testers have a look to the navigation system?”
“No problem.”

George was studying his laptop.
“According to the user story it is possible to enter the right destination using voice commands within 10 seconds.
Your aunt asked you to come to Paris, which is in the neighborhood of Tupelo.”

First test:
“The destination is Paris.”, Pete said.
“What is destination?” was the answer of the navigation system.
“I want to go to Paris.”
“What means “I want to”?”
“Go to Paris.”
“Go to Paris go to Paris is an invalid voice command.”

Second test:
“Go to Paris.”
“Do you want to go to Paris in Arkansas, Paris in California, Paris in Idaho, Paris in Illinois, Paris in Kentucky, Paris in Maine, Paris in Michigan, Paris in Mississippi, Paris in Missouri, Paris in New York, Paris in Ohio, Paris in Pennsylvania, Paris in Tennessee, Paris in Texas, Paris in Virginia, Paris in Grant County in Wisconsin or Paris in Kenosha County in Wisconsin?”

Third test:
“Go to Paris in the neighborhood of Tupelo.”
“What is neighborhood?”
“Begin again.”
“Go to Paris, which is near Tupelo.”
“How far is near?”
“I don’t know.”
“Give an estimation.”
“I don’t know.”

Fourth test:
“Go to Paris via Tupelo.”
“Do you want to go to Paris in Arkansas, Paris in California, Paris in Idaho, Paris in Illinois, Paris in Kentucky, Paris in Maine, Paris in Michigan, Paris in Mississippi, Paris in Missouri, Paris in New York, Paris in Ohio, Paris in Pennsylvania, Paris in Tennessee, Paris in Texas, Paris in Virginia, Paris in Grant County in Wisconsin or Paris in Kenosha County in Wisconsin?”

Fifth test:
“Go to Tupelo.”
“The destination is Tupelo.”
“Go to Paris, which is closest to Tupelo.”
“Give an estimation.”
“Uuuuuh.”
”What is Uuuuuh?”

George looked at the PO:
“Do you think, that a user acceptance test is a considerable option?”

Sound check (and other interesting things in other backyards)

Xoun is a strange brand name to pronounce. The question is, whether this sounds right to shopping people. If you turn the picture upside down, you will read a known brand name in the Netherlands. (Which I associate with a mug with welcome warm soup after hours of sailing on the lakes in Friesland.) By taking a different view some things might need more attention than you might expect. In this article I will tell about three situations, in which non IT related information can be helpful for an IT engineer.

Granting a small favour

In the nineties my customer planned in a special activity to introduce internet to his employees. So I ended up talking with a woman from the legal department. She stated, that shipping information should always be mentioned. It would save her department and company a lot of time and money.

A few weeks later it was time for my courtesy call. I called the lady from the legal department. After a short introduction I came to the point: “I just discovered, that your company is selling products on the internet. I could not find the shipping information.” A silence followed, so I had to repeat the message. A muffled “Thank you” followed. A few days later the web shop was off line.

In case of surprise

A special meeting was planned and the project manager was constantly talking about Rbbit. After a while I figured out, that the Rbbit was not a nice white fluffy animal appearing in the magician’s hat, but a Big Bug in the software system. “Two weeks ago we had a Rbbit. Last week we had a Rbbit. What do you expect for next week?” I answered, that another Big Bug would show up. “What are we going to do?”. I spoke up again: “I would set up an emergency procedure.” The project manager was not pleased with the answer: “Do you expect, that I will restore the complete database?”

“If wrong information is sent to the customers, then a new mail must be sent to them, that they should ignore the information in the sent mail. You could also add information, when the right information will be sent. The next step is to investigate and solve the problem.” The project manager finally agreed: he needed phone numbers of people in the operations department and operational measures.

What’s it in for them?

As a software tester it is very tempting to use different plug ins in your browser to analyse web sites. During one of my trials I encountered a tool, which provided me much information. I did not understand, why the tool was given away for free. The web site for the plug in tool was basically stressing the benefits. At that moment I was doubtful, whether I had installed malware.

After more extensive searches on the web I discovered a related business web site, which offered information about websites. This information was gathered by users using the above mentioned plug in. So the business model was as follows: determine, which information is useful for IT people. Provide a free tool for collecting information and sell the gathered information with a nice profit.