To grow as a tester it’s important to exercise and develop your ability to question and investigate. I try to seize every chance I get to practice and reflect.

The other day I was assigned a task to test a server log reader. All the information available was a pink post-it with the text;

Idea: web interface to facilitate log file reading. PK

So, how do I test this? Of course I wanted to move the pink post-it down from my row “Ready for test” to the liberation of the row “Completed” in reasonable time. There were other post-its to attend to and also other project tugging my sleeve for attention.

My first step was obvious; get more information. From the initials on the post-it and my previous knowledge of the project I knew who was responsible for the idea and the implementation of the functionality. I was able to get an URL to where the functionality resided and some more information about the thought behind and inner workings of the function.

On to step number two then. Retrieve enough information about the function to create a model of it that allows me to spawn relevant test cases. What’s enough information is of course depending on your needs and it takes some experience to know when enough is enough. If I should’ve tried to get all information I would have gotten nowhere in my testing in reasonbale time. I figured the easisest way to gain information was to go to the URL, try out the functionality and ask any questions I had to the developer who was just a couple of feet away.

It turned out the functionality of the server log page was not really complicated and my quick assesment left me with the conclusion that the functionality to query log information based on date interval was most vulnerable. It was probably most heavy on logic.

After som discussing with the developer, PK, about how the base date, todays date, was calculated It became clear that he had included some logic to calculate date and not just used the basic libraries. PK, was not entirely sure of how the calculation was actually done. PK had not really tested the functionality.

So, determined to figure it out we headed for his pc to fiddle with the server clock and determine what the actual logic was and if my hunch that there was a bug in the handling was correct.

We started by resetting the year to 2009 and checked the server log page – nothing strange seemed to be going on – then we set it to an later date, still 2009 – everything seems fine – then a date early in 2010 – nothing strange… or!?

I suddenly realised that the data displayed on the page did not correspond to the interval set. It was supposed to display data from given date to a end date, but instead displayed nothing. Server date was set to 2010-01-01 and date interval was set to 2010-01-01 – 2010-12-31. We knew there was data in that interval in the database. It should be displayed based in the set interval.

Bug!!

It’s a real good feeling to find a bug this way and it really felt like out of a book on quick, exploratory testing where I got to use

• Exploration to create a model on the system
• Experience to limit test effort and indentify probable erronous areas
• Design test cases from knowledge of test techniques and imagination
• Attention to spot the bug

Testing at it’s best! And the creator of the bug actually hi-5:d me for finding it