Chalk symbols on pavement

Backtracking for testers

“I cannot reproduce it.”, I admitted to my scrum master. He replied with:
“You can do exploratory testing, but you have to note down the steps, which led to this situation.”

How did I get in this mess?
I sanitised this story BTW.

On my screen were some filters and buttons. It was not possible to use the action button any more. That was NOK. I made a partial screen shot and put it into my test charter. I would later come back to reproduce it.

Somewhat later I looked at the screen shot. I thought it would be easy to reproduce the situation. After three attempts I gave up. That was NOK.

My scrum master had a point though. I had lame excuses like no recording tools and extra bureaucratic steps. Back to The Bug. If I could find it.

A little bit of theory
Backtracking is a term I picked up during my study. It took me years to understand the principles.

It is basically solving a labyrinth: continuously pick a direction and walk, until a dead end is encountered. Then go back to the place where the last wrong decision was taken and take a new direction.
Rinse and repeat.

This tactic can be applied to find the toilet or to solve a puzzle.

Sorry for this theory interruption. I will now continue with my blog post.

A lot of practice
The first thing was to examine the screen shot again. I realised I was on the wrong screen. So I switched screens.

Then I rebuilt the situation. I added the filters with the same values. I pressed the action button. That went right. I kept my mouse on the button. It could be used again.

I used the other buttons on the screen. After a few presses I returned to the action button, which was still completely functional.

I did a reset and started to rebuild the situation. If I pressed the other buttons before the action button, then it might become insensitive. After adding the last filter I pressed on one of the other buttons and clicked on the action button. It was still functional. Business as usual.

It was time for my visual memory. The adding of the filters went from left to right. It felt great. Every time the set of available filters became smaller. It was like dealing cards. The stack became smaller and the cards were put from left to right.

I looked to the most left filter. It was a date filter. I already had filed some bug reports on that one. Wait a sec. This was my starting point for bugs. I might have set it to a wrong value and quickly checked the side effects.

The word quickly triggered my mind. I was so used to this filter, that all date filter related actions were absolutely normal for me. It became natural and therefore easy to forget. Because I moved my mouse so fast, the movement was not stored in my memory. That made sense to me.

So another attempt to reproduce my bug began. I set the date filter to a single bad number and added the other filters from left to right. And I pressed the action button. It worked. Then I tried to use it again, but that was not possible. Bug reproduced.

Now I wanted to reduce the number of steps. My assumption was that the invalid value in the date filter triggered the bug. Time for a short cut.

I reset the screen and only added the bad date filter. The second push on the action button was useless as expected. I was able to backtrack my steps and reduce them afterwards. That was OK.

At the end of business day my scrum master groaned, when I showed him the bug.
“What else did you find?”