Category Archives: Reconstruction

January Testing

Somehow I ended up with this test term or test type. Actually is a subset of boundary value analysis. But I got your attention.

That’s my right

It was the second day of the year 2018. I was about to place a new post on my web site. I just knew something was wrong.

I went to the web site lay out. It took me a few clicks to open the footer. Then I changed the text to
“2014 – 2018. Mindful Tester. All rights reserved.”

Now I could add my post.

It is my right
for which I fight

That’s my audit input

The same week.
For the audit I ran a query in the defect registration system. The number of items on the list was startling low: 0. My query was wrong. That bugged me. Last year it gave the right results. Actually a few weeks earlier.

I had a look to the query and noticed:
StartOfYear()
I don’t know all the commands, but I could make a good guess.
This year started at January 1st 2018. I was one year off.
The report was about 2017 and not about 2018.

A few hours later I had to go to my boss. He still used the same old query. It was easily explained.

It is not the query
I marry

A test idea approach

Let me generate some test ideas:

  • Is there a checklist for things to be updated in the new year?
  • If yes, so when is it updated?
  • Are queries based on fixed dates instead of relative dates?
  • Are there changes in laws which I have to pay attention to?

Still wondering about the pic with door?

Janua is the Latin word for door.

What about May 2018 testing? Excuse me GDPR testing.
Do you know what the effects of the General Data Protection Regulation are? An European customer has the right to be forgotten. But what about payments?

No notes

I had no notes
No music came into my mind. Silence.
It was my turn.

I had no notes.
No melody, no bass line, and even no chords came into my mind.
The people in the room expected me to do something.

I had no notes. After I had looked in my subdirectories: no database scripts. No relevant test charters. Actually I was supposed to test, not to make music. Mind you.

Getting back on track

It was time for my first flashback. A week earlier I had to test the same application. The import function had not been implemented yet. So I used some code of the unit tests.

I told myself to write a short note in the knowledge management system. This hunt for the code should not be repeated every test session.

The first step was to open my IDE or Integrated Development Environment. This tool helps me to program, build, and use version control among other things.

It was simple to find the right repository: it was still in view as I left it.

Another flashback came in. I could not use the code and one of the devops replied that I did not use the latest version.

So after the flashback I did a pull request and got the last version of the code.

My purpose was to find code to fill the database. I went to the unit test. A unit test has several phases. First I focused on the setup and breakdown. I could easily copy the code to make a table and the code to throw the table away. There were more commands for the breakdown than expected, so I had a small chat with one of the devops.

The second step was to find a way to fill the table. No other database commands could be found in the file. I saw a method to put a record into a table, clicked on it and saw the code of the wanted database stuff.

Then I reformatted the code. Now I could make, fill, and destroy the table at my own convenience.

During the test session I opened a test charter for notetaking.

End of the track

Did I put my steps in the knowledge management system?
Nope.

Last flashback. I promise.
I was talking to a team member. He explained that he never bothered to make notes for these cases. Things changed continuously. His Best Friend was the IDE.

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

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.

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