Category Archives: AgiLe

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?”
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.

House Rules For Rules

A few years ago my wife asked me to attach some tubes to the wall. I noticed that there was little room for a wrench. So I used a ratchet wrench as shown in the picture.

There is an unwritten rule to use a wrench for a nut and a bolt.

There is no rule for the type of wrench.

Proof in the pudding

In the kitchen one of my kids was stirring in a pan:
“30 seconds should be enough, but I think it is not enough.”

I stopped with my actions:
“Is that not long?”

“Last time it went all right.”
I tried to remember the taste, the structure, and the smell of the dish. But I had only positive thoughts.

I remarked:
“First you follow the rules. Then you must change them.”

“Must?” was the reaction.
“I mean: if you think it will make things better.”

“Your boss will not be happy.”, my kid remarked.

“If you stick to the rules, then you will not become better than your teacher.
Otherwise everything will remain the same.

Not all experiments will go right, so you need some room.

My boss is also experimenting:
“I have this product.”
Customers will give feedback:
“We would like to have another product.””

Agile Manifesto during test

The appointed ticket was about a business rule. I had done all the preparation stuff and I only had to analyse the data. In most cases a front end or a good looking application is enough to determine the quality of the work. In this case it would miss a lot of points. A front end shows a summary of the data in the database. And a summary was not enough for this case. I mean database.

What I write down, is a sanitised version of the story: all confidential stuff has been changed.

Individuals and interactions over processes and tools

I opened the database client. With this program I can easily browse through the tables. I got a connection error. That was not a good start. I retried to establish a connection and got the same connection error. I tried another server: same connection problem.
At this point I could just stop. Hey, I am a …. professional tester.

I had to start to analyse my test environment. I am not someone who runs to the helpdesk on the first encounter with an error. So I tried to make a connection with a terminal. This connection was possible which I did not expect. But thanks anyways.

Now I had a connection with the right server, I could do more things. Yes, the test environment was right back in my mind.
I remembered that it was possible to use a primitive database tool. I could use a database prompt, which let me query the database. I entered a command in the terminal: unknown command.
I switched to a browser and just entered the wrong command in the search engine, which suggested the right spelling. Using this command I saw a database prompt. The internet has lots of knowledge. Now I could use my queries from the day before.

I called a fellow devops and explained the situation. I reported about my failed attempts with the database client and he agreed that the database prompt was feasible for testing.

He told me how to connect to the right database. Thanks.
And off I tested.

Working software over comprehensive documentation

While I was still figuring out my test environment I realised, that I had forgotten to log. I opened a template of a test charter. It contained useful information like date, name, and application. Mine was based on some templates. Thanks Jean-Paul.

During my exploration I wrote some quick notes in my charter. They were mental notes to me. At the end of the day I would put a comprehensible summary in the ticket.

I copied the query from a file to the database prompt and pressed the Enter key. The database tool gave feedback, that the queries could not be used. Did I mention 1 query by the way?

My query contained multiple lines which were interpreted as multiple queries. There was some logic in it. E.g.
“Show the dates
of all Saturdays in 2017.”
The tool processed “Show the dates.” as follows:
“I have dates in my databases, but I am not sure which table: the birthdays, the working days or the school Holiday days.”
The second line “of all Saturdays in 2017.” would be interpreted like
“What would you like to know about the Saturdays in 2017? The times of the sunset or the number of Saturdays?”

My fellow devops had mentioned the option to execute the database prompt with the parameter /i. This stands for input file. This is a time saver.
So I left the database prompt and saw the system prompt again.

I executed the database tool with /i query file.
I got a response that /i was an invalid parameter.

Time to get help from the database tool:
I execute the tool with /help.
I got a list of all valid parameters and their usage. Then I settled for /f, which is short for input file.

During the next attempt I executed the database tool with /f query file. And I got a decent feedback from the database.

Both my hands went in the air.!!

Responding to change over following a plan

My plan was to use a nice looking database client and I ended up with a rough and tough database tool. Okay, but I could deliver value.

I looked to the output of the file and it was hard to read. All data was shown in ASCII or text. No table for easy scrolling and reading. No fancy stuff. The table was shown in multiple line: the header was scattered over several lines and the same was true for every record. So it was hard for me to determine which attribute was linked to which value.

I put the data in a text editor. It was still hard to read. I had to remove line breaks. No way.
But I did not need all the attributes. Oops, I was hoarding data again.
So I reduced the number of attributes to a minimal set. I accidentally maximised the window of the terminal and all data was shown in more readable table.

Now a new pattern emerged:

  • Adjust the file with query in an editor.
  • Go to the system prompt.
  • Execute the database tool with the latest version of the file.
  • Look at the output.
  • Correct the query.
  • And start again.

All that opening and closing of the input file was quite cumbersome.  I felt like a file jockey. So I opened a second terminal. Now I had one screen with the query in an editor and another screen for the execution of the database tool and analysis of the output.

Time for a tweet.

Customer collaboration over contract negotiation

After reading the Agile Manifesto I realised that I had not really listened to the customer or her/ his proxy.

The next working day I went to the business to talk about the business rule. Did I really interpret this well? Instead of conditions and codes I heard a story, what the story was about. About people who needed the right service.

PS Task 4