A testing exercise: ParkCalc

Early the other day, I noticed some of the tweets of testers I followed had a #parkcalc hashtag. At first, I couldn’t exactly get what they were saying, but I guessed that they must have been testing something collaboratively. At the time, I couldn’t stay online long enough to find out more about parkcalc. Luckily, when I got home that evening, I found a blog post on the topic. The author of the post suggested to click the link to the parking calculator before reading any further, and so I did.

The first thing I tried to do was to click the Calculate button without changing any of the default values. A page with error messages (e.g., Warning: mktime() expects parameter 4 to be long, string given in /home/grrorg5/public_html/Includes/Calculator.inc on line 72) got displayed before the page refreshed to show a more user-friendly error message.

The next thing I noticed was the layout seemed a bit off. I thought maybe it was just a Chrome thing. I tried loading the page and the pop-up calendar in Firefox, and I was able to confirm my hunch.

Next thing I did was to play around with the inputs for the entry date and time, and exit date and time. I tried the usual stuff — entering no values, entering invalid values, non-existent values (e.g., 13 for month, non-existent dates like Feb 29 on a non-leap year), cases wherein exit date/time came before entry date/time, etc. Most interesting finds I think were triggering the “Not Acceptable” page and managing to get an estimated cost of $3,946,162,582,627,248.00 for 1.64423440943E+14 Days, 15 Hours, 21.6 Minutes of “Short-Term Parking”.

I then checked out what the rest of the blog had to say as well as the recent tweets tagged with #parkcalc. And apparently, I’m not the only one who enjoyed tinkering with parkcalc. 🙂 Finding the bugs on my own is in itself a good exercise, but more than that, it was pretty interesting to read about how other testers attacked the app and to read about their finds even if they make mine look lame. For instance, someone used exponential notation for the inputs, someone managed to trigger a cost value of $5,124,095,576,028,720.00, and my fave so far is this link that I got from one of the tweets: http://is.gd/bknIb


[Edit] Additional links:

The triangle test

The Triangle Test is considered as a classic exercise for devising test cases. This was devised by Glenford Myers whose name should be vaguely familiar to the testers. His name pops up at least once in the tester training material, but he is more known for authoring “The Art of Software Testing.”

Anyway, in this exercise, you are supposed to test a very simple program.

The program reads three integer values from an input dialog. The three values represent the lengths of the sides of a triangle. The program displays a message that states whether the triangle is scalene (no equal sides), isosceles (two equal sides), or equilateral (three equal sides).

So try out listing your test cases. Give it about 30 minutes to an hour.

Continue reading

Wason’s four card task

One of the necessary traits in being a tester is being a critical thinker. This skill, when applied in testing, can surely help us in identifying the parts of the program that are potentially more buggy than the rest. It can also help us in tracing the causes behind the bugs we encounter. Now here’s a simple exercise on critical thinking:

Given four cards (roughly depicted below) — each having a letter on one side, and a number on the other, but you can only see one side of the card at a time… Which cards need to be turned over to verify or negate the claim that “If a card has a vowel on one side, then it has an even number on the other side.”

A D 4 7

Continue reading