All posts by Mindful tester

Cooperation

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.

Psychology, You've got a nerd in me

DUMB heuristic

During the Rapid Software Testing course James Bach advised to name things. If I cannot tell, what I am doing, my boss would think: “What the < beep > is he doing?”
So after the course I came up with the DUMB heuristic. This heuristic I use frequently during my testing.

Suppose my boss asks me how the testing goes. My answer could be: “I do uh my best.” A busy tester is always good, but if I am too busy things might go wrong. All my energy and brain power are focused on the work at hand. I forget to think. That’s DUMB.

When I figured out my heuristic, I had to find some smart explanation for this abbreviation. It became Do Uh My Best. Most heuristics are acronyms or lists of words. In turn every word is explained in detail. You know: turned upside down and shaken. But I just stick to the abbreviation.

Some readers have a good reason to ask. So hold on. The emphasis of the heuristic is on Uh. This is an alarm bell. Hesitation is a sign, that too much is going on in my head. I might forget to pay the deserved attention to the real problem.

This following discussion I had several times with my scrum master:
“I am writing test cases.”
“Why do you make test cases?
How often will the tests be executed? Who will maintain the test cases?”
So I was doing my best. And my scrum master got an Uh out of me.
He let me reflect on my work. What was I doing? And why?

Many test heuristics I know are acronyms. Some I do use. The S in SFDIPOT stands for Structure, how is the application under test built? So which components do I have to test? Etcetera.

If I apply this to DUMB then I would get things like: Do is the activity I am involved at that moment. It can be taking notes in my test charter or just thinking. Etc. Etc. The only thing I need on that moment is a short reminder to reflect on my work. DUMB. One syllable. Keep it sweet and short.

When do I use this heuristic? If there is a lot of work to do. When I have hours of straight testing ahead, I can go in my little cocoon and do something testy and something nice comes out. Tadah.

What about the focus and defocus stuff? Most of the time I use this when I got stuck. What can I do now? Let’s take a step back. Now I see the big picture. I figure out at a high level. Let me zoom in.

The point is, that doing my best is equal to doing stuff which is in front of my nose. I just pick it up and start running. Maybe I get it done today or this morning. Completely forgetting to ask for the reason. And that is DUMB. NOK?

When I was writing this blog, something hit me in the face. That was my imaginary hand palm. This so called heuristic is maybe already known under another name or in another way. Like a proverb.

And yes Madam within a few minutes the following proverbs came in my mind:
Eile mit Weile
Dépechez lentement
Easy does it

A day later followed by
Haastige spoed is zelden goed.

So why am I not using proverbs to keep my testing right? It is too long. Maybe a short heuristic could be useful.

“My scrum master would say something like Does it help?

This is really STUPID which stands for Some Thing …. I Do. UP are two words, so ….

Do I have to figure this out? WHY?”
“We Hear Yes.”

 

 

 

 

 

 

 

 

 

 

 

 

 

“GIRLS”
“Good In Real Life Software”

 

 

“GUYS”
“Graphic Userinterface You See”

 

 

“PLEASE”
“People Lik E A Software Errooor”

“CHEERS”
“Co Herent Entertaining Erroneous Random Synthesis”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

So you are a mindful reader. Congrats. Here is the bonus.

Why did I not throw this blog post in the waste bin? People already thought about it and distilled their experiences to proverbs.

It is about my thought process. I do not want to stop thinking. Once in a while I discover that other people already have figured it out. Sometimes I find something new. But apart of discovery of new thingies it is about thinking thingies through. Getting better to verbalise my thoughts and explain them to you the reader.

That was what I forget a while ago. Thanks for the attention.

Optional reading Also Known As scientific stuff for nerds like me
When I Do Uh My Best, System 1 is operating. More information about System 1 can be found in this blog post.

WYSIATE stands for What You See Is All There Is. If I am too busy, I forget to look for other relevant information as mentioned in Thinking Fast and Slow.

The Lindy effect is about using knowledge especially from books. Thinking Fast and Slow is quoted for years by some testers. If a book is relevant for 5 years, it will probably remain relevant for another 5 years.

Reconstruction

Training Train of Thoughts

This would be a quick test. The cells in a table had been minimised, so an empty cell had been displayed like a rectangle with the height of a few pixels. Now it had been fixed.

I used some scripts to install the latest version. I put some test data into it. Then I modified the view. The empty cells were as big as the filled ones. Case almost closed.

I quickly browsed through the description of the ticket. The impact of the change was minimal or nothing. The table was used to show information. There was no way to modify the contents of the cells, either filled or empty.

Then I noticed a comment of mine. It could also occur in another application. The same functionality was used by a different application, so the developers would have reused the code. This is an obvious assumption and it was more plausible by the use of TDD.

Some explanatory stuff ahead.
Test Driven Development or TDD is a continuous cycle of test, code and refactor. During one of our Cleancode sessions uncle Bob told about this approach:

  • Make a test, that fails.
  • Make code, that let this test succeed (and of course all other previous unit tests)
  • Improve or refactor the code.

An example of refactoring is to reduce the occurrences of the same piece of code. If it is in one place, the dev has to fix it in one place.

Refactoring can also be used in making automated tests or manual test cases. Knowledge can also be refactored. The knowledge management system is my best friend. Specific information is stored in one place accessible for everyone in my firm.

Where was I writing about?
O yeah, testing the absence of minimised cells in another application.
Right. So I installed the other application and put some test data into it. I tried to find some empty cells, but that was not possible.

Thought while blogging
I could modify the input file, but that was an invitation to errors.
Sorry no access.

Let me continue with my thoughts.
I looked at the table and thought about the installed database client. Good. I opened the application and connected with the right database and the right table. Then I emptied one cell. And the cell was shown minimised on screen. Hmmm. That was not right.

Because I sat in the same room as the devs, I knew who had worked on this ticket. I told him about my finding. This could easily be fixed.

Then I tried to find out, why it was only fixed in one application:
“I put it in the comment.”
He did not read the comment.
“Okay, what can I do to fix this? Put in the description?”
The dev said, he would definitely read it. Even it was an assumption from my side. He had no problems with it. OK fine with me.

After a couple of minutes the dev made eye contact with me. He told me it was solved. I installed the other application. Just fivesome clicks.

I started the application. Nothing happened. Another reinstall followed by unsuccessful start. I opened two logs to find some clue, but there was nothing special to be found. So I asked another dev. He listened to my story and had a quick look in the logs. Back at his workplace he discovered a process that was still operational despite the reinstall. So a script had to be fixed.

Then it was time to go home. You know family waiting for daddy to join dinner.

The next day I could finish my test. There is no such thing like a quick test.
This might lead to a heuristic.