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.