Category Archives: Cooperation

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

House rules for bug reports

Some people liked the TV serie about a doctor with a walking stick. This blog is about rules, which are applicable in a company or an office

“There is 1 rule: There are no rules.”
3rd movie about Mad Max

“This is not logical.”
Leonard Nimoy

Let me finish
The most dreaded part of the game: she or he will win for sure. Or worse we have to hang on for another hour. Of mental mockery. This is a sign of unbalanced game. A game you only play once. I am not writing about life here. This is not serious.

Some smart people developed some house rules to balance the game or to accelerate the game. Preferably both.

There is also some serious stuff to do.

One of the basic skills of a tester is to write decent bug reports. There are complete courses for them. I want to share some of my thoughts about them. Particular how house rules are applied to bug reports.

The trick for a good tester is to find the house rules for bug reports. Sometimes they are familiar. Let’s examine an imaginary situation.

  • Select movie Monsters Unlimited.
  • Select two for tickets.
  • Press Next.
  • Add Cola.
  • Set Cola to 1.
  • Add Lemonade.
  • Set Lemonade to 2

Actual situation:
The following message is shown: “You ordered too many drinks.”

Expected result:
It must be possible to order more than 1 drink per ticket. A warning should be shown.

That looks like a pretty example, how to describe a problem.

Let me determine some house rules:

  • Every button press is described.
  • It is completely repeatable.
  • The actions are described in an objective way. No hard feelings. Devoid of emotions.

This is logical.
Leonard Nimoy.

  • It describes what I would expect as a tester.

There are some serious drawbacks:

  • It is hard to read for a dev.
    One dev once gave up after reading my reports.
  • It took me time to write it well.
    You might have notice the tickets and drinks are set in different ways. And I am quite experienced.
  • A standard reaction is: “No user would ever do that.”
    Bug reports are not about proving the odds, but about telling the plausible.

So the trick is to modify or add house rules for bug reports. As a tester I have to make reports. As a dev someone else has to solve them.

It is time for Finding Marlin
“Finding Marlin you wrote?”
“Yep and I …”
“Don’t write any more.” [I just did.]
“It is about three fishes. Now the dad has been caught. Now his son and his blue thin friend whose name I always forget, go on a heroic journey to get dad back.”
What is your favourite sea dweller?”
“Dolphin..”
“So the dolphins are going to help.
And…”

“Thanks for your help.”
“Huh, I was just brainstorming about a movie spoiler. ”
“You just described a realistic situation, what people do in a particular situation.”
“Talking about fish?”
“Yes and showing how people can act in a natural way. ”
“I just happen to like movies.”
“And that’s what makes this talk completely plausible.”

Actually, Marlin stands for ‘Make a real life impression now’.

If I can tell a realistic user story, then devs are compelling to solve the problem. It is not something like this:
“As a cinema visitor I want to order my snacks and drinks before the visit, so I can save time.”
This is an abstraction.

It is about thoughts and needs. Let’s read a mind.
“In the movie Monster Unlimited there are too many monsters, so Mike and his blue furry friend have to move to the desert. That thought makes me thirsty. I need 2 lemonades for sure ”

Is this plausible? I think so.
Let’s ask the PO or Product Owner. Fine with you? So what are we waiting for?

Let’s tweak again
I do a small rewrite of my three drink bug report:

  • Order two tickets for Monsters Unlimited.
    [Hey. That is great. I can order my drinks in advance. Let me see]
  • Order 1 Cola.
    [Looking at a desert makes me thirsty, so I take an extra drink.]
  • Order 2 lemonades.

Actual result:
A message is shown, that at most 2 drinks can be ordered. [I need that drink. This is ridiculous.]

Expected result:

It must be possible to order more than 1 drink per ticket. A warning should be shown. [I take the consequences].

Let me extract some modified and new house rules:

  • The actions are written in a more natural way.
    This speeds up my reporting and it is more readable. I am not programming the programmer. I wouldn’t dare to.
  • Thoughts have been added, so people can identify themselves with the user.
  • Emotion has been added.
    This is a dangerous one. It is extremely helpful in the steps and can become harmful in the actual result. My thumb of ruie is, that it is allowed for a customer and in a few cases for a tester. A customer is not always a tester.

Are you in for a little experience? Have another read.

  • Order two tickets for Monsters Unlimited.
  • Order 1 Cola.
  • Order 2 lemonades.

Actual result:
A message is shown, that at most 2 drinks can be ordered. [This is ridiculous.]

Expected result:

It must be possible to order more than 1 drink per ticket. A warning should be shown.

“This is ridiculous,” sounds a lot harder than in the first rewrite, when only 1 thought has been added.

I will come back to the emotional part later and a few decimeters lower.

A more important question is: Why did I stop the presses? I mean the description of presses on a button or mouse.

This might be a lack of detail for some people.
“You ordered 1 cola and 2 lemonades. Right?”
“Yep.”
“So how did you do it?
Add 1 cola, add 1 lemonade and add 1 lemonade.
Or was it: add 2 colas, drop 1 cola, add 2 lemonades.
Or: add 1 cola, add 1 ginger ale. Drop 1 ginger ale, add 2 lemonades
I could even add some steps to go back, select Finding Marlin, order 2 drinks, change movie to Monsters unlimited, add third drink. But you wrote, that you did not do this. … Maybe.”

Sometimes programmers are great debriefers for testing.
What did you actually do? Why do you think this was a useful test? Did you also have a look at the other features? Did you also check the interaction with the other modules?

“They scare, because they care?”
That is not the appropriate way to write about devs. I do not have to fear, if I can answer their questions. And yeah I make mistakes like devs. Then I have to admit, that I was wrong.

Back to the example:

  • Order 1 Cola.
    [Looking at a desert makes me thirsty, so I take an extra drink.]
  • Order 2 lemonades.

Now I can make another house rule: take the shortest route.
Of course the devs have to agree. Then you have a new rule. In da house.

Can this lead to a discussion?
You bet.

“Did you test other combinations?”
“No, I was just exploring the web site.”
“Did you know you cannot order the lemonade in the winter?”
“No”
“So you better test it. It took me some time to program that.”
“Thanks for the information. I wonder how I can change the system time. Maybe you can help?”
“Well that is easy. You …”
I just leave these 2 techies alone. I have another interesting section coming up. In the meantime ..

is a scenic tour also plausible:

  • Order 3 donkeys.
  • Order 2 dragons.
  • Reduce the number of donkeys to 1.
  • Reduce the number of dragons to 1.

This is still the shortest route. Every step was needed.
You might call it Advanced Donkeys and Dragons. So long the troll stays away.

Lectori Ludum – Game for the reader
The game shown in the picture is the pocket version of the Hive. It is a 3 dimensional game and it has house rules.  And it is about bugs.
I like it’s complexity. In case you want to buy it, you could use this link.
End of commercial break.

Let me get emotional
I promised you to explain, why emotions are important. I already gave a small hint.

This is something I experienced.
I was in the hospital. The nurse behind the desk tried to formulate excuses to me:
“I did not give [your case] a high priority. You sounded completely in control. ”

This is a big disadvantage of being a tester. I had been programmed – I know: bad word choice. – to give an objective report, which put me in the middle of the line.

A bug report is a thing I not only make for work, but also in private life. If I don’t like something, then I want to get things fixed. So if I order a book and the book is damaged on arrival, I file a bug report. If the book seller does not provide a good service, I get angry. So why can I not show anger to get things fixed?

Do users of software have needs and feelings?
I think they do.
What about persona?

This is a description of customer with all her or his interesting characteristics. A good name can help a lot.

I do not have any experience with it. Personally I think it can be useful. No pun intended. I am a personal ally of the User experience or UX designer. That’s an intended pun.

Let’s start a thought experiment.
So we have the excited Kid, the bragging teenager, the unlimited cinema visitor, ….

Of course the excited kid will not handle the payment on a cinema web site, but she or he will definitely want to choose her or his own drink and snacks. “Dad, how can I order a Cola? It has already been chosen.”

A small side step.
For marketing people this is cool: can I sell packages to the kids?
For the regular movie visitor a limited collectible cup for the drink can be quite tempting. Gotta have them all.

Back to the Excited kid.
“Dad, did you really choose Finding Marlin?”
“Yes, I did. Just pick your drink and snack, dear.”
“What is a kid package?”
“I think it is a drink, a snack and maybe a toy in a box. Does the web site show some description?”
[A little silence]
“I can use a link. Yes you are right, dad. ”

[Another little silence]
“How can I get back on the page?”
“Push the back button.”
“It does not work.”
“Just close the tab.”
“It works.

Where is the page for the drinks and snacks? I cannot find it dad.”
“Let me have a look dear. That is strange I cannot find the tickets.
We have to start all over again.
O dear, all tickets have been sold out.”
This will start an outburst of emotions. In turn these form a good starting point for Non Violent Communication.

Last week while I was still assembling this blog post, I saw a tweet of Santosh asking about NVC. He had read a conversation between Jari and Lucian. And he couldn’t resist himself to “barge” in. I sent him a link to some basic  resources.

NVC stands for Non Violent Communication. This model uses 4 elements: observation, feeling, need, request. Luckily there is a cinema example available for use.

  • Observation
    The kid tried to figure out, what a kid package was. This led to a situation, that tickets were lost.
  • Feeling
    The kid is sad and the dad angry.
  • Need
    The kid has a need to share: to tell about the movie at school. The dad has a need for independence, that his kid can order her or his own drink and snack.
  • Request
    Would you please provide a way to show information about the kid package without losing the ordered tickets?

Browsing through these four elements makes the request reasonable. I am tempted enough to call it logical.

[Answer on, why his parents married]
“That was logical.”
Leonard Nimoy [TV serie]

By the way it took me a while to determine the need of the angry dad on https://www.cnvc.org/Training/needs-inventory. A need is personal. The basic thing is to describe the point of the view of the user. As an observer I have to be very careful to fill in the need of the user. It is not possible to read one’s mnd, but it is possible to ask about someone’s need.

Now I am quite close to the heart of the bug report. If someone asks to solve a bug report, then it is easy to program the expected result. If I test something, it is easy to check only for the expected result. And of course I can test all the other impacted functions and data, but does it really solve the problem?

Let’s have another look at the kid package problem.
A programmer could program the interaction as follows:

  • if the mouse is on the kid package, a small message will be shown containing the description of the package.
  • The message will disappear, if the mouse is moved.

As a tester I can easily determine, that the impact on the data and features is minimal. So it looks easy to test.

Well. There is a huge problem lurking there.

Let’s take a closer look
“So I have 2 tickets for Finding Marlin, 1 cola, and 1 carrot.”
“A carrot?”
“What’s up, doc?

So I go to the ticket counter and get tickets, the package, the drink and the veggie.”
“No, you only get the tickets. The rest you have to collect in the shop.”
“Why?”
“There is no place for all the snacks and drinks.”
“Sounds fair to me.”

“If I enter the shop I pick up my order and continue to the movie.”
“You actually have to collect all your ordered stuff yourself.”
“Why?”
“Just imagine a cola standing there for a few hours. It might have less bubbles and is warmer. Now think about ice creams. Or your carrot’s waiting days for a nibble.”
“You’ve got a point.”

“But where does it state that I have to collect all the stuff?”
“It is on the voucher.”
“Which voucher?”
“The one you get at the ticket counter.”
“Okay. Can you please show me 1?”
“Sure. Here’s one.”
“Hm that is small font.
That means I still have to be 10 minutes earlier to collect my order.”
“Uhuh.”

“So I collected.my order, I show my voucher and see the movie.”
“Yes, you just go to the counters to claim the voucher.”
“Wait. You said counters. But I do not have to pay again.”
“The counters have a scanner for the vouchers. There are so many orders, that there is no standard voucher.”
“Okay, let me summarise again.”
“Collect order, go to the counters, show voucher and see movie.”
“You’ve got it.”

“So I go with my voucher to the voucher queue.”
“There is no voucher queue.”
“Wait a minute. I have to get in the same queue like the other people.”
“Yes.”

“But there are no real benefits to the service. I only pay in advance.”
“Yes, but I like the idea of a special voucher counter.”

“The user story was:
‘As a cinema visitor I want to order my snacks and drinks before the visit, so I can save time.’
If I look for a need, i would say the need for ease. Within minutes I should get everything: just show the tickets and collect everything.

What about this?
How much time does it take to collect the order for a customer?”
“3 minutes.”
“So if I couple the GPS location of the customer to the order, then it is easy to collect the order. What about that?
Faster service and happier customers. Just make them smile.

And I could continue writing about what to do with the money in case if the customer does not show up. Or the customer changes his mind over the snack. Every solution should be focused on the need for ease.

Let me speed up the reporting
Navigation can be compressed using arrows. E.g. Menu => New.
If too many arrows are used, then the user experience should be improved.

It is possible to save time by adding bug descriptions in the comments instead of linking new bug reports to the report. If the devs can keep up with your pace of reporting, this saves lots of time. In one project I had a supplier, who had no overview and was slow. Then separate bug reports were extremely handy.

During my first year in an agile team
“I found a bug.
Do I have to report it?”
“You can talk about it?”
“So I do not have to write it.”, I wondered.
“We are talking.”, my scrum master answered with a smile.

Let me think
Post Ludum [After the game]
A continuing thought from me: are there other house rules to break? For better quality of life and work.

Why am I now thinking about retrospectives? It must be a flash of insight. I just wrote one : )

 

 

 

 

 

 

Let me write
I thank you for that.

Let me talk
I wanted to write a small blog post about bug reports and it almost turned into a talk. Too many stories in my head. So …

my proposals for talks for test conferences will be sent in the following months.

Let me thank you.
Thanks for reading. Real thanks again.

Pizza dough though

One of my kids read the recipe.
“Now we need salt. So I take the Baker’s Salt.”
And I had to switch gears: Baker’s Salt?!

For a starter …
On my days at home my wife hands all the cooking stuff over to me and I have to figure how to cook, grill, or bake. In my family weekend starts on Wednesday. My wife and I puzzle about the meals.
One of the no brainer recipes is pizza. I thought.

My wife was still collecting recipes. It basically meant, that I had to sift all kinds of papers. I already used the pizza dough recipe a few times, so I could tell the basic characteristics: white paper with a eightsome steps.

I browsed through the recipe folder: nothing.
I opened the Baking Bible: niente.
My kid was thinking all along the way.
“Let me have a look at the folder.”
Again: nope.
Then I remembered a book written by a national known baker. My kid had enough information and retrieved the book with half centimeter stack of recipes: bingo.

The next course is …
Next step to the dough was machine assembly. I put the machine on a comfortable place and picked the K-beater. Yep, that thing in the picture.  I still remember my first impression of this part. there is a K in it. When my wife mentioned the K-beater …

All parts were fixed. Now I needed the ingredients. My kid helped me measure the water and the flour:
“We need to use the patent flour”.
I agreed.
I was proud to remember to put the water first into the bowl. My wife had stressed that several times.

Then Baker’s Salt had to be weighted. A special spoon with a built in scale was used for this purpose.
“That is little.” I heard.
Before I could help: “It was 0.3 gram.”
I heard nothing more, so the accuracy problem was handled.

Then I wanted to add the Baker’s Salt to the water and the flour. But my kid was determined: it had to be added later on. OK. But we still needed the yeast.

My kid picked a small plastic cap out of the drawer.
“The salt and the yeast must not be mixed.”
The cap was placed in the spoon and the scale was reset.. Then the yeast in the cap was measured and added. Oil was also added.

Then it was time for me to start mixing. After a minute the salt was added. The K-beater had a heavy time, so I switched it after a small consult with my kid. Imagine a dancing kitchen machine. Not funny. So I used a new part. It looked like the left hand (?) of Captain Hook.

After 18 minutes I got the dough out of the bowl. My kid made a circle in the air with two hands:
“Mom always does this.”
“Can you show it again?”
The movement was a few times repeated. So I gently moved my thumbs over the ball of dough. My kid was not content. The ball was pcked out of my hands and placed on a kitchen cupboard. Then the ball was firmly cupped with two hands. The shape looked familiar to me. Nice touch.

I then let the dough swell.

For dessert …
“The pizza bottom is crispy.”, my wife remarked.
I bit and agreed.

Some people might have noticed that I did not use any computer related word. Except the bolded one. Let me continue.

My point is of course related to my profession. It was not about looking beyond the instructions neither about using knowledge in practice. This story is all about cooperation.